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.
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.
the gulf between what should be and what is can be quite large. can you name any software you use which you think is likely to be bug free and/or unlikely to need any updates in the next few years?
but anyway, the discussion was about operating systems
what makes you pick this, of all programs? just because it hasn’t had a release in four years?
Skimming the commit log one can see it certainly has had some bugs, and given that it is written in C it is reasonable to assume it has had some security-relevant ones. (eg, i’m not certain but this commit from a few months prior to the latest release looks like it could be fixing an actually exploitable bug?)
Currently there are 13 commits newer than the latest release. From a quick glance none appear to be obviously fixing security bugs (i guess there will be a new release when they next find some) but there are actually as-yet unreleased commits there fixing bugs… such as this one, made two days after the last release, which fixes searching being left-anchored.
Even for the most minimal oneliner you’ll have to depend on complex library code under the hood which you’ll have to keep up to date as part of the OS. And/or depend on the compiler itself to not introduce bugs into the resulting binary you are distributing.
Either that or you write your software in pure assembler (which will end up exposing a lot of internal complexity anyway, resulting in asm files that are far from “minimal”).
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
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.
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.
deleted by creator
lmao, [citation needed] - what in the desktop OS space is sufficiently minimal to be “completely bug free”?
Removed by mod
the gulf between what should be and what is can be quite large. can you name any software you use which you think is likely to be bug free and/or unlikely to need any updates in the next few years?
but anyway, the discussion was about operating systems
Removed by mod
what makes you pick this, of all programs? just because it hasn’t had a release in four years?
Skimming the commit log one can see it certainly has had some bugs, and given that it is written in C it is reasonable to assume it has had some security-relevant ones. (eg, i’m not certain but this commit from a few months prior to the latest release looks like it could be fixing an actually exploitable bug?)
Currently there are 13 commits newer than the latest release. From a quick glance none appear to be obviously fixing security bugs (i guess there will be a new release when they next find some) but there are actually as-yet unreleased commits there fixing bugs… such as this one, made two days after the last release, which fixes searching being left-anchored.
Removed by mod
Please show me an example of a perfect software which does not have a single bug.
Even for the most minimal oneliner you’ll have to depend on complex library code under the hood which you’ll have to keep up to date as part of the OS. And/or depend on the compiler itself to not introduce bugs into the resulting binary you are distributing.
Either that or you write your software in pure assembler (which will end up exposing a lot of internal complexity anyway, resulting in asm files that are far from “minimal”).
These are just some known vulnerabilities in libc (we don’t know how many “unknown” ones there might be, or if new fixes will introduce new problems): https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html