With 16.04 I get core lockups (Intel microcode) and cannot switch out of X with Ctrl-Alt-F1.
NetworkManager no longer connects the mobile surfstick, so I do it manually now with pppd.
I can't claim that I had a specific problem with systemd, but I never had an issue with SysVinit either.
The overall trend however is that Linux distros accumulate crapware by RedHat's NIH developers. I'm not surprised that NetworkManager is also by RedHat.
Apparently not -- netplan is ubuntu originated. They don't do themselves any favours.
For networking I suggest looking at ConnMan. It has a somewhat unintuitive UI, but it is lightweight, fast, and I have yet to find a wireless network that it will not let me connect to.
You can't switch users within x either, it's been broken since at least 14.04 (according to an old close bug report I found). It works the first time but on subsequent tries you just get the lock screen.
The bug report was closed after several years of nothing.
Since some time switching VTs resets all hardware accelerated applications (i.e. crashes them).
Since some time unlocking the graphical session is randomly broken and requires loginctl session-unlock from another VT (which then promptly triggers bug 2).
These things keep coming and going... it's not even Linux-specific. Stuff just breaks all the time and you shrug and move along, hoping that maybe someday it's fixed. For most of these I wouldn't even know who should receive a bug report. Maybe it's the graphical login, maybe the compositor, maybe mesa, maybe a kernel driver, maybe systemd, maybe maybe...
You could try Ctrl-Alt-F3, F4, etc to get a login terminal.
Not all SysvInit implementations were equal, which was an issue in itself.
https://devuan.org/os/init-freedom/
The runit init Void Linux is quite slick. I also installed an Artix runit image in a virtual machine that works nicely. We are using it as a supervisor on openSuSE piggybacked onto systemd to run critical infrastructure. It works flawlessly, it's also included in busybox but almost always never enabled.
I tend to avoid systemd so I’ve taken to running Debian machines without it. But if you’re doing something like ephemeral cloud installations then it’s not “worth” the overhead of swapping out your init (and having the consequential reboot and potential instability) so the default is a required target for automation anyway. And if you’ve already set a target then why have another one?
This is why defaults can be harmful if widely deployed and considered non-optional (as systemd is on Debian). They become enforced by convention because they are the only valid common target without wrangling.
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.I'm still not sure about the complete garbage thing but sysV init definitely wasn't good enough.
busybox init if all you want are some ttys and fs and openRC are probably what you want.
Stuff like running /bin/true for the non-versioned unit, so that it can coerce the activation to take it sequentially when it actually executes the versioned unit.
There’s also the fact that “no boot is exactly the same” which means reproducing a race condition at boot is basically impossible if it’s anything other than the most trivial.
And anyway. The truth here is that you haven’t actually removed the shell script. You’ve just added boilerplate C-code around it.
If your biggest complaint is/was the composability of shell scripts for the common use-case then this is very much a solved problem in the BSDs (where an init script is usually around 5 lines).
EDIT: please come back with some concrete examples of why I'm wrong. because not only would I like to resolve my own issues; it is also the case that you shouldn't be using downvotes as a "I love systemd so I disagree" button.
It's never been a better time to go BSD instead.
It’s a great distro, gives you loads of choice (even lets you go with systemd) and the developers actually care about open source and the act of giving a shit (unlike what I see from the systemd bug tracker).
Still compiling it, but I'll let you know how it goes
For example "emerge x11-base/xorg-x11" would install X and related utilities, but you wouldn't do that. X is a dependency, what you really want is whatever desktop environment you like. So "emerge qtile" and the rest is handled. The compilation time thing isn't a big issue on any reasonable solid state hardware, and there are precompiled packages available for large popular projects (like office suites).
Install instructions: https://wiki.gentoo.org/wiki/Handbook:AMD64#
Recently I purchased some bluetooth headphones, they don't work well without PulseAudio and so far I haven't gotten anything but raw audio files to playback directly.
Same goes for Firefox. I think there's an intermediate plugin to play directly to ALSA, but for now I'm just playing spotify||netflix via chrome.
Point is, it's slowly becoming harder to avoid Systemd and PulseAudio. Because all the major distros use them, the support, development and documentation for !systemd has died off radically :(
Your point is super valid and it makes me sad, I donate/try to support as much as I can but the amount of developers that are apatheic to niche cases is increasing day by day.
I'm still sad that such a good system fell in the hands of Oracle :(