5 ms·
probably because you called systemd a disaster without qualifying why you think so
by elktea 10y ago
probably because you called systemd a disaster without qualifying why you think so
- i336_ 10y agoHrm. Okay, let me have a go. If I had to use one word to describe systemd's integration and adoption into the Linux ecosystem it would have to be "hostile" - the label has unfortunately been applicable in both directions. Most of the feathers flew around 2012 when the major Linux distributions adopted systemd as their default init system, irreversibly pulling in all of systemd's system management policies as well, many of which were poorly designed. Several big names in the Linux community (Linus Torvalds and Greg Kroah-Hartman, to name two) have had heated discussions with Lennart Poettering and other people behind systemd about major bugs, design flaws and policy integration issues, with the systemd response consistently being "the way we're doing it is the right way, no patches will be accepted, go away" even when shown multiple times that something contravenes design best practices or tradition (aka principle of least surprise). For this reason I dislike systemd's highly bureaucratic "manglement" style, and am very sad that all major distributions have adopted it so widely. systemd uses a very dictatorial approach which makes it very very hard to use any other init system without nontrivial and obscure system reconfiguration. I understand Lennart also built PulseAudio and got it integrated into pretty much all Linux distributions. PA works well now, but if it's having a bad day and I really need sound working in a pinch, I can just kill it and use ALSA/OSS directly. systemd categorically isn't like that because it's (ostensibly) an init system. However it comes with so many extra "side features" (which an increasing number of things are depending on) that temporarily shoving it out of the way to became impossible very quickly, and before any real documentation was established. I think it's understandable a large amount of the Linux community have growled and snarled when presented with this set of circumstances. Nowadays, systemd is pretty much part of the woodwork now, but the communication and social issues continue. The first reply to a previous comment I made about systemd was extremely enlightening to read: https://news.ycombinator.com/item?id=12877934 https://news.ycombinator.com/item?id=12877934
- 72deluxe 10y agoI remember the Fedora 7 (?) days when PulseAudio was made default and nothing worked (silence is golden apparently). I routinely removed PulseAudio from my systems and dropped to ALSA. I observe that systemd has a plethora of other systems that you mention, including a DHCP server. Yes a DHCP server. I do not understand it. Edit: Yes I know Fedora 7 was ancient. Just my memories. I think the fact that PA was broken in it got fixed pretty swiftly, from memory. But I was plagued with glitchy audio releases after this - could be my incredibly lame hardware at the time (but worked fine in ALSA).
- belorn 10y agoDo you understand why the Linux kernel has a network stack and do encryption algorithms? Historically, its the difference between Monolithic vs Micro design. The linux kernel is not just a layer between the application and the hardware, it also support a bunch of extra things which the project want to have built in rather than as optional libraries. There is no TCP/IP or AES library, but there is non-supported alternatives to those that are libraries. If you wonder why systemd has a dhcp implementation, ask why the tcpip stack don't.
- i336_ 10y agoThat is a very good point, and I'd like to hear the arguments for why such capabilities wouldn't be added into the kernel. They'd probably go along the lines of saying that there are already millions of lines of code in there and adding these types of features would add to the codebase size and permanent maintenance requirements. But it would be really cool if all of these kinds of high-level features were available, yeah...
- lmm 10y agoYou don't want them in the kernel, that makes them much harder to replace/upgrade/tinker with. If anything you want to go the other way and move the TCP stack out of the kernel and into a normal userspace library.