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.
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.
Indeed. Civilized nerds don't fight; they fork. (God won't let us fork the Middle East, unfortunately.)
Table-ized A.I.
I believe X.org versus Wayland would be another pair bridging the old and new Linux world.
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.
Oh I think people have been forking the middle east for quite some time.
Mod me down, my New Earth Global Warmingist friends!
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.
It's "forked up", if that's what you mean.
Table-ized A.I.
P and NP can be verified given enough resources. systemd can not.
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
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?
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.
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..
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
> 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
Must be a FreeBSD thing since this is a solved problem in Linux.
You need to update your FUD playbook. It's out of date.
A Pirate and a Puritan look the same on a balance sheet.
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
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.)
I think we've pushed this "anyone can grow up to be president" thing too far.
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!
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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
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.
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.
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...
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
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.
Fork bomb it from orbit, it's the only way to be sure...
I guess you don't know anything about servers? It's a whole different world, you wouldn't understand.
Are you really arguing that the huge number of people all over the planet who have complained about structural problems with the Unix init system for the last 50 years are in error because you don't mind 15 minute boots but do mind patch problems?
PC-BSD would probably be your best bet for a desktop BSD. It's got the same newbie-friendly vibe that you see with *buntu but is pure FreeBSD under the hood.
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.
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.
You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools that does one thing a does it well. "hostnamectl" sets and displays hostname information, systemctl stops and starts services, "localectl" control the system locale and keyboard layout settings, etc.
All the systemd tools (*ctl) are just totally normal Linux tools; yes, you can use pipes, direct output, and combine them with all the standard tools like grep, tee, sed...
The systemd tools doesn't break any of those rules you listed.
Sure, some of the systemd daemons (not tools) are specifically designed to talk to each other, in order to have logging info from eg. early boot, or in order to prevent a daemon from forking if the kernel capabilities forbid it, but this behavior is quite common on all unix'es.
Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
This is a good place to start, together with a Linux distro that uses systemd:
http://www.freedesktop.org/wik...
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...
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.
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
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.
It's not Linux, it's the runtime system, so there is no need to fork... but I think it's about time for a distribution to actually take the Unix philosophy to heart and to throw out all that new crap.
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.
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.
I started seriously with Linux in 1999, after 5 years of WinNT4. And I do not like the systemd.
SystemD is a reinvention of Windows for Linux. It's even made the same way as the Windows: modular design with monolitic architecture. Just like a card house: pull one card, and the whole thing comes down.
That's why Linux back then was like a breath of fresh air to me. Coming from NT4 (which was hard to keep working) to Linux (which I could bring back from a fatal failure in under 15 minutes) pretty much exemplified to me how *NOT* to design the software.
SystemD is indeed the "second system effect" which (unknowingly?) implements many errors of the Windows. The errors which still hunt MS to this day!. (E.g. all embedded Windows attempts failed. Now they have a dedicated embedded system - WinPho - because porting the "card house" to another device built around different paradigms is hard and costly and error prone. It works like crap in the end, while providing no benefits to developers (making portable applications proved to be futile; with WinPho MS stopped promising it) and consequently users.)
All hope abandon ye who enter here.
And even with init scripts you can do things in a way that isn't slowing down things - you can start that database engine in the background. It might require some knowledge about how to start a background process using 'nohup' and have applications waiting on the startup of the database, but nothing that should block the accessibility.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Unfortunately, it doesn't seem to read large ext4 volumes. Gentoo is looking like the better option.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools
Could somebody then either rename the collection of tools to have a name that doesn't sound like the name of a UN*X daemon, or rename the tool in that collection that some Linux distributions run in process 1 to something other than "systemd", so that people don't confuse the collection of tools with the init-process tool in that collection? This might fix at least some of systemd's public relations problem.
(I mean, srsly, Apple's made some changes to "traditional UN*X", but they don't designate mDNSresponder or the ASL-version of syslogd or... as parts of the "launchd" project.)
so, there was tail -f /var/log/syslog, now you need an own tool.
Unix: Everything is a file, small general purpose tools, which do one thing well.
yeah, more like tail on a logfile than using a *ctl tool. And a initsystem running just a sequence of commands instead of trying to manage daemons in containers ... if i want a daemon to run in an own cgroup, i set it up to do so.
Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
I'm afraid you're just trying to cloud the systemd nonsense with nonsense of your own, which is a classic tactic of the passive aggressive way in which the systemd crew deal with things.
Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
I'm afraid you're just trying to cloud the systemd nonsense with nonsense of your own, which is a classic tactic of the passive aggressive way in which the systemd crew deal with things.
Totally wrong. I mere point to the fact that almost none of the ranting systemd detractors have a clue what they talk about, for the very simple reason they haven't read the systemd documentation (which is quite large), looked at the source code, or even glanced the 'man' pages.
The amount of straight up factual nonsense you hear from systemd detractors is simply staggering, they just repeat memes spouted on some blog by a swivel eyed loony, instead of simply starting to read the systemd documentation:
Like or not, systemd is the future of Linux, the vast majority of all Linux distros will use systemd, so every Linux user should cram up on systemd, the sooner the better.
so, there was tail -f /var/log/syslog, now you need an own tool.
Unix:
The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs.
How about "journalctl _EXE=/usr/sbin/smartd -f" ? Now you are "tailing" the output from a single executable.
Don't worry that the command line seems long: there is tab-comppletion for everything. That is the power of an index log file: every process, daemon, commandline, kernel subsystem etc. that have ever written to the log file are indexed so they are tab'able. The journal have total knowledge of all entries; they can all be traced back to whatever wrote them. Notice the underscore in the field value _EXE, that means that there is kernel guarantee the entry isn't faked.
Spend some hours playing around with journalctl. You will never want to go back to unstructured text log files again.
Everything is a file, small general purpose tools, which do one thing well.
That is a perfect description of the tools in systemd.
yeah, more like tail on a logfile than using a *ctl tool. And a initsystem running just a sequence of commands instead of trying to manage daemons in containers ... if i want a daemon to run in an own cgroup, i set it up to do so.
OS containers are a big thing (tm). Because systemd is running as PID1 and have total control and supervision of all processes in the system and can control them with e.g. cgroups, it is possible to have OS containers that runs _unmodified_ from the host system. That is beyond a humongously big thing (tm). No need to "Dockerize" your OS/app.
"Dumb" init systems like Sysvinit, who just throws some processes up in the air and then promptly forgets all about them, are unable to so.
Systemd is seriously the most cool technology that have come to Linux for years. It really saddens me that the joy of hacking new Linux technology seem to have disappeared.
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.
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.
> The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs. /var/log/apache/access.log, for systemd you need to remember the tool. Now imagine, every program would bring its own "view my logs" tool ...
And there is the Problem.
File+Minimal Utility -> SystemD specific tool.
The tail command can easily pointed to the next file, i.e.
> That is a perfect description of the tools in systemd.
its not. see your own example.
> The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs. /var/log/apache/access.log, for systemd you need to remember the tool. Now imagine, every program would bring its own "view my logs" tool ...
And there is the Problem.
File+Minimal Utility -> SystemD specific tool.
The tail command can easily pointed to the next file, i.e.
You don't need tail, and you don't need to point to some particular daemon's separate logfile when using journactl. /usr/sbin/smartd" (Tail all smartd generated log entries at loglevel "warning".) There are many other filters (see the FIELD values in the man pages).
First, the journal contains all logs on the system, so there is no need to hunt around for various logs like "access".
Secondly, it is childs play to filter out a particular deamon's log and tail it like "journalctl -p warning -f
Sure, journald can easily cope with multiple logfiles and even interleave them using e.g. monotonic timestamps for easy comparisons between different machine boot sequences etc. You just don't need to point on any files without such special needs.
journalctl is just a filtering device like grep, just much easier to use for powerful filtering since the journal is structured and indexed.
You don't need journalctl to read journald logfiles; the journal is well defined, and there are API's and language bindings to create your own journal reader or log-watcher etc. AFAIK, rsyslog already reads journald logfiles.
The bottom line is that systemd's logging facilities are a giant leap forward for Linux, and since basically all Linux distro's are about to use it in the future, it is worth a serious study. This may be a good place to start:
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
> You don't need tail, and you don't need to point to some particular daemon's separate logfile when using journactl.
> First, the journal contains all logs on the system, so there is no need to hunt around for various logs like "access".
THIS is the problem. journald is your syslog, my favourite program does not use it. and now?
Then imagine, everyone would behave like poettering. Hey, for my favourite program, you need another "view logs" command! And for mine, another, too!
No. Lets keep it textfiles, which can be used with textfile programs.
syslog still has a role to play as a logsink, but it is simply outdated compared to systemd's journald. Just the fact that it can collect log-files from the early initramfs stage, before root is mounted, is superior to what syslog can do.
Monotonic timestamps, indexed logfiles, multi-language support, rich meta data, ... The feature list is long and syslog can never gain most of the features because its file format is so primitive.
And again, the journal works with every textfile tool imaginable through the basic concept of piping. The journal only enhances those tools, it does not prevent their use.
The reason why all major Linux distros have switched to systemd, is simply that it is a vastly better technological solution than everything else. Don't get stuck in the past by refusing to learn anything new, just before you know the old stuff so well.