From: "Russell Coker" <russell@coker.com.au>
Technical analysis of the features and relative merits of different software has some value.
For a FreeBSD user it is annoying if a well-known Unix/Linux desktop environment gets "Linuxalized" via systemd etc. It is obviously harder to port it to other than Linux if you think of systemd during development in the first place. It is a learning curve from shell scripts to something different. But that is okay as long as it is worthwhile. The init scripts are grown in nearly half a century and are well-thought through. In substance, a daemon start/stop script looks the same under all kinds of Unix. A postfix start/stop scripts runs under any kind of Unix/Linux so - minimizing the work to integrate it in any kind of distribution. Complexity risks to overlook problems. I remember putting a LDAP dependency in /etc/nsswitch.conf in Linux as done under FreeBSD before, and then udev starts.. waiting for a 30 seconds timeout per device created. It found it reported and closed in the Red Hat bugs database. It is not a nsswitch problem, it is not an udev problem.. nobody wanted to "own" it. It was somewhere fallen through the cracks. Best advice: "Don't do it." The containers get less and less shared resources from the base system. E.g. networking: Whether it is Solaris Crossbow architecture or FreeBSD jails v2 or newer Linux containers, they all can have their own network stack. Does it make sense to have one journald on the "host system" and one network daemon? Isn't that better located in "normal userland" (so in containers when appropriate) and so separated by default? That are questions I had in mind when going through systemd. More in general, it is a question of effort and result. Why reinventing the wheel? E.g. FreeBSD is using the old fashioned /etc/rc and this uses "rcorder" to prioritize /etc/rc.d scripts. After that they start in order - and it is possible to do things in parallel. The main reason _not_ to do so are (IMHO) a conservative approach to satisfy different environments (e.g. diskless clients etc.) You only have to modify the /etc/rc "starter" and rcorder to have parallelisation in place. For a physical server I wait for the hardware when booting, the OS initialisation only take seconds. A jail is running more or less immediately. The gain will be in millisecond range. Yes on a desktop it takes a bit of time. But start a system on a SSD and it isn't that much anymore. With hibernation you do not boot that way at all. Mobile devices with Android are using another approach all together. Not to mention Busybox. It is a huge development .. and it isn't clear how many people will actually benefit from it significantly. [This is opinion] The history of Linux daemons close to the hardware (udev, hald, policy-kit, dbus, kdbus) as well as filesystem layout (procfs,sysfs) does not convince me. It all feels half-baked (sometimes even a bit narrow-minded, "I need this for me here now", and there are huge egos involved it seems) and I am not confident about quality and security of the code which is redone every few years and with competition between different approaches (and with this, splits in attention and effort). In general, I have the feeling Linux developers are "overcomplicating" things;-) Regards Peter
On 9/10/2014 2:56 PM, Peter Ross wrote:
From: "Russell Coker" <russell@coker.com.au>
Technical analysis of the features and relative merits of different software has some value.
For a FreeBSD user it is annoying if a well-known Unix/Linux desktop environment gets "Linuxalized" via systemd etc. It is obviously harder to port it to other than Linux if you think of systemd during development in the first place.
;-)
It is a learning curve from shell scripts to something different. But that is okay as long as it is worthwhile.
Agreed. Trouble is, systemd doesn't look like it is worth it. Perhaps that will change, but right now it doesn't look that way to me.
The init scripts are grown in nearly half a century and are well-thought through.
Absolutely correct.
In substance, a daemon start/stop script looks the same under all kinds of Unix. A postfix start/stop scripts runs under any kind of Unix/Linux so - minimizing the work to integrate it in any kind of distribution.
Yes, I even heard one systemd advocator say that he couldn't understand how sysvinit works ... it is far simpler and much more easily maintained than an almost black box like, do anything and everything systemd via a monolithic single binary that is bloated to heck, together with binary log files and not enough documentation to satisfy many users. All in all, it is far too much risk for security and code auditing and is a significant backwards step away from the tried, true and proven sysvinit.
Complexity risks to overlook problems.
I remember putting a LDAP dependency in /etc/nsswitch.conf in Linux as done under FreeBSD before, and then udev starts.. waiting for a 30 seconds timeout per device created. It found it reported and closed in the Red Hat bugs database. It is not a nsswitch problem, it is not an udev problem.. nobody wanted to "own" it. It was somewhere fallen through the cracks. Best advice: "Don't do it."
It will be a whole lot worse with systemd too.
E.g. FreeBSD is using the old fashioned /etc/rc and this uses "rcorder" to prioritize /etc/rc.d scripts. After that they start in order - and it is possible to do things in parallel. The main reason _not_ to do so are (IMHO) a conservative approach to satisfy different environments (e.g. diskless clients etc.)
You only have to modify the /etc/rc "starter" and rcorder to have parallelisation in place.
For a physical server I wait for the hardware when booting, the OS initialisation only take seconds.
It certainly is much easier and far more maintainable.
A jail is running more or less immediately. The gain will be in millisecond range.
Yep, even if it saved seconds per server, it really doesn't amount to much and as you say, it is perfectly possible to do things in parallel with sysvinit. The time and effort being put in to systemd could be much better spent fixing the configuration issues of sysvinit setups where they are being blamed as a reason to justify the complete change to systemd.
Yes on a desktop it takes a bit of time. But start a system on a SSD and it isn't that much anymore. With hibernation you do not boot that way at all.
So true.
It is a huge development .. and it isn't clear how many people will actually benefit from it significantly.
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
In general, I have the feeling Linux developers are "overcomplicating" things;-)
Yes, the days of a boot floppy and a root floppy are long gone [my /boot partition on wheezy is 21M and there isn't anything special there]; hardware compatibility is a good reason for kernel bloat (somewhat), but the ever growing Linux kernel itself is enough of a concern without systemd growing into another monster. cheers A.
On 09.10.14 14:56, Peter Ross wrote:
The init scripts are grown in nearly half a century and are well-thought through.
For a change to systemd to be merited, it must bring benefits¹. In comparison, my understanding is that ubuntu's switch to upstart is mandated on the new ability to handle events. Since sysv init was never designed to handle them, it may have been easier to start again. And half a century of experience _may_ have shown a better way. As long-term users, we're not happy about being pushed to deal with anything new, unless we can see the benefits. With upstart, the old user interface still works, supported by a compatibility interface. And after we oldies drop off the perch, it won't matter. OK, with systemd, a couple of commands are oddly verbose, e.g. # systemctl list-units --type=target which is an arcanely encrypted way to query the current runlevel, but as the "runlevel" command still works, the underlying guff becomes irrelevant, so long as it does the job. Now, I'm quite vague on what systemd's benefits are supposed to be, but the first place I looked:¹ https://www.linux.com/learn/tutorials/524577-here-we-go-again-another-linux-... seemed to burble encouragingly about faster boost, and elimination of the hassle of ensuring correct service start order. It wasn't at all clear on how systemd compares with upstart on handling events, e.g. hotplugging, but I guess we'll figure it out once that bus pulls up at our stop, and we have to decide whether to get on. Since most of my hosts run ubuntu, I've been gobbled up by upstart, and hardly noticed. The debian laptop doesn't have systemd, I can't directly check whether it still uses text files for any config which systemd might need. (It can only be accepted as *nix-compatible if it does) But here: http://www.freedesktop.org/wiki/Software/systemd/ we read "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts." Ah, there are caveats: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ But here: http://www.freedesktop.org/software/systemd/man/ it seems that any config files are plain text, even the scarily named binfmt files. So, what is all the kerfuffle about? The fact that not all new runlevels correspond with one of the old? Erik -- Habit is habit, and not to be flung out of the window by any man, but coaxed down-stairs a step at a time. - Mark Twain, "Pudd'nhead Wilson's Calendar
On Thu, Oct 09, 2014 at 06:53:16PM +1100, Erik Christiansen wrote:
So, what is all the kerfuffle about? The fact that not all new runlevels correspond with one of the old?
the problem with systemd is not that it makes some minor changes to the init process, but that it tries to do too much. If systemd just did init, then nobody would give a damn, but it's absorbing way too many low-level system functions into itself - udev has been merged; it does logging; has half-arsed substitutes for ntpd, cron, automount, inetd, and network configuration. this feature-creep is on-going, with more being absorbed into systemd all the time....and announced just a few days ago, a console daemon to replace the kernel's virtual terminals. Apart from the inevitable problems associated with being a jack-of-all-trades, master-of-none the result will be the death of innovation for all functions absorbed into systemd as it is impossible to replace any one of them without replacing systemd entirely....which makes the job of developing improvements just too big a job. right now we have several alternatives to choose between for cron, ntp, logging, etc - each of them with different advantages and disadvantages. With systemd, it becomes a one-size-fits-all-or-else situation. If what it does doesn't suit you then tough luck, because you can't replace it without breaking your system. the second major problem with systemd is that it is becoming (or has become) mandatory - unneccesary dependencies on logind or systemd itself make it nearly impossible to avoid having systemd installed. at least when gnome jumped the shark with gnome 3 there were alternatives like kde, xfce, lxde, etc we could switch to. there'll be no such alternative for systemd. for a while it will still be possible to hang on to sysvinit or upstart or whatever but eventually the effort required to keep everything working with dependencies breaking stuff all the time will be too great. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
If systemd just did init, then nobody would give a damn, but it's absorbing way too many low-level system functions into itself - udev has been merged; it does logging; has half-arsed substitutes for ntpd, cron, automount, inetd, and network configuration.
Incidentally, upstart also 1. claimed to be compatible with inittab[0]; and 2. planned to replace at least cron and automount. [0] in fact all it supported was one line -- it used a bit of sed to determine the default runlevel. All other entries in inittab were silently ignored.
For a while it will still be possible to hang on to sysvinit or upstart or whatever but eventually the effort required to keep everything working with dependencies breaking stuff all the time will be too great.
Speaking as someone who has suffered under upstart since 2008, it's definitely not worth keeping -- at least not on servers and embedded systems. (I don't care about desktops.) upstart is systemd with a smaller budget and less demagoguery.
On 10.10.14 09:18, Craig Sanders wrote:
On Thu, Oct 09, 2014 at 06:53:16PM +1100, Erik Christiansen wrote:
So, what is all the kerfuffle about? The fact that not all new runlevels correspond with one of the old?
the problem with systemd is not that it makes some minor changes to the init process, but that it tries to do too much.
If systemd just did init, then nobody would give a damn, but it's absorbing way too many low-level system functions into itself - udev has been merged; it does logging; has half-arsed substitutes for ntpd, cron, automount, inetd, and network configuration. this feature-creep is on-going, with more being absorbed into systemd all the time....and announced just a few days ago, a console daemon to replace the kernel's virtual terminals.
OK, now I'm frightened too! Such monolithic madness is antithetical to the core concept of unix, and alien to the modularity which users and administrators cherish. The resulting artifact will not be Linux any more, but L$, spawn of the derangement that is M$ architecture. Absorbing udev is no biggy, I think, but the rest are not even remotely integral. If the policy becomes "anything that systemd uses is ripe for absorption", then the plot has been lost.
Apart from the inevitable problems associated with being a jack-of-all-trades, master-of-none the result will be the death of innovation for all functions absorbed into systemd as it is impossible to replace any one of them without replacing systemd entirely....which makes the job of developing improvements just too big a job. right now we have several alternatives to choose between for cron, ntp, logging, etc - each of them with different advantages and disadvantages. With systemd, it becomes a one-size-fits-all-or-else situation. If what it does doesn't suit you then tough luck, because you can't replace it without breaking your system.
That system does not sound like one I would choose to use. If necessary, there's always FreeBSD. Linus can have Linux to himself again, if all the other distros all go feral.
the second major problem with systemd is that it is becoming (or has become) mandatory - unneccesary dependencies on logind or systemd itself make it nearly impossible to avoid having systemd installed.
at least when gnome jumped the shark with gnome 3 there were alternatives like kde, xfce, lxde, etc we could switch to. there'll be no such alternative for systemd. for a while it will still be possible to hang on to sysvinit or upstart or whatever but eventually the effort required to keep everything working with dependencies breaking stuff all the time will be too great.
Yes, Gnome is hardly irreplaceable. Let's ditch that too. I find LXDE just as good. Non-paying users have only one power - voting with their feet. You have convinced me, and I believe I may well have installed my last Debian distro. Erik -- There are two kinds of fool. One says, "This is old, and therefore good." And one says, "This is new, and therefore better" - John Brunner, "The Shockwave Rider"
On Fri, 2014-10-10 23:24:53 +1100, Erik Christiansen wrote:
You have convinced me, and I believe I may well have installed my last Debian distro.
Maybe not! Re-Proposal - preserve freedom of choice of init systems https://lists.debian.org/debian-vote/2014/10/msg00001.html
On 17.10.14 20:02, Aníbal Monsalve Salazar wrote:
On Fri, 2014-10-10 23:24:53 +1100, Erik Christiansen wrote:
You have convinced me, and I believe I may well have installed my last Debian distro.
Maybe not!
Re-Proposal - preserve freedom of choice of init systems https://lists.debian.org/debian-vote/2014/10/msg00001.html
Ah, the chains may yet be thrown off, then. That is great news. Restoration of choice would force systemd to compete on its merits. That can hardly be a bad thing - for it or the users. Erik -- Malcolm Muggeridge: Never forget that only dead fish swim with the stream.
On Sat, 18 Oct 2014 12:46:51 AM Erik Christiansen wrote:
Ah, the chains may yet be thrown off, then.
My understanding is that this GR will try and make packages not depend on system, it explicitly doesn't change the fact that new installs of Jessie will have systemd. Of course this asks those packages that do depend on systemd (and are not covered by the exceptions) to not do so, and asks maintainers to accept such patches, but someone still has to write and test them. Discussion of this GR finishes 5 days before the Jessie freeze with a voting period TBC and if we allow 1 week for that the vote will be 2 days after the freeze. https://www.debian.org/vote/2014/vote_003 So either: * it'll be too late to affect Jessie due to the freeze rules or: * it'll delay the release whilst dependencies are changes and any Rc bugs introduced are fixed * Jessie will ship without the dependencies but with new non-RC bugs or: * all the patching and testing will be done without impacting the timeline and without contravening the rules of the freeze. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 18 October 2014 09:31, Chris Samuel <chris@csamuel.org> wrote:
On Sat, 18 Oct 2014 12:46:51 AM Erik Christiansen wrote:
Ah, the chains may yet be thrown off, then.
My understanding is that this GR will try and make packages not depend on system, it explicitly doesn't change the fact that new installs of Jessie will have systemd.
I think the result of this GR would be any bug along the lines of "XYZ won't work with initd system ZYX" would be treated as RC (release critical). Which sounds good, except: * They left it to the last minute before the freeze. * I don't believe it actually is a problem any more. Gnome no longer depends on systemd (there are some bugs that have been ironed out in unstable, and just need to propagate through to testing). If people really want init system XYZ to work, somebody will do the work to do this. Trying to force the maintainer to do something via a GR and RC bugs isn't going to work. So, I don't actually see the point of this GR, and may vote against it. -- Brian May <brian@microcomaustralia.com.au>
On Sat, Oct 18, 2014 at 04:35:31PM +1100, Brian May wrote:
I think the result of this GR would be any bug along the lines of "XYZ won't work with initd system ZYX" would be treated as RC (release critical). Which sounds good, except:
* They left it to the last minute before the freeze.
* I don't believe it actually is a problem any more. Gnome no longer depends on systemd (there are some bugs that have been ironed out in unstable, and just need to propagate through to testing).
apparently this is the case at the moment, which makes now a perfect time to have it made into policy - no additional work is required to comply. if we wait until there is a lot of work to be done then it will be declared an impossible task. not having such a policy would make it acceptable to have stealth or forced conversions to systemd via Depends. it's already hard work to avoid having systemd auto-installed on upgrade - making it impossible would mean that all the rhetoric about systemd being "only the default init system, users can choose" a sadistally obvious lie.
If people really want init system XYZ to work, somebody will do the work to do this. Trying to force the maintainer to do something via a GR and RC bugs isn't going to work.
you could say the same thing about any debian policy - requiring a package to conform to debian's numerous policies is forcing the maintainer to do something. IMO complying with policy is a hugely important part of what it takes to get a package into debian...if you're not willing to do the work, then don't submit a half-arsed non-compliant job. craig -- craig sanders <cas@taz.net.au>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/10/2014 9:31 AM, Chris Samuel wrote:
* it'll be too late to affect Jessie due to the freeze rules
Debian doesn't do many things quickly, what harm would it do if Jessie was postponed indefinitely? Putting a date on a freeze is only a recent phenomenon-- it used to be, "it will be ready when it IS ready". A. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlRDAU4ACgkQqBZry7fv4vsQiwD/RPCYeapDWVU+8H6k4IfdAsJ9 IdnXGi/Y8Gi0h7/mjowBALq7O9DfRIuTIbMzxP7/bRRclY/TASS+VVlC6PcU/vat =CQ0O -----END PGP SIGNATURE-----
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
On 18/10/2014 9:31 AM, Chris Samuel wrote:
* it'll be too late to affect Jessie due to the freeze rules
Debian doesn't do many things quickly, what harm would it do if Jessie was postponed indefinitely? Putting a date on a freeze is only a recent phenomenon-- it used to be, "it will be ready when it IS ready".
It makes life harder for companies (like mine) that want to plan multi-year upgrade cycles to suck as little as possible. For example, RIGHT NOW we could start migrating a bunch of infrastructure from Ubuntu 10.04 to Debian 7, which would suck. OR we could start targeting jessie so that migration will be done around the time Debian 8 is actually released. Having said that, one of the reasons we're sick of Ubuntu is their release policy is less "WIR" and more "when it's not ready"... ;-)
On 18/ott/2014, at 00:31, Chris Samuel <chris@csamuel.org> wrote:
On Sat, 18 Oct 2014 12:46:51 AM Erik Christiansen wrote:
Ah, the chains may yet be thrown off, then.
My understanding is that this GR will try and make packages not depend on system, it explicitly doesn't change the fact that new installs of Jessie will have systemd. I'm sorry, I've probably lost something: what does GR stand for?
Mick
General Resolution apparently. On 20 October 2014 17:25, Michele Bert <micbert75@gmail.com> wrote:
On 18/ott/2014, at 00:31, Chris Samuel <chris@csamuel.org> wrote:
On Sat, 18 Oct 2014 12:46:51 AM Erik Christiansen wrote:
Ah, the chains may yet be thrown off, then.
My understanding is that this GR will try and make packages not depend on system, it explicitly doesn't change the fact that new installs of Jessie will have systemd. I'm sorry, I've probably lost something: what does GR stand for?
Mick _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Colin Fee tfeccles@gmail.com
On Mon, 20 Oct 2014 08:25:46 AM Michele Bert wrote:
I'm sorry, I've probably lost something: what does GR stand for?
Oops, sorry! It's a "General Resolution". There doesn't appear (from a quick search) to be a plain English explanation, but it's set out in the Debian constitution. https://www.debian.org/devel/constitution#item-4 cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 18/10/2014 12:46 AM, Erik Christiansen wrote:
On 17.10.14 20:02, Aníbal Monsalve Salazar wrote:
On Fri, 2014-10-10 23:24:53 +1100, Erik Christiansen wrote:
You have convinced me, and I believe I may well have installed my last Debian distro.
Maybe not!
Re-Proposal - preserve freedom of choice of init systems https://lists.debian.org/debian-vote/2014/10/msg00001.html
Ah, the chains may yet be thrown off, then. That is great news. Restoration of choice would force systemd to compete on its merits. That can hardly be a bad thing - for it or the users.
Even if the GR gets through (this one....), the maintainers will have a "policy" to support other init systems -- it won't change the default init system that Jessie uses, nor will it mandate a change in the future. In some respects, this looks like a "claytons" GR; I think we need one that specifically says that the default init system will NOT be systemd as well -- that can be done even with gnome desktop returning as gnome can now run without systemd as a depend. So, not sure this is the best GR to come about, time will tell. At least it would help enshrine Debian Policy to continue support of alternate init systems. A.
participants (10)
-
Andrew McGlashan -
Aníbal Monsalve Salazar -
Brian May -
Chris Samuel -
Colin Fee -
Craig Sanders -
Erik Christiansen -
Michele Bert -
Peter Ross -
trentbuck＠gmail.com