Forgot your password?
typodupeerror
Ubuntu Debian Linux

Ubuntu To Switch To systemd 279

Posted by Soulskill
from the follow-the-leader dept.
GuerillaRadio writes "Following the decision for Debian to switch to the systemd init system, Ubuntu founder and SABDFL Mark Shuttleworth has posted a blog entry indicating that Ubuntu will now follow in this decision. 'Nevertheless, the decision is for systemd, and given that Ubuntu is quite centrally a member of the Debian family, that's a decision we support. I will ask members of the Ubuntu community to help to implement this decision efficiently, bringing systemd into both Debian and Ubuntu safely and expeditiously.'"
This discussion has been archived. No new comments can be posted.

Ubuntu To Switch To systemd

Comments Filter:
  • Good...? (Score:5, Insightful)

    by Kagetsuki (1620613) on Friday February 14, 2014 @12:39PM (#46246927)

    I think it's good Shuttleworth was able to suck up his pride and go along with this decision to prevent fragmentation. I do however call the original decision slightly into question, but that's only because I've gotten sort of used to upstart. Hopefully anything good that was implemented in upstart but was not in systemd will make its way over.

    • Re:Good...? (Score:5, Insightful)

      by fishybell (516991) <fishybell@@@hotmail...com> on Friday February 14, 2014 @12:53PM (#46247099) Homepage Journal
      Having switched from System V to upstart to systemd I can safely say that yes, systemd is better for a full server or desktop OS. It has better reporting tools, it has more fine grained control, and it's fast. The trade off is complexity and size. There are many computer systems that the cost of switching to systemd will not bear fruit for a very long time (ex. embedded), but for servers and desktops that time has arrived.

      Learn to love systemd; it's here to stay and for good reason.

      • by Anonymous Coward

        I don't think very much embedded stuff will ever use systemd. Most use System V or Busybox init or spin their own simpler version. If someone is using a general purpose install like Ubuntu for embedded work, they're doing it wrong right from the start.

        • by skids (119237)

          It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language. Systemd supposedly will allow a leaner build.

          • by dalias (1978986) on Friday February 14, 2014 @01:24PM (#46247479)
            This is a fallacy. A shell script running on a non-bloated shell (e.g. Busybox ash) consumes less than 50k of dirty pages per instance. It would take at least 20-30 such scripts running to even come close to rivaling systemd's memory usage, and that's not even counting other resources systemd is consuming.
            • Re: (Score:5, Funny)

              by binarylarry (1338699) on Friday February 14, 2014 @01:48PM (#46247777)

              Well fuck it, lets rewrite the Linux kernel in bash!

            • by RR (64484) on Friday February 14, 2014 @04:50PM (#46249861)

              It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language.

              This is a fallacy. A shell script running on a non-bloated shell (e.g. Busybox ash) consumes less than 50k of dirty pages per instance. It would take at least 20-30 such scripts running to even come close to rivaling systemd's memory usage, and that's not even counting other resources systemd is consuming.

              Memory isn't the only resource. (And if you're using Linux, you're already using a ton of memory.) Systemd brings standardized, concurrent, event-driven startup, so it takes less time to start up, both CPU time and wall clock time. For example, systemd's declarative unit files have much less boilerplate and take less effort to parse than SysV-style init scripts.

              At this point, systemd has also been concentrating on correctness and functionality. They aren't even optimizing for speed and memory consumption, yet. It would be interesting if Busybox added a systemd-style init.

        • At a point when even the cheapest SoC has more processing power, memory, and storage space than your current desktop the cost of learning and using a custom system like Busybox will outweigh the benefit for many. For devices that need instant-on capabilities I don't think it's realistic to expect anything other than a custom init, but for the rest I expect programmers to programmers; that is, lazy.
        • by Anonymous Coward on Friday February 14, 2014 @01:34PM (#46247581)

          I don't think very much embedded stuff will ever use systemd..

          I am using Angstrom, which uses systemd, for embedded stuff. Haven't had any problems with systemd, but haven't tried to do anything complex either. It gets stuff started at startup time, that's all I have needed.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Shell scripts are horribly inefficient and systemd is already being used in some embedded systems (BMW for instance).

      • Can you enlighten us?

        Mostly, unless I've needed to hack something I've ignored the init system more or less completely. SYSV seemed to work OK (never noticed any obvious problems) and on Arch it used to be really rather fast to boot as well.

        I genuinely do not know what is bad about wrong with SYSV and what is better about systemd.

        There seems to be a lot of hot air in general and people arguing from a point of ignorance. You seem to have looked into it. What's the beef?

        • Re:Good...? (Score:4, Informative)

          by s.petry (762400) on Friday February 14, 2014 @01:17PM (#46247387)

          I am with you, I never saw a reason to get rid of SYSV. The reason Linux started pushing is based on the same Logic Sun had to go away from it. A master daemon which monitors all services and their current states, restart when necessary, etc... The Sun implementation took a bit of getting used to, but in reality the daemon used XML files which contained mostly SH scripts. It was still hackable, which is why SYSV stuck around for so long. When something does not work, write a new SH script and stick it in init.

          The Linux implementation is not as straight forward as Sun's implementation which to me says a lot. RH6 went to systemd and I hated it. Cryptic, not hackable, and simply a pain in the ass to customize unless you run everything in legacy mode which is still SYSV. The alleged better logging did not exist, and was much harder to access than "set -x" in an init script.

          The overlord daemon is an advantage, previously we all used monitoring scripts to do things for us. The system now has it built in. I never saw an issue with writing restart options into BigBrother, Nagios, etc.. so don't save much with this small feature. In the grand scheme of things, I lose a lot of flexibility with this system. So most of my custom tools, code, and scripts will run in legacy mode.

          • by caseih (160668)

            RH6 went to systemd? I don't see systemd on any of my RHEL6 or CentOS6 machines.

            I am running a RHEL7 beta box, and it does have systemd. And it's not really that cryptic or unhackable. In fact getting a new daemon installed and running is far simpler than with sysv. You don't have to write an init script. Just create a simple ini file, and away it goes. Because there's no init script to screw up, things are easier to debug. If you can run the daemon from the command line and it's happy, then you know

          • Re:Good...? (Score:4, Interesting)

            by RabidReindeer (2625839) on Friday February 14, 2014 @02:34PM (#46248281)

            One of the biggest selling points of Linux for me was that its log and config files were text files.

            When I first started working with OS/2, one of my principal frustrations was that each and every IBM program product had its own proprietary config and log file format that could only be accessed using a product-specific utility. In Linux, the standard text utilities were all that were needed, and there are text utilities for almost every conceiveable way to search or update those files.

            While there are certain things I like about systemctl and the newer Linux logging manager, their departure from this inherent simplicity disturbs me. It's aking to the trend to provide "improved" systems like Gnome3 or Windows 8 where your gains are offset by your losses.

            Even a relatively open binary system like OLE/COM turned out to be more trouble than it was worth for me. I'd rather not throw out the good with the bad.

            • Re:Good...? (Score:5, Informative)

              by amorsen (7485) <benny+slashdot@amorsen.dk> on Friday February 14, 2014 @03:25PM (#46248835)

              Indeed, journalctl is probably what I dislike the most about the current systemd stack. For one thing it is slow with full text search in large log files -- it is reasonably fast if you use the built-in column-specific search, but just running fgrep on it is not really feasible. In contrast, fgrep is ridiculously fast on modern systems as long as your log files stay below a few gigabytes in size. Also, the output of journalctl changes (mostly for the better) when you use it with pipes, which can be quite surprising.

              The other major problem with systemd is how difficult it is to debug boot failures. It is quite annoying when an fstab which was correct with upstart results in silent boot failure with systemd.

            • by F.Ultra (1673484)
              Well good then that the ini files for SystemD is text and that you can export the textlogs from the logger.
              • Well good then that the ini files for SystemD is text and that you can export the textlogs from the logger.

                Exporting isn't the same as processing in place. And the other day, in fact, I ran into an issue where messages that I expect to be able to "tail" out of the older log simply couldn't be found.

                The systemd authors have already admitted that there are certain functions that the older script-based ini's could provide that their strictly-declarative system at present cannot. Having text formatted files is useful but not being excessively restricted in what the text can do is also important.

        • Re:Good...? (Score:5, Informative)

          by fishybell (516991) <fishybell@@@hotmail...com> on Friday February 14, 2014 @01:30PM (#46247533) Homepage Journal

          System V has a scrict sense of a run level. For example, if you want a full desktop, run level 5 is often used, for a headless server, run level 3. What if you have a box that is headless most of the time, but you want to be able to run a full desktop sometimes? With System V you would change from run level 3 to run level 5 which would, depending on implimentation, stop and start services that are needed by both. Systemd instead has the concept of targets. Your full desktop target would have the headless server target as a dependency, and starting the full desktop would only run what isn't already running. You typically also have individual sevices that have dependencies. For example, you'd want your dhcp server to wait to start until the network has come online. In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.

          All of that is just the most exposed part of systemd (to me at least). It also supplants other processes such as xinetd and udev. Instead of having three different ways to start processes based on system events (startup, port connection, hardware event) you have a single system to manage all three. It can get complicated (wasn't udev already complicated?) but the consistency is worth it.

          To keep all the consitency systemd provides a series of functions and magic variables. By magic variables I mean you set a list dependencies, which IMHO is less magic than the chkconfig comment lines in a typical System V init script. Both the magic variables and functions mean your typical service initaliation script is 10 lines instead of 100. While they may not be as obvious what's going on (a System V script is self-contained and can be ran on it's own) it is once you've become familiar with them.

          • by DikSeaCup (767041)

            Have you ever tried logging into a box at runlevel 3 and typing "startx"?

            On the super rare occasions where I'd need a GUI at the console of a system, this would work well enough for me (assuming all of the proper packages were installed).

            A regular practice for me was to do installs as "minimal desktop" and then during the final configuration, change runlevel to 3 in inittab.

            • Re:Good...? (Score:5, Interesting)

              by Bacon Bits (926911) on Friday February 14, 2014 @03:35PM (#46248973)

              Yes, and you have to understand that that only works because your DE of choice has bent over backwards to make sure all it's dependencies are running and functional when you try to start it. That is to say, startx has to duplicate functionality of init because init is too stupid or too unreliable to be able to do it for your DE.

              This issue can be generalized to any significantly complex application. That means you already have a half dozen "init systems" working on your systems. They're all independent (even though they maybe should know about each other), and you can't manage them universally (even though you might want to fire things off with system level events, like restarting a service if it crashes), and you certainly can't be sure you're not stepping on each others' toes.

              Essentially: a large enough number of people noticed that the same features for starting and managing processes were getting implemented over, and over, and over. They realized that these functions belong in the init role -- because only init has the authority and knowledge required to not screw it up -- but that sysv-init didn't have the capability to do any of that.

              All this began to happen perhaps 10 years ago, when other operating systems (e.g., Windows, which has had service dependencies and crash recovery since Windows 2000) showed what a more feature-complete init system was capable of.

              At this point these "why do we even need a new init system?" questions are like someone watching I-40 getting repaved in the 1970s and asking "why do we even need Interstates?"

          • Re:Good...? (Score:4, Informative)

            by nabsltd (1313397) on Friday February 14, 2014 @03:20PM (#46248783)

            In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.

            If only systemd were really "smart enough", it would be great. Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it.

            All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence. This really isn't any different in SysV, but at least there I could trivially edit the startup script of the dependent service and add some sort of test.

            Because there is no way to test every combination of services, there is no way to reliably create systemd dependency files that will always work. Because of that, we get things like rc.local running before other services have started completely.

            • Re:Good...? (Score:4, Informative)

              by JesseMcDonald (536341) on Friday February 14, 2014 @05:41PM (#46250403) Homepage

              Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it. All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence.

              That isn't true. Putting aside the systemd-specific sd_notify() API for reporting just how completely the service has been initialized, and the socket activation model which allows other services to connect while startup is still in progress, systemd also supports traditional "forking" daemons which complete their initialization before the main process exits. You can also use the ExecStartPre and ExecStartPost fields to inject arbitrary commands into the startup process separate from the daemon itself.

              The best case short of actual systemd integration is that the service already does the right thing with the fork-and-exit model, so that it's ready to be used before any other services are started which depend on it. But even if that isn't the case there are ways to deal with it under systemd, up to and including custom shell scripts for the really complex cases.

        • Re:Good...? (Score:5, Insightful)

          by Billly Gates (198444) on Friday February 14, 2014 @03:07PM (#46248649) Journal

          The bad is is SysV not event driven.

          This might be ok for servers but lets say you have a laptop with Ubuntu. You are on a network and it goes to sleep at work. You grab it and head to the airport for a trip and the laptop wakes up elsewhere. All of your SYSV scripts to do things like pass settings to daemons relating to network and Samba get messed up.

          With an event driven system you tell it to do things based on conditions or events such as your laptop going to sleep and waking up on a different network as an example. You can use SystemD to re-initialize itself not just on startup but when things happen with this new ability. A hacking attempt on a server, an unplanned reboot, or anything else

          The bad about SystemD compared to upstart and Apple's or Sun's event driven systems:
          - no text files
          - binary reporting
          - quite complicated compared to other event driven systems like the older upstart

          System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-(

          Some also is resistance to change as many unix old timers hated anything new by Sun and did not want to relearn writing new scripts all over again. But, this tries to solve a problem like the laptop example but at the cost of complexity and non integration.

          • The bad about SystemD compared to upstart and Apple's or Sun's event driven systems: ... - no text files

            What do you mean by that? The database used by journald may be binary (with the ability to export to text), but systemd unit files are simple text files with an INI-style layout. There are some other systemd configuration files with different formats for historical reasons, but to my knowledge all of them are still text.

          • by Omicron32 (646469)
            > System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-( Firstly, it's systemd. I'm not sure where you're getting the capital from. Secondly, generalise much? I'm a long-time Linux system admin and I can't wait until systemd filters down to server distros like CentOS and Ubuntu LTS. It will make my job a whole lot easier.
      • not bear fruit for a very long time (ex. embedded)

        Don't be so quick to count embedded guys out yet. While there isn't much in systemd itself, but as I understand it it will integrate well with kdbus. And kdbus (I think) plans to support QNX style "yield CPU to destination" type message passing. Which is a very nice feature for realtime systems.

      • by Kremmy (793693)
        The tradeoff is complexity and size. I've got to say, I still don't buy it, this entire concept of requiring more resources to do the same job and yet somehow being more scalable to a degree that makes the trade-off worthwhile. If you have to upgrade your system to see the benefits (embedded systems are no slouches these days, look at any ARM tablet specs) then those benefits are seriously questionable.
        • Current systems, even phones, have dual and quad core processors. That means the existing hardware can run four threads on the CPU simultaneously, or about 16 active processes. System V runs one process at a time, meaning it's only using 6% of the hardware's capability.

          Systemd, on the other hand, runs several processes at once, getting things done faster by making use of post-1995 hardware.

          You say you don't see point of changes that take advantage of modern hardware. You only really benefit from 64 bit if y

          • by Kremmy (793693)
            I say you're wrong because we don't need systemd to do that. No, we don't, because it's been possible to multiplex the SysV style init for ages. My debian server does it, with a slow SSD, and the results are beautiful. I'm all about taking advantage of modern hardware, but you're seriously talking about rewriting init because you don't want to use one of the pre-existing options for multiplexing the start up process. That's silly.
  • Maybe the linux distributions should stop pulling an AppleSoft and start maintaining their shit instead of rewriting it again.

  • omg! could this be my first, first post! Karma! yeah!


    Good call Mark, glad to see Ubuntu embrace what is comming. Now, for the interesting part, it is time for sys admins to rally and push for the interfaces/workflows that we need. systemd obviously has certain strengths, now lets bring the experience and know how of good sys admins to make working with systemd mutually beneficial for all.
    • by iwbcman (603788)

      oh well i was within the first 100 posts!....

      the one time i am fooled into claiming it! and not even received with the humour intended! pffff!
  • by Viol8 (599362) on Friday February 14, 2014 @12:47PM (#46247033)

    People talk about parallel start up , well you can do that with init anyway. Its it smarter with dependencies or is it just change for the sake of it? I'm really not thrilled with the prospect of yet another config language, there are quite enough already.

    • by EmperorArthur (1113223) on Friday February 14, 2014 @01:04PM (#46247251)

      Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.

      I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

      In the end, I just really like the ease of use of service files. Oh, and the stupidly fast boot time on my laptop is really nice. People who say boot times don't matter aren't living in the real world.

      • by tlhIngan (30335) <slashdotNO@SPAMworf.net> on Friday February 14, 2014 @01:49PM (#46247797)

        Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.

        I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

        Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.

        In the end, it's bit of a maintenance hassle, and while completely understandable, it's a nightmare.

        In fact, I'm guessing most utilities don't even bother handling the case - you just reboot and forget about it.

        After all, computers are good at doing stuff automatically - so stuff like maintaining which services should run at which runlevels should be automated - the init can figure out what it needs to start, what it needs to kill and the order based on dependencies. All the user needs to do is select what needs to run at what runlevel, and the tool does the rest.

        Then there are the various hacks to SysV - PID files (if so many tools need to know the daemon PID, why not have init actually do that work than requiring every script to do it manually?), the fact that state tracking isn't really in the system, and if you need services to relaunch on failure within limits, there ought to be a way to do it without requiring a trip to /etc/inittab to specify that fact.

        • by causality (777677) on Friday February 14, 2014 @02:29PM (#46248245)

          Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.

          I know what you mean. I've used Linux systems that were set up that way, and it's messy and a bit of a nuisance to make sure the system is really going to do what I think it's going to do.

          Personally I'm a long-time Gentoo user and my system runs OpenRC. Have you ever used it? It eliminates the sources of confusion you illustrate there. It's neat and it's simple and it works and I can forget that it's there. That's what I like about it. There's nothing I want it to do that it doesn't already implement.

          Right now Gentoo is one of the few distros that supports a non-systemd installation, mainly because the idea that as little as possible should ever be forced on the user is one of their core principles. Gentoo has very few mandated default anythings and they encourage users to file a bug if they discover an unnecessary one. I am interested in systemd and I acknowledge it probably isn't taking off so well for no reason, but this is why I'm not in any hurry to adopt it.

          BTW OpenRC does have a form of state tracking. It simply uses start-stop-daemon for this, so that each initscript doesn't need to worry about it.

          • by Rich0 (548339)

            Yup. I suspect Gentoo will be one of the last distros to make systemd a default, and I think that is because openrc really is the best traditional sysvinit implementation out there. I've used systemd on some of my Gentoo VMs and when you get into edge cases it can be clunky (I couldn't get it to wait until after getting an IP to try to mount NFS, for example).

            The fundamental design is very good, but it will be a while before it completely surpasses openrc. It isn't unlike ext4 vs btrfs - the latter is al

    • by fishybell (516991) <fishybell@@@hotmail...com> on Friday February 14, 2014 @01:39PM (#46247653) Homepage Journal

      Yes, you can do parallel startup with System V. You also can make a systemd init process that doesn't do anything in parallel.

      Yes, systemd is smarter with dependencies in the sense that it has dependencies and not a numered list. Yes, you can have a System V script that manages it's own dependencies, but because you can do an infinite number of things with System V scripts many people have tried. I've ran across dozens of System V scripts that are hundreds of lines long even without couting the standard ". /etc/init.d/functions" size, which, on my system, is almost 600 lines long. Systemd simplies this by having a much larger library of functions and uses the presumption that you'll never call a script without using systemd to manage it. No longer does every script have to define a start, stop, restart, condrestart, status function; it's handled by systemd. No longer do you have to do checks for your PID file; it's handled by systemd. No longer do you have to make sure your script will always run after another script even if that script's chkconfig number changed; it's handled by systemd.

      In the end, yes, it's another config language you'll have to learn, but it's worth it.

      • by F.Ultra (1673484)
        And if I'm not mistaken your script can be set to start when /var/run/mysql.socket becomes ready instead of being started directly after /etc/init.d/mysql started and the mysql process decides to do a major table check so that the server is not accessible for 5 minutes which makes your daemon exit with an error since the database was not available at start.
      • by nabsltd (1313397) on Friday February 14, 2014 @03:38PM (#46249009)

        In the end, yes, it's another config language you'll have to learn, but it's worth it.

        Why is it worth it?

        I've heard lots of "systemd is better" claims, but not one real-world example of how it took 27 hours to debug a startup issue when using SysV, but only 13 seconds using systemd. And, I really don't care about boot times, because my physical servers take 10 times as long running through BIOS checks as they do going from grub load to system ready. Even VMs don't matter much, as they don't get rebooted very often, so saving 5 seconds on a 30-second boot time isn't really a big deal.

        On the other hand, I've heard lots of stories from people who have to install a custom service (i.e., not from a "apt-get" or "yum install") on a systemd system and complain about how it took hours to get the dependencies right.

    • What is wrong is it is not event driven.

      It is nice for example is you can set your laptop up for different networks and when conditions change such as it sleeps and wakes up on a different network it can respond differently. You do not have to write a complex script for every possible combination you can think of.

      Just put in the parameters and tell it what to do with events.

      It can be used too after booting up for servers so if a hacking attempt is detected it can dynamically change its firewall settings as

    • by amorsen (7485)

      The config language, if you mean the syntax of what used to be the service files, is actually nice. Most keywords are well chosen and you can do partial or complete overrides of them by adding a file in the appropriate place in /etc.

      The dependency system is good too, and being able to launch daemons without the traditional double fork is brilliant. The only surprise I have hit so far is that network.target does not actually wait till the network is up -- network-online.target does that.

      If only those were th

  • by Virtucon (127420) on Friday February 14, 2014 @12:58PM (#46247183)

    I'm sorry but the systemd thing is really, really a mole hill when it comes to Ubuntu embracing things. From my perspective it doesn't matter what init scheme you use as long as it does it efficiently and allows you to augment things when you need to. Shit most Linux users don't even know what their distro's choice is for init scripting! Cripes you'd think that folks would have thought that the Vatican was now allowing electronic balloting and using Green Friendly e-smoke for electing the Pope or something with all this nonsensical whoopla.

    • by raxx7 (205260) on Friday February 14, 2014 @01:14PM (#46247357) Homepage

      Users rightfully do not care about what init system they use, as long as it works.
      But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

      By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said.
      Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian.
      GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

      And that means they can actually spend time fixing other stuff.

      • by causality (777677)

        Users rightfully do not care about what init system they use, as long as it works. But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

        By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said. Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian. GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

        And that means they can actually spend time fixing other stuff.

        This is more like the kind of answer I was expecting to my earlier posts in this discussion. It makes a lot of sense. Thank you for that.

        It's nice to seen an adult person give a reason that makes sense instead of getting all pissy that everyone doesn't already see it his or her way.

    • by joebok (457904)

      The Vatican is using green friendly e-smoke and electronic balloting??? Wow!! Now THAT is NEWS!!

      However, I wonder what init system the voting station OS will use? That could be of critical importance.

    • I don't know what Slashdot you're reading but the one I'm reading is packed with supportive comments about the decision. I think there's just relief that Shuttleworth hasn't decided to NIH something for once.

      (Not that I'm particularly upset that they tried to do something different with Unity. GNOME 3 needed a good alternative, the problem was that Unity seems to be just as flawed, not with the principle of doing something. It'd be nice to see them stick with X.org rather than go Wayland, but they've als

  • I basically hate upstart, so bring it on, systemd.

  • by bzipitidoo (647217) <bzipitidoo@yahoo.com> on Friday February 14, 2014 @01:12PM (#46247339) Journal

    The philosophy of modularity. Tools are many and small and simple, do one thing and do it well. But then, the Linux kernel also violates this principle.

    There's also this seeming drive to make more tools dependent on systemd. Does udev really need to depend on systemd?

    Wayland may be an example of an approach more in line with the UNIX philosophy. X has a lot of baggage that has become useless over the years. Lot of basic graphics functionality has moved into specialized graphics hardware.

    • by joejor (578266) on Friday February 14, 2014 @01:26PM (#46247497)
      Here's a pretty good treatise on the shortcomings of systemd: http://ewontfix.com/14/ [ewontfix.com]
    • by zixxt (1547061)

      Amen!

    • by broken_chaos (1188549) on Friday February 14, 2014 @01:36PM (#46247605)

      Wayland is actually one of the "new Linux" things that I'm interested in. I'm not getting rid of X anytime soon, but when Wayland has the tools, hardware support, etc. I need, I'll likely switch to it without any fuss. (For the curious, I use i3 as a window manager, and there's just no equivalent compositor for Wayland yet. None of my applications are GTK+3 or QT5, either, so I'd be using the X compatibility layer for essentially everything too.)

      But systemd I really am not fond of. It's not an issue of being different (though that is some part of it), so much as the way it dictates so much of how you use things. It seems to touch every single part of your system on an ongoing basis, rather than just booting the system and staying out of the way. I sincerely doubt there would be as much distaste for it if it was just the init system part, rather than stuffing everything else in too.

  • by wonkey_monkey (2592601) on Friday February 14, 2014 @01:16PM (#46247381) Homepage

    service is a word. systemctl isn't, and it's 50% more characters to type, too.

  • by dAzED1 (33635) <brianlamere@[ ]oo.com ['yah' in gap]> on Friday February 14, 2014 @01:20PM (#46247423) Homepage Journal

    There's this new thing called "init.d" which makes things really simple - you can start a system up and step through things, and though the boot takes 5 seconds instead of 1 second, that isn't really a problem.

    Once I read the original post about systemd, [0pointer.de] and all the other let's-invent-a-problem-to-fix nonsense surrounding init.d, I literally hung up my hat and stopped being a syseng. I was a unix guy starting in 93, so it was probably time anyway, but it was the straw that broke my back, as it were.As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. I especially "loved" this line: As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. No. A good init system does it reliably, with no drama and no politics. A good init system allows one to easily determine the state of a system, and doesn't assume things like GUIs and such. A good unix init system does all this with commands which can be piped and parsed easily with grep and awk - two things the original post about systemd actually complains about. The idea that a unix person would complain about grep and awk was so mind-boggling to me that...well, I just hung up the hat. You did all this nonsense, just to save a few seconds? Because what, the only thing linux is used for, is laptops? Meh.

    • by dAzED1 (33635)
      oh boo, slashdot dropped the pre tag? Dorks. "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast." = that was a quote from that original post about systemd
    • by jbolden (176878)

      No they did all that nonsense to have features like monitoring and recovery that init.d didn't have. If a daemon has problems and needs to restart itself how does it do that? Heck if you really mean init.d and not xinit.d how does a system support triggers for hundreds or thousands of daemons most of which run very infrequently?

      • by broken_chaos (1188549) on Friday February 14, 2014 @01:59PM (#46247897)

        If a daemon has problems and needs to restart itself how does it do that?

        ...Monit [mmonit.com]? runit [smarden.org]? Two completely different approaches to service monitoring, one not even in an init system. And there are more (s6, daemontools, etc.).

        hundreds or thousands of daemons

        ...What the heck are you running that puts thousands of daemons on a single server? If you're doing something this large, you might want to consider virtualization. Thousands of daemons is a gigantic attack surface to have on a single system, and a mess if something were to go wrong with one of them that takes down everything.

    • by tokiko (560961)

      Correction: The original post about systemd was not complaining about using grep and awk on the scripts. The complaint was that the scripts where calling these commands way too often during the normal boot up procedure.

      On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74. Every time those commands (and others) are called, a process is spawned, the libraries searched, some start-up stuff like i18n and so on set up and more.

  • by exabrial (818005) on Friday February 14, 2014 @02:17PM (#46248099)
    I really like upstart. The scripts are stupidly easy to write and understand, and the syntax is plain english.

    Actually that's the only reason I like upstart. Maybe with Ubuntu onboard with systemd we can get an alternate, easier-to-use syntax than the default systemd.
  • A few mails down the line, I saw someone (Ian Jackson, I think), call for a vote to depose Bdale as the TC chairman, and another vote with more options. The mail thread went on and on...
    Can anyone summarize what happened then? Is Shuttleworth premature in this decision?

  • by Freshly Exhumed (105597) on Friday February 14, 2014 @03:21PM (#46248801) Homepage

    I got SystemVd on vacation in Thailand and now I'll never be able to spawn child processes again.

  • by trek00 (887323) on Friday February 14, 2014 @04:49PM (#46249853)
    a really interesting reading: http://ewontfix.com/14/ [ewontfix.com]
  • Shuttleworth ... Take heed from ... well ... everyone and dump Unity.

"In order to make an apple pie from scratch, you must first create the universe." -- Carl Sagan, Cosmos

Working...