It not having systemd seems like a bit of a distraction from all of the other stuff that has gone into it.
For some reason I can't directly reply to transpute's comment, but it's relevant to this thread so here goes:
> Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground [...].
Desolder the EEPROM and read the secrets - the loophole is open wide without a TPM/SEP.
The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors, while desoldering and reading the flash is trivial for a hobbyist with cheap tools and some patience.
However this is still an enormous step forward. All of the recent attacks on secure boot chains on Windows[1] and Linux[2] are due to usage of partially-unencrypted core system components in a complex boot chain. Sixos takes the correct approach - minimise the attack surface. All it takes is to stop rejecting the "voodoo" and take what the hardware already offers.
On the contrary. TPM _is_ an attack in itself. Its result is that control lies not with you as the user but with whoever provided you with the TPM - relative to all software which uses the TPM. And if you can't avoid that kind of software, then the HW providers and the software providers have conspired against you to control your own hardware.
NixOS' module system works, but I don't think there's anybody who thinks it's particularly pretty or generalisable. As soon as you want to run one service twice with slightly varying config you're SOL ...
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
It has all of those words next to a bullet point, but the implementation is quite different, and I (like the presenter and probably many many others who are clearly not you) have more confidence in a simple fuse than with systemd[1].
[1]: https://app.opencve.io/cve/?vendor=systemd_project&product=s...
> At that point, any rational person would question the reasons for doing so.
That is excellent advice. The presenter has done something you clearly cannot. You should be rational, follow your own advice, and try to figure out what those reasons are (hint: some of them are actually in the video). That might take a few hours to a few weeks of reading depending on your own experiences, and that's just how life is sometimes.
> Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
When I have a new gadget I want to produce, I'm responsible for all of the code in it, so productivity, reliability, performance, and size are important to me whether I have written the code or I have merely used it in my product. I do not understand the way these things are important to the systemd people (or even if they are important at all), so for me, systemd is off-the-table to begin with.
Or to put it another way: I never needed a car in the first place, because I'm making boats, and I'm not starting with a car just because I like the people who made the engine. Ignoring "solved problems" can just make everything more expensive, and maybe I only know that because I've seen enough people make that mistake, but sometimes this is true.
Keeping an open mind means allowing yourself to be convinced too.
At this point Systemd its unit files are in a really nice place, to the point where Systemd can often guarantee correctness now.
This is just the same old "systemd sucks, let's rip it out" and then later reinvent everything it provides, because it was needed. Also commonly known as reinventing the wheel, the curse of any IT project.
Continuing with the vehicle metaphors, the wheel has been reinvented many times for different purposes. The wheel on a tractor is different from that of a Formula One car.