It will be modular they said. It wont be invasive they said.
Whatever you think of it, systemd is doing the "ground-up rewrite" correctly. Normally, you get 90% of the features for 10% of the code in a rewrite, but then the last 10% of the features are the "plugging this thing into the ecosystem of other crufty things" features which bloat the codebase into something exactly as bad as the original.
The only successful way to do a rewrite is to scope your rewrite not to the size of one component, but rather to the size of the whole component ecosystem, such that you get to redefine all the crufty boundaries requiring convoluted code into clean and simple ones. This means you do have to rewrite more things, but each one can stay at that 10%-for-90% size, because none of the bad-API bloat has to come along.
systemd is consuming components of the Linux userland and leaving cleaner boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before.
People also forget to compare the functionality of the entire ecosystem of software—not just the big stuff everyone uses, but the niche stuff—before and after. Linux's original bazaar approach to system software meant that everything worked with whatever components it explicitly planned to work with, and nothing else. Do you know how many codebases contained some random subset of support for logging via STDOUT, logfiles (with or without rotation), syslog, rsyslog? That's what you get with a bazaar approach. systemd's "hub-and-spoke" cathedral approach means that everything just has to work with systemd, and then systemd can ensure that everything works with everything else.
> I really dislike the idea of having one project handling everything on a box
Which is crazy talk because that is one of the selling points to something like openbsd.
If linux tried to add pledge you'd have people coming out of the woodwork claiming that linux was breaking UNIX and requiring "linux specific" patches to every project.
Now SELinux isn't perfect by any meaning, but the key difference is that applications can be SELinux aware if they choose, but you can still have full protection without the application knowing that it exists.
I would much rather try to improve SELinux than try to make pledge work for precisely this reason.
Developer knows better what program should and should not do and is much more capable to set this kind of rules with pledge.
And that concept in turn means that a general can put a trusted system into hostile territory and trust it to not leak secrets.
And NSA still care for it. Around the time of the last kdbus dustup, someone from NSA voice a worry about how kdbus would compromise certain parts of SELinux.
Second, and much different from what SystemD just did, pledge does not affect any program that doesn't use pledge. From an external caller point of view, each changed user land program should act in the exact way that it did before the change.
A programmer can safely ignore pledge and nothing has changed for them. A user can safely ignore pledge as it shouldn't change their usage.
If Linux (I would guess more appropriately the maintainers of the GNU user land) tried this under those conditions, it would still be an internalized change that shouldn't affect anyone outside the project except in the positive as an exploit mitigator.
The bottom line is: OpenBSD is not requiring changes in other developer's programs or in user usage to continue to run in the same way they have run in the past.
Many of these tools have to run in other *nix. Tmux came out of the OpenBSD community. Why would they necessarily want to put in effort to make sure your house is built correctly?
Instead of moving everything to a new platform-specific init system like freebsd's rc system, I instead moved everything to runit. Runit can run ontop of an existing init system, so now I can have this code running ontop of bsd, upstart and systemd based systems without having to change a thing. It's really be a savior for me. I don't touch anything, I write scripts that are about the simplest thing I've ever seen and it just runs anywhere I toss it. I used to avoid writing init scripts like this like the plague but runit has made it quite enjoyable. I've even moved a lot of dev stuff where I had everything running in tmux to runit based control.
I've spent 20 years with this platform and seriously worry about it being as useful the next 20.
More importantly, I think that some of the systemd maintainers have a track record of not really knowing what they're doing, as exemplified by this tmux issue. I have serious worry about running their process as PID 1.
Other than that, totally positive effect: It deepened my interest in OS security and hastened my switch to OpenBSD which was probably happening anyway.
"Stability" in the sense that OpenBSD provides though is something that I valued more over time of running Arch and my experiences with other things on the side (mainly QNX).
The one that really annoyed me (and is still present) is when it replaced cryptsetup init scripts but did not implement support for root file-system key-files.
For release-upgrades this will result in broken, unbootable, systems - it isn't difficult to imagine how this causes swearing and bad feeling!
For new installs it means loss of required functionality, and lost time and productivity exploring and implementing work-arounds to counter the regression and return to the status quo.
The reason for the lack of key-file support in systemd-cryptsetup? The purist idealism that key-file support patches will only be accepted if they use the Linux kernel's key-ring API (rather than replicate the existing cryptsetup init script behaviour).
* connecting to different wireless networks that use wpa enterprise authentication (which I think some of the bsds only recently added support for)
* bringing up usb networking interfaces via cell phone tethering on demand
* managing multiple different vpn clients and profiles from a single interface
Or do you mean things like
* Bringing up a networking interface with a static ip address
Because I use network manager for the former on laptops, and remove it on servers that only need the latter.
As with many things, yes, it took OpenBSD and FreeBSD longer to get that functionality. The tradeoff is that they delivered a well thought out, consistent, and well-engineered solution, rather than a poorly thought out mess of CADT-driven bloat.
With systemd it's not so simple.
iface wlan0 inet dhcp
wpa-ssid redacted
wpa-psk "redacted"
It actually works rather well but it doesn't have every feature that NetworkManager does.
For non-wifi use cases you probably don't need anything at all (maybe dhcdcd).