On Mon, 2012-05-07 at 22:06 +0800, Patrick Lauer wrote:
> On 04/27/12 15:54, Josselin Mouette wrote:
> > Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> >>> Yes of course, because event-driven init systems have *always* been
> >>> *only* about mounting USB devices.
> >> Then explain the _real_ reasons for having an event driven boot system!
> > BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
> > Full stop.
> > End of story.
> > Bye bye.
> Calm down, take a breath, think about ponies or butterflies or whatever
> lets your mind go to the happy place ...
> >
> > This must have been explained HUNDREDS of times in the endless threads
> > full of stupid messages from stupid dumbasses who don’t understand a
> > thing about init systems but don’t want their precious, idiotic, buggy
> > init scripts to go away.
>
> Ok, you're mixing a few concepts *and* insulting everyone who tried to
> have a technical discussion here.
>
> That's rude. Please don't do that.
>
> Now, let's take these issues apart into simple problems we can
> understand and fix:
> * buggy initscripts - well, just fix them
The same work and same bugs are being repeated again and again. And
some may be unfixable.
> * idiotic because no dependencies - that's why some people suggest
> OpenRC or maybe upstart if that's your cup of tea. Solved problem, so
> don't go on a NIH rampage ...
> * event driven - I really (really!) hate repeating myself, but, *sigh*
> what does event driven mean in that context?
Means that services can be started (and stopped?) in response to events
such as hardware discovery, incoming network connections, the status of
other services, and so on. (With dependencies still taken into
account.)
Currently we have an event-driven daemon for hardware discovery (udev)
and a dependency-aware init system. The init system doesn't know about
events and udev doesn't know about dependencies. And there is no way
for a udev rule to tell the init system 'start this service if its
dependencies are met'.
> (now I feel the need to wash my hands. Don't make me repeat myself again!)
> * how does the current combo of udev/mdev and OpenRC not cover that?
It's not a 'current combo', it's something you're proposing as yet
another option.
> * abuse of capital letters - no, caps lock isn't cruise control for cool.
>
> >
> >> Finding new hardware for example can be related to software like hwdata.
> >> And why is udev classified as important, what's the use of that on
> >> servers?
> > Because Linux, in its current architecture, won’t work correctly without
> > it.
> >
> Blah. The only things that won't work are the two big desktop
> environments that have a dependency on libudev / gudev. And that is
> easily rectified.
>
> Having a udev-free system is surprisingly easy and without big
> surprises. You should try it :)
>
> So, if you want to have a polite discussion among adults, feel free to
> join ...
No, enough politeness. We get that you like the way Gentoo does things
(lots of options, you get to keep the pieces when they break), but some
of us are trying to make Debian better than that. We don't need more
half-assed options, we need a solution.
Ben.
--
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get out.
Attachment:
signature.asc
Description: This is a digitally signed message part