> Ultimately it's all software, and software can be > written/changed/updated to do anything required - all that's needed is > the skill and the motivation. If systemd is so "core" that it can't be > unplugged and plugged easily, and glues together a lot of otherwise > unrelated components, then it's just bad software - end of story (the > problems with tightly-coupled components were first identified over 40 > years ago, and modularization has been the watchword ever since.) > > In my view, it's high time someone independently analysed systemd down > to basic code level, and understood why it's so invasive (if it actually > is.) Then the way forward would be clear - fork it, and produce a new > version which wasn't so invasive, and which could be swapped in/out. I'm > not saying it would be easy! ("We do not do these things because they > are easy - we do them because they are hard!")
I know only one attempt : uselessd. Unfortunatly, the project is dead. http://uselessd.darknedgy.net/ > >> I remember people complaining about SysV-style init too, "what's with >> all these scripts" and "why can't I just add a line to /etc/rc". >> systemd is a different way of thinking, but it isn't exactly original >> (Sun and Mac have similar launchers); practical experience has shown >> that this can be a better way of managing services. > > No one is saying that sysvinit is perfect. What I can't grasp is why > replace it with something which is no less imperfect, and is almost > certainly worse in at least some respects - and to make that replacement > unavoidable and mandatory. I agree. There are other init/service managers (no, init and service manager are not one same program) that combine the best of System V (simplicity, lightness, minimalism), and interesting ideas used by systemd ("BSD-style" dependencies management between services, for example). On Gentoo, the duo sysvinit/openrc works well, for example. > - faster boot time (this was apparently the main motivation behind it.) > My experience with systemd-managed systems has been limited - but so > far, I've not noticed faster boot times with systemd (maybe because the > boxes booted fast enough previously.) My professional experience shows me systemd is by far lower than, for example, upstart. But... let's be honest : is the OS launch time so important to make a software like systemd so revolutionary when it promises to save a handful of seconds ? On servers, which spend much more time checking and starting the hardware components than really booting the system, the difference is negligible. A bit less on virtual guests, I agree, but, anyway, they're always on, and the lonely reason to reboot them is normally to update the kernel... This kind of intervention is normally scheduled, and the announced unavailability time is often overestimated, to be able to get round Murphy's laws. Benefit ? Zero. On stations, maybe, systemd might potentially be useful. I don't know, I don't have systemd-dependant stations to hand. And I reboot my stations as often as my servers. > > - parallel startup of services. Not sure that I'd want that anyway Especially when the obvious directives are not respected. Tell systemd to start sshd AFTER network, for exemple, but forget to say sshd REQUIRES network, and systemd starts sshd... BEFORE network ! And says network isn't started, by the way. Anyway, one more time, why this obsession to gain one or two seconds ? > - better handling of hot-plug devices. I've not yet seen that in action, > but that is the one thing which makes me inclined to investigate systemd > in more detail. Why does systemd care about devices pluging ? It's not its rule, it's the device manager's one. Udev, for example. Oh, wait... > >> Nobody is forcing you to run systemd; you can continue to run CentOS 6 >> and earlier for years. But if you are a system administrator, your job >> is about learning and adapting, not trying to keep a static setup for >> life. systemd is different (just like SELinux was years ago), but I >> suggest you learn it. So I learn... I adapt... And I update... So I learn... I adapt... >> It can make your admin life easier. But it didn't say us how, then. :) > As we all know (don't we just?) sysadmin work and responsibilities are > heavy, and frequently eat into evenings, nights, weekends and > (so-called) holidays. Anything which increases the sysadmin workload - > e.g. suddenly faced with a vertical learning curve just to do the tasks > they did yesterday, or a GUI which leaves them unable to find anything > on their screens - is a major issue, and prejudicial not only to the > sysadmin's own work, but also to that of the users to whom he/she is > responsible. And when you're talking about systems used by hundreds and > thousands of users, that's a big problem. I don't think systemd was designed for servers... But sysadmins have to deal with it though. When we need simply, robust and reliable softwares, systemd offers us lots of useless, incomplete, and buggy features, replacing other softs that really work as we expect. So we learn... we adapt... Sylvain. Pensez ENVIRONNEMENT : n'imprimer que si ncessaire _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos