Comment by geocar
3 months ago
> systemd already has encrypted boot support.
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.
Hear hear!, It's like flogging packages and frameworks at a problem without ever considering if it was easier/more efficient to roll your own.
I hope this lesson has become clear more clear with the recent deepseek upset. That proved that simply throwing more money and hard to wear at a problem doesn't guarantee a better outcome, innovation seems to favor the opposite. As as Germans say the German saying goes: "
NixOS checks/enforces its own reproducibility via systemd in various ways. It seems unlikely to me that replacing something battle-tested with a bunch of self-rolled brittle scripts will make it more reliable.
This is somewhat ironic, given that it was systemd that replaced the battle-tested systems that came before it, and variants of your comment were used to argue against it.
Sysvinit was brittle as hell. It was bad at preventing races (hence no parallelization), in part because it couldn't give guarantees on which services had started when, and if they started at all.
At this point Systemd its unit files are in a really nice place, to the point where Systemd can often guarantee correctness now.
1 reply →
"Battle-tested systems"? Are you talking about those bash scripts that weren't reliable? lmaoo