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.
Description: This is a digitally signed message part