On Wed, 21.07.10 13:29, Chris Adams (cmadams@xxxxxxxxxx) wrote: > Once upon a time, drago01 <drago01@xxxxxxxxx> said: > > And when I say/here admin I'd expect to be talking about a human (not > > some kind of robot that has hardwired commands and can't adapt to > > changes). > > If you only have to manage one system, good for you. I have to manage a > bunch, and everything that is different _for_no_good_reason_ between > them is a PITA. Yes, management scripts can be adapted, but now they > have to handle systems A-Z one way, systems AA-ZZ another (but > apparently not for all services, try to guess which?). That makes an > admin unhappy and less likely to deploy any more of systems type AA-ZZ. 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. 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. 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 suggestion right away if the semantics for that one call are close enough to what the user intended. And that's what I added to my todo list and Jef thankfully offered to implement. We are trying to find a way here between radical new designs, and staunch interface conservatism. i.e. we innovate and carefully try to select the stuff we want to keep around and leave out the stuff whose end has come. That naturally means that we do things on middle grounds, not on extremes. We won't do 100% compat with sysv, but we won't do 0% either. And that being the way it is I can only ask people to be a bit 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 incomparably more stuff in then we remove. For example, we provide compatibility with /dev/initctl, with sysv init scripts, with LSB init script headers, with chkconfig init script headers, with the various sysv client tools, with the kernel command line options, with the signals we take, with /etc/fstab and more. So, please, when Jef finishes his work, or I find the time to, we will provide chkconfig compat too (at least to a certain degree). However, doing this is actually just the cherry on top of the topping of our delicous cake. But even without the cherry it still would be very yummy and still have topping. Or in short: extremism sucks. Please acknoweledge that we try to find a middle ground, and that we are open for suggestions. Because we are. I already fixed a couple of issues that were discussed on this mailing list and added a couple more to my todo list. I won't make everybody happy, but you have a bigger chance to get your suggestion heard if you don't take extremist positions, declare sysv the holy grail and say you'll abandon Fedora if we depart from that. Yes, I guess being a developer who develops new stuff I like innovation in interfaces more than administrators who then might end up using this. But it doesn't really help claiming we had no idea what admins want and consistently ignore their wishes. Because we actually do have a pretty good idea. We don't fully share all opinions, but we are aware more often than not. 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. 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> It shows you all processes that belong to a service (in a tree actually), something that was previously impossible to figure out. It gives you a nice status string of the daemon. It tells you the cgroup. It tells you that everything is OK. When it fails, it weill tell you the exit code/status and stuff. It's just really really handy for administrative work, and it gives you a lot of information that was previously lost entirely: processes could just vanish from sight and their exit codes were completely lost. Now, tell me, as an admin, wouldn't you agree that it is kinda amazing that for so long you managed to survive without all that information? And that we now offer this to you is long long overdue? Solaris SMF had something like this for a long time, and much like for ZFS and dtrace those Solaris admins always made fun of us Linux folks that we still lacked all these toys. And now finally we provide something equally useful. So as an admin you should really love systemd, -- not hate it just because it does a few things differently. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
