[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: runlevels remodeled

> > I'd counterpropose to make this optional. I very much like the
> > fact that the runlevels have no default meaning and would prefer
> > it to stay that way, although I can see the issue of LSB
> > compliance.
> Personally, I hate that it isn't a standardized way to get down to
> a minimal system, or a standardized way to start everything bug
> *dm/X.

I've seen this discussion crop up a few times, and I've had a few things on my mind along these lines for ages.  I'm not sure if I can send to the group, as I'm not subscribed to it in any way.  Anyhow, here comes a more or less normal persons long-held perspective...

The progressive nature of the LSB run levels is good for tracking down some problems.  I set my system up that way long before I ever read any discussion on it, and have used it over the years to track down a few problems by progressively bringing the system up in stages.

Having four identical runlevels makes less sense than having progrssive run levels.  In either case, if you want to change it, you can.  In fact, I'd suggest that it's easier to make them all the same, then to switch from that to LSB behaviour.

As a desktop user, I duplicated the LSB runlevel 5 down to 4, and used 5 to pack my own stuff into (SETI@home, a few little services I've written for my self (okay, not not QUITE a regular user ;) ), and so forth.  For a commercial/server situation, the LSB's duplication in rl 3/4 would probably be better.

In either case, setting the run levels up as I'd like is difficult, and worse still that anything installed just gets tossed into all runlevels, leaving you to hunt through the list of packages for the new ones so you can put them where you want them.  Personally, sometimes I'd rather they don't go into any runlevel, or maybe only runlevel 5, or even an extra unused runlevel that contains everything, and the rest with next to nothing that you can add things into as you go along.  Either of these two options would be infinitely better than every new service being hurled with no rhyme or reason into every single runlevel.

Of course, better still, would be a way to configure, somewhere, which runlevels a newly installed service should go into.  And then the runlevel system is already divided by priorities, with certain priority ranges being used for certain tasks.  So perhaps some system could be set up related to that for default runlevel filling.

But at the end of the day, a very basic runlevel 1, a fairly complete runlevel 5, and a means to easily configure the runlevels without losing any (a problem with some of the older runlevel editors I've used), especially losing information about what priority the service is supposed to be started/stopped at, is essential, I think.


Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Reply to: