On Fri, 24 Feb 2012, "Bernhard R. Link" <brl...@debian.org> wrote: > > > > Not an option: we really need an events-based init system. > > > > If you want legacy at all costs, I think that Slackware is looking > > > > for developers. > > > > > > What's the supposed answer to this kind of ad hominem attack? > > > > [...] > > > > That is not an ad hominem attack. Ad hominem would be dismissing the > > opponent with 'but you are just an old fart'. > > It's ad hominem because of "If you want legacy at all costs". > Dismissing my argument by simply claiming that systemd being inferior > in my eyes is my fault is no way to convince me.
http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Straw_man It seems to me that it's more of a Straw Man attack than an Ad Hominem. Although it's not a total straw-man as it seems that the people who are opposed to new init systems are making too much of an issue out of legacy support. In the time I've been using Debian we have had a couple of major changes of libc, a change of executable format, huge and significant changes to the kernel and the way it's packaged, replacement of the old static /dev with udev (and a diversion via devfs along the way), replacement of syslogd, and lots more. It seems that the only things which haven't changed significantly are init and cron. So reviewing those things in light of all the other changes seems sensible. On Fri, 24 Feb 2012, "Bernhard R. Link" <brl...@debian.org> wrote: > My point is that every init system will have a constant stream of > problems. There simply is no way anyone will ever write a system that > always work. Currently we have a system where every user has a chance to > debug and fix those problems and make their system work again. systemd > is something where mostly only a systemd developer will be able to fix > stuff (It's easy to add some echo to a init.d script, debugging C code > is not that easy). Thus anyone with problems mostly has a choice of > reinstalling, giving up or switching to something else. Debian has already become rather difficult to debug. During the text boot process we have a change to the video mode which resets the scroll-back buffer and makes it difficult to read early messages that appear on the console. Now a serial console can make some of these things easier to debug but a recent hardware trend is towards making systems without a serial port. Is there any way of capturing the old text output from /dev/console at a later stage in the boot? Also a recent hardware trend is to make systems without a PS/2 keyboard port. It seems that the USB modules don't get loaded from the initramfs if you configure it with modules=dep which makes the recovery option of init=/bin/bash incompatible with a small initramfs on a new system. But another issue is the creeping lack of support for systems without an initramfs. For example when we had upstart upstream refusing to accept a patch for SE Linux support that made it impossible to use an upstart based distribution with SE Linux on hardware which didn't support an initramfs. Finally one benefit of an event based booting system is that it won't become stuck if one daemon hangs. I've had problems in the past when one daemon didn't start up and that prevented other daemons from starting due to the sequential processing of init scripts. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202241131.39746.russ...@coker.com.au
