I think the focus must be on an image-based design rather than a package-based one. For robustness and security it is essential to operate with reproducible, immutable images that describe the OS or large parts of it in full, rather than operating always with fine-grained RPM/dpkg style packages. That’s not to say that packages are not relevant (I actually think they matter a lot!), but I think they should be less of a tool for deploying code but more one of building the objects to deploy.
How is this different from any linux distro with docker installed on it?
Its the opposite. What he is talking about is images based OS, like Ubuntu Touch is doing it, also the Steam Deck and stuff like CoreOS. I think Android and ChromeOS are also doing that. Its not a bad idea in general.
Removed by mod
I think Poettering’s assumption here, which I agree with, is that it’s difficult to produce software without bugs, and it’s even difficult to patch those bugs without ever introducing new bugs
But, let’s pretend that we’ve accomplished this and never have to fix any bugs: we’ll still have to update firmware and other software components when a new CPU or other device needs to be supported
Although, admittedly, a user might not decide to install a hardware-enablement update if they know in-advance that they’ll never upgrade their hardware or plug in a new device
that it’s difficult to produce software without bugs
When you build software like Poettering build software, it is. Large, monolithic, kitchen-sink systems are going to be bug-ridden. It’s much easier to verify small, independent, focused, Unix-philosophy software. This is the singular reason why people object to systemd.
I like systemd. It made things easy for me… until it didn’t, and until parts started breaking. I migrated to dinit (and back to all of the independent components systemd has absorbed over time), and there are gaps. Some things are harder; the init part of systemd was nice, if only it could be isolated… but it can’t, and this is why Poettering thinks bug-free systems are hard. Because he builds giant monolithic edifaces and (for all his talent) doesn’t know how to isolate.
He’s a good programmer, but a lousy architect.
the init part of systemd was nice, if only it could be isolated… but it can’t
Which other “parts” of systemd are needed if you only needed the systemd init “part”?
journald. cron. systemd core does these, whether or not you succeed in hacking around them and run one of the standard daemons independently.
The systemd ecosystem is increasingly fragile unless you use all of the parts. resolved is becoming increasingly necessary for DNS lookup stability on systemd distros on things like laptops. homed is being pushed pretty hard; arch boot logs complain about not having homed if it isn’t being used, although it still works.
Leonard has argued that, just because systemd isn’t one giant binary, it isn’t monolithic. However, the parts of the systemd ecosystem that take over logging, cron, daemon control, logind, and so on are tightly coupled. The elogind effort spends most of its effort decoupling elogind from systemd (c.f. seatd). I’ve read (but haven’t tried) that you can’t replace logind with something else on systemd installs. You can run it alongside, but removing systemd-logind breaks login. I suspect thats less systemd and more a distribution thing, but the tendancy to tightly couple these packages is concerning. It’s something which doesn’t tend to happen in Arch for other systems… there are usually alternatives providing a capability to choose from, but the systemd components are so tightly coupled that, if you want to use, say, syslog-ng, you basically have to switch distributions.
built from traditional distribution packages, but deployed via images.
Hell no. https://nixos.org and https://guix.gnu.org ftw
i don’t see why the concept of building immutable images using existing distro packages and tools shouldn’t apply equally well to nixos and guix as it does to deb and rpm distros.
Lennart’s influence over Linux distros are why I’ve been moving more to the *BSD camp.
Who?
The systemd and pulseaudio guy.
The guy that made the terrible audio stack? Got it.
Ah yes, the guy who funfamentally objects to the unix philosophy and is doing everything to make GNU/Linux the exact opposite of it… Yeah, no. Not interested.
in what way(s) specifically do you think he objects to the unix philosophy?
have you read his rebuttal to that claim (point #10 here)?
(disclaimer: i am using systemd on some, but not all, of my gnu/linux systems today… and after years of finding it irritating I am actually coming around to appreciate it.)
