Please create an account to participate in the Slashdot moderation system


Forgot your password?
Ubuntu Open Source Operating Systems Software Linux

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.
This discussion has been archived. No new comments can be posted.

Ubuntu To Officially Switch To systemd Next Monday

Comments Filter:
  • by Anonymous Coward on Friday March 06, 2015 @12:02PM (#49196961)

    Now time for me to switch to Windows!

    • by dotancohen ( 1015143 ) on Friday March 06, 2015 @12:26PM (#49197191) Homepage

      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: []

      • by FreonTrip ( 694097 ) <.freontrip. .at.> on Friday March 06, 2015 @12:59PM (#49197571)
        It's like hastily cobbling PulseAudio into the works so many years ago, but dramatically worse. Ubuntu's its own worst enemy, and you're foolish if you slap 15.04 onto bare hardware on day one.
        • by Anonymous Coward on Friday March 06, 2015 @01:21PM (#49197833)

          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.

          • by Movi ( 1005625 )

            Well, Gentoo will never make your run systemd, or even udev. Come over, we have cookies (which you can compile yourself)!

          • I started with Linux in 2007 experimenting with Debian and later using Ubuntu. Switched to Kubuntu for several years and just recently to Mint. I think at some point Mint is going to drop its dependence on Ubuntu for its main distro and use Debian exclusively. They're already well-positioned to do so with their Debian variant, and have a rock-solid understanding of what a desktop computing experience should feel like to the average user. To systemd or not to systemd is not the question for most people, the
        • by Pope Hagbard ( 3897945 ) on Friday March 06, 2015 @03:50PM (#49199611) Journal

          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.

      • by Anonymous Coward on Friday March 06, 2015 @01:07PM (#49197653)

        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.

  • by halivar ( 535827 ) <bfelger@gm a i l . c om> on Friday March 06, 2015 @12:04PM (#49196973)

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

  • by Shakrai ( 717556 ) on Friday March 06, 2015 @12:04PM (#49196975) Journal

    Enjoy []

    • Needs more blood.

    • by kolbe ( 320366 ) on Friday March 06, 2015 @12:31PM (#49197249) Homepage

      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.

      • by DoofusOfDeath ( 636671 ) on Friday March 06, 2015 @01:16PM (#49197753)

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

      • by devent ( 1627873 ) on Friday March 06, 2015 @01:18PM (#49197777) Homepage

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

      • by gweihir ( 88907 )

        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.

      • by Peter H.S. ( 38077 ) on Friday March 06, 2015 @02:27PM (#49198605) Homepage

        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.

  • I've been a user since Dapper Drake. Later, gator.

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

  • Bug report (Score:2, Funny)

    by Anonymous Coward

    The bug is systemd.

  • by ArcadeMan ( 2766669 ) on Friday March 06, 2015 @12:19PM (#49197133)

    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)

      by Anonymous Coward

      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.

      • by Anonymous Coward on Friday March 06, 2015 @12:32PM (#49197251)
        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?
      • by Anonymous Coward on Friday March 06, 2015 @12:40PM (#49197361)

        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: (Score:2, Informative)

      by Anonymous Coward

      As an OS X user, you know it as launchd.

      • Re: (Score:3, Informative)

        by macs4all ( 973270 )

        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.


        • by MachineShedFred ( 621896 ) on Friday March 06, 2015 @01:58PM (#49198235) Journal

          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.

    • by blue9steel ( 2758287 ) on Friday March 06, 2015 @12:40PM (#49197363)
      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.
      • by tlhIngan ( 30335 ) <slashdot@w o r f . n et> on Friday March 06, 2015 @01:30PM (#49197935)

        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.

    • by ledow ( 319597 ) on Friday March 06, 2015 @12:59PM (#49197567) Homepage

      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.

    • by vux984 ( 928602 ) on Friday March 06, 2015 @01:28PM (#49197895)

      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.

  • by wisnoskij ( 1206448 ) on Friday March 06, 2015 @12:37PM (#49197329) Homepage
    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.
  • by bmajik ( 96670 ) <> on Friday March 06, 2015 @01:23PM (#49197847) Homepage Journal

    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)

    by Maltheus ( 248271 ) on Friday March 06, 2015 @01:47PM (#49198125)

    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!

"An open mind has but one disadvantage: it collects dirt." -- a saying at RPI