Slashdot Mirror
Choose Your Side On the Linux Divide
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."
Why should we even bother with this? Is there anything to this notion AT ALL, or is this clickbait?
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The Lone Ranger Linux Distro...
signed,
at least we have our pride guy
And THAT pretty much sums up what has always held Linux back (and probably always will).
SJW's don't eliminate discrimination. They just expropriate it for themselves.
yeah we lost all our old code so we can never back out our mistakes
Is this controversy anything like the P=NP debate?
Dont feed the Troll
It's not like anyone is FORCING you to use it if you don't want to, a la M$ Windows 8 "features"
I believe X.org versus Wayland would be another pair bridging the old and new Linux world.
My opinion is the correct opinion. No matter how much logic or rationale you can bring to the table, you will never be right.
Only in the open source community would people that think it is perfectly fine having to compile drivers every time a kernel gets a .1 update throw a tantrum because of a honest improvement that comes with new distributions, and just because "it breaks things". Jeeez.
System V scripts here and don't plan to change, even if my distro does, if it gets infected with systemd then I'll change distros. It really is as simple as that. Unless something goes horribly wrong there is always slackware, which as I recall not only still uses system V but still uses LILO to boot, and long may it do so :D.
http://chimpbox.us
I don't have a pony in this race. Don't know much about it. But the title says I gotta choose a side, and from the looks of things the new guard is winning, at least with this systemd thingy, so I'll go with them. GO NG GO!
"Fundamentally, I think this exposes a separation of the Linux community: between those who were deep into Unix before Linux came on the scene and those who came later. I can't help but think that a number of younger developers and admins are missing key elements of how Unix-like systems were designed and how they functioned before, say, 1998" TFA seems to imply that because I'm young, I automatically have to love systemd and laugh at the so called unix philosophy. Like the world is just a big hiveming of "old reasonable and anti-systemd UNIX wizards" VS "them hipster kids who don't know better". Thanks, but no thanks. Some vocal minority of people wanting a ridiculously large PID 1 doesn't make it sane, and just because I wasn't there when UNIX was the big thing, doesn't mean that I can't learn from it or disagree with some of it's designs.
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.
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?)
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.
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.
Don't know, don't care as long as it is well documented for us non-coding sysadmin types so we know how to configure our systems to behave in the manner we want. And big blatant announcements when $DISTRO_OF_CHOICE implements it for a release. And a smooth easy painless upgrade/change path would be appreciated too.
Don't blame me, I voted for Kodos
LOL ... Then I choose FreeBSD. :-P
Lost at C:>. Found at C.
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.
Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.
systemd doesn't play well with others and it's an architectural abomination. Not to mention that systemd folks have the reputation of not playing well with others. It does things that admins and engineers just don't want their systems to do. Hmmm... I don't like systemd and it does things I do not like... Well F!@#$ that!
If SysV isn't enough we need to start coding something new.
I too am suspicious about the quick adoption of the Upstart init system in Ubuntu. (^W^W^W oops this article is about something else?)
Upstart is an Ubuntu-Only-ism, yet lots of people are using Ubuntu, and many times they are even on current/supported releases!
Upstart is not tested / does not work with many emerging technologies, such as Docker. We should all rally together against Upstart!
Seriously, I am not sure which side I should be on. I use Ubuntu with Docker and I've become a fan of baseimage-docker, which leveraged the "runit" system of managing service processes. It's braindead simple and totally transparent. After a couple of weeks using it occasionally, I feel like I can know it inside and out as a system that provides a level of clarity and transparency that I never had with Upstart, and don't get yet with Systemd. I am writing my own init "run" scripts and touching the binaries with my bare hands, and I don't mind.
Then outside of Docker, where Upstart works, I am letting the package maintainers handle this for me, and outside of the occasional "/etc/init.d/foo is a no-op and doesn't tell me so when I try to use it", everything works as I expect and I'm never touching inits at all. It's too cumbersome. Systemd, for the little bit that I've used it seems to me like a marginal improvement over that. There are a lot of keywords and config file directives to master. There is potential that these inits could be ported into a docker container with no additional keystrokes, since systemd itself is able to run in those container/protected environments. Great!
Restating the obvious since nineteen aught five.
You clearly don't know anything. Systemd screws up everything. I'm pretty sure it gave my sister herpes.
Slackware does things The Right Way(TM). I've been using it since 1995 as my main distro with a brief detour into SLAMD64 in 2007 when I bought a 64-bit AMD and Slackware was still x86-32.
I've had the misfortune to have to suffer Debian. RedHat/CentOS, Ubuntu and Arago for work over the years, but Slackware is the best. Everything I've learned from Slackware has empowered me to be productive with all of those other distributions.
Stick Men
discussion outdated,... next!
Each one is great for getting out the gunk, but when you string them together a great result it does not necessarily make. We know a lot more about computers and systems are far more complex than they were 22-years ago. That said, I don't know or care about systemd vs sysvinit.
"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.
Who is John Cabal?
...just... make sure it's mine, mmkay?
Since most distros already use systemd, it's pretty well moot, don't you think? I smell a MS troll here...is it one of the "Pawn Stars"?
Old-school Unix admins don't WANT anything to change, or get easier. It threatens their livelihood. This is true of anyone with any kind of skill, but int computer-land, the changes come quickly.
It wouldn't be a problem if people weren't fundamentally lazy. But most people are. And admins are some of the *laziest*, because that laziness translates into an "automate everything" mindset, which is actually a good thing if you are an admin. But the idea of having to RE-automate everything sounds like work. Lots of work.
It's not like anyone is FORCING you to use it if you don't want to, a la M$ Windows 8 "features"
Huh? Since most distributions have already or plan to switch over to it, it becomes very difficult to avoid it, even if it's not actually impossible. Yes, you can use an old distribution or switch to one of the fewer and fewer distros which don't use it, but you can keep using older versions of Windows too.
The init process - whatever it is - has one job. Get things started.
SysV init didn't need more FEATURES - it merely needed (IMO) streamlining to obtain faster bootup.
The current systemd is what you get when a bunch of coders are left unsupervised - lots of "cool new features" that someone thought were "neat" and got to burnish their ego by coding, but that don't solve any real problem. And all at the cost of complexity and crazy dependencies.
It's a bloated turd in a punch bowl.
This schism is, in a sense, the unix wars all over again. Because systemd is breaking compatability with "the old way" and at the same time explicitly linux-centric, thus shutting out other OSes of the programs that (perhaps perforce) depend on systemd's way of doing things.
I don't usually put much weight into Paul Venezia's ramblings because he's not exactly on top of the news, but this one thing he has managed to discern: It's about Unix beard-types vs. spotty basement dwellers.
The poettering creature is clearly someone who likes bells and whistles on his software, but you can find it in other places too, like anything that gratuitously adds colour to output by default (cmake, busybox, various distributions) or otherwise does things that it really shouldn't. You can even extend it to the gn00 crowd, who singlehandedly sought to replace manpages with something they said was better, only it wasn't unless you loved their favourite OS-lacking-an-editor too.
I'm clearly a beardy type despite cutting my teeth on Unix well after 1988. Apparently I did get the message where so many others did not.
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.
Change and control. Why replace something that isn't broken? What necessitates this change? If there's no necessity, then what value are we seeing to prompt this change? All features and tests and comparisons aside we then get to the final bit, the control. A fair amount of control is lost by switching to a dynamic init system, and it quite simply, confuses a lot of old world admins. There are a lot of advantages to a dynamic init system, but configuring and maintaining it aren't one of them. I myself have spent my share of time lamenting the difficulty the init changes have made modifying what used to be a simple one line fix.
then does it apply to SMF in Solaris and launchd in MacOS too? I don't remember anyone asserting those to be going against unix philosophy based on having a service management facility..
"but you can keep using older versions of Windows too." No, you really cannot.
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
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.
So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)
A highly coordinated sneak attack, where the victim was essentially asleep, until 3 or 4 months after the major release, they tried upgrading to it and suddenly found... WTF? All my shit be broke, and everything's suddenly changed across all my major systems.
Systemd + Grub2 + FirewallD = Triple Whammy
for now i have become neutral on the topic of SystemD
i have Slackware-14.1 on an old 686 desktop that uses BSD style boot scripts, and i love it because they are easy to read and edit to my personal taste
i also have a x86_64 laptop that just got a fresh install of Debian Testing (Jessie) and Debian comes stock with SystemD starting with Jessie forward (unlike older releases) and so far it has not given me any problems, of course i did not do any tweaking to the startup scripts on the laptop
Politics is Treachery, Religion is Brainwashing
Interoperability used to be the biggest thing going for Linux. What gives?
Its true, I prefer the upstart syntax, but either way, its a damn sight better than those scripts that we had to write for years. Why must people hang on so much to the old when there are so many clear advantages.
But you know it'll use it as default in future releases. It's not the default now.
No it didn't. Android did. GNU/Linux is still pretty irrelevant outside of cheap servers
I beg to differ. It even has the largest growth in under $300 laptops. https://www.google.com/chrome/...
You seem to bogged down some crazy definition. When whether you are using a chromebook, an Android phone, or Ubuntu/Debian you have a shitload of companies like Samsuing and Google who now as of 2013 are top ten contributers to Linux.
Get over it Linux won. It is why Microsoft is irrelevant outside the Desktop xxx
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.
A better question is why does it matter. Nobody is forcing systemd on distros. They are free to use whatever init system them want. The only reason this is an issue is because debian change to it and all of the derivatives, including the *buntus are now changing because of debian's change. However, nobody is forcing anybody downstream to change.
Distros are free to use whatever init system they want. Now, if they don't want to expend the effort and use the upstream init system, well, that is a design decision on their part. But, they aren't being forced into it.
Clickbait is clickbait. Loving that Dice media takeover!
Congratulations systemd folks: you "fixed" a problem that isn't a problem, awhile simultaneously adding nothing of value in the process.
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?
But linux distros have grown huge piles of bash cruft around sysvinit too in those years.. I don't think systemd would be more complicated. More like less so. That's the reason for distros wanting to adopt it. It's not possible to something as simple as an if block in a shell script without risking to do something subtly wrong and unportable.
Yes. launchd is a royal pain.
I got my original MacBook because it was a good BSD Unix that ran on a lap top and would sync to my PDA (as we called them back then) and everything worked well. OS X Mavericks is getting far enough away from Unix that it is a royal pain to get real work done. Also, Linux now runs quite well on nearly every laptop I throw it at, with minimal hackery. Which leaves only syncing -- but syncing is moving to "the cloud", and with the advent of things like owncloud, OS X is looking less and less compelling.
I don't use Linux anymore and couldn't care less about systemd - if it helps drag desktop Linux further out of the UNIX stone age then I'm all for it - but this article is the most pathetic attempt to seem neutral I've encountered all day.
The "established, learned old guard" are the main reason Linux has gained a reputation for being hard to use. They're the reason that basic things like hardware drivers constantly break and the only reliable way to get the latest version of an app is to compile the source code. If the old guard are upset about systemd, that probably means it's a good thing.
I notice that of the top 500 fastest computers in the world, 97% run Linux. http://www.top500.org/statisti... That would include the $390 million Tianhe-2. Oak Ridge National Laboratory spent $60 million to upgrade the $104 million Jaguar to become Titan, both running Linux. So yeah, if you're definition of "cheap" includes "the most expensive and powerful in the world", I guess you're right.
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.
Hire a Linux system administrator, systems engineer,
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.
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.
6th Street Radio @ddombrowsky
Ubuntu doesn't support it by default because Ubuntu originally replaced sysvinit with upstart. The systemd people saw upstart, thought they could improve it, but didn't want to because it was GPLv3 and upstreaming patches requires licensing all your code to Canonical. So they wrote their own version, and as it began accreting other Linux subsystems into itself those on other init systems found themselves having to tear apart larger and larger portions of systemd to get the same functionality they had previously. Which, btw, is completely unsupported by systemd and the developers of that project take an all-or-nothing approach to the init system. Every other distro, most lately Debian, voted to adopt systemd wholesale as they realized that any other choice is custom_init + hacked up bits of systemd anyway. After Debian adopted systemd, their downstreams pretty much had to do the same or basically fork ten bajillion packages that need to touch the init system.
The current state of the Linux ecosystem is that systemd is more critical to Desktop Linux than even glibc or X11 nowadays. I would be only slightly surprised if Android started using it, too.
then does it apply to SMF in Solaris and launchd in MacOS too? I don't remember anyone asserting those to be going against unix philosophy based on having a service management facility..
It almost seems like systemd - or at least its quick uptake - is a response to launchd. Apple makes launchd available under an open source license, and it does things system v does not - but when people suggested bringing it over to Linux, there were a lot of vociferous "it's the wrong license and it's from a company I hate" responses. But I wonder if what came out of that is people began to really notice the shortcomings of sysv and started looking at alternatives in earnest.
I. AIX, Solorais and Mac OS X all use systemd like init systems, why should Linux be stuck with an init system from the dinosaur age when Unix(which linux is a clone of, not an implementation of) has evolved.
II. Linux esp. the GNU camp has ALWAYS be about politics, idealism and the good old days.
I have two desktops: one is running centos 6.5, the other was running centos 6.5, and is now running centos 7.0.
I am not seeing any improvement in startup, or anything else, with Systemd.
OT: Centos 7.0 interface (gnome3) is *far* worse than the centos 6.5 inface (gnome2).
Just my experience.
If that were even remotely true, there would not be so much protest.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The question is what was wrong with OpenRC?
It's flexible enough to do just about all the useful tasks that sysV and that systemd does.
We really don't want a kernel in user space unless you want Linux to become infected with the finder syndrome of MacOSX.
Compare and contrast SysV init vs Solaris SMF. Not that systemd is SMF but there are real Enterprise class problems with the more traditional model. And systemd developers aren't the first to notice them.
I haven't looked closely enough to have an informed opinion about how good the systemd solution is, but SMF on Solaris is vastly better than the situation in older SunOS system I've dealt with over the years
(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.
My strategy:
a) Install distribution according to purpose (default: debian, laptop: ubuntu, server/with supported commercial sw configurations: red hat) out of the Box
b) Verify if additional features needed are there
c) Add the features you really need which are missing
d) If it does not work, follow the documentaiton
e) If following the documentaiton does not work withing a reasonable time, change distribution to a more conservative one and repeat from step a
f) perform testing
g) optimize performance (up to compiling a new kernel)
Has served me well the last 20 years. If i need knowledge about systemd, i hope its documented well, otherwise its off the list.
Sorry, but this reminded me of http://xkcd.com/1095/ :-)
(I gotta say, I use MacOS and Windows more than Linux these days; but even when I was a heavier Linux user I didn't care THAT much)
At least SMF doesn't, if I recall, do more than slightly more sophisticated startup script management. Init scripts still work, and you can, if you want, handcraft the XML wrappers. In fact, underneath all the automation there's basically an old style script.
Sigs are so 1990s. No way would I be seen dead with one.
yet even though kiss is clearly stupid systemd advocates will come and say systemd is very clever yet it still doesn't conflict with kiss because... it's not clever at all. make up your minds already? systemd is the OPPOSITE of kiss, yet arch maintainers will even ban you on their forums for saying that their move was sudden and stupid. not to mention that systemd wasn't even very stable or fleshed out when they brought it to arch. i was amazed and bewildered to learn that other distros were using systemd for years already. my god those people must have been desperate for saving 3s boot time each day.
systemd is a needlessly complex and monolithic behemoth that (barley) solves a problem i NEVER FKING HAD in 20 years of using linux in all variations. no... actually it makes matters worse, because it makes me learn something i'm not interested in learning. not to mention that the transition from sysv to systemd took me 3 days. THREE days for NOTHING.
i'm just glad there's people in the community that made it possible to ditch systemd on arch... and ofc there's always gentoo.
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.
Actually, Gentoo allows you to choose if you want to use it or not (vs openrc), you can even have both init and choose which init to run from the bootloader.
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...
https://git.kernel.org/cgit/ut...
https://bugzilla.redhat.com/sh...
Stop trying to make me happy.
I was involved in another discussion in one distro where the idea was floated to replace all of /etc XML files. A number of people even proposed replacing /etc with a mysql database that could be stored on or off the local system. Of course the idea was shot full of holes but having said that, the Next Generation (TM) thinking is that of replacing the UNIX paradigm of chaining simple tools together with larger monolithic tools. One of the arguments against was that if any of this broke the only recourse would be to re-image the box (reminds me of Windows). As a "dinosaur" myself I'm not enamoured with the idea that Linux (and Solaris and *BSD to a lesser degree) are becoming more Windows-like, Personally, I'd rather be in control and I don't like it when software "thinks" it's smarter than I am.
this debate is hysterically funny. "The past doesn't matter, throw it out!" is the rallying cry every few years, and people who were yelling right along become the "old guard" in faster and faster cycles. I moved from mainframes to minis, to micros, to embedded SOCs, and each time encountered a crowd whose disdain for "the old way" meant that they had to make all of the mistakes again rather than learn from other people's mistakes (which is much cheaper). At each transition, some of "the old way" was, indeed, crap; but some was the result of hard-won experience and long stabilization, and all too often I see the good tossed out with the bad. (BTW I don't use Linux at all; I use embedded RTOS.)
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.
Apple offers a server variant of OS X as well.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
Man, If people want professional productivity tools and gaming just go with windows already and stop wasting time fucking around with linux or bsd.
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.
So, using your logic, all other executables on the system violate the first principle, too.
Next!
... that is all.
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.
systemd handles dhcp functionality, too. With IPv6 adoption growing, surely it makes sense to support it.
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
What's stopping you from booting via a boot disc or USB stick, chrooting and viewing the journal?
What's stopping you from moving the journal to another machine and viewing it there?
What's stopping you for directing the journal to a logging server?
Ignorance, by the looks of things.
Mind telling me which RTOS you use? I'm just curious about the idea.
The thing is, what we called a linux distro, is not the same anymore. Linus wanted to make some kind of cheap (by price) UNIX.
With systemd, 2 fundamental pricniples of UNIX are broken:
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
So, probably distros shipping systemd should not be called linux distros anymore. It was already a mistake to call "Linux" distos. With systemd, linux distros are as close to unix as android does...
I gave up with the idea of an useful sig...
These same people pushing SystemD were against ZFS because of point #1. The standard line is now, "We don't care about your OS. We will do things our way and if it breaks your stuff, touch shit. Now go fuck off." This is usually aimed at the BSDs these days. It is amazing that Linux has become Windows in the server realm and the Linux developers and advocates cannot see how hypocritical they have become.
My systems that use System V init don't make any of those assumptions. They just *don't*. I have some subsystems that take 15 or more minutes to boot, *because* they do complex communication - not just with other subsystems, but also with other computers and networks! So I use appropriately architected startup scripts and everything works cleanly. It's simple and elegant.
And it all works fine... unlike my systems with systemd, which tend to break hard due to routine patching.
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.
I choose the side of NOT systemd. I was not terribly impressed with upstart either. While we're at it, some may find it tangential at best, but I am also fundamentally opposed to pulseaudio. Linux has a lot of problems barring its universal adoption for both the desktop and the server market, but all of these things share the dubious quality of possibly theoretically solving a few niche annoyances (that can mostly also be labeled "user error" or "suboptimal default configuration") by sacrificing decades of tried-and-true field-tested methodologies, all the while introducing a whole slew of their own.
I hear a few sane distros are holding their ground in this regard. Slackware, Gentoo, maybe? Can anyone improve upon this list for me? I think its time the distros who sympathize actively with the "old guard" methodologies step forward and get more public about it. Many of us will be desperate to find a lifeboat, soon. I really was shocked to find out Debian was amongst the ones that "drank the koolaid."
as in ALL system configurations go in /etc..
Devs and others that think they go elsewhere need to be beaten with a sack of hot nickles. Linux has becom a giant steaming pile of crap with how freaking configs being thrown all over the damned place.
If it's a user config it goes under the user's folder. if it's system wide it goes under /etc anyplace else is FUCKING STUPID!
Do not look at laser with remaining good eye.
Yes, it would be pretty trivial to have a stable kernel ABI. But two bad things would happen:
1. Once set there would be howls of outrage over breaking it so development would be forever inhibited.
2. The second one exists the number of venders contributing new device drivers to the kernel would drop to zero. The kernel developers intentionally make it painful for binary modules and out of tree drivers.
I thought this was a nice response, and I would be interested in the naysayers' response to this response: The Biggest Myths, by Lennart Poettering.
Also, the main complaint against systemd is that it is big and monolithic, instead of a series of simple tools strung together, like cat, awk, and sed. But what about Apache, OpenOffice, and PostgreSQL?
Disclaimer: I am just a lowly web programmer, not an operating system developer or even a sysadmin.
And I'm sure that the five people who use it are quite happy
The problem I have with this debate is the lack of forks.
The whole premise of open source is that you can change the code to the way you like it. Look at XFREE86/Xorg, OpenOffice/LibreOffice, X/Mir/Wayland, Unity/Gnome3/MATE, MySQL/MariaDB, and so on. So if there is a large community of experienced Linux people who hate systemd there should be plenty of forks of major distros that use SysVinit instead. So where are they, where is the 'save SysVinit' project? Where is the Debian derivative that keeps the old scripts? For all of whining about systemd you would think where is enough people to maintain several distros. Yet the systemd and upstart teams seems to be the only groups of people actually doing anything concrete.
Linus said “Talk is cheap. Show me the code." and I think that applies perfectly here. No amount of trash talking is going to generate code, forks, or distros.
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.
And indeed containers ARE a big deal.
Compartmentalization and Virtualization used to be either full fledged emulators (VMWare, and the like) or ultra simplistic mecanism like chroot (which alows some minor way to restrict some file access but weren't really meant for that purpose in the beginning).
LXC had brought actual container (chroot on steroid, isolating not only file-system but everything else).
Now SystemD is helping even further.
At the beginning, LXC more or less meant installing a full distro under a different chroot. With all the problems of installing a full distro (needing to configure it, needing to launch a tons of things while booting it, very slow start of containers). Systemd simplifies this a lot: the system can auto-configure it-self and boot without needed any saved configuration or whatever. Just autogenerating all the needed on the fly. Also faster boot time, because the systemd's umbrella, besides the PID1 deamon (= the replacement of the old school "/sbin/init") also develops tons of other small lightweight clients and daemon the implement the bare strict minimum to be able to start a container without taking into account all the corner case that a full featured alternative might need.
The end result is that we're nearing an era when you could just tick a "run-in-a-jail" check box next to a software that you either don't trust (skype) or a public service that you need to isolate (webserver) and systemd will auto-magically take care of everything needed.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The advantage of older init systems, whether Sys V or BSD, was that I could figure them out. I did not know those systems well, I was not an expert in them. If all the scripts in them changed overnight I would be fine with that. But the advantage was that I could easily figure out how to search or hack or change them just by using programs that display or process text.
Systemd changes that. Now not even the log files are text. Systemd cannot be figured out or easily hacked. You can only do with it what others want you to do with it, unless you are willing to dive into source code, recompile and reinstall.
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
Uh, Gentoo supports SystemD just fine. It hasn't become the default yet, but it seems pretty close. I suspect a good percentage of the developer community runs it now.
I have mostly stuck with Ubuntu variants and was wondering what the fuck systemd was, now I'm hoping like hell it is not adopted.
systemd made me say hello to FreeBSD, bye bye Linux. Can't say I've been missing it.
I've stayed with Slackware for 20 years. I've looked at others, but cannot abide SysV mess'o'symlinks init. chmod +x is about all I want or need. systemd might be slightly less bad, but it is still over-complex. I reboot my machines once a year (typically Xmas) whether they need it or not.
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.
These days I only boot occasionally and it's usually when I'm stepping away to do something else .. never notice how long the boot takes.
Dont compare systemd to SMF.
With SMF:
1) The init process palms off all the service management by launching svc.config.d and svc.startd, none of the crap is piled into init itself.
2) The size of init is still less than 50k.
OK, I guess I am sort of answering my own question.. Checking the wikipedia
https://en.wikipedia.org/wiki/...
it's the init process. That page also describes that a bunch of other stuff was merged into it.
I have no idea who this is, but on the 2nd page of the quoted article, there is this quoted:
The funny thing is, I agree with those in theory... but in actual practice (yes, I'm alluding to the cliche), pine/alpine is one of the best UNIX programs around.. it's "friendly" (unlike most UNIX programs), but ALSO configurable as heck for those of us who can't stand to use its defaults (e.g. its built in editor)... and you can just move the binaries around, unlike most UNIX programs.. So it's basically a big huge program, comparatively.
(trn's another example of a huge program that does a lot of things well.)
. Now there is no Mac OSX server, just a "server add-on" pile of utilities for Mac OSX desktop. Never was a hit...
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.
I have found the OEM-VAR philosophy a useful guide.
And so I ask:
What value does systemd(8) add to UNIX, that was not there before?
What value does systemd(8) take AWAY from UNIX, that WAS there?
What do we value in UNIX?
I say, we value diversity. systemd(8) takes away diversity.
We value openness, and flat text files. systemd(8) takes away openness.
We oppose the concentration of powers. UNIX is democratic. systemd(8) concentrates power (others have said this as well).
BUT, systemd(8) raises an interesting question: how can the boot process be improved, given that, with multiple processors ... processes no longer NEED, in many cases, to be run sequentially?
The issues surrounding parallel execution are not new. The same sorts of issues are raised when a compiler encounters a bunch of files and needs to figure out which pieces can be compiled to execute in parallel - IE, where the dependencies are.
The UNIX community has been well aware of these issues for decades. There must be a good reason why UNIX, itself, has not been improved. Perhaps reliability has a higher priority than speed. We need to ask this question.
Speaking as a UNIX systems and network administrator with three decades of experience under my belt, I can tell you all about dependencies, and about keeping things simple. And THAT is why I like init, and shell scripts.
(Because if you can't write a working start script, or troubleshoot a failing start script ... you probably shouldn't be logged in as root. But this is another topic.)
Or maybe it's just a question of the cobbler's children going barefoot - we're all so busy taking care of other peoples' problems that we rarely have the time to take a step back and think about our OWN problems.
It is a true statement that faster boot times are required if UNIX is going to penetrate the desktop market - schools can't afford to wait five minutes for laptops to boot.
In closing, I would like to say that Lennart Poettering is not helping matters with his arrogance.
Although he claims PulseAudio is demonstratably superior to every other contender, I've never seen any evidence supporting this.
I've spent the past few weeks compiling ports under FreeBSD 9.3, with an emphasis on multimedia-capable browsers - and I can say, with 100% confidence, that none of the dozens of software packages I configured had PulseAudio selected as the default - although many of them had it listed as an option - along with Ogg-Vorbis, and all the others.
~childo - the old guy who newgrp'd alt.conspiracy, before some of you were even born.
Get off my lawn!
When I was younger, I loved learning how to do shit in DOS, then later in Linux. It was fun. Now it's just hell.
I suppose some of the reason I thought it was fun was because once I learned to do something, I could do it whenever I wanted. So I was picking up valuable skills. However, anymore when I go to do something, I find it's no longer done the way it used to be done. No, now there's some new and "better" way to do it that is only ten times as hard to understand. So I waste a day or two learning the new way of doing things, then decide I need to upgrade, and what do you know: The last two days were a complete waste of my life because now it's done some other way.
Needless to say, I don't want to learn anything anymore. As time goes on, the new way of doing things becomes progressively more complex than before with less explanation than before. I mean, I once tried to look into how to properly put something into the startup scripts of Linux Mint 15, and all the documentation I could find was "it's easy, it's like a shell script" even though there was clearly shit in there about dependencies that was nothing like a shell script. So just how much like a shell script was it? I didn't know, it didn't say. So what do I do about that dependency stuff? I don't know, it didn't say. So I just read the whole manual, front to back? No, I don't care to spend three days trying to figure out how to do one simple fucking thing. So I just tried something that looked about right -- after all, everyone on the internet was convinced it was so easy that I couldn't possibly need help -- and ended up with a system that would boot correctly about 50% of the time, and the other 50% of the time the GUI would start up too soon and I'd have to log out and back in again before everything would work. ...and, what do you know: If I'd bothered to learn the init system of Linux Mint 15, I would have been wasting my fucking time, as they're now going to switch to systemd.
I really need to install FreeBSD in a virtual machine and start learning to use it. Maybe do Linux how Linux people used to do Windows: Just keep it in a VM for things like watching YouTube but otherwise try to stay the hell away from it. I tried it once a year or two ago, and it was generally nice in that nothing seemed as retarded as shit tends to get in Linux. The only real problem I had was that the user base is small enough that when I couldn't figure out how to do something, not only was there no help, but it was quite likely I was the first person to ever want to do what I was trying to do. E.g., I wanted to do some MIDI stuff, but found no MIDI routing subsystem, and the applications in the ports system weren't actually capable of connecting to what MIDI support there was. On the bright side, they didn't have ALSA, and so I found fixing that to be rather easy. An OSS implementation that's actually able to allow multiple applications to play audio at once is wonderful.
How much effort does it take to create a systemd service wrapper to run init.d scripts, run sysvinit from systemd or run both independently. My guess is a week of work for a competent developer. If nobody is willing to invest this much time, people should stop grumbling and accept that minor changes like that are inevitable.
I did. And let me tell you, putting your faith in a Master Control Program is a very, very bad idea.
I'm responsible for a bunch of servers now.
One of them has a uptime of 660 days. Other, 120 or about it. My server with the lower uptime has 35 days - it has 37 days of life, by the way.
I'm not slightly interested on the booting speed of these machines - my main concern is the speed of the diagnostic procedures I need to carry on when something goes wrong.
God saves the runlevel 1.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
So I switched to MacOS. If it's not going to be transparent and I have to spend time digging around and doing system-level stuff in the non-Unix way, why not do it on a system that's at least got great UX and lots of officially supported hardware and applications?
STOP . AMERICA . NOW
The battle is between the distros who decided to ship systemd and the users who didn't realize they were having their OS tools they know how to use thrown out.
The vast majority of users are not involved in the development of their distros ... they find out the hard way *after* things become default, like this.
- Michael T. Babcock (Yes, I blog)
/etc/rc.d/rc.S on my Slackware system is 400 lines of bash. That doesn't look too complex to me.
As long as people don't start depending on systemD, I have no problem. It's like ALSA versus PulseAudio: you want to run that on your system, fine, but I'll stick with ALSA kthx please don't rip out support for it.
vi ~/.emacs # I'm probably going to Hell for this.
im getting used to systemd, scripts init and Sysv.. using arch linux on my laptop, slackware on desktop and RHEL back at the office . who knows whats going to happen, so the best advice is to learn to live with everything. heh
I was looking for an appropriate thread to make the same suggestion. I come down on the side of the sysvinit people when it comes to servers and other stable installations. OTH, I come down on the systemd side when I want my laptop to correctly connect to the appropriate WiFi network (but only if not connected to a wired network). It really makes sense to support both. Stability, reliability and simplicity for the server folks and something more flexible for desktops and laptops.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Bout time linux forked.
Tell me more abpout how having a dependency chain to your init is a good thing?
Most of the people complaining here about systemd say they don't like it because it breaks the philosophy of init being configured by shell scripts and not by config files. Slackware's Volkerding said basically the same thing. So if Ubuntu's upstart is stated to be perfectly backward compatible with the init scripts, isn't it the better choice? Is systemd really better than upstart or is it that just everyone loves to hate Ubuntu.
The time when people who had no idea started to believe they could create something better then UNIX.
This created the mess we had in the 1990s when it was OK to have log files in binary files and you could only view them through a small non-resizable window. A time when you could display the owners of open files on your network share... but you couldn't do anything with that info except for writing it down and manually act upon it. Of course that data was also displayed in a small non-resizable window.
There is a reason why normal init is based on shell scripts, and that reason is simply because there is no reason against it. Shell scripts are perfectly adequate for that job. Binaries on Unix however make it much more difficult to deal with them. If you want to edit a binary you have to get the source code, edit it, make it compile, and then hope it'll run. It's even worse when you have dynamically linked binaries since they depend on other files, particularly for init.
Binaries are just a botched solution to somehow get faster execution. The whole design of Unix doesn't require them. Unlike Windows you shouldn't need to link in a library to have some API you should instead have a little program you can call. (actually Windows now has a little wrapper allowing you to make arbitrary calls to DLLs since even Microsoft has recognized the problem)
Dynamically linked libraries are just a botched solution for the problem of library bloat. You shouldn't need them, if you want some feature you should just call the program implementing it. That's how bc worked originally. All the calculation functionality was in dc and bc just re-formated its input to what dc expects. The problem why this doesn't work well any more is long startup times caused by library bloat.
Not if you're responsible for the upkeep and maintenance of large production systems.
I've been working on, developing for and using Linux since 0.94 . I am currently trying to understand the idea of systemd. I almost never have to reboot my linuxes (not even on my laptops), even if I reboot, those SSDs makes it quick, I am glad that I can grep or find -exec grep through the whole system to find stuff I need, I find the idea of cryptic (or even binary) config files repulsing (vs. bash scripts) and un-unix, network-manager is the first thing I disable (who needs it anyway/). systemd gives me nothing in return for trying to understand it. It kind of feels like se-linux. Sounds like a good idea, unless you do something the packagers didn't expect .. like moving the database-files somewhere else or gosh! roll you own servers. Than you ether need to go down and dirty or echo "0" > /selinux/enforce .. oh wait, it's now /sys/fs/selinux ... I don't know why the development of Linux has changed to focus on 'Lindows' (I know .. ) .. but for us server folks, the direction doesn't seem to look good. I simply hope that somebody (maybe even myself) will spawn a server focused Linux that concentrates on stability, easy maintenance and reliability instead of gimmicks.
We've seen this architecture where scripts are replaced by configuration in Java since long (first a bit in Ant, then more in Maven).
We've seen this in XPath, which is by nature of its syntax (XML) configurative but fights hard to script something.
It's not good, folks!
We've seen the monolithic architecture before in J2EE, mainly because Java has nice interfaces to Java and not-so-nice interfaces to the rest of the OS.
Do you know of any oh-so-modern Spring library that nicely talks to syslogd?
What about cron being re-implemented?
It's not good, folks!
In my opinion, we have a new generation of graduates who don't understand modular system design or functional programming or assembler or real-OO.
And we have everyone else, who doesn't fight for the principles because we are pragmatic and there are not many alternatives anymore.
Sad.
That someone sounds like he was the /dev/null of the ancient tribe, Having no output and ignoring input.
Mobile. Linux on the desktop is not a big thing, on servers the boot-time doesn't matter, but for mobile applications the ability to fully shut down and boot on demand can be a huge energy saver.
1) Everything is a text file
Everything acts like a file. You added the "text" part yourself.
After much yelling and screaming on the CentOS mailing list, I still see *nothing* that was so broken or unwieldly in SysV that it needed to be completely replaced. And by something that requires a lot more typing.
And I *so* enjoy telling a service to start, and having *zero* feedback.
While we're at it... GRUB2 MUST DIE!
mark
I'm pretty sure that most of the main guys working on Wayland are guys that have been involved with X for a long time.
Most of the people who are complaining about SystemD are either the BSD guys or those who maintain smaller distros. I'll start with the smaller distroes: they don't like it because it's a lot of maintenance (see Fuduntu), and is pretty bulky for a smaller distro. For something that is designed to be simple, reliable, and well understood by one person, SystemD goes against the principles established by these smaller distroes (Slackware, Gentoo, LFS, etc.). For the BSD guys, they actually don't care about SystemD: it doesn't affect their world, and seeing as SystemD isn't compatible with any of the BSD kernels by design, it would be fine if it were on it's own. The big problem is that SystemD is also converting applications to rely on it, and it exclusively - GNOME 3, anyone? When this happens, it starts to cut off their supply of software, and at the very least adds so much more maintenance and hassle. It's really annoying, especially given SystemD's newness, lack of a track record, and intentionally trying to be as hard to port as possible. On the other end of the spectrum, there are the SystemD proponents, mostly Redhat and Debian guys. They like it because they often maintain massive systems, which are pretty complex. At this point, integrating everything into one init process saves so much work, and makes life much easier. Neither crowd understands the other, understandably because of the vastly different approaches. The real probelm is that the SystemD proponents are pretty pushy, and insist that SystemD be used in places where I don't think it makes sense. If nothing else, maintaining compatibility would be nice, but they intentionally break it. Because of this, the classic init crowd feels threatened because their way of life - computing, same thing to us nerds here ;D - is disappearing. When this happens, there is naturally a great deal of resistance, and that's where the tensions lie. My recommendation would be for software to try to avoid being specific to either init system, and instead let the user decide. The two groups can coexist peacefully, although less aggressiveness from the SystemD people would probably go a long way towards helping this. I've tried to provide as much of an unbiased view as possible, and I hope someone finds it helpful. If I get buried at the bottom, never to be seen again, I wish the person reading this in 2034 a good day! Yes, you're probably thinking SystemD is old, crufty, and is probably about to be deprecated, but it was hip and trendy at one time, much as that blows your mind :D
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
The HURD users outnumber the Server Mac OS X users.
I know tobacco is bad for you, so I smoke weed with crack.
When an obvious software bug gets blamed on everyone and everything else but the buggy software, When a program breaks functioning systems and it is the functioning systems fault it no longer works.....
Hey, we've gone through this bullshit with Microsoft long enough, that every problem is "The stupid user's fault". No thank you. Get a new attitude, show us how good it is rather than blame us when the hardware quits working. It removes a huge reason I moved to Linux.
Or move to programming for Microsoft. That attitude might just fit in gangbusters there.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I'm not an expert on systemd or why the change was deemed necessary. All I know is that last year when Arch Linux made the change, the update crashed my installation and I had to reinstall from scratch. As a non-expert casual user, the switch came out of the blue, was never justified, and when I went into the forums the attitude from the "experts" was shut up and learn to live with it.
I'm not pathologically averse to the idea of replacing the classic SysV-initscripts in Linux distributions (having used them for 15years, I am well aware of their limitations), but I personally believe the overall migration process should be executed with far more caution, preparedness and reservation than currently demonstrated if I am to place more trust in systemd.
1. Given that the Linux kernel by design will go into kernel panic if PID 1 crashes, I think it would be CRITICAL that any systemd code that runs in PID 1 should be formally verified, and kept to a minimum size/scope as possible. The classic sysV /sbin/init C code was able to fit on one A4 page, for example.
2. I think the salesmanship by systemd advocates is very poor - trying to sell the concept of systemd on "faster boot times" is largely irrevelant for many environments (server, some workstation) where the systems spend most of their time powered on and rarely reboot (or already boot fast enough with sysV init that the time gains are negligible).
Hence some people are reluctant to take on the increased complexity of systemd for little gain, if any, and I believe that's a valid position to hold.
3. I would not feel comfortable using systemd unless the documentation was extensive and accurate enough to allow someone to carry out a manual migration from SysV initscripts to systemd.
Understanding which functionality in systemd replaces previously needed functionality in SysV initscripts will help greatly with trying to troubleshoot failed boot processes. This will also help users plan how to migrate back to SysV init (or some other startup process) if systemd doesn't meet their needs.
I've spent the last 15 years learning the SysV-style initscripts, and I think the systemd developers need to show respect for the learning commitment that system administrators and UNIX/Linux users have invested in the SysV way.
4. I'm also very wary of userspace application software that forces adoption of systemd through dependencies (such as recent GNOME 3) - the use of systemd by user-space applications should be entirely optional (at the very least configured at compile-time if not run-time).
I think systemd should need to win its place based on its own merits, rather than being "snuck in through the back door". Distros should have an install-time option of either classic SysV or experimental systemd for startup.
I like init. Its worked fine for years. I understand that some people like systemd and that it does a few other nice things that might not be available for init. Ok, so here it is: if you really want me to like systemd, then it had better be backwards compatible with init. If not that, then at least make sure that it doesn't break current functionality (all current functionality). I know I'm talking inertia, but 'first do no harm' is not a bad mantra for operating systems too.
SYSV and BSD
Gnome and KDE
Didn't care which one - SYSV or BSD back in the 1980s, pick one and all of us - use it! Didn't happen. That BS still rages on today when BSD was rescued out of oblivion by replacing the Apple OS with a modified version of it.
Gnome and KDE - again, pick one. Can't have that now can we? Let's fragment everything!
Now this crap. I go back to the mid 1980s with Unix. It built my house and has paid for everything I own. I'm happy to move to the new way. It's better. SYSV - nice knowing you. I'll put you in the back of my closet like I did with the Casette, 8 track, other stuff that had a good run. I'm sure I'll always remember you.
Not to say that the new way is a bed of roses. Getting better, however.
For me, unix is robust and stable because it's simple.
Nowadays sysadmins needs ubuntu server and a nice desktop to do the job. At the end, windows server was not so bad...
I worked on solaris and it's 'services'. Editing and validating xml files instead of modifiying conf files was not a plus for me but a pain in the ass...
It boot faster!!! So what! my servers are not supposed to reboot...
Perhaps it makes sense on a desktop computer but I don't see the point of using it on a server.
What about embedded devices and their low resources ?
Linux need more skilled and experienced sysadmins and less enthusiast geeks. Too many distros, too many forks, too many projects, too many githubs.
Don't forget : Keep It Simple and Stupid and read "linux from scratch" docs.
However, Apple offers no server-class hardware to run their toy OS on, nor will they allow you to run it on other hardware. So it might as well not exist as far as most people are concerned.
Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.
I think it's partially because containers are the hot thing right now.