6 ms·
Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init
by hiddennetwork 10y ago
Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting to take effect in IT. Unix-like operating systems are supposed to be non-complex. My example above, of OpenBSD, is true. Maintaining OpenBSD systems is trivial compared to similar Linux systems, and I maintain both. Sadly, I admin a series of CentOS PBX servers that are an absolute pain. A friend runs his on FreeBSD and has less than half the pain points I do. And we're running the same PBX software.
I believe in lowest common denominator everytime. Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs. You will not see this in OpenBSD, for example. The BSD folk reverse engineer the drivers and write their own free drivers -- and they are usually far and away better afterwards.
Take the wireless chipset drivers for Ralink. The BSD guys took a 30,000 line driver and rewrote the entire thing in less than 1/3 of the code. That's just the whole attitude between Linux and BSD. Linux is a series of cobbled-together hacks on top of an ever-growing, ever-complex kernel (that really needs legacy crap removed). BSD, on the other hand, is engineered as a single OS with a small collection of pruned base programs. Big difference. If you've ever used BSD, you will know the joy of /etc/rc.conf vs the nightmare of Linux config files that live in myriad locations depending on the distro.
- chris_wot 10y agoI'm afraid you still haven't answered my question. Aside from binary logs, what binary blobs are you referring to in systemd?
- stephenr 10y agoI guess he means systemd being a compiled binary so how exactly a service file is processed is less clear as say with a sysvinit script
- chris_wot 10y agoI can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-init script. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems https://fedoraproject.org/wiki/How_to_debug_Systemd_problems It's curious that he says "Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs." That's not exactly true now, is it? He seems to be implying that there are closed source binaries in the Linux kernel...
- chris_wot 10y agoFunny how nobody can answer this question!
- jack9 10y agoYou already answered the question and acted like it wasn't an answer: "Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities," - yeah, those binary blobs (inherently unstable blobs of logic). http://linoxide.com/linux-how-to/linux-systemd/ http://linoxide.com/linux-how-to/linux-systemd/
- chris_wot 10y agoThere isn't anything "inherently unstable" about them! The only true competitor to systemd is s6, and you should see the amount of "binary" he has had to develop to get his service manager to run outside of PID 1! However... it's all a moot point, because that isn't the definition of a "binary blob". In the context of Linux, or "free and open-source software, a binary blob is a closed-source binary-only piece of software without publicly available source code." [1] 1. https://en.wikipedia.org/wiki/Binary_blob https://en.wikipedia.org/wiki/Binary_blob
- chronid 10y agoYou seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system. Those commands will not help you if you have to find a bug into systemd code to find something like a constant on the maximum size of a core dump and work around it. Then open a bug and hope it does not get ignored for ~3 years. But who needs core dumps anyway, right?