Re: [HEADS-UP] systemd for F14 - the next steps

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

 



On Thu, Jul 22, 2010 at 01:18:09AM +0200, Lennart Poettering wrote:
> BTW, you are emphasizing that that there was no reason for the stfuf we
> do. But you are wrong. There actually is. The reason why we came up with
> systemd-install as a counterpart of chkconfig instead of patching
> chkconfig is that it actually works very very differently from
> it. i.e. beyond the fact that both create symlinks, one in
> /etc/systemd/system, the other in /etc/rcN.d/ they have very little in
> common. One cares about priorities, the other doesn't. One knows only 6
> runelvels, the other knows arbitrary numbers of targets. One can hook
> stuff into runlevels and runlevels only; the other can hook stuff into
> any unit. One can actually make the changes effetive immediately, the
> other doesn't do that; one can handle sockets and mounts and other kind
> of units, the other cannot; and so on and so on.

It appears that you're looking at this from the point of view of chkconfig
as a tool which causes certain manipuations of the system to happen
(symlinks changed). That's the backwards approach. Look at it from the other
side: it is a user-interface for changing under what conditions certain
services run. Then extend that user interface to fit the new capabilities
that you're adding. 


> Yes, they are counterparts in some way, but they nevertheless are very
> differnt in what they do. Which is why we chose not to hack the old tool
> to make the it half work on the new system, but came up with a new tool.

They're different in the particulars. They're the same in purpose.

> Of course, there's a solution between "transparently" and "different
> tool", which is to warn the user loudly and make suggestions what to do
> instead if he uses the old tool, and possibly even execute the

So, making an annoying warning here is really an option of last resort. If
your goal is to antagonize and annoy your audience, it's a good approach,
but I'm pretty sure that's not your intention. Think I'm kidding or
exaggerating? Look at the horrible mess with the message from nslookup (I
still hear people complain about that from time to time -- and still use
nslookup!)


> more conisderate in their positions. i.e. people whining on the mailing
> list that they will leave Fedora just because chkconfig might be not as
> 100% supported as they wish it was don't really help and don't see the
> big picture. Because the big picture will tell you that we keep

I didn't see anyone saying that they will leave Fedora. However, in my job,
I see Fedora increasingly sidelined for any serious use -- and it's not just
because of some other distro's mindshare. Fedora is important to me and I've
been involved for a long time, and I dislike seeing this happen, so it's
frustrating to have legitimate concerns rudely tossed aside as not seeing
the big picture -- when, in fact, the big picture *is the problem*.



> Also, one last thing: there's so much in systemd that admins should really
> love. It would be great to sometimes look on the bright side of things.

Sure. I don't love sysv init. It sucks in a whole multitude of ways. And I'm
not really sold on upstart or any of the other replacements either. Systemd
looks interesting, which is why I'm bothering to comment in the first place
rather than just taking the "make it stop! make it stop!" line.

> One small and random example, just to make a point: Look how awesome the
> output of "systemctl status avahi-daemon.service" is:
> 
> <snip>
> avahi-daemon.service - Avahi mDNS/DNS-SD Stack
> 	  Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
> 	  Active: active (running)
> 	    Main: 6841 (avahi-daemon)
> 	  Status: "Server startup complete. Host name is lambda.local. Local service cookie is 813782141."
> 	  CGroup: name=systemd:/systemd-1/avahi-daemon.service
> 		  ├ 6841 avahi-daemon: running [lambda.local]
> 		  └ 6842 avahi-daemon: chroot helper
> </snip>

So, um. This is not so awesome, because for logged output, the multi-line
format makes it hard to parse. And for human-readable output, it's got the
opposite problem: it's more than 80 columns, and it's very verbose,
burying the answer I want (is the thing running?) in the middle of the
paragraph, while telling me many things I probably don't care about.



-- 
Matthew Miller <mattdm@xxxxxxxxxx>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux