Ubuntu To Officially Switch To systemd Next Monday 765
jones_supa writes: Ubuntu is going live with systemd, reports Martin Pitt in the ubuntu-devel-announce mailing list. Next Monday, Vivid (15.04) will be switched to boot with systemd instead of UpStart. The change concerns desktop, server, and all other current flavors. Technically, this will flip around the preferred dependency of init to systemd-sysv | upstart in package management, which will affect new installs, but not upgrades. Upgrades will be switched by adding systemd-sysv to ubuntu-standard's dependencies. If you want, you can manually do the change already, but it's advisable to do an one-time boot first. Right now it is important that if you run into any trouble, file a proper bug report in Launchpad (ubuntu-bug systemd). If after some weeks it is found that there are too many or too big regressions, Ubuntu can still revert back to UpStart.
ABOUT FUCKING TIME! (Score:3, Funny)
Now time for me to switch to Windows!
Re:ABOUT FUCKING TIME! (Score:4, Insightful)
Interestingly enough, 15.04 is deep into the Beta status and due for release next month. A major change, such as swapping out the init daemon, should be done in Alpha, and far before any Beta release. Certainly not in the month before a release!
Why is everything connected to systemd pushed out in such a hurry? Why isn't systemd getting proper time for review?
Here is the Ubuntu 15.04 release schedule:
https://wiki.ubuntu.com/VividV... [ubuntu.com]
Re:ABOUT FUCKING TIME! (Score:4, Insightful)
Re:ABOUT FUCKING TIME! (Score:4, Interesting)
What you say is very true. IMHO Ubuntu has become an answer but someone that forgotten the question.
I lost faith with it around the 2012.4 release. Far too much essential stuff unfinished.
Went back to Debian for a while but a new job in 2013 has given me an insight into the RedHat world. now I run CentOS on my laptop. Rock solid.
However if you want nowt to do with 'systemd' then there is very little choice left. Even Debian has gone to the dark side.
BSD? Off you go then.
Personally, I think that Ubuntu is becoming increasinly irrelevant with each release.
Re: (Score:3)
Well, Gentoo will never make your run systemd, or even udev. Come over, we have cookies (which you can compile yourself)!
Re: (Score:3)
Re: (Score:3, Informative)
The question is: "What is the maximally fucked-up linux distro?"
Well, that would be Suicide Linux, obviously.
Re:ABOUT FUCKING TIME! (Score:5, Informative)
Link: Suicide Linux [qntm.org]
Re:ABOUT FUCKING TIME! (Score:5, Informative)
Really, though, if you're sticking anything but an LTS version onto bare hardware you're asking for trouble. They're very up-front about non-LTS releases like 15.04 being barely-supported betas for LTSes. So in that sense rolling out systemd at this stage is a pretty good idea since they'll have a year to work out kinks before 16.04, while IIRC they switched to PulseAudio not long before the LTS 8.04 release, with disastrous results.
Re:ABOUT FUCKING TIME! (Score:5, Informative)
Ubuntu 15.04 is not a LTS release, it's a testbed for features looking to be included on the upcoming Ubuntu 16.04 LTS.
It is not recommended for production systems. If you want the latest stable version, use Ubuntu 14.04.2.
Re:ABOUT FUCKING TIME! (Score:4, Funny)
Happily, if systemd really is a train-wreck in the making, there are still some other distros keeping the altneraties alive. So if Canonical and/or Debian ends up regretting the choice, there should be the living knowledge for a while to revert.
Re:ABOUT FUCKING TIME! (Score:5, Insightful)
Re: (Score:3, Interesting)
I'm thinking of a few specific aspects of how the ACA passage happened.
The first is Pelosi actually convincing members of Congress to vote on the bill before reading it. I.e., her infamous "you'll have to pass the bill to find out what's in it" gambit. (It takes a lot of self control to not go into a tirade every time I think of that.)
The second is this: NPR did a great story talking about a variety of healthcare systems around the world, in terms of cost, outcomes, and implementation details. (Germany's
Re: (Score:3)
Re: (Score:3)
I don't think so. It's doubtful she had a clue what was in it aside from a broad overview of the key parts. It was after all over 2,000 pages, right? It was a glib assurance which we see in hindsight was unjustified.
Sigh. As I said, the bill had already passed her chamber of congress, so she had either forgotten about that (I suppose you'll say that's possibility), or she was referring to the Senate reconciliation process. I'm not even saying I disagree with the point you're trying to make, but the comment is still taken entirely out of context. I'm certain there were people in the Senate debates... the *year* of debates, that knew full well what was in the bill.
FY2007's omnibus budget bill was 1400 pages. You're usi
Re:ABOUT FUCKING TIME! (Score:5, Informative)
I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves.
I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.
Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.
Re:ABOUT FUCKING TIME! (Score:4, Insightful)
I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves.
I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.
Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.
You mean they took the people that actually have to deal with init scripts and made them happy? Instead of making something good that would make people using init scripts happy?
Wait. What is the difference?
Re: (Score:3, Insightful)
Funny-looking duck you have there.
Almost everything you say there is blatant misinformation. Way to spread the FUD. Pretty amazing stuff. Especially your idea that there's no technical merit to systemd, and by extension replacing upstart, which replaced sysv.
90% of systemd's suite of utilities are not part of init, and not even required or used by most people and their distros. It does, though, make containers and cloud a lot easier for those who want to do that. Certainly makes administration better o
Re: (Score:3)
That's kind of the point. It's a fucking octopus that doesn't even offer enough of an improvement over other forms of init to justify such widespread adoption. It's not ultra-fast like the one that had a proof of concept on the eeepc, so instead it's more like change for the sake of change. Binary log files at startup when you have little available if it hangs and other idiocies that are a step backwards.
Re: (Score:3, Informative)
Re:ABOUT FUCKING TIME! (Score:4, Informative)
Wow, what the hell do you take us for? Aluminum foil? Aluminum foil?! The shit you put on your TV antenna to get better reception? Yeah, yeah, that's really going to block the government mind control rays.
Jesus. Tinfoil man. Tinfoil.
Re: ABOUT FUCKING TIME! (Score:3)
Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).
Re: (Score:3)
Re: (Score:3)
GNOME single-handedly fucked up the Linux ecosystem when they decided to make systemd a hard dependency!
Systemd is not a hard dependency of Gnome, and probably never will be. I'm not sure why people think that.
Re: (Score:3)
Re:ABOUT FUCKING TIME! (Score:4, Informative)
Re: (Score:3)
Not ready for primetime (Score:5, Funny)
It still doesn't have a decent architecture for scheme plugins and a robust text editor.
Re: (Score:3, Informative)
Re: Not ready for primetime (Score:5, Informative)
Re:Not ready for primetime (Score:4, Informative)
The upstart team will be disappointed.
Here are two interesting talks presenting the two approaches: systemd [youtube.com] vs Upstart [youtube.com] for Debian.
I learned a lot about what systemd actually is and does.
Comment removed (Score:5, Funny)
Re: (Score:2)
Needs more blood.
Re:Watching systemd evolve (Score:4, Informative)
But but Fedora has been using it for years without issue! Oh wait, that's because no Admin in their right mind would use Fedora as a server. But but it is stable and secure. Oh wait, your high load servers keep corrupting the journald and journalctl can't read portions of it without trying to replace the who journal with a new one. But but you can install rsyslog to fix that! Yeah, because we ALL like having to beta test an unproven product in a production environment only to be forced in resorting to something else that actually works as intended.
I'm caring less about systemd and more about how shortsighted they were when they forced everyone to use journald. The fact that I have to configure rsyslog to have a working log that does not constantly get corrupted and restart a new log, erasing the old one is annoying and shows just how unproven this entire systemd implementation truly is.
Re:Watching systemd evolve (Score:5, Insightful)
When you pretend to be a foolish version of someone else, in order to mock them, you only make yourself look foolish.
If you really have a valid point to make, argue against your opponents' best points. Don't make an ad hominem attack against a caricature of the opponent.
Re:Watching systemd evolve (Score:5, Informative)
Fedora is a testing ground for Red Hat Linux, you know, the predominant server distribution. Red Hat Enterprise Linux have systemd starting with version 7.0 and Ubuntu just joins the ranks of every other enterprise Linux distribution to use systemd, like SUSE Linux Enterprise Server and Mageia. So, you are ignorant of the facts to call systemd an "unproven product".
Re: (Score:3)
Indeed. This is crap-ware in the finest tradition of old Windows releases. Unfortunately, parts of the Linux-community seem to have forgotten why good Linux software is stable, secure and mature.
Re:Watching systemd evolve (Score:5, Informative)
Don't get your panties in bunch just because you discover that the journal is "corrupted"; usually it is just trivial stuff like a malformed timestamp or a field value that isn't valid in a single log entry. journald actually test and validate incoming log messages and report errors as it finds them. Even then, you can often read the log entry, but of course, the invalid field value will be missing.
The reason why people discover "corrupted" journal log files is because systemd's journal have integrity checks, unlike syslog who doesn't and where the admin therefore never will know if there are spurious or invalid log entries unless he happens to stumble upon them by chance.
Seriously, if you really care about each and every log entry, you should never have been using syslog anyway; it simply silently drops messages under load, and both local and remote logging are inherently unreliable. Yeah, I know Rainer have made a signal-safe syslog library, but does anybody actually use it?
There are simply too many Linux newbies who seems to be unaware of decade long struggle to improve the many, many problems with syslog. The "rsyslog" team have fought heroically, but often in vain, to try to fix many of the problems.
Syslog, like cron and SysVinit are among the several pieces of Linux infrastructure that can't be changed or radically improved. Because if you change your syslog/cron/SysVinit implementation, it would be incompatible with syslog/cron/SysVinit, so no one would use it, because user space programs doesn't support it etc. A circular dependency that prevent all progress. The systemd project have finally broken Linux free from that quagmire, so now we can actually have Linux infrastructure developed in the same pace as the kernel and user space programs and daemons.
systemd's journal is, warts and all, a massive improvement over the what existed before.
Re:Watching systemd evolve (Score:5, Informative)
Here is one of many:
https://bugs.freedesktop.org/s... [freedesktop.org]
The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog
Lennart Poettering's comments about it:
"our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse"
Re:Watching systemd evolve (Score:5, Insightful)
Nice. This person does not even understand what logs are for and why it is critical to make sure they get to disk uncorrupted if possible at all. A decent system will achieve that as long as the disk is still up. systemd apparently does not even try to.
Re: (Score:3, Interesting)
Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?
Re:Watching systemd evolve (Score:4, Informative)
Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?
Utterly false. The idea that syslog doesn't have corruption is false. I have seen syslog corruption many times. Whether it's truncated lines, merged lines because half of an old truncated line has a new message appended, blocks of 4k zero bytes, or single bit or single character errors.
In particular if a syslog file is truncated mid-line by either disk full, system failure, filesystem bug or drive bug, the best thing syslog could do when it resumes after boot would be to rotate log files at that point, instead of appending to the truncated file.
These are quite rare, but not so rare that I haven't seen them maybe 50 times in 20 years in Linux syslog files.
I have no opinion on systemd particularly, but with regard to this single thing of rotating logs on detecting corruption, instead of attempting to patch the corruption or continue appending to the file, I think the right decision was made, from the perspective of an admin wanting the best available information after a problem.
Re:Watching systemd evolve (Score:4, Informative)
Fascinating. You have not the least clue what you are talking about. Obviously nobody with the least bit of clue would expect logs to be cleanly written on failing disks, hence this is not even a subject for discussion. As to rsyslog, you really are utterly stupid: Failing disks or filesystems are detected rightfully by the kernel, nothing else has any business doing so. Different from systemd "logging", rsyslog will not make the log problem worse by using a binary format and a broken flush strategy, and for remote logging will transfer the messages off-site.
Re:Watching systemd evolve (Score:4, Informative)
Here is one of many:
https://bugs.freedesktop.org/s... [freedesktop.org]
The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog
Lennart Poettering's comments about it:
"our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse"
Totally sensible solution, why would you edit log files? They are not meant to be changed.
Besides that, the log entries that are mangled are in them self important info; How can you detect a pattern of a misbehaving program that sends wrong field values if you delete the entry every time it happens?
Or what if the log corruption is caused by a failing disk where the bad blocks are spreading like wildfire? If you silently delete such entries and files, you delete the evidence for that something is wrong.
Re:Watching systemd evolve (Score:5, Informative)
The bug report linked by kolbe (https://bugs.freedesktop.org/show_bug.cgi?id=64116) is, IMO, a very good read to give a quick glimpse of the fine lines between the two camps (pro-systemd; anti-systemd).
Poettering's first reply/answer was simple, "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."
That embodies the "here's a bug; our answer is to say it's a feature and not a bug; NOFIX" that some people feel.
He then follows it up with a much longer reply because, "Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd". I'm not quoting out of context - that's the first sentence of his reply. Regardless of the motivation to his reply, the reply was much more thorough and he seems to truly want to help others understand. IE. I think it shows some of the good side there.
However, I'm still anti camp, and I'm not there because bugs like this are not directly fixed. I'm anti because of the underlying assumptions that are needed in order for his reasoning to be justified. In this case, that reasoning only works if one assumes the need for a binary log whose format includes re-writable parts at the front of the file, and whose corruption results in an non-repairable state. However, if the format is such that, after corruption, it's difficult or impossible to fix, why are they using that format?
FWIW, that specific bug report was, "How does one fix journal corruptions?". In that context,his answer is completely sufficient - you don't. The next question seems obvious to me though - how do we avoid that in the future? Currently, it seems that the systemd solution is to make the log reader more intelligent so that it can handle the corruption, like an FSCK, and read as much as it can.
Personally, I'm really hoping that uselessd matures and becomes commonplace and easy to drop in. It's not ideal, but it seems that systemd is going to be everywhere through the Linux community, and there's no good way to avoid that at this time. Uselessd would at least allow someone to use alternative init systems while still being able to use modern applications and environments without crippling them. Regardless of ones opinions on systemd and other init systems, the ability to swap out a subsystem is something that we should all be able to recognize as valuable.
Re:Watching systemd evolve (Score:5, Informative)
> Have better hardware, have a RAID, transfer the log messages over the network, have a UPS on your computer, invent a time machine.
You do realize this happens regardless of what hardware you are running. In my case, I have a VCE VBLOCK 720 running VMware Vsphere 5.5 against an EMC VMAX 10K that is only only 40% full and has 1ms FC latency across an ALUA mode4 (MPIO least-connect) configured path.
The issue isn't some out of place one off situation, but rather a consistent issue that other admins have experienced while running applications like Oracle E-Business Suite (EBS), SAP and Oracle RAC 12c with high limits of logging facilities. Visit VMworld, go to a VMUG, a VCE UG or any other group that runs lots of priority 1 applications on high end systems for their corporate environment and you will hear the same issue crop up in conversation many times.
Transferring log messages via rsyslog or snmp traps is CURRENTLY the only resolve here and it is one I find to be annoying.
"The next question seems obvious to me though - how do we avoid that in the future?"
I do not know, I am not a programmer. All I can say though is that it is an issue where the systemd camp has yet to satisfy sysadmins.
Goodbye, Ubuntu (Score:2)
I've been a user since Dapper Drake. Later, gator.
Re: (Score:2)
All the sudden I don't feel so bad about using OSX as my primary personal laptop (where I can keep pre-systemd CentOS 6.6 on a VM until the heat death of the universe...)
No. (Score:5, Interesting)
I just installed Linux Mint 17.1 Cinnamon (Rebecca release) on the machine I'm typing from this week. While it does have some things I don't like (some weird config location choices, /var/run, /etc/bash.bashrc, bash_completiond,WTF is up with dnsmasq?, some weird sound behavior, semi-broken bash tab completion, won't mount my cellphone no matter what, etc - aka issues I've never had with CentOS).
I also still have 2 several years old but up to date CentOS boxes I use every day and prefer them but I picked Mint because it's supposed to be better for day to day regular desktop use, has far more up to date packages, and I was tired of fighting dependency hell with extra packages from 2008 (my own fault, admittedly) for things like VLC.
My understanding, and I can't find where I read it before I went and downloaded/installed it, is that Mint is in wait-and-see mode and will be waiting until their next LTS release in a few years and then re-evaluating whether to switch to systemd. Looking at the system I have installed right now, it looks like there are a few pieces installed for compatibility (although none of them are running) but the init system is still old school init.d and runlevels.
I haven't looked at systemd in depth but my gut feeling is it throws away the UNIX mindset of, do one thing and do it well, output/input everything in text in favor of aping Apple (paritcularly)/Microsoft and the politics behind it seem dirty. I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).
$.02
Re:No. (Score:4, Informative)
I'm using Mint 17, and I also had trouble getting it to mount my Galaxy Note 4. FYI, I was able to solve it with about 15-20 minutes of Googling + a reboot.
Re:No. (Score:4, Insightful)
I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).
How do you feel about Theo? I think there must be some deep psychological understanding you can come to based on people's reactions to Linus, RMS, Theo, and Poettering, but I have no idea what.
All four of them are massively arrogant, though three have earned it and deserve some respect, but only one is a douche bag.
Re: (Score:3)
The fact that you stayed into Unity shows that you're lying and going to continue to stay.
The fact that you haven't heard of lubuntu or xubuntu shows that you're an ignoranus who should shut his cakehole.
Bug report (Score:2, Funny)
The bug is systemd.
What is systemd exactly? (Score:5, Interesting)
Can someone explain to us Windows and OS X users, without using acronyms and Linux-only mumbo-jumbo, what exactly is systemd and why do we keep hearing so much about it?
Telling us to go read a wikipedia page probably won't help because it will be either too long to read, too complex or require knowledge about other topics to understand.
Re: (Score:3, Informative)
It's a system for managing the start, stopping and restarting of system services and a whole other slew of important system tasks. Unlike previous init systems, it does its job significantly better.
Unfortunately slashdot is filled with armchair sysadmins who are upset they'll have to learn something new, while the real sysadmins are out their already using systemd in production. More systemd, I say.
Re:What is systemd exactly? (Score:4, Interesting)
Re:What is systemd exactly? (Score:5, Informative)
I am not especially well versed in the systemd vs sysinit issues. However, it is my understanding from reading other posts and articles on the issue is that those who are complaining about systemd are concerned unhappy with the non-linuxy way systemd approaches system process management.
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.
That is my understanding looking in from the outside.
Re:What is systemd exactly? (Score:4, Informative)
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well.
To be clear, the unix philosophy is much deeper than that. Here's an example [catb.org]. Here is a different set [wikipedia.org].
IMO the only way to describe the unix philosophy in a single sentence is, "write good code."
Re: (Score:3)
UNIX manpages were great. The problem was when people stopped writing manpages.
INI files vs the Registry (Score:3)
Re: (Score:3)
It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process.
Your understanding is wrong. systemd init have only a few components, and everything else is in independent daemons/tools. It follows exactly the Linux "Philosophy".
Re:What is systemd exactly? (Score:4, Informative)
What are you talking about? In the core systemd have only 5 daemons: systemd, journald, networkd, logind and user session, and it depends only on dbus, cgroups, autofs and kdbus. That is very minimalistic. The rest are optional daemons and tools that make your life easier.
http://en.wikipedia.org/wiki/S... [wikipedia.org]
Re: (Score:2, Informative)
As an OS X user, you know it as launchd.
Re: (Score:3, Informative)
As an OS X user, you know it as launchd.
And all the people whining about how systemd is the ruination of all that is hole-y in Linux conveniently ignore, OS X switched over to launchd (from its previous use of init rc, IIRC) way back in the 10.4 (Tiger) days.
And guess what? Virtually no one noticed. The sky didn't fall. Legions of OS X admins didn't crawl out of their holes to proclaim that the switch to launchd (which, BTW, Apple created and Open-Sourced, thankyouverymuch) was the end of civilization as we know it, blah, blah, woof, woof.
Lin
Re:What is systemd exactly? (Score:5, Informative)
In fact, launchd was a godsend in the early OS X days. Instead of a mishmash of INIT and Classic MacOS nonsense (/Library/StartupItems), you ended up with one system that could handle per-user agents as well as system daemons, process monitoring and respawning, jobs defined in the same property list format everything else in the system is, and a scriptable interface (launchctl) for simple administration.
Then they open sourced it. And nobody decided to use it, even though it has been bulletproof for 10 years now.
Re:What is systemd exactly? (Score:5, Informative)
PROS: It has faster boot time and more sophisticated dependency management
CONS: It's new (which means lots of people who understand the current system will have to relearn how things work), it's harder to directly customize (requires a higher level of skill to modify), it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.
In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.
Re:What is systemd exactly? (Score:5, Informative)
Kinda sorta. You missed the fact that init itself is also a process manager. In that it's responsible for starting and stopping processes based on runlevels. (Yes, init can start and stop processes on runlevels)
There's a nasty hack called SysVInit that adds a bunch of shell scripts to init in order to try to replicate the functionality of init. This is done because instead of fixing init's fundamental flaw, people decided to hack a workaround and create a lamer version of a process manager and its hacks. The flaw? Init relies on /etc/inittab for all its process management information needs. One file makes it extremely non-trivial to add and remove services from it programmatically.
It's why we have to deal with daemons that monitor other daemons that restart daemons should they quit (something init does quite well - even handling cases where a daemon restarts too quickly by pausing it so it doesn't hog system resources).
And on another note, we have userspace versions of init that manage user processes on login. The desktop/mobile use cases often have per-user applications that startup and run in the background for the user, and need to be managed on a per-user basis.
So in the end, we end up with the system master process manager, init, a set of hacks and shell scripts to try to emulate it (SysVInit), and one for individual users who wish to have personal services run. Because it's more unix-y to hack three different tools that do almost the same thing, but each with their own limitations and idiosyncrasies rather than one tool to do the job well.
Re: (Score:3)
If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.
Re:What is systemd exactly? (Score:5, Interesting)
Collate all the thousands of customised, random and disparate init scripts that start up the system (what services to run, in what order, when to mount the filesystem, how to do so, what flags to use, how to tie it all in so you boot properly every time, etc.) into a handful of huge binaries that do some clever magic to do roughly the same job (maybe quicker, maybe more reliably, maybe not - there's evidence both ways depending on the usage case in question).
The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems. Systemd is tying into everything from initial boot to how to configure your soundcard.
On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.
It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.
I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.
On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.
More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.
It doesn't help that personalities on both sides fan the flames in the heated debate.
Re:What is systemd exactly? (Score:5, Insightful)
what exactly is systemd and why do we keep hearing so much about it?
Part of the problem is that its poorly defined. It's touted as a replacement for the init system. (The system that manages other services. So for a windows user it's core functions as the services host process -- its where you can start and stop services, determine which startup at system startup. Stop them. See which are running. Restart crashed services, etc. It does startup in parallel so it's faster than the traditional init system.
But doesn't just replace init, it relplaces cron (the task scheduling system -- "scheduled backups and such" not "cpu thread scheduling"; it replaces the event logging system, it replaces the login system...
The unix philospophy is for components to be small and do one thing well and to to let users build a system out of the different pieces they want. systemd is big and tightly integrated and more of an all-or-nothing and that rubs a lot of people the wrong way.
And the main valid criticisms of are (IMHO)
1) Binary logging -- the advantages of the systemd logging system are apparent, but there are disadvantages too; users should have
2) It potentially creates a layer between kernel and the rest of the system that becomes entrenched and irreplaceable. As applications going forward will develop dependencies on the rich services of systemd it will become impossible to replace systemd with anything else, except maybe a fork of systemd. (This rubs a lot of people the wrong way.)
3) the rich service layer and tight integration stifles innovation; for example assuming systemd has traction someone can't make a "better cron" now, because that functionality is part of systemd. They can't make a better init-only system because applications will be relying on all the other services of systemd.
4) it gets between the rest of the system and the kernel, and in many cases you have to work through systemd and can't just go to the kernel. This has its good points, but also its problems and further entrenches systemd.
Perhaps GNU/Linux systems with systemd should properly be called GNU/systemd/Linux systems to emphasize the point.
I don't personally hate systemd; I recognize a lot of thing it does are good for large parts of the linux user base. But I do agree with the 'haters'; that its not modular enough and that leads to several valid complaints.
I doesn't help that the egos involved on all sides are large and uncompromising.
Re:What is systemd exactly? (Score:5, Interesting)
then you need to know that "sudo service apache2 restart" is now "sudo systemctl restart apache2" (probably) and that is about all you need to know.
But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.
Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.
Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.
*Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.
Re: (Score:3)
But, why do that when a 4-line config file can do most of what you need.
Because the systemd supporters seem to think that they can second guess what "we" need. Without understanding the requirements of a few dozen subsystems that have evolved over time.
Re: What is systemd exactly? (Score:5, Informative)
Note that sysv init only does anything useful for 3 use cases:
-booting the system
-shutting down the system
-changing run levels (which both of tje above are considered to be)
On most machines these days, no one changes run levels more than once or twice a month.
Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.
Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.
On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...
systemd is noy perfect, but it is much better in all of these aspects.
Why systemd took over (Score:5, Interesting)
There are several main reason why systemd has overrun some of the best known distros. On of the biggest is simple. Gnome depends on it, and soon KDE will too. Distro maintainers either bend over for systemd, or will spend a lot of time patching and trying to get these two desktops working on GNU/Linux.
Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.
Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.
But what do I know, I've been told enough times that I am heretic (hater in doubleplusgood newspeak) for daring to criticise systemd.
Re: (Score:3)
Thanks, that's interesting. I always thought one of the strengths of Linux was that the OS was highly separated from the GUI.
Don't believe him, what he says is demonstrably untrue. Both KDE and Gnome runs just fine on non-systemd distros and on BSD. This couldn't happen if they somehow where totally dependent on systemd.
The real story is that systemd provides some very needed OS infrastructure that Desktop Environments (DE's) like KDE and XFCE needs. The old non-systemd infrastructure that DE's could use instead, like ConsoleKit (CK), hasn't been maintained for years. The DE developers have warned the non-systemd distros for yea
Re:What is systemd exactly? (Score:5, Interesting)
That baffles me too.
But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).
I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows: /home at bootup. I have to log in as root, and mount it over command line.
-About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
-The same Fedora box cannot mount
-Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.
The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
Reading bash scripts is much easier.
Re: (Score:3)
I was on the fence (Score:5, Funny)
themes and skins? (Score:5, Funny)
I won't use systemd until it is themeable, or at least skinnable.
Also, where are all the good screenshots showing cool systemd setups?
Gentoo FTW (Score:5, Insightful)
Ubuntu is geared more toward people who don't care much about managing the boot details. So I think it might make sense for them. I chose my distro based on how much control it gave me. And luckily, they still seem committed to OpenRC. When it comes to booting, keep it simple!
Re: (Score:2)
and their favorite movies are Event Horizon and Battlefield Earth.
Re: (Score:3)
What was wrong with Event Horizon?
Re:beta lovers use systemd (Score:5, Funny)
The first half was a very good science-fiction movie ... The second half was a bad horror movie.
So, just like systemd then.
Re: (Score:2)
Ditto sibling... Event Horizon was campy as hell and even funny at times - I actually liked that movie.
Now Battlefield Earth? It and all of its Hubbardite followers can all die in a fire.
Re: (Score:2)
Meh - my personal laptop runs OSX.
Professionally, I'm stuck with learning and using it.
As ugly as it is, systemd is still better than Windows Server 2012, the registry, services.msc, and (*puke*) Powershell.
Re: (Score:3)
This systemd mess has me floating now
Yeah, that was me for awhile. Systemd has it's problems but over all I've not seen any real issues with it that didn't just simply involve me learning a new way of doing something. I've been using fedora, now 21, on my desktop at work for 2 years now. I've not really seen any issues at all with the it doing its job. Infact fedora 21 has been the best workstation OS I've used.
I was against systemd for a while, I'm still kind of iffy on some of the issues it has. I don't like binary logfile over ascii
Re: (Score:3)
While trying something new can have merit, throwing away the old, reliable and perfectly usable alternative is not. And that is what systemd is trying to force people to do.
Re:Floating (Score:5, Informative)
Init is still good for many applications (and completely satisfactory for server use). If somebody tries to prevent me from using it or to make that hard, then these people become an enemy. The systemd crowd qualifies.
Re: (Score:3)
Re: (Score:3, Insightful)
Simple: I am not against progress if it has merit. Systemd has none.
Re: (Score:3, Insightful)
If systemd had no merit, it would not be adopted by so many distros
Re:Dumped for BSD (Score:4, Insightful)
Linux has become an utterly chaotic mess that isn't fun anymore because most of my time is spent relearning the bullshit that comes with software designed by consensus
Actually Linux always was an utterly chaotic mess and that's precisely what made it so fun. It's the waves of Windows envy followed by waves of Mac envy which have sucked the fun out of it.
Still it's all relative and I'd rather use Linux than one of the more commercial offerings by a very long way.
Re:Question from a non-Linux user (Score:5, Insightful)
The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD. Essentially it's being bundle in with other services.
Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.
Pros:
* Boots fast
Cons:
* When it breaks, you're fucked
* Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools
* No real new features
* Is network connected and running as superuser
* Is unaudited
* Is virtually untested
* Was written by a raging moron
* Is completely unneeded by a large section of people who have run linux for a long time
Essentially, it's the Windows 8 of the *nix world
Re:Question from a non-Linux user (Score:4, Informative)
If everyone hates systemd so much, why is it being incorporating into all these Linux distributions? Have all the major ones incorporated it? Does this "evil" Poettering guy really have that much clout in all the disparate distros?
The systemd haters are actually a tiny but vocal minority. They tend to flash-mob systemd threads, so you can often see here on slashdot, how a little handful of systemd-haters post 10-20 anti-systemd posts in anything remotely related to systemd. They seem like they are many, but when counting they are quite few.
No distro have lost users because of switching to systemd, in fact, systemd is part of the whole OS container wave that are fuelling the Linux engine at the moment. Not a single non-systemd commercial Linux distro have emerged since all the major Linux distro announced their shift to systemd, so the server market seems firmly behind systemd.
One reason why Canonical is changing to systemd as fast as it can, is because their OS container costumers are impatiently tapping their feet, waiting for systemd integration.
People have started to ignore this small, sometimes very toxic minority for quite some time, since the anti-systemd people are basically uninformed about any technical aspects of systemd, because they rely on hearsay and random hate blogs for their information about systemd instead of actually reading the systemd documentation.
Re: (Score:3)
I have been using systemd since its inception, and it has been rock solid. It is better tested and documented than most other FOSS projects; a Jenkins back-end and Coverty scans, integrated self tests, and rather strict coding practise really helps too in that regard. Take fx. SysVinit; their developers doesn't even have build test framework, so the only way to test whether a new patch doesn't break everything, is to make a live boot. No wonder they haven't made a release for many years despite the patches
Re:Question from a non-Linux user (Score:5, Informative)
No, systemd detractors really is a tiny minority; some ways this really shows is how there are almost no developers working to maintain even critical needed infra structure for non-systemd distros; ConsoleKit has been abandoned for years now, eudev is just a shadow fork of udev with no independent development going on, and several key components like systemd-shim and cgmanager are only kept alive by paid Canonical developers and a few Debian devs; once Ubuntu and Debian shifts to systemd, those projects will languish too. SysVinit will properly also deteriorate completely; Red Hat/Suse was the defacto upstream before, and now it is only Debian as long as it last. So the non-systemd infrastructure will probably deteriorate further as the commercial distros stops to maintain it.
In short, almost no developers are working on maintaining non-systemd infrastructure, this reflects how few the systemd-detractors really are.
The recent Debian debate also show how few the systemd detractors really are when the numbers are shown: The system-detractors made a lot of noise on the Debian mailing list, but after the technical committee had decided that systemd should be the new Debian Linux init system, the detractors were unable to even gather 5 (like in five) Debian developers out of around 1000 to sponsor a vote on this subject.
Even the GR bill trying to keep other init-systems equally supported was clobbered at the GR vote.
So going by the noise on the mailing lists, the systemd-detractors seemed like a force, but when voting they where nowhere to be seen.
Same with Linux distros; you would think that the non-systemd distro ranks would be swelling with the numbers of systemd-refugees. This certainly doesn't seem to be the case. A couple of rather obscure distros like Funtoo and Void are among the few distros that don't want to support systemd. Slackware is undecided on the issue, and Gentoo etc. support systemd, with a growing number of its users that prefer it to OpenRC.
Also no medium/major commercial non-systemd Linux distro have emerged this last couple of years, this is a strong indication that the paying costumers wants systemd, and doesn't care at all for the alleged superiority of SysVinit. Several companies made it clear during the Debian debate that they favoured systemd, none spoke for SysVinit or Upstart.
No wonder; systemd is great and it solves real world problems like daemon management and security much better than any other alternative.
Re: (Score:3)
And you know and trust this person and Red Hat management to not lie about it?
Given that they were heavily pushing Upstart at the time, yes.
To me this sounds like an all too convenient artificially created "legend" of the heroic single developer that changed the world. In other words, complete BS.
He has obviously not done it alone, just check the git commit log.
Re: (Score:3)
Er...not Archlinux... [googleusercontent.com] ( cached page as the original seems to be down )
In fact, Arch adopted it pretty early on. Its Slackware, Crux, or Gentoo these days, unless you head on over to BSD land...
Re: Why binary logging? (Score:3, Informative)
Systemd stores a lot of metadata in the journal, not just simple text rows. A custom format allows this to be queried very quickly.
Re: (Score:3)
Oh yes. I am so sure that your test plans include such unlikely things as your customers deciding to run your app on a Pentium III with no SSE support. That's when you discover that the compiler settings are defaulted for SSE support. Or you discover that a shared memory file is being used by an old software version and a new software version at the same time, resulting in disagreements about exactly what should be locked when. Or maybe you find out that if a customer opens more than 1024 file descriptors y