4 ms·

No surprise there https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect My guess is that systemd was developed i

No surprise there https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect My guess is that systemd was developed in order to solve some very real but fairly specific issues, and that ultimately the community will get around to replacing it with something more sensible. It's just not a huge priority at the moment.

zzzcpan 8y ago
This is the only positive thing about systemd - it's so bad that it pushes people to try other things and other ideas. However, I don't see anything sensible coming from popular distros that adopted systemd in the first place. Instead we are heading towards more fragmentation and new distros.
- marcosdumay 8y ago
  Nobody else is doing the political/power play that made systemd widespread. As far as there is a well financed party interested on pushing its code into mainstream (what's not entirely a bad thing), I don't thing there's anybody capable of fighting. Well, maybe I'll be more optimistic when we replace pulse audio for a start.
  - microcolonel 8y ago
    I don't think it took much political will to get systemd everywhere. I switched to Fedora, then to ArchLinux specifically because I wanted to use systemd. I've found it to be great the whole time (if missing a little bit in terms of using device units/events in user instances). It may well be possible for there to be better general solutions to these problems, but systemd has been the best for my use cases (laptop, desktop workstation, server, headless embedded) each time I've evaluated anything else. Are there problems? Probably (I haven't noticed, mind you); should they be addressed? Yes, certainly; Do problems people see in systemd mean that the whole thing is doomed and should be replaced with some unknown contender? I don't really think so. If there were a better init system, an easier reliable NTP, better integration with Linux device events, more useful logging, simpler dhcp, etc. etc. etc. I would be using them (whether they were separate or integrated). For me, it makes a huge amount of sense to enable ntp with timedatectl (assuming the upstream NTP is configured properly), to boot with systemd-boot† (formerly gummiboot), and to configure my simple networks with systemd-networkd. I have never needed to fuss with these things to get the essential benefit they claim to provide; and it has never been more convenient. If I were starting a distribution today for anything except self-initializing applications or tiny microcontrollers, systemd would be the obvious choice, including most of its components. † This is going to get even better and more universal as the ARMv8 ecosystem, and the RISC-V ecosystem inevitably continue to rally around UEFI. As far as I can tell, a universal distro installer for IA32, AMD64, AArch64, ARMv7, and every common Linux-capable (within reason, not counting μClinux here) RISC-V ABI is not actually going to be that crazy to make (apart from size restrictions on the install disk maybe) in a couple years.

zzzcpan 8y ago

This is the only positive thing about systemd - it's so bad that it pushes people to try other things and other ideas. However, I don't see anything sensible coming from popular distros that adopted systemd in the first place. Instead we are heading towards more fragmentation and new distros.

marcosdumay 8y ago
Nobody else is doing the political/power play that made systemd widespread. As far as there is a well financed party interested on pushing its code into mainstream (what's not entirely a bad thing), I don't thing there's anybody capable of fighting. Well, maybe I'll be more optimistic when we replace pulse audio for a start.
- microcolonel 8y ago
  I don't think it took much political will to get systemd everywhere. I switched to Fedora, then to ArchLinux specifically because I wanted to use systemd. I've found it to be great the whole time (if missing a little bit in terms of using device units/events in user instances). It may well be possible for there to be better general solutions to these problems, but systemd has been the best for my use cases (laptop, desktop workstation, server, headless embedded) each time I've evaluated anything else. Are there problems? Probably (I haven't noticed, mind you); should they be addressed? Yes, certainly; Do problems people see in systemd mean that the whole thing is doomed and should be replaced with some unknown contender? I don't really think so. If there were a better init system, an easier reliable NTP, better integration with Linux device events, more useful logging, simpler dhcp, etc. etc. etc. I would be using them (whether they were separate or integrated). For me, it makes a huge amount of sense to enable ntp with timedatectl (assuming the upstream NTP is configured properly), to boot with systemd-boot† (formerly gummiboot), and to configure my simple networks with systemd-networkd. I have never needed to fuss with these things to get the essential benefit they claim to provide; and it has never been more convenient. If I were starting a distribution today for anything except self-initializing applications or tiny microcontrollers, systemd would be the obvious choice, including most of its components. † This is going to get even better and more universal as the ARMv8 ecosystem, and the RISC-V ecosystem inevitably continue to rally around UEFI. As far as I can tell, a universal distro installer for IA32, AMD64, AArch64, ARMv7, and every common Linux-capable (within reason, not counting μClinux here) RISC-V ABI is not actually going to be that crazy to make (apart from size restrictions on the install disk maybe) in a couple years.