3 ms·

Opponents of systemd aren't opposed to smarter dependency tracking at boot time. We're opposed to vendor lock-in (making desktop environments and regular GUI ap

by byuu 12y ago

Opponents of systemd aren't opposed to smarter dependency tracking at boot time. We're opposed to vendor lock-in (making desktop environments and regular GUI applications dependent upon it), an intentional and strong lack of portability (especially important given the former), pushing software into production servers before it is stable and mature, the backroom politics involved in this displacing other competing technologies (OpenRC, upstart, etc), the move to corruptible binary log files, the assimilation and/or replacement of countless other services that already have more mature and stable implementations (consoled, hostnamed, journald, localed, logind, networkd, resolved, shutdownd, timedated, timesyncd, udev, etc), the PID 1 requirement, coupling itself tighter with the kernel (cgroups changes just for it, kdbus, etc), the aggressive and hostile attitudes of the lead developers (Poettering and Sievers in particular), the complete lack of choice being provided from nearly all major distros, Debian dismissing their heritage as a rock-solid, stable, conservative distro, on and on. Further, rc.d really isn't anywhere near as bad as SysVinit. See an example of an rc.d script here: https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-hookup.html https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-ho... (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)

not_with_retard 12y ago
> making desktop environments and regular GUI applications dependent upon it There are precisely _zero_ applications in the world which depend on systemd. They depend on APIs, and would be happy to use an API by a different application. The current issue is that systemd is the only one providing these APIs, and no one has done the work to replace it yet. Be patient, or write your own as you do with everything else anyways. > an intentional and strong lack of portability He doesn't want the added complexity to support OSs which are over a decade behind. Should Microsoft still support Windows XP? Seems like some of the BSDs are already planning on forking it anyways, which is precisely what he wanted. > pushing software into production servers before it is stable and mature It's been on production servers over at Red Hat for about three years now, and thus quite mature. > the backroom politics involved in this displacing other competing technologies I haven't seen any proof of this yet, but feel free to link some beyond him showing why systemd is better. Is he actively poaching OpenRC developers or something? Shit, even the upstart creator admitted systemd was designed better. > the move to corruptible binary log files It's just KEY=value. When a log file is corrupt, it's just the particular portion of the entry which is affected, you can still read the others. Or, just have it forward to the syslog of your choice. > the assimilation and/or replacement of countless other services that already have more mature and stable implementations While being maintained under the "systemd" umbrella, only journald is required by systemd. Feel free to ignore the rest if you don't approve. > The PID1 requirement This is _absolutely necessary_ for any init system. The very definition of "init" implies it. > coupling itself tighter with the kernel There have been zero changes which will _only_ effect systemd. > the aggressive and hostile attitudes of the lead developers Mr. P is actually incredibly kind and helpful, you shouldn't only look at the few cases where the peanut gallery pipes up. See: Linux, Theo De Raadt... > the complete lack of choice being provided from nearly all major distros It's always been like this, you just haven't noticed. How many other init systems did they have scripts for before? That's right, none. > Debian dismissing their heritage as a rock-solid, stable, conservative distro Refer to me mentioning that systemd has been battle tested already, and has the full backing and support from a commercial entity on top of that. > Further, rc.d really isn't anywhere near as bad as SysVinit You chose one of the simplest examples possible with Mumble, and it's still needlessly complex. RC still uses a scripting language as a necessity instead of declarative syntax, needs a process watchdog, unique device names, socket activation, etc. Compare it to systemd: [Unit] Description=Mumble Daemon After=network.target [Service] ExecStart=/usr/sbin/murmurd -fg -ini /etc/murmur.ini [Install] WantedBy=multi-user.target

by byuu 12y ago

not_with_retard 12y ago

> making desktop environments and regular GUI applications dependent upon it There are precisely _zero_ applications in the world which depend on systemd. They depend on APIs, and would be happy to use an API by a different application. The current issue is that systemd is the only one providing these APIs, and no one has done the work to replace it yet. Be patient, or write your own as you do with everything else anyways. > an intentional and strong lack of portability He doesn't want the added complexity to support OSs which are over a decade behind. Should Microsoft still support Windows XP? Seems like some of the BSDs are already planning on forking it anyways, which is precisely what he wanted. > pushing software into production servers before it is stable and mature It's been on production servers over at Red Hat for about three years now, and thus quite mature. > the backroom politics involved in this displacing other competing technologies I haven't seen any proof of this yet, but feel free to link some beyond him showing why systemd is better. Is he actively poaching OpenRC developers or something? Shit, even the upstart creator admitted systemd was designed better. > the move to corruptible binary log files It's just KEY=value. When a log file is corrupt, it's just the particular portion of the entry which is affected, you can still read the others. Or, just have it forward to the syslog of your choice. > the assimilation and/or replacement of countless other services that already have more mature and stable implementations While being maintained under the "systemd" umbrella, only journald is required by systemd. Feel free to ignore the rest if you don't approve. > The PID1 requirement This is _absolutely necessary_ for any init system. The very definition of "init" implies it. > coupling itself tighter with the kernel There have been zero changes which will _only_ effect systemd. > the aggressive and hostile attitudes of the lead developers Mr. P is actually incredibly kind and helpful, you shouldn't only look at the few cases where the peanut gallery pipes up. See: Linux, Theo De Raadt... > the complete lack of choice being provided from nearly all major distros It's always been like this, you just haven't noticed. How many other init systems did they have scripts for before? That's right, none. > Debian dismissing their heritage as a rock-solid, stable, conservative distro Refer to me mentioning that systemd has been battle tested already, and has the full backing and support from a commercial entity on top of that. > Further, rc.d really isn't anywhere near as bad as SysVinit You chose one of the simplest examples possible with Mumble, and it's still needlessly complex. RC still uses a scripting language as a necessity instead of declarative syntax, needs a process watchdog, unique device names, socket activation, etc. Compare it to systemd: [Unit] Description=Mumble Daemon After=network.target [Service] ExecStart=/usr/sbin/murmurd -fg -ini /etc/murmur.ini [Install] WantedBy=multi-user.target