[Mageia-dev] bug, omission or feature

Colin Guthrie mageia at colin.guthr.ie
Sun Jun 3 22:56:10 CEST 2012

'Twas brillig, and Johnny A. Solbu at 03/06/12 18:49 did gyre and gimble:
> On Sunday 03 June 2012 19:09, Felix Miata wrote:
>> On 2012/06/03 17:46 (GMT+0100) Colin Guthrie composed:
>>>>> /etc/inittab is no longer used or read.
>>> For real men (and women), we just change the 
>>> /etc/systemd/system/default.target symlink to point at whatever 
>>> target we want to use by default.
>> So instead of changing one character in a file that has been 
>> standard for decades, one must figure out the name of the desired 
>> target file, then type a lot so as to get the required symlink.
> I agree with Felix, this is not a good change. I'm sure there is a 
> perfectly valid ans sound reason for changig it, but there's a 
> difference in changing it for the better and changing it for the 
> worse. This is a bad change.

Well, if you think about inittab it's pretty crazy... it's a single file
that contains no dependency information but allows you to create a
watchable service (i.e. one that can be automatically restarted). Then
there are sysvinit scripts which allow you to write a non-watchable
service (unless you fork off your own watching service).

That's two ways to do some pretty similar things. Why? Why do I have to
learn which way is best and why it's appropriate to start some services
via initscripts and some from inittab? Truth be told this is just a
classic example of how features grow an mould over time. Thinking
logically it's fundamentally broken to have packages install themselves
and modify your initab file so that they are started automatically.
That's one of the reasons the initscripts themselves came about, but
inittab still supports this, even if we don't actively use it so much
these days.

systemd at very least provides a single, unified method of how units
are started (with the exception that it still supports sysvinit scripts
for compatibility although this has now been modularised such that a
"generator" will actually generate native units in /run tree for
sysvinit scripts and thus they are converted dynamically every boot).
All units can contain complex dependency information and vastly improved
logging and documentation. If you work with it for a while and follow
what it does, I genuinely hope that you'd agree.

With newer systemd's you could likely write a generator that would take
the information from inittab and convert it to native units. This is
pretty difficult due to the lack of dependency information, but it
should work for the most part. You could certainly write a generator
that parsed the default target easily enough, tho' I'd prefer to just
leave it behind personally.

> Besides, the best thing about the inittab is that it is 
> self-explanatory even to novices. A symlink is Not obvious.

I completely disagree - I'd say both are equally confusing to novices. I
mean what the hell is /etc/inittab? It has no meaning unless I know what
it means - just like the symlink.

>> Thank God everything that used to make good sense hasn't been 
>> replaced by something more complicated.
> Don't give them any ideas. ;-)=
>> I've taken to including a digit on every Grub kernel line quite 
>> some time ago.
> I've done the same for more than 10 years.
> Editing a text file to change a number, eg. from "5" to "3", is much 
> easier to remember than changing a symlink to 
> "/lib/systemd/system/runlevel3.target", especially when explaning 
> this to a not so advanced user over the phone, who doesn't have a 
> working X at the moment. (Yes, I actually do have such support 
> calls.) The support departments are just going to love this. ;-)=

If you have to support a user to change their default runlevel then
"explaining" to them how to use vi is your problem anyway! Now you don't
need to school them in how to use a shell editor, you just need to tell
them one command that support tab completion!. I'd personally say this
is easier. There are also patches to turn this into an easy command:

Not sure if it's upstream yet, but the principle IMO makes sense.



Colin Guthrie

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

More information about the Mageia-dev mailing list