A used Thinkpad can be had for under $100, and will include a screen and keyboard. If you toss Ubuntu on that and preinstall Python/Scratch, you'll probably have a happy camper.
But if you insist on going down this odd almost purist open source road, Xbuntu is probably better for an old device since XFCE looks better than both Gnome and KDE, while using less resources. Many youngsters give up on Linux completely when someone parrots this "give them a 100 dollar laptop and install Ubuntu" crap
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.
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
When I said old I meant old in apple fanboy terms, like, four years old but thanks for this caveat, you're right that if you go too far back you can't run macOS
(And honestly you probably will want to get a few packages etc so "no internet is a feature" is a little simplistic but I like the spirit of the thinking)
I linked to some ads stuff, it's my understanding Apple does telemetry more than *nix, but actually doesn't do marketing tracking like Ubuntu has done.
That is correct, Apple products check in with the mothership at each app launch and other important events. They have the ability to prevent applications from launching on a device you own in a targeted way.
There was a SNAFU a few years back when their fast-fail code stopped working after an update and everyone in a region was unable to use their devices.
Yeah it is, they are more big brother than Microsoft is. What's even worse, it happened in 2016 or 2017 (from memory) and had made quite a big splash in IT. They basically had an issue with a load balancer or manifest server not being properly updated, and it caused their network fast fail code to not bug out correctly which hung all launched applications in that particular region.
If you go searching for it now, they've completely wiped it from the web. Went looking for the article and its gone now.
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).
Comments
A used Thinkpad can be had for under $100, and will include a screen and keyboard. If you toss Ubuntu on that and preinstall Python/Scratch, you'll probably have a happy camper.
I have concerns about the tracking present in Ubuntu, especially in a device for a minor:
https://en.wikipedia.org/wiki/Ubuntu#System_terminal_adverti...
But if you insist on going down this odd almost purist open source road, Xbuntu is probably better for an old device since XFCE looks better than both Gnome and KDE, while using less resources. Many youngsters give up on Linux completely when someone parrots this "give them a 100 dollar laptop and install Ubuntu" crap
https://en.wikipedia.org/wiki/Xubuntu#Xubuntu_11.10
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
When I said old I meant old in apple fanboy terms, like, four years old but thanks for this caveat, you're right that if you go too far back you can't run macOS
(And honestly you probably will want to get a few packages etc so "no internet is a feature" is a little simplistic but I like the spirit of the thinking)
Wouldn't an Ubuntu laptop have less tracking than a Macbook?
I linked to some ads stuff, it's my understanding Apple does telemetry more than *nix, but actually doesn't do marketing tracking like Ubuntu has done.
That is correct, Apple products check in with the mothership at each app launch and other important events. They have the ability to prevent applications from launching on a device you own in a targeted way.
There was a SNAFU a few years back when their fast-fail code stopped working after an update and everyone in a region was unable to use their devices.
That's pretty horrifying, it's a good thing Canonical isn't as integral to the Linux desktop as Apple is to the MacOS one...
Yeah it is, they are more big brother than Microsoft is. What's even worse, it happened in 2016 or 2017 (from memory) and had made quite a big splash in IT. They basically had an issue with a load balancer or manifest server not being properly updated, and it caused their network fast fail code to not bug out correctly which hung all launched applications in that particular region.
If you go searching for it now, they've completely wiped it from the web. Went looking for the article and its gone now.
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).
Can confirm. I bought a Lenovo x1 on Craigslist for 200. I put Ubuntu on it and ran it as my primary work computer for a year. That’s the way I’d go.