diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016118.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016118.html | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016118.html b/zarb-ml/mageia-dev/2012-June/016118.html new file mode 100644 index 000000000..cccbc04b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016118.html @@ -0,0 +1,179 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] bug, omission or feature + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20bug%2C%20omission%20or%20feature&In-Reply-To=%3C4FCBCF6A.2040003%40colin.guthr.ie%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016124.html"> + <LINK REL="Next" HREF="016149.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] bug, omission or feature</H1> + <B>Colin Guthrie</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20bug%2C%20omission%20or%20feature&In-Reply-To=%3C4FCBCF6A.2040003%40colin.guthr.ie%3E" + TITLE="[Mageia-dev] bug, omission or feature">mageia at colin.guthr.ie + </A><BR> + <I>Sun Jun 3 22:56:10 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016124.html">[Mageia-dev] bug, omission or feature +</A></li> + <LI>Next message: <A HREF="016149.html">[Mageia-dev] bug, omission or feature +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16118">[ date ]</a> + <a href="thread.html#16118">[ thread ]</a> + <a href="subject.html#16118">[ subject ]</a> + <a href="author.html#16118">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>'Twas brillig, and Johnny A. Solbu at 03/06/12 18:49 did gyre and gimble: +><i> On Sunday 03 June 2012 19:09, Felix Miata wrote: +</I>>><i> On 2012/06/03 17:46 (GMT+0100) Colin Guthrie composed: +</I>>><i> +</I>>>>>><i> /etc/inittab is no longer used or read. +</I>>>><i> For real men (and women), we just change the +</I>>>><i> /etc/systemd/system/default.target symlink to point at whatever +</I>>>><i> target we want to use by default. +</I>>><i> +</I>>><i> So instead of changing one character in a file that has been +</I>>><i> standard for decades, one must figure out the name of the desired +</I>>><i> target file, then type a lot so as to get the required symlink. +</I>><i> +</I>><i> I agree with Felix, this is not a good change. I'm sure there is a +</I>><i> perfectly valid ans sound reason for changig it, but there's a +</I>><i> difference in changing it for the better and changing it for the +</I>><i> worse. This is a bad change. +</I> +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. + + +><i> Besides, the best thing about the inittab is that it is +</I>><i> self-explanatory even to novices. A symlink is Not obvious. +</I> +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. + + +>><i> Thank God everything that used to make good sense hasn't been +</I>>><i> replaced by something more complicated. +</I>><i> +</I>><i> Don't give them any ideas. ;-)= +</I>><i> +</I>>><i> I've taken to including a digit on every Grub kernel line quite +</I>>><i> some time ago. +</I>><i> +</I>><i> I've done the same for more than 10 years. +</I>><i> +</I>><i> Editing a text file to change a number, eg. from "5" to "3", is much +</I>><i> easier to remember than changing a symlink to +</I>><i> "/lib/systemd/system/runlevel3.target", especially when explaning +</I>><i> this to a not so advanced user over the phone, who doesn't have a +</I>><i> working X at the moment. (Yes, I actually do have such support +</I>><i> calls.) The support departments are just going to love this. ;-)= +</I> +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: +<A HREF="http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/4911">http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/4911</A> + +Not sure if it's upstream yet, but the principle IMO makes sense. + + +Col + +-- + +Colin Guthrie +colin(at)mageia.org +<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A> + +Day Job: + Tribalogic Limited <A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A> +Open Source: + Mageia Contributor <A HREF="http://www.mageia.org/">http://www.mageia.org/</A> + PulseAudio Hacker <A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A> + Trac Hacker <A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A> +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016124.html">[Mageia-dev] bug, omission or feature +</A></li> + <LI>Next message: <A HREF="016149.html">[Mageia-dev] bug, omission or feature +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16118">[ date ]</a> + <a href="thread.html#16118">[ thread ]</a> + <a href="subject.html#16118">[ subject ]</a> + <a href="author.html#16118">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |