I've spent 20 years with this platform and seriously worry about it being as useful the next 20.
I've spent 20 years with this platform and seriously worry about it being as useful the next 20.
* 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's a bit clunky if I need to take a laptop around to different wifi networks, but I don't do that very much.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).
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).