What can I buy instead of an RPi for my nephew to learn to program on?

> A third option is to get them a very old Macbook -- they used to call MacOS "shiny BSD" for a reason, and if all you need is scratch and python, you can plug in some Ethernet and use brew to get whatever you want.

I would advise against this, because old Mac hardware does not support modern macOS and I'm about 99.9% certain brew will not run on anything other than the latest macOS (by their design). You may have some success just using their Formulae to compile everything you want from source, but at that point, I think things have become "a project" versus the shiny BSD approach

An alternative perspective is that having an old Mac is fine minus the "plug in some Ethernet," since the Internet is the biggest attack vector in that discussion

Wouldn't an Ubuntu laptop have less tracking than a Macbook?

Also set him up with a pihole on a rpi zero w and start blacklisting some tracking networks.

It is possible to remove parts of the system, but you have to know Linux fairly well to do it, its time consuming trial and error.

I did it, but it was by no means a simple task, and there are still some areas I had trouble nailing down where I had to remove the binary completely (the tracker-3-* applications). You can remove snap without much trouble. There's a unique machine-id generated that should be changed to something less unique. You should prevent snapd from being reinstalled, they only provide snapd packages in their repo for certain things like Chrome/Firefox.

Canonical have designed it so it is not easy, and their team is actively trying to monetize this, and I hope eventually they discover and correct course since much of their customer base moved to Linux to get away from Windows for the same privacy reasons they are doing. They are having trouble monetizing their business model which is why its largely gone downhill since 18.04. I can't recommend any newer LTS for use with production.

I ended up building my own OS using LFS given the high number of shenanigans Canonical has done, and the untrustworthiness of any company in the monetization stage.

You should be able to disable a service, and have it never load with a single command. Imagine my surprise when systemd masked services continued to load.

There are at least 3-4 different areas of the system that will allow loading despite the user making choices to disable or stop certain services. Dbus is the primary offender, it loads on-demand with no centralized logging.

/usr/libexec is where they store most of their tooling. Gnome has modes to load the required extensions (json files), Gnome has many different places that it looks for autostart .desktop applications, if you set the debug in the gnome config file it will list where it looks in the logs. The greeter is its own session, separate from the user sessions. Disabling gnome-settings-daemon, abreviated gsd-* will cause the fail whale, you generally can't disable all of those, you can remove it as a required component in one of the gnome features but it will still fail if certain parts are broken. That's hard-coded into gnome.

There is an entire section under the dbus-1 directory, which sets up dbus activation which is their term for, 'autostart application as root without prompt', and those processes are triggered by dbus-launch-helper (a setgid/setuid application). Applications launched in this way are also not readily displayed, they often appear under the systemd user, though they can be downgraded to whichever user as the launcher has root perms.

You will have trouble masking user services. System services mask correctly, user services run as dbus, gdm, or other non-login users like systemd don't mask correctly (and continue to load).

/etc/xdg is one of those places gnome looks for config files, there are various other areas under /usr.

GDM is responsible for launching everything (and setting dbg), you can start or stop it for testing from a TTY and look at pstree and ps.

If you are going for a SoC like a RPI, there can be issues with getting it running initially. You'll need to put some guided effort into getting them started. Odroid is better hardware IMO because of the realtime clock (RPI doesn't have a realtime clock, occasionally runs into race issues with ntp after a boot).

well, from a pre-internet 11year old with a heavy interest in doing library intensive searches for geeky stuff, depends on how motivated & how difficult an internet search is for related platform, python & scratch.

IMHO: think HN can provide reasonable help / direction / pointers.

For my kids setup I actually went with a Pi Zero 3 (It's a RPi but without the USB or Ethernet ports. It's hot-glued to the back of a monitor. She's 7 and all I need is for it to run a python program that she practices typing on. They are in much better supply than the full 4GB RPi-v4 boards. You need to break out the USB with a powered hub and any connection must be by WiFi/Bluetooth, so it's harder to set up (although I did it by using an "overlay" to make the USB be a temporary TCP port to get set up).