Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete.
They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modularized programs. None of the collateral damage is in subsystems related to init. Instead, it is subsystems that worked well, but that were easy to delete.
One the other side of the coin, look at all the effort people are spending to rip systemd out. Multiple Linux distributions exist solely to contain the damage it’s doing.
It’s unclear if gnome will even survive the war if systemd loses.
It’s also wasting the time of end users, so the damage can greatly exceed the total resources put into building Linux distributions.
A few days ago, I ran an “apt-get fullupgade” on my headless Raspberry Pi, and some systemd subsystem wedged during the upgrade. Now networking is broken. I want to use this raspberry pi in an embedded I2C application that run for last decades. So, I need to find an operating system that:
(a) doesn’t use systemd - fool me once, shame on you, fool me twice, well this is well past the second time.
(b) runs on raspberry pi
(c) has userspace tools to work with the i2c bus on the pi
(d) has a working upgrade path.
This is a huge pain, and it’s all to delete one software package that I don’t even care about, and that is irrelevant to the use case for this machine.
You might be able to put something together using Raspup or Ultibo. IIRC, both should be able to run on all Pi models. Both are pretty lightweight, simple, and they could be a good base for building what you are looking for.
Raspup is a Puppy Linux for Raspberry Pi. It uses Raspbian Buster as base. I haven't messed with I2C on my Pi, but if there are any userspace tools in Raspbian Buster's repo then you can use them on Raspup. The working upgrade path is the biggest annoyance here. Package management on Puppy in general is a pain for anything but simple install and removal. It seems like the Puppy community either doesn't upgrade or upgrades by installing the next Puppy version (which is usually fast).
Ultibo is not Linux but a Free Pascal kernel that doesn't implement a complete OS. It is for using a Raspberry Pi board more like a microcontroller, but you can use it as a base for anything. For example, someone made a Z80 CP/M emulator that runs pretty fast. Besides the Free Pascal library, the tools here are pretty much what you write. This is probably the simplest option for a Pi that may be alright if you don't plan on using the full functionality of a Linux machine or you want to avoid the Linux kernel scheduler.
Raspberry Pi hardware is not really suited for "decades" reliability. If you want to use it for an application like this, you need to arrange to recover/replace the devices in the field and plan how to upgrade out of production models in a controlled way. (And you need to rehearse/test doing it too so it works when you need to do it, especially as things change between RPi hardware generations)
Check out buildroot linux. I have had very good luck with this distro for professional embedded applications. It doesn't have the same annoyances that other common embedded linux distros have. It is easy to hack on, easy to customize, and if you must, it is easy to understand.
> some systemd subsystem wedged during the upgrade. Now networking is broken.
All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook.) Become a curmudgeon, and idolize the past, at your own peril.
I recommend, instead, to live in the present, to use currently normal software, and to fix every problem as it appears. Ceasing to upgrade permanently (possibly by moving to an obviously dead-end fork) is never a sensible option in the long run.
Don't bring the Unix-Haters Handbook into this. A fun, self-consciously curmudgeonly romp like that has about as much in common with the systemd debate as P.J. O'Rourke does with Bill O'Reilly.
I think the point of the parent was that systemd will be much harder to replace than other init mechanisms once something better comes along, because it grows into every part of a Linux setup. And if that's true, then systemd actually hinders progress and innovation, because the cost of replacement will be too high.
They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modularized programs. None of the collateral damage is in subsystems related to init. Instead, it is subsystems that worked well, but that were easy to delete.
One the other side of the coin, look at all the effort people are spending to rip systemd out. Multiple Linux distributions exist solely to contain the damage it’s doing.
It’s unclear if gnome will even survive the war if systemd loses.
It’s also wasting the time of end users, so the damage can greatly exceed the total resources put into building Linux distributions.
A few days ago, I ran an “apt-get fullupgade” on my headless Raspberry Pi, and some systemd subsystem wedged during the upgrade. Now networking is broken. I want to use this raspberry pi in an embedded I2C application that run for last decades. So, I need to find an operating system that:
(a) doesn’t use systemd - fool me once, shame on you, fool me twice, well this is well past the second time.
(b) runs on raspberry pi
(c) has userspace tools to work with the i2c bus on the pi
(d) has a working upgrade path.
This is a huge pain, and it’s all to delete one software package that I don’t even care about, and that is irrelevant to the use case for this machine.
/rant