Re: upstart: please update to latest upstream version
On Fri, 24 Feb 2012, "Bernhard R. Link" <brlink@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" <brlink@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/
Reply to: