IRC meeting

[Rob Ubuntu Linux]

On Nov 27, 2007 12:22 PM, Scott James Remnant <scott at netsplit.com> wrote:
> On Tue, 2007-11-27 at 12:08 +0000, Rob Ubuntu Linux wrote:
>
> > On Nov 27, 2007 8:27 AM, Scott James Remnant <scott at netsplit.com> wrote:
> > > This isn't an argument for runlevels, this is simply an argument for
> > > admins to be able to select the level of system they wish to bring up.
> > > There are plenty of alternate ways to implement this.
> >
> > Are you saying that the init(8) replacement does not need to support
> > some "service" level, which is configurable in some way?  Or are you
> > saying that it can be diferent from having run levels 2,3,4,5 be
> > configurable by OS Releaser and/or Sys Admin?
> >
> There are many ways to do this, for example flags where you can say
> "boot, but without networking support" -- these could be combined in
> arbitrary ways.

Put yourself in a sys admins position, reacting to urgent alert on a
key system in the enterprise.  You are under a lot of pressure, and in
that situation,  you feel much calmer, if you have simple easy to
remember things.  Selecting a lot of different flags sounds
complicated and time consuming, rather than a pre-define label
(perhaps with easy to type alias like '2') which seems much easier to
me.

Those runlevels in Sys V init are entirely configurable, by the admin
in arbitary ways.  But Upstart is doing dependancies, OS 10.3 has
innserv with named facilities.  So it seems logical to use that fact
to make things simpler, rather than impose detailed knowledge.

That spot is an opportunity for a real enhancement, which should help
Upstart gain acceptance on enterprise systems (even if the average
end-user doesn't care, and doesn't know).

The issue I've found in Ubuntu, is that the SyS V stuff is used
improperly, just taking the defaults, and unfortunately someone didn't
do (100 - X) for the stop side.  Then you end up tracking lots & lots
of scripts and config files when you're debugging a glitch in the
system.  It's very fragile, and unfortunately packages are having to
assume intimate knowledge of other packages which breaks the "Need to
Know" principal and increases maintenance problems.

Even having spent quite a lot of effort, reading Documentation, I
shall still have to consult this list, if I try to fix the
"firestarter" package scripts, and be posting in terms of SyS V init
scripts known firewall pattern.  If it were a daemon, that got started
it'd be obvious, but it's actually about a number of steps of
coordinated configuration, which are done at boot time, but also may
be later on at behest of things like hotplugging and network manager
applets.

> Alternatively you could have different profiles, picking the profile
> determines which services are enabled or disabled.
>
> Either way, these should be a lot more descriptive than "2".

Agreed.   But as this is partly a configuration choice of the admin,
important stuff is likely to be made easy to type, fast and easy to
remember.

> > See I am concerned by statements like "Runlevels are ancient history,
> > forget about them", because whilst in Debian/Ubuntu space they may be
> > regarded that way.  But an admin using Red Hat/Fedora, Novell/OpenSuSE
> > and any other number of distro's will for instance, pass init an
> > argument of 2 or 3 sometimes, rather than 5 to do things like change
> > graphics cards, monitors, or upgrades of software like X & GNOME/KDE.
> >
> Which kinda proves the point how silly runlevels are, since they're
> completely non-standard.  Having X in runlevel 5, but not in 3 (with
> some vague difference between 2 and 3) is a RedHat-ism.

They are sys admin configurable!  That's not silly, that's letting
folk choose what is right on their system.  The standard is that
2,3.4,5 have administrator defined meanings.  In practice OS vendors
have tended to use 2,3 & 5, and admins have followed that practice.

> It's never been true for Debian, and the plethora of distributions that
> derived from it (including Ubuntu) where runlevels 2 thru 5 are
> identical (X starts in all of them) and the default is 2.

Except where a sysadmin has actually fixed the defaults used by
packages, to make use of the feature.  Just because the OS provider
didn't define anything for those run levels, doesn't mean the end user
cannot make use of them as they see fit.

The bottom line is :

Sys V init  : Debian, supports run levels
Upstart      : Ubuntu, supports run levels by SyS V init compatibility

Other distro's use these, despite it being a limitted imperfect concept.

Now does Upstart provide something better?  Or does it just say run
levels are deprecated?

If Upstart presumes that you either have single user mode, or full
service; yet it's doing dynamic dependancy calculations, then it's not
doing anything to make enterprise sys admins jobs easier.     Tthen
will  you face difficulties having the "enhancement" accepted?

Are you writing a project for Ubuntu/Debian, or is it aimed at wide
acceptance in the Linux-sphere?