Ubuntu To Officially Switch To systemd Next Monday

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.

Comments

Not ready for primetime

[halivar]

It still doesn't have a decent architecture for scheme plugins and a robust text editor.

Re: Not ready for primetime

[TheBilgeRat]

Seriously? Puppet Labs has supported it for 5 years now. Managing a slackware sever or servers is no harder or easier than any other one. Now, if you're hand rolling special snowflakes and have no strategy to manage them, sure. But that would be true for any distro or OS.

Watching systemd evolve

[Shakrai]

Enjoy

Re:Watching systemd evolve

[DoofusOfDeath]

"But but ...

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

[devent]

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:Watching systemd evolve

[kolbe]

Here is one of many:

https://bugs.freedesktop.org/s...

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

[gweihir]

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:Watching systemd evolve

[Peter H.S.]

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

[unrtst]

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

[Jamie Lokier]

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

[kolbe]

> 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.

What is systemd exactly?

[ArcadeMan]

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:What is systemd exactly?

[Anonymous Coward]

Don't forget that SystemD also has integrated into it, boot manager(not INIT, think GRUB), DHCPD, DHCP, an actual NAT, Firewall interfacing, keyboard culture, time settings, USB notification. etc etc. At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?

Re:What is systemd exactly?

[Anonymous Coward]

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?

[blue9steel]

The init system handles the initial startup of a linux os. It's been acknowledged for some time that it has some limitations, especially in terms of threading and dependency management but for the server world that's usually not that big a deal since the primary users are technical specialists who are comfortable mucking around with that sort of thing. For desktops and mobile devices though those are more serious concerns because they impact user experience and many users don't have the skills to modify things themselves. Systemd is a replacement for init.

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?

[ledow]

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?

[PPH]

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:What is systemd exactly?

[vux984]

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?

[tlhIngan]

The init system handles the initial startup of a linux os. It's been acknowledged for some time that it has some limitations, especially in terms of threading and dependency management but for the server world that's usually not that big a deal since the primary users are technical specialists who are comfortable mucking around with that sort of thing. For desktops and mobile devices though those are more serious concerns because they impact user experience and many users don't have the skills to modify things themselves. Systemd is a replacement for init.

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:What is systemd exactly?

[MachineShedFred]

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?

[CurryCamel]

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:
-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 /home at bootup. I have to log in as root, and mount it over command line.
-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: What is systemd exactly?

[buchanmilne]

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.

I was on the fence

[wisnoskij]

I never really understood either side, far above my head. But I have used Ubuntu a few times and followed their major changes over the last decade. If there is one thing I do understand is that if Ubuntu is switching to it it must be a trendy piece of crap, far from ready for prime time.

No.

[waspleg]

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:ABOUT FUCKING TIME!

[Anonymous Coward]

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!

[Anonymous Coward]

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.

themes and skins?

[bmajik]

I won't use systemd until it is themeable, or at least skinnable.

Also, where are all the good screenshots showing cool systemd setups?

Re:Question from a non-Linux user

[Anonymous Coward]

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

Gentoo FTW

[Maltheus]

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!

Why systemd took over

[jbernardo]

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:beta lovers use systemd

[fahrbot-bot]

The first half was a very good science-fiction movie ... The second half was a bad horror movie.

So, just like systemd then.

Re:ABOUT FUCKING TIME!

[almitydave]

Link: Suicide Linux

Re:ABOUT FUCKING TIME!

[phantomfive]

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!

[phantomfive]

Systemd has laudable goals and people do want it. That's why it's been adopted, because some people want what it does. "It fills a use case people have" is what Linus says. And that use case happens to be the one that desired by the people responsible for building distros.

Re:ABOUT FUCKING TIME!

[Pope Hagbard]

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:Floating

[gweihir]

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:Question from a non-Linux user

[Peter H.S.]

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.