systemd is such complete garbage that I immediately write off any distros that run on it as unusable. For all the fail of SysV init, at least it sticks to its own job and little else.
SysV init was so full of fail (race conditions, no dependency management, slow as hell, stupid metaphors -- run levels? really?) that people wrote Systemd. Anyone can expand on systemd to have it do stupid shit it shouldn't. But you can do that with any technology that is composable. It does not mean that the core of systemd isn't anything short of incredibly useful.
And yet Linux distros like Ubuntu around 9.0 were much more stable than these days.
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.
On current Ubuntu releases gdm (login screen) now runs on VT1, which is what you are trying to switch to with Ctrl-Alt-F1. Your current session is likely on VT2 (Ctrl-Alt-F2)
You could try Ctrl-Alt-F3, F4, etc to get a login terminal.
I was really disappointed by this myself. Netplan seems slick, but I don’t want yet another new, distributor-specific way to manage this stuff. Red Hat seems to be quite good at wrangling such tooling, but I don’t know of a solution by them/others as slick as the netplan config.
Ctrl+Alt+F1 switching is not possible unless you expose virtual terminals on the other virtual displays. Arch Linux at least does this by default, except that your first X session will start on the same display as your virtual terminal (which is good for security relative to the earlier practice of moving Xorg to VT7 while leaving an active shell on VT1).
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 my main Linux box won't continue booting to the graphical login manager unless I hit some random keys (any will do) on the keyboard. I guess there is some service asking interactively for something, but I can't see any prompt (maybe swallowed by systemd, who knows).
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...
I hated working with SysvInit but to be fair Debian's version of SysvInit had dependency support and parallelism and was therefore reasonably fast. The only real issue was how hard it was to write a correct script resulting in almost all of them having bugs in edge cases.
Not all SysvInit implementations were equal, which was an issue in itself.
I take it you don't work with linux professionally? I'd enjoy being a fly on the wall during the meeting where you convince your boss to run the company critical infrastructure on void linux.
Kinda. There are increasing numbers of hard dependencies on systemd components. And systemd components pull in systemd itself more often than not. So while in theory it’s optional, in practice it seems decreasingly so.
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.
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.
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 don’t follow this logic. I’ve written unit files and they can be very easy, but when you start looking at something like postgres on Debian and want to move it to another directory, then suddenly you’ll see all the hacks that have been employed to make it work.
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.
I never had an issue with sysv, but there are several modern init systems such as runit and openrc that don't require selling your soul. Systemd extends tentacles throughout a system in ways that make me question how anyone ever thought it was a good idea.
MX Linux does a nice job with SysV, and Artix uses OpenRC. I've tried both and liked them, though Artix broke pretty hard once during an upgrade. But yeah, it was hard to find a Linux distro that runs well without systemd.
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).
For anyone wondering, when you install Gentoo, you untar a stage3.tar.gz into a / that you chrooted into. That tar file contains a precompiled environment and toolchain. From there most things get compiled.
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).
If you only care about how fast the system will be, you only need to compile the compiler twice, not thrice. Probably that is his problem and why it's taken him 7 years so far. He should have compiled the compiler thrice...
I wrote scripts that build from scratch to my custom desktop configuration in < 8 hours using Packer on a single i7. I'm also toying with the idea of a buildserver that creates precompiled binaries :)
10-Year Gentoo veteran here. Every time I move away from Gentoo I come back purely because I have some headache caused by systemd or pulseaudio (which seems to depend on / be depended on by systemd). If they didn't get in the way I wouldn't care, because not needing to compile packages would be nice.
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 :(
12 years here. I finally let pulse back on my system a year or two ago when after enough upgrades (notably Firefox) my sound config went from perfectly fine for years to unreliable. At least pulse is better now. And more stable than the version I have to use on work machines (ubuntu). No dependencies on systemd required, though, that project will never be installed. OpenRC is great, and it's simple enough that it doesn't need any team of paid devs figuring out how to cram more features into it.
There is apulse this which I used successfully in the past, it’s included in the portage tree. Since I happen to like systemd itself, I don’t have much of an issue with that. I used to avoid pulseaudio and networkmanager, but on my latest installation on a laptop I just included them and they are working fine for now. We’ll see how long they survive this time, esp NetworkManager is starting to bother me again ;)
I used to have a poetteringware mask, but I had to let pulseaudio slide (but without udev and systemd (eudev works well)) because I couldn't find support for my non-standard setup anywhere for alsa.
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 surprised to hear of problems with Firefox and ALSA. On all my Gentoo machines I simple compile Firefox with USE="-pulseaudio" which sets --enable-alsa within Firefox's build. Still working fine up to and including Firefox 66 directly to ALSA.
