Choose Your Side On the Linux Divide 826
snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
My opinion on the matter. (Score:3, Insightful)
Who really needs systemd?
It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.
Re:My opinion on the matter. (Score:5, Insightful)
> Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition.
Sure it should. At the very least, such sweeping changes should be met with some skepticism based purely on mundane ideas about change control. Why are changes with such a massive impact being considered? What is being done to mitigate risks? How is this going to impact how Linux fits in with other Unixen?
What's broken exactly?
Re:My opinion on the matter. (Score:5, Insightful)
What's broken is that some people would rather change Linux into something else fundamentally, rather than wait for the rest of the world to catch up. The result is going to be the same kind of pain that's happening in the browser arena. There, you have reasonable standards bodies who move "too slowly" for a few, who wish to replace the web with a new version that's obviously even more flawed, all in the name of progress. Sometimes the old guard aren't just holding back progress, but don't tell that to inexperienced youths and bitter old men who want to make a name for themselves.
Re:My opinion on the matter. (Score:5, Interesting)
The new guard in most arenas seem predisposed to think that newer is the same as better. And sometimes that is true. In the case of systemd it's a mix of some new stuff that's good and desirable but inseparable from other parts which are new but not so good. So the conflict seems to be in the push to get the new+good stuff out soon while other people are concerned rightly about all the new+bad stuff being pushed out without any plan or discussion.
Similarly, there's the ubuntu unity style of stuff: a big push by new guard that want tablet/phone presence, and an old guard wondering what corrupted their desktop (you could probably peek inside Microsoft and see the same divide in the Windows 8 debacle). You can see this in the Mozilla Firefox version deathmarch probably.
Ultimately it's the push to get new stuff in as soon as possible that leads to the conflict.
Re:My opinion on the matter. (Score:5, Insightful)
There is no "fundamental change" to Linux with systemd
I'd call moving DBUS into the kernel, assimilating udev, and making the init system a large complex system that does lots of things rather than the old school ideology of doing one thing and doing it well, some pretty big, somewhat fundamental changes to GNU/Linux.
Re:My opinion on the matter. (Score:5, Insightful)
Embedded systems are exactly the ones that don't want a bloated init system that requires dbus for communication.
Re:My opinion on the matter. (Score:5, Insightful)
Nothing is broken with Linux. But by now I believe something very fundamental is broken in a highly dangerous fashion with the systemd developers. They hardly seem to qualify as UNIX folks at all with their mind-set....
Re:My opinion on the matter. (Score:5, Insightful)
The init system (Score:5, Interesting)
What's broken is this. The initt system assumes:
1) All the subsystems boot quickly
2) None of them need to communicate back and forth about status in complex ways
3) The list isn't too long
There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.
What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.
The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.
Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.
OpenRC (Score:4, Insightful)
OpenRC is a really good replacement for SysV init. A serious enhancement that keeps with the spirit, an upgrade rather than a rip out and replace. OpenRC doen't keep daemons alive but that would be easy to add. Ultimately then there is only one hard problem what to do about hardware that changes. OpenRC doesn't architecturally have any good way for handing that while systemd does.
Certainly if the argument were OpenRC vs. systemd instead of SysV init vs. systemd I suspect the advantages of systemd wouldn't have outweighed the huge shift. I hope distributions like Slackware which don't have systemd move to OpenRC so that it gets tested in environments other than Gentoo.
PID1 - A Controllable Master Control Program (Score:5, Insightful)
Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.
The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.
Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).
I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.
Re:The init system (Score:5, Interesting)
systemd developers explicitly stated that they do not care about other OSes at all. If it is ported, then whoever ports it has to maintain it. Not to mention that they'll either need to port all the Linux-specific OS APIs it depends on, as well (and then maintain them), or else rewrite huge chunks of it. Basically, it's non-portable by design.
This is why the effects of this are so big that they go beyond Linux even. It means that software, in some cases, has to make a choice over whether it wants to support other platforms at all, or at least with reduced functionality. This doesn't bode well for *BSDs.
Re: (Score:3, Interesting)
You must be really stupid. Otherwise you would be able to use a search-engine and would have found out that there are numerous ways to do so and none of them involve complex software (except the systemd version). Hell, I wrote a python-wrapper in a few hours for that 12 years ago that has since worked flawlessly 24/7.
Re:My opinion on the matter. (Score:4, Insightful)
That sounds like a good way to create an infinite loop of crashing and restarting services.
Re:My opinion on the matter. (Score:4, Insightful)
I cannot understand what your problem is. I have systems that run continuously for years without processes dying. I have systems where the OOM killer inadvertantly kills some system task, in which case, simply re-starting that task isn't likely to be a helpful response.
From the perspective of re-starting system tasks, systemd is a solution to a non-problem.
Re:My opinion on the matter. (Score:5, Interesting)
You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be
When I was a junior network engineer, I sometimes had to work on (what we now consider ancient) technology such as ATM, Frame Relay and ISDN. I even had my share of IPX/SPX. Back in those days, the experienced network engineers with 20+ years of experience despised Ethernet while complaining about those junior folks who knew nothing about the established technologies. As it turned out, all of them are out of a job now.
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant. I don't care if something has been done like this for 1000 years. If we can find a better way to do it, let's do it.
The question should be whether or not systemd is progress, or an unnecessary burden. History is irrelevant in this case.
Re:My opinion on the matter. (Score:5, Insightful)
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant.
Translation: "Why should I learn from the mistakes made in the past? I'll just make them all over again. All in the name of progress."
Re:My opinion on the matter. (Score:5, Interesting)
I don't think the seasoned admins will argue that systemd is bad because it doesn't follow history, they'll argue it's bad because it doesn't follow well established design principles.
(I'd also dispute that there really were a large percentage of Network engineeres who really disliked Ethernet. I heard some complaints 20 years ago from people who did real-time process control systems, but that's quite a small nitch.)
I've been doing Linux admin in some fashion or another for 20+ years, so in many ways I'm part of the "old guard". The argument about small being better, making programs that do one thing well, etc is a good design element that's worked for years. At the same time I've also often been bitten by the problem of having to port "yet-another-shell-script-for distributiion-X" problem that seems like it should have a more standardized way of doing things. So from a replacing init-scripts perspective, I can see the appeal.
I'm not heavily involved in administration like I once was, so I don't have experience with systemd as of yet. (My systems run Ubuntu or Debian, no RHEL7). With that said, the monolithic design and trying to do everything sounds like a major design flaw to me.
Re:My opinion on the matter. (Score:4, Interesting)
Despite what people claim, systemd is a perfect example of one tool does one job and does it well. Systemd is an umbrella project where a collection of tools are developed in the same place, and with the specific aim of making the tools work together in a modular integrated fashion. There is nothing monolithic about systemd and the way it works.
So "systemctl" controls stopping and starting services, "journalctl" filters log files and displays the output via a pager ("less" is standard, but it is easily changed), "hostnamectl" sets and display hostnames etc.
All the tools can be chained together with standard pipes, so they are just like any other Linux tool, though remarkable well made (tiny and fast) and well documented. bash-completion is also well integrated, so "hostnamectl " will show all possible keywords.
Regarding network engineers disliking ethernet; I heard plenty of that in those days. Remember, ATM was once king in telecom, and Token ring in the LAN world. Believe me, at lot of those network guys really looked down on ethernet in the beginning; they saw it as primitive and that it did everything the wrong way. The "happy-go-lucky" ethernet attitude to network collision grated on their nerves.
Re:My opinion on the matter. (Score:5, Interesting)
From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.
Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.
And frankly, OpenRC is a lot better.
How do you figure? I've been using OpenRC for more than a decade and there are a LOT of things it doesn't accomplish like: /etc that sets that one setting and systemd merges it in every time.
1. Having upstream-provided service scripts for most packages. Most OpenRC scripts are custom-built by Gentoo maintainers. If a Gentoo maintainer doesn't maintain a script, you will have to write your own.
2. Actually stopping services thoroughly. If a service doesn't clean up children properly. OpenRC doesn't care.
3. Optional auto-restart.
4. Sane network configuration. The networkd configuration is much simpler than oldnet/newnet/whatever.
5. Drop-ins. I like a Gentoo-provided openrc script, but I want to set ionice. That means hacking up the script, and then merging in changes every time it is upgraded. With systemd I just stick a drop-in file into
6. Booting in milliseconds in a container. I'm not sure how well it boots in a container at all, though I know this is being worked on.
7. Clean shutdowns when you're using stuff like lvm/raid/etc. Systemd can drop to dracut and allow the initramfs to do a full clean unmount. Sure, the read-only approach works reasonably well, but it always bothered me seeing OpenRC shut down with in-use messages.
OpenRC is about as good as it gets for a traditional bash-based service management system. I've always been happy to use it. However, unless I'm stuck on BSD or something I doubt I'll be using it much in the future.
Re:My opinion on the matter. (Score:5, Informative)
RHEL 6.5 uses Upstart. It does not have Systemd.
Re: My opinion on the matter. (Score:5, Informative)
If that is the case then someone at Redhat needs to be hit with a Clue-by-four (tm). A system should have absolutely ZERO binaries/files that are required to boot into a working (if only minimal) system in /usr. Stupid, man. It's universally stupid.
Re:My opinion on the matter. (Score:4, Insightful)
Any random Joe Schmuck can also make a required change to the blinkenlightsd init script to programmatically alter its startup characteristics to fit his unique system startup requirements. He can't do that with systemd. I call that a limitation. So what we're really arguing is whether or not the status quo limitations are less important than the new limitations you want to introduce.
Re:My opinion on the matter. (Score:5, Insightful)
Who cares if you have to relearn stuff? Its the fact that systemd is less than stable... In many cases, you end up with corrupt binary log file after a crash, have services that don't (run a process that does heavy syslogging to the tune of 25-30K messages per second. Yes, its bad app design but come on - this thing worked for years and now its suddenly broken???) that used to work just fine before and then top it off with really braindead configuration options (go ahead and change the pgsql listen port - and see how long it takes you...)
I'm all for systemd - once its been stable for a while, but till then it would be nice to have at least a choice...
Peter.
Re:My opinion on the matter. (Score:5, Insightful)
> Who cares if you have to relearn stuff?
Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.
This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.
The anti-dinosaur sentiment should not be an excuse to blindly and gratuitously change things just because of "new shiny shiny".
All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".
Re: (Score:3)
True,
However Linux has shone from time to time that it was able to push Traditional Unix systems to switch to their method of doing things.
However the real question is what is the benefits vs cost of the change.
How will that affect GNU/Linux primary purpose (Server OS).
Re:My opinion on the matter. (Score:5, Insightful)
This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.
http://en.wikipedia.org/wiki/S... [wikipedia.org]
Re:My opinion on the matter. (Score:5, Insightful)
Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.
Except that's actually false. Unixen really don't share common interfaces. Mac OS uses launchd, FreeBSD uses init.d, many Linuxes use systemd.
On Linux you'll find devices named /dev/hda(n) and sda(n), while on OS X you'll find /dev/disk(n)s(m), and on solaris you'll find /dev/dsk/c(n)t(m)d(l)s(o).
All unixes differ. Trying to claim that the way it happens to have been done in Linux for a while is the "one true unix way" is frankly bullshit.
Re: (Score:3)
SysVInit is broken. It doesn't restart services that crash. In an environment with many hundreds of servers, the menial task of restarting services becomes a full-time job.
Re:My opinion on the matter. (Score:4, Insightful)
Re:My opinion on the matter. (Score:5, Informative)
An init system should do one thing and do it well, manage the startup of services when called. A proper *nix designed system for monitoring and restart would CALL init, but it shouldn't BE init, otherwise it violates the principle of modularity.
Consider for example looking for all the active settings in a standard Linux config file:
grep -v ^# ldap.conf | tr -s '\n'
By using two standard tools you can do something pretty fancy, basically stripping out all the comments. Could grep be enhanced to include the newline trimming feature? Of course it could, but that's not grep's job, its purpose is to match things not trim things. By keeping the scope narrow you reduce the error space and provide a more flexible toolset.
If you design the monitoring system into init then it can't be used generically to monitor other things and you lose half the value of the tool you've created.
Re:My opinion on the matter. (Score:5, Interesting)
You know what sucks my ass though? Not being able to modify the init scripts as I need. I'm so glad we've made a daemon that will make sure I never need to alter the low-level starting dynamics of a service again. At least I assume it does that, since it *does* deprive me of my ability to.
Re:My opinion on the matter. (Score:4, Interesting)
What's funny is it actually has the ability, and nobody uses it except for gettys.
This. Actually, in RHEL/CentOS, you can simply run /etc/rc every minute via cron and it'll sync what's running with what's supposed to be, assuming things have been /sbin/service stopped. (And if they haven't been cleanly stopped, you need a specialized tool that understands how to *TEST* the service rather than rely on subsys.)
Re:My opinion on the matter. (Score:4, Insightful)
Run blah every X seconds is just about the dumbest way we can be doing things on a computer. It's a closed system. It can know exactly when a process dies, and handle the event then. The inability to do this is a huge flaw.
Re:My opinion on the matter. (Score:5, Interesting)
A "crash" does not involve anyone running "service X stop" so you're providing a solution for a problem nobody wants nor asked about.
And that specialized tool is... wait for it...
THE SERVICE'S OWN INIT SCRIPT!!!
That's right, you can iterate through service "$X" status on everything, and do a restart on anything that has terminated, but that's just a hack, and something that can be done infinitely superior within the software handling the service startup... namely, upstart or systemd.
I hate Lennart Poettering and PulseAudio as much as anybody, but SysVinit is broken, and systemd is a fix. Angry zealots repeatedly denying that there's a problem, is probably why it's taken so very long before a fix finally arrived.
Re:My opinion on the matter. (Score:5, Informative)
One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become.
The init system is a very poor example of Unix common interfaces. As beelsebob [slashdot.org] and oursland [slashdot.org] point out, different Unix systems use different init systems. The Linux alternatives, upstart and systemd, were actually inspired by the clear advantages displayed by MacOS X's launchd.
And even in Linux, with SysVinit, there are different interfaces. When you want a script to run at boot, do you use update-rc.d, like Debian? Do you use rc-update like Gentoo's OpenRC? Or chkconfig like Red Hat? Or insserv like SuSE? And where do you find important details like the hostname and network configuration?
I don't find systemd to be a pleasing design, and I especially don't share their love of long command names with lots of consonants, but I think their work is very important.
Re:My opinion on the matter. (Score:5, Insightful)
Much like pulseaudio, it will probably become quite good when Lennart stops working on it and hands it over to someone else to maintain.
Re: (Score:3)
(go ahead and change the pgsql listen port - and see how long it takes you...)
vi /var/lib/pgsql/data/9.3/postgresql.conf
^] :%s/^#port = 5432/port = 1234/
:wq
/usr/libexec/iptables.init save
semanage port -a -t postgresql_port_t -p tcp 1234
iptables -I INPUT -p tcp --dport 1234 -j ACCEPT
systemctl restart postgresql
Was that so hard?
So sorry that even with iptables-save installed and the new systemctl firewalld turned off... "service iptables save" command has disabled so suddenly, even though it's
Re:My opinion on the matter. (Score:5, Informative)
Was that so hard?
Hey, guess what? I did that, and it didn't work.
Hint: you missed at least one more place where you have to change the port number.
Re:My opinion on the matter. (Score:5, Interesting)
Are you also using 'cat | grep'?
What's wrong with that?
It is more convenient for me, for example /some/file/somewhere| grep something (hmm, didn't get what I wanted) /some/file/somewhere| grep some (good)
cat
cat
If I do grep something /some/file/somewhere and and to edit my search string, I have to move the cursor further than in the cat|grep version.
Also, I sometimes replace tail with cat when looking at a log file
tail -n 2000 | grep (it wasn't here, let's look at the whole file)
cat | grep (found it)
Re:My opinion on the matter. (Score:4, Informative)
Basically we *need* something like systemd, which is why it's gaining ground. It's providing a lot of sorely-needed features, efficiency, and cleanup in a ton of areas. The are a handful primary meta-downsides that cause all the teeth-gnashing can be summarized as follows (all of which are avoidable in theory...):
1) The developers are often uncooperative assholes - True of many projects in the OSS world, sadly. Generally not a deal-breaker when everything else is fine, but it really exacerbates problems with the other points below.
2) Emacs Syndrome - systemd has begun to be the kitchen sink of Linux. They're adopting a philosophy that anything anything which touches/interacts with systemd and doesn't work for them (doesn't fit their new radical model) should be re-written into compliance, and since too many of the authors of these non-compliant projects are also systemd grumblers, the project has taken to the habit of rewriting these components themselves and making them a part of systemd. Thus systemd's scope has grown tremendously, and it's bundling a ton of risk into a single meta-package. Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).
3) Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons. For a traditional *nix daemon, this means the collection of POSIX-y system calls that deal with things like privilege management, daemonization, logging, socket binding, etc. The systemd model tries to replace all of this with declarative service configuration files which set all of this up from outside the daemon before it's launched, allowing it to focus on merely processing socket traffic. Think of this as a much more advanced variant of the inetd model. The problems with this approach are three-fold (and you'll see examples of these problems in other areas of systemd as well):
3a) They haven't mirrored every possible legitimate use of the old POSIX-y syscall API in the new declarative configuration. In little ways this means things like not supporting every socket option in the normal socket APIs. In big ways, this means more complex behavior patterns. For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc). Systemd's declarative model is far more limited in scope and can't possibly map to all of these creatively-beneficial uses of POSIX behaviors. Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style, and the long course is to get rid of sysv init compatibility completely. This really screws these cases.
3b) It introduces a new latency in exposing new APIs. Before if, say, a new socket option appeared that was useful to a daemon, it first appeared in the kernel, then later in glibc, at which point it's at least conditionally available in a reasonable manner to portable (among linux versions/variants) software. Now we must wait for it to hit the kernel, then glibc, then systemd, and only then can the application take advantage of the feature. Who's coordinating this the way that kernel/glibc APIs are coordinated? This stuff isn't even documented.
3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case. Thus these APIs aren't well-thought-out for the server-like case, and the concerns of authors of that sort of software are not being taken very seriously (see point 1). However, the distros which have all (how the hell?) been convinced it's a good idea to move their whole distro to systemd in the long run will obviously be using the same init system in both cases. I know we all want some year to be the Yea
Re: (Score:3)
Bullshit. There is no "need" for systemd. It does solve a few exotic problems and does to at a huge cost to reliability, security and flexibility.
Re:My opinion on the matter. (Score:4, Insightful)
Re 1: Developers uncooperative?
Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.
Re 2: Emacs syndrome.
It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.
Re 5: Total disregard for everything outside of Linux,
All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)
So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)
No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).
I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.
systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.
Re:My opinion on the matter. (Score:5, Insightful)
Who really needs systemd?
I've been working with Linux since 1995, where I started with Slackware, moved over to Redhat until it went all "enterprise-y", at which time I moved to Fedora.. Stayed there till a friend turned me on to Ubuntu in 2007, where I stayed pretty much till the recent Unity shitfest over there, where I then moved to Debian.. I cut my teeth on /etc/init.d and a stock standard init() process.. I could do pretty anything I needed to do in troubleshooting/starting/stopping daemons from memory.. Can't remember the last time I consulted a man page regarding anything having to with init() or logging.. Now with this $#@$%%$#@ systemd, I have manpages up ALL the time just to do simple shit that I could do with init() and standard logging in my sleep before systemd. It also seems like this crap is spreading like sewage over pretty much of the standard distros.. Debian/Fedora/CentOS.. The only one I'm somewhat familiar with (haven't used it recently) is Slackware and from what I've heard Patrick and the devs over there feel the same way I do about systemd.... Maybe its time to revisit an old friend.....
Re:My opinion on the matter. (Score:4, Interesting)
TL;DR version: You spend around 20 years getting used to the old way of doing it and now you can't stand change.
My story: Been using Linux heavily since 2000. Arch adopted Systemd big-time in 2013 or so. I spent a little while learning the new commands, and now it's just as easy/hard/whatever as the old RC system was. Oh, but my boot times are way shorter than they used to be.
Re:My opinion on the matter. (Score:5, Informative)
Systemd's strenghts are:
- Fast startup & shutdown (compared to sysVinit);
- Better on-demand loading and stopping services and processes and changing network settings.
Compared with all the problem it brings:
- That is useful on a tablet or phone - where you never have to modify the factory configuration;
- A bit useful on a laptop - if you only use GUI tools that can do a limited ammount of config editing for you;
- Not very usefullon a desktop - unless you are prepared to get your hands dirty with systemD's smelly and poorly-documented guts;
- Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.
For a server situation, the BSDrc style startup is even better than sysVinit.
Re:My opinion on the matter. (Score:4, Insightful)
Bull. Lots of servers currently run daemontools or similar, or else they use some other hack, because the SysVinit doesn't have any way to restart services (like crond) the one time they exit after running fine for months...
Alternatively, somebody has to take the time to set-up exhaustive monitoring, including ALL the trivial services running on the servers, and some dummy has to watch it around the clock, and manually perform this extremely simple and menial task. Or else maybe you're the dummy who gets paged at 3AM to do a trivial service restart, due to some simple and transitory event.
I would have been just as happy with upstart or anything else, but it was a dammed nuisance lacking that 30 year-old feature, and downright embarrassing that Linux still lacked it, while it's been working well in the base of Windows since the first version of NT.
Re:My opinion on the matter. (Score:5, Insightful)
This is the problem with systemd, Gnome 3 and a lot of other recent stuff.
Unix was originally designed rather like a tinkertoy set. The individual parts might not be very smart, but you could glue them together however you wanted. A "RISC" architecture, if you will.
Recent "improvements" to Linux have attempted to be all-in-one solutions. By making them one-size-fits-all, you lose useful, important, sometimes critical functionality. Because no one system can be all things to all people. It's a "CISC" solution, and what you are left with is what the designed wanted you to have, not what you wanted to have.
So that's the Great Divide. Turn into another Apple, where you can have any solution you want as long as it's the one the providers want to give you or retain the original spirt of the system, and allow it to be powerful at the expense of the presumed masses who'd gladly chuck Windows if only Linux was more friendly to the casual user.
Re:My opinion on the matter. (Score:5, Insightful)
Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.
A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.
Re:My opinion on the matter. (Score:5, Insightful)
Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.
A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.
I mostly hate X11 because I have to program for it... It's like eating a cactus and washing it down with a whole bottle of Carolina Reaper Chili Sauce.
Re:My opinion on the matter. (Score:5, Informative)
The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:
Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.
There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.
There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).
The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.
XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.
None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).
If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.
It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.
Re:My opinion on the matter. (Score:5, Interesting)
Also, what advantage does X forwarding offer over VNC?
Integration with your existing desktop; the forwarded app works just like an existing app.
It's like you get married and instead of you and your wife moving into the same house you just move your houses together so you have two external windows that are touching and you can look into her house. That's such a stupid analogy but it just occurred to me so of course I have to jot it down here.
Re:My opinion on the matter. (Score:5, Insightful)
I think, for a lot of people, they don't have the challanges that systemd solves.
Conversely, systemd daily inserts problems that never existed before.
Actually they did. I dealt with binary log formats in Windows, OS/2, and IBM's mainframes. IBM has a really bad habit of creating a different binary format logfile for every app, complete with special binary utilities to be able to read them in any way you like - as long as it's a way IBM supports.
The old text logfiles might not be as tidy, but I constantly string together strange concatenations of the text utilities to garner critical information from them. Something that's nowhere near as easy when the logs are in binary form.
What systemd reminds me of is the Windows Registry. A fine concept that turned out to be a nightmare in practice.
Re:My opinion on the matter. (Score:5, Interesting)
It amuses me greatly that both replies to this post responded as if Bill was talking about "X" the windowing system rather than a placeholder variable.
Should've used $X. ;)
Re:My opinion on the matter. (Score:4, Insightful)
KISS is not a "religious idea" or a "sacred cow". KISS is the very foundation of all working engineering. Systemd throws KISS out the window.
Re:My opinion on the matter. (Score:5, Informative)
Re: (Score:3, Informative)
My question then is why are we seeing a near universal switch?
Because Lennart works for Red Hat which is pretty much the only profitable Linux distro out there and has a massive amount of control in the Linux arena. If the change happens in Red Hat there is a 90% chance it'll happen everywhere else, which is basically what we're seeing with only a few holdouts on systemd like Gentoo.
Re: (Score:3)
Scientific/CentOS/Fedora/Fuduntu/OpenSUSE just to name a few. I could also list off all the spins like Korora etc. Yes it is a monoculture where the only people using DEB's are the hobbyists. Ubuntu was the one shining hope for something other than RPM but they crapped all over that.
If you want a job doing any type of linux work, you better know RPM. Period.
Re:My opinion on the matter. (Score:5, Insightful)
That, I must say, is one of the arguments that turns me off to it. I really could not possibly care less how long it takes any system other than my laptop to boot. My laptop does run a distro with systemd, and I do like that it boots fast....I would not hesistate for a second to give that speed up if I needed to for something I do once a day usually and twice a day at most.
The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.
Really the most annoying thing about it for me isn't going to be learning it, its going to be training other people to deal with it and supporting them when they find the software they are installing isn't setup for it properly and they need to troubleshoot and fix it.
If there was some real benefit, I am all for it but....boot speed? Talk about not worth it if that is the "benefit"
Re:My opinion on the matter. (Score:5, Insightful)
Re: (Score:3)
I have to admit, I've never understood this fetishism for boot times. Boot times stopped being unreasonably long years ago. Why do people still care about modest improvements in speed to something that doesn't happen that often?
Re:Better question (Score:5, Informative)
Nobody is forcing the adoption? Really? You do know that Gnome3 has a dependency on logind and logind has a dependency on ... yes, kids ... systemd.
Re: (Score:3)
That sounds like a truly excellent reason to stop using Gnome.
My distro is better than your distro (Score:3, Insightful)
And THAT pretty much sums up what has always held Linux back (and probably always will).
Not in this instance (Score:3)
And THAT pretty much sums up what has always held Linux back (and probably always will).
Except this is not really a problem with the exception of Slackware and Gentoo two obvious holdouts ...and if you use those distributions you know why.(Go on read the wikipedia on systemd it has some great quotes).
all these distros use systemd - Arch Linux, CoreOS, Debian GNU/Linux(Default for Debian 8 "jessie"),Fedora, Frugalware Linux, Mageia, NixOS, openSUSE,
Red Hat Enterprise Linux, Sabayon, Ubuntu(Coming). The deal is done.
Oh FYI Linux overtook windows back in 2013 is quite well know.
Re:Not in this instance (Score:4, Informative)
> GNU/Linux is still pretty irrelevant outside of cheap server
Linux is the flagship platform for a leading enterprise software vendor that sells their product for 60K per CPU.
One single server installation of their product can cost more then your domicile. This is true regardless of where you live or what kind of structure you live in.
Linux isn't just "relegated to cheap servers".
Yep, cheap $390 million supercomputer servers (Score:4, Insightful)
Re: (Score:3)
My opinion is that my opinion is false.
Re: (Score:3)
That's your opinion, sure...
Display server (Score:3)
Re:Display server (Score:5, Insightful)
As long as xterm & the web browser are running on Wayland, nobody will complain.
X.org has became such a mess itself (compared to the old XFree86) so anything smaller, simpler, faster and 100% compatible is welcome.
OTOH systemD is not smaller, simpler and 100% compatible with the systemV init and BSD rc - so it requires everybody relearning a lot of concepts for scratch just to gain 4-5 seconds at boot time - unsually on a server that you reboot only a couple of times a year.
Re: (Score:3, Insightful)
Do you see any disadvantages of wayland?
Uh, let's see. Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.
Oh, but the desktop is dead, etc, etc and we'll all be doing software development on phones in future.
Re: (Score:3, Insightful)
[quote]Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.[/quote]
Let me fix that for you:
Using X-forwarding *right freaking now* you are pushing megabytes of pixels every time you scroll a window because every single modern toolkit operates that way and you have obviously got problems distinguishing between a simple
Re:Display server (Score:4, Interesting)
Choosing Sides (Score:3)
Re:Choosing Sides (Score:5, Informative)
Re:Choosing Sides (Score:5, Interesting)
If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?
Still, there's always BSD.
Re:Choosing Sides (Score:5, Insightful)
You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.
What battle? (2010 wants its article back?) (Score:4, Informative)
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)
Re: (Score:3, Insightful)
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)
Ubuntu is the largest distro I know of and it doesn't support it by default.
But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.
Re:What battle? (2010 wants its article back?) (Score:5, Insightful)
I've yet to read something I'd consider a valid argument against it.
It violates basic *nix design philosophy, which basically has two pieces: 1) Everything is a text file 2) Lots of small tools that can be chained together to do big things
Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.
Re:What battle? (2010 wants its article back?) (Score:5, Insightful)
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)
Ubuntu is the largest distro I know of and it doesn't support it by default.
But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.
When the neck beards speak, it's often prudent to at least listen.
I'm reminded of a myth, of when the Ancients were sitting down to design Unix, someone said "Why would we ever need a special file, that never contains any data, and always throws away everything written to it?" The Ancient replied, "Trust me, you'll need it." And thus, /dev/null was born.
This is just a rant (Score:4, Insightful)
This article is just a rant, full one one-liner insults and clichés. There are probably good debates on this topic, but this is not one of them.
systemd adds to and supports the old model (Score:5, Informative)
the general concept behind systemd makes sense, its mainly some additional features on top of the current model, such as the ability to have processes started on certain system events. The fact is, if you want your bootup process to be controlled by bash scripts, all you need to do is configure systemd to start your bash script and youve got a more traditional init system. So, systemd does not take away any functionality, only adds it. Systemd supports the system v init process features so you still have all the old model functionality available to you. So, it does not make much sense that people complain about this when they can easily configure things however they want, including having a BSD style init, by having systemd hand off control to your own scripts, including to work the way things always have. People act like systemd has taken away something when it has not, i think many people just hears some soundbite about systemd introducing a new model and assume that they can no longer use things the way they do currently, which is not the case. it seems like people who don't like systemd don't want people to have the additional functionality that it provides, because it does not take away anything. Its open source software, and its something that you can control and configure to your hearts content. Its much ado about nothing. systemd, while being configurable, also will make things easier to use for many users. I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users. This is even though making it more useable for less adept users does not in any way harm or take away flexibility from experts, who can still configure everything if they want they want to.
Re:systemd adds to and supports the old model (Score:4, Interesting)
If by "less technically adept users" you mean ordinary PC users who are being encouraged to adopt the Linux desktop, there is no reason that the init process has to be changed to woo them, because such users won't ever touch the system internals anyway, whether they be sysvinit or systemd.
If by "less technically adept users" you mean people with some command-line skills but who are not yet Unix wizards, well, arguably systemd makes things more difficult for them. One of the biggest reasons systemd adoption has pissed people off is that for the systemd devs, documentation is at best an afterthought. The API has changed significantly over the last couple of years, but most documentation one can find on the internet is now out of date, and it has not been replaced with docs for the current state of systemd. sysvinit, on the other hand, is extremely well documented from a number of sources, and the technology remains accessible to anyone with some bash skills.
Re:A complex, fragile, unmanageable TURD (Score:4, Interesting)
It actually did need more than just streamlining, e.g. it needed to use multiple processors if available. But systemd seems "a bridge too far". OTOH, I prever grub over either lilo or grub2. Grub gave me enough control and was easy enough to understand for the simple features I wanted to use. Grub2 is inintelligible, and all the readable files say "warning: This file will be automatically overwritten". And lilo didn't give me any control over what what happening.
I'm not deep into systems administration, and I don't want to be. OTOH, I do want to configure my own system to do what *I* want. And what I want is often not what the designers of the software expect, even though it's well within the range of things handled by the software. So I dislike systems that are either too automagic or too inflexible. Systemd is, from all reports, too automagic, and simultaneously too inflexible. So I'm seriously thinking about switching to Gentoo or Slackware. Or even one of the BSDs, though I don't know enough to even guess which one. (I have a desktop orientation, not a server or minimalist orientation, but I need to do some server style jobs. Most Linux systems will handle this easily, but I think that some BSD systmes are too heavily oriented towards server setups.)
A plague on both their houses (Score:5, Interesting)
Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.
But systemd is just plain FUCKED UP. Read the dependencies [debian.org].
Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.
How is this sentence anything but unsupported? (Score:3)
"Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition."
The more fundamental a change is, the more it changes everything - that's basically why we call it 'fundamental'. Making fundamental changes says there's a lot broken. If I said we need a program to fast track educating doctors for rural areas, that's a moderate change to the US medical system, and might a good or bad fix for one specific problem. If I say we need to shoot all existing physicians and substitute Qui-Gong practicioners, that's a fundamental change to American medicine. If someone asserts a change is fundamental, they have also implied the existing system is nearly or totally borked, so they have a very strong burden of proof shifted entirely to them for making that assertion. Unless they can meet that burden of proof, the other side should win any debates.
The smart thing to do is to claim that a change is not alll that fundamental, and changes only a limited subset of things. For example, I could argue that gay marriage is a limited change, in that it is still based on a moral principle many of us respect (that the people choosing it are consenting adults with normal understanding), and not a more fundamental change (such as throwing out any moral base, including the principle of informed consent, so that pedophilia would somehow become legal). Notice how it's been mostly anti gay marriage advocates that are trying to paint the issue like everything under the sun will change if the other side wins - that's because many people have figured out how this burden of proof stuff works.
not reasonable at all (Score:5, Insightful)
A complex startup system that logs to a database rather than a text log, is just poor engineering.
And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.
Just the requirement for dbus proves systemd far too complex and bloated a thing, it is against the Unix way of doing things. Failures and problems in a needlessly complicated black box may well be too difficult to even troubleshoot
Mirrors industry schisms... (Score:5, Insightful)
You can see this in Development vs Operations, Bay Area Startup Hipster Programmers vs System Administrators Who Have To Carry The Pager, Big Data vs Simpler Analysis, and a lot of other places in the industry right now....
There's an influx of talent that doesn't seem to understand the fundamentals of system architecture, or assumes they have all the answers and can/should hard-code them into the design, preventing "the Unix Philosophy" from being applied by the operator who's trying to deal with the crisis at 3 in the morning. "whatcouldpossiblygowrong", ergo I shall design this in C, and if you need more flexibility than I'm offering then You're Doing It Wrong.
What they don't understand is that they don't have all the answers... Nobody does. The only solution is to leave as much flexibility available as far down the stack as possible to allow the folks who have to deal with this (eg, system administrators) the ability to do their jobs. Replacing shell scripts with C code and the unix toolkit with monolithic binary blobs does not help the situation.
systemd does a few things right (cgroup management, for one), and promotes the state of the art in a few areas that probably only could be dealt with at the PID1 level... Also, as the original article admits, there's nothing inherently wrong with working to speed up boot times across the board. All of these things are irrelevant and outweighed by enforcing declarative styles on system configuration, and the sheer philosophical hazard of taking all these disparate functions and putting them into a program.
It makes absolute sense for Android, and perhaps an embedded system that just needs systemd and busybox. For a regular Linux userland, it takes us in the wrong direction.
False "new vs. old" dichotomies (Score:3)
(FYI: I haven't followed the systemd saga but I have noticed this fight in a growing number of places)
This seems to be a VERY common problem in the modern computing environment: arguments are reduced to ad hominem labels of their supporters where the proponents of "new" are just "kids fascinated by the trendy at the expense of stability" or other "why maintain it when I can write something better?" inexperienced people and the proponents of "old" are just "out of touch old-timers who are afraid of the unknown" or people "only interested in their own job security".
Of course, the reality is some bits of these straw men, combined with massive doses of reality. The truth is, both sides of the argument make more sense if they are reduced to actual concerns and interests, as opposed to "us versus them" camps.
The truth is that "change for change sake" is a dangerous position and the reality is that the "legacy" moniker is slowly changing from a negative term into something which means "has worked well for a long time".
Alternatively, sometimes new ideas are beneficial since they tend to think of current realities, as opposed to sometimes-extinct realities.
This whole notion of "choosing your side" doesn't help anyone since it isn't actually a division, but a conversation/argument. Sometimes stepping forward is correct while sometimes standing still is correct and neither approach is "always correct". Maybe we would choose our next steps better if we worked together to choose them instead of all lining up in our preassigned trenches.
Discordian date (Score:4, Funny)
Never mind trivial things like systemd - the real watershed moment for Old Unix vs New Linux was back in 2011, when a humourless package maintainer excluded 'ddate' from the default build of util-linux:
http://en.wikipedia.org/wiki/D... [wikipedia.org]
https://git.kernel.org/cgit/ut... [kernel.org]
https://bugzilla.redhat.com/sh... [redhat.com]
Re:Still on (Score:5, Informative)
Systemd still supports the system V boot process features, you can still run init scripts from systemd if you wish.
Re: (Score:3)
Sortof. But even if this were 100% true, it still doesn't solve the problem that systemd is present.
Re:If systemd is deemed going against unix philoso (Score:4, Informative)
Yes, the bloated pigware Sun/Oracle has put into Solaris is against the Unix philosphy and bad. I speak as Sun Certified Systems Engineer with 24 years experience in Solaris/SunOS. Happy?
MacOSX is a desktop system, who cares how complex Apple makes it to be easy for non-admin to use? not relevant to this discussion of a bloated complex thing for servers.
There, your questions have been answered.
Re: (Score:3)
Old-school Unix admins don't WANT anything to change, or get easier. It threatens their livelihood.
I would have my doubts that this were the real explanation. Maybe for a few people here and there, but most techies that I know wouldn't mind things being much easier. I think it's more of a stubbornness and resistance to change, maybe with a little bit of laziness in the realm of "I don't want to have to relearn things." And as you say, "I've developed some ways to make my life easier, and I don't want to re-develop them all."
Of course, there's also the possibility that some of the new ways of doing th
Re:It's job security (Score:5, Insightful)
System admins both old and new that are worth anything don't want things changing just for the sake of change.
It boils down to the old adage: "If it ain't broke, don't fix it."
Which further boils down to something admins care very much about: stability and reliability. Changing something that's been in production for 5, 10, or more years just because someone decided to roll out the new "shiny, shiny" is not an effective use of the admin's time.
Last but not least, admins are often responsible for systems from multiple vendors. Having a unique configuration model for each system goes against the whole point of things like POSIX APIs and standardized startup processing.
Sure on a desktop or developer system, the difference is probably irrelevant. But when your main job is configuring and maintaining services on servers instead of just using a box, the arguments and priorities change for damned good reasons.
Re: (Score:3)
Nonsense. systemd doesn't make anything easier or threaten anyone's livelihood, it's just change for the sake of change (at the UI level), as are the changes to network configuration. Whatever benefits there may be to whatever changes under the covers doesn't require replacing the init.d structure, the service command or the network config file formats. System administrators have enough to do without dealing with gratuitous changes that don't buy anyone anything.
Re:I call TROLL ALERT (Score:4, Interesting)
It's true that most distros are committed to using systemd. That doesn't make it a good choice, and it was often a very narrow vote that approved it, because that are lots of things to hate about systemd. Also, a large number of people don't really trust the lead developer. And .... well, there are a large number of things not to like about it.
I'll probably wait to decide that I won't have anything to do with it for awhile, though. Perhaps it won't turn out to be as much of a blivet as it looks like. But in the meantime I'm going to be checking out alternatives. Just in case. If it's as bad as some have reported, I may be switching to some flavor of BSD.
Re:snydeq = InfoWorld (Score:5, Informative)
I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... [centos.org] -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.
To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.