5 ms·

For those of us that are more interested in FreeBSD due to the whole Systemd 'controversy', look at the other HN link about the 'FreeBSD: the next 10 years' pre

For those of us that are more interested in FreeBSD due to the whole Systemd 'controversy', look at the other HN link about the 'FreeBSD: the next 10 years' presentation. They clearly state that FreeBSD is in the same position and it seems that they are not hostile towards the concept of Systemd. Personally I hope that FreeBSD will choose a solution that does not involve QR codes (not mandatory).

digi_owl 12y ago
Well the concept of "systemd" have been explored multiple times over the years. But only systemd found the "need" to sprout tentacles everywhere.
jimktrains2 12y ago
There isn't anything wrong with the systemd concept. However, what many of the people I've discussed this have an issue with are: * Becoming the default init in stable even though it's fairly new (and untested) * Strong break from how common tasks are done (e.g. logging) * Applications are very tied together and cannot easily be replaced or left out. * NIH syndrome (e.g. their DNS resolver that just had a major caching issue)
- pmoriarty 12y ago
  There is plenty wrong with the systemd concept. Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Systemd is an application that more properly belongs on Microsoft Windows and MacOS, because of their own tendency towards centralization and control. But I'm not surprised that many popular Linux distros have chosen to adopt systemd, as they suffer from a bad case of Windows and Apple envy. [1] - https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
  - jimktrains2 12y ago
    You don't need to convince me systemd is doing it wrong! I'm in the process of switching to FreeBSD because I don't want the default system to contain something that hasn't been well tested. (Yes, it's a stupid thing, but I've been toying with switching for other reasons and this kind of made me do it :) I've also drunk the jails kool-aid for my next project.) The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components. I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable." So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
  - mappu 12y ago
    I've posted this before but >goes directly against the Unix Philosophy "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
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
stock_toaster 12y ago
> They clearly state that FreeBSD is in the same position.... He also talked about using XML (blech!) for configs, and seemed to be implying that launchd was more what he was talking about (see [slide 33][1]). I am not especially worried though, as it was just a presentation from [one guy][2] who is not a current member of the [core team][3] or [the FreeBSD foundation][4] and is probably not wholly representative of the entire FreeBSD project. [1]: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-... [2]: http://en.wikipedia.org/wiki/Jordan_Hubbard http://en.wikipedia.org/wiki/Jordan_Hubbard [3]: http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_members http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_membe... [4]: http://en.wikipedia.org/wiki/FreeBSD_Foundation http://en.wikipedia.org/wiki/FreeBSD_Foundation

digi_owl 12y ago

Well the concept of "systemd" have been explored multiple times over the years. But only systemd found the "need" to sprout tentacles everywhere.

jimktrains2 12y ago

There isn't anything wrong with the systemd concept. However, what many of the people I've discussed this have an issue with are: * Becoming the default init in stable even though it's fairly new (and untested) * Strong break from how common tasks are done (e.g. logging) * Applications are very tied together and cannot easily be replaced or left out. * NIH syndrome (e.g. their DNS resolver that just had a major caching issue)

pmoriarty 12y ago
There is plenty wrong with the systemd concept. Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Systemd is an application that more properly belongs on Microsoft Windows and MacOS, because of their own tendency towards centralization and control. But I'm not surprised that many popular Linux distros have chosen to adopt systemd, as they suffer from a bad case of Windows and Apple envy. [1] - https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
- jimktrains2 12y ago
  You don't need to convince me systemd is doing it wrong! I'm in the process of switching to FreeBSD because I don't want the default system to contain something that hasn't been well tested. (Yes, it's a stupid thing, but I've been toying with switching for other reasons and this kind of made me do it :) I've also drunk the jails kool-aid for my next project.) The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components. I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable." So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
- mappu 12y ago
  I've posted this before but >goes directly against the Unix Philosophy "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike

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

stock_toaster 12y ago

> They clearly state that FreeBSD is in the same position.... He also talked about using XML (blech!) for configs, and seemed to be implying that launchd was more what he was talking about (see [slide 33][1]). I am not especially worried though, as it was just a presentation from [one guy][2] who is not a current member of the [core team][3] or [the FreeBSD foundation][4] and is probably not wholly representative of the entire FreeBSD project. [1]: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-... [2]: http://en.wikipedia.org/wiki/Jordan_Hubbard http://en.wikipedia.org/wiki/Jordan_Hubbard [3]: http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_members http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_membe... [4]: http://en.wikipedia.org/wiki/FreeBSD_Foundation http://en.wikipedia.org/wiki/FreeBSD_Foundation