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 m

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).