×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Ubuntu To Switch To systemd

Soulskill posted about 9 months ago | from the follow-the-leader dept.

Ubuntu 279

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

Sorry! There are no comments related to the filter you selected.

Good...? (5, Insightful)

Kagetsuki (1620613) | about 9 months ago | (#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...? (5, Insightful)

fishybell (516991) | about 9 months ago | (#46247099)

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.

Embedded uses something different anyway (2, Insightful)

Anonymous Coward | about 9 months ago | (#46247219)

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.

Re:Embedded uses something different anyway (2)

skids (119237) | about 9 months ago | (#46247271)

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.

Re:Embedded uses something different anyway (5, Insightful)

dalias (1978986) | about 9 months ago | (#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: (5, Funny)

binarylarry (1338699) | about 9 months ago | (#46247777)

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

Re: (1)

Anonymous Coward | about 9 months ago | (#46247813)

Bah, VB6!

Re: (3, Funny)

Anonymous Coward | about 9 months ago | (#46248605)

"You mean you don't love me anymore?" sobbed PHP.

Re:Embedded uses something different anyway (3, Interesting)

fishybell (516991) | about 9 months ago | (#46247385)

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.

Re:Embedded uses something different anyway (1)

Anonymous Coward | about 9 months ago | (#46247677)

I doubt there are many SoCs with more than 16GB ram and more than 8 processing cores.

Re:Embedded uses something different anyway (1)

Anonymous Coward | about 9 months ago | (#46248545)

...now.

Re:Embedded uses something different anyway (0)

Anonymous Coward | about 9 months ago | (#46248763)

s/Busybox/systemd/;

Re:Embedded uses something different anyway (5, Informative)

Anonymous Coward | about 9 months ago | (#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:Embedded uses something different anyway (2, Interesting)

Anonymous Coward | about 9 months ago | (#46248045)

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

Re:Good...? (2)

serviscope_minor (664417) | about 9 months ago | (#46247227)

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...? (3, Informative)

s.petry (762400) | about 9 months ago | (#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.

Re:Good...? (0)

Anonymous Coward | about 9 months ago | (#46247441)

RH6 uses upstart.

Re:Good...? (1)

Anonymous Coward | about 9 months ago | (#46247621)

RHEL6 may use upstart (though I doubt it) RH6 (releases 26 April 1999) used SysV Init.

Re:Good...? (1)

X0563511 (793323) | about 9 months ago | (#46247699)

CentOS 6 doesn't. I know Centos doesn't track RHEL 100%, but that's a significant difference...

Re:Good...? (2)

caseih (160668) | about 9 months ago | (#46247917)

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 it will work with systemd. And the logging facility is much better since the daemon can just write to standard out or standard err if it wants to, and everything is captured to the log (and normal syslog still works).

Yes if you resist working with Systemd, and work against it, your life is going to be a lot more difficult. And I used to think as you do about it, but after working with it a bit more, I can see how it is a better system. It's still too opaque for my tastes, but in practice it works very well.

My only concern is how deeply it ties into the Linux Kernel, which means that we're losing the freedom to use other Unix operating systems once we tie to systemd. Competition is always good but this is going to really squeeze FreeBSD (and to a lesser extend OpenBSD). Gnome 3 is Linux only because of this. We'll have to see where this goes I guess.

Re:Good...? (0)

Anonymous Coward | about 9 months ago | (#46248155)

Here is a forum post that explains some of the reasons Arch Linux switched. Obviously, not all of these reasons are important to everyone. And maybe none of them are important to you. But there definitely are reasons.

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Re:Good...? (3, Interesting)

RabidReindeer (2625839) | about 9 months ago | (#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...? (5, Informative)

fishybell (516991) | about 9 months ago | (#46247533)

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.

Re:Good...? (2)

DikSeaCup (767041) | about 9 months ago | (#46248673)

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...? (4, Insightful)

Billly Gates (198444) | about 9 months ago | (#46248649)

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.

Re:Good...? (0)

Anonymous Coward | about 9 months ago | (#46247349)

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.

I understand that better reporting tools are a good thing (can you explain more to those of us who haven't migrated?). But otherwise, it's an init system. Just how often are you rebooting that server?

Re:Good...? (1)

fishybell (516991) | about 9 months ago | (#46247779)

In truth, like System V, it's a set it and forget it sort of thing for most users (or more realistic, never realize it's even there sort of thing). For me, I have about 40 servers, physical and virtual, and about 150 thin clients to manage using various shades of Fedora, CentOS and RHEL. The thin clients boot over pxe to and then connect via xdmcp to a Fedora 19 box for their desktop environment. As Fedora 19 isn't exactly the best, and users do strange things, one will end up getting rebooted every week or so. The thin clients end up getting rebooted all the time (people think they should turn off their computer at night, so they do). Being able to use journalctl to see exactly what process took how much time was instrumental in getting a fast bootup time, which makes users happier. Happy users = happy admin. Happy admin = the building doesn't get burned down in a quest to get back the stapler. Every time I have to mess with anything other than systemd (on the CentOS and RHEL servers) I die a little inside. It's like using ipchains instead of iptables. Yes it worked, but the world moved on (and yes, I know, iptables is archaic at this point in time).

Re:Good...? (1)

causality (777677) | about 9 months ago | (#46248259)

In truth, like System V, it's a set it and forget it sort of thing for most users (or more realistic, never realize it's even there sort of thing). For me, I have about 40 servers, physical and virtual, and about 150 thin clients to manage using various shades of Fedora, CentOS and RHEL. The thin clients boot over pxe to and then connect via xdmcp to a Fedora 19 box for their desktop environment. As Fedora 19 isn't exactly the best, and users do strange things, one will end up getting rebooted every week or so. The thin clients end up getting rebooted all the time (people think they should turn off their computer at night, so they do). Being able to use journalctl to see exactly what process took how much time was instrumental in getting a fast bootup time, which makes users happier. Happy users = happy admin. Happy admin = the building doesn't get burned down in a quest to get back the stapler. Every time I have to mess with anything other than systemd (on the CentOS and RHEL servers) I die a little inside. It's like using ipchains instead of iptables. Yes it worked, but the world moved on (and yes, I know, iptables is archaic at this point in time).

It's a shame that System V became so widespread instead of OpenRC.

Re:Good...? (0)

robmv (855035) | about 9 months ago | (#46247361)

Jolla Sailfish OS use systemd [lwn.net]

Re:Good...? (1)

Anonymous Coward | about 9 months ago | (#46247467)

As a sysadmin, the complexity in creating a random startup script for a new custom service on a systemd server is a huge barrier to entry.

Re:Good...? (1)

Eunuchswear (210685) | about 9 months ago | (#46247913)

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.

My phone uses systemd. It seems to work.

Re:Good...? (2)

inhuman_4 (1294516) | about 9 months ago | (#46248015)

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.

Re:Good...? (2)

Kremmy (793693) | about 9 months ago | (#46248175)

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.

Re:Good...? (1)

baffle (144921) | about 9 months ago | (#46247265)

From what I've read about systemd it seems like a better system, and it sure helps with the fragmentation situation. Hopefully RH/Canonical can decide on Wayland vs Mir as well..

I agree (1)

Anonymous Coward | about 9 months ago | (#46246965)

Good call. Ubuntu needs to keep the same basic internals as upstream otherwise what's the point.

Re:I agree (-1, Offtopic)

MightyMartian (840721) | about 9 months ago | (#46247061)

Ubuntu can adopt the NT kernel for all I care. I abandoned it a number of years ago and will never go back. I just wish those toxic bastards would stop trying to influence the Debian team.

Re:I agree (4, Interesting)

ZarathustraDK (1291688) | about 9 months ago | (#46247289)

Your comment made me switch back to Ubuntu. Seems like all the tinfoil-whiners are gone from there now.

Re:I agree (1)

hcs_$reboot (1536101) | about 9 months ago | (#46247067)

systemd is as good as init daemons management system - the problem is how the transition is going to be performed? Hopefully it won't be like the gnome-classic => Unity mess. Init and systemd will both have to be available, giving time to administrators to migrate what could not be automatically transferred and specific applications.

Re:I agree (2)

caseih (160668) | about 9 months ago | (#46247983)

Fedora made the transition some time ago, and from a user's point of view it was completely transparent.

RHEL7 beta has transitioned to systemd, and again it's pretty transparent. The old service command is still there and thunks through to systemd. The only time you really notice the difference is if you want to install a custom daemon. You can either use an init script, or you can create a simple systemd service file. There are a few systemctl commands to learn. But really, it's as close to a painless transition as you can get.

Xubuntu 13.04 Live CD is already running systemd (2)

Kremmy (793693) | about 9 months ago | (#46246967)

Maybe the linux distributions should stop pulling an AppleSoft and start maintaining their shit instead of rewriting it again.

What? (0)

Anonymous Coward | about 9 months ago | (#46247009)

They aren't implementing their own?!?

Well color me surprised! (1, Offtopic)

iwbcman (603788) | about 9 months ago | (#46247023)


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.

Re:Well color me surprised! (1, Offtopic)

wiredlogic (135348) | about 9 months ago | (#46247261)

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

Nice try. You still have to wait a few months before everybody else leaves for good. Then you can have FP to your heart's content.

Re:Well color me surprised! (1)

iwbcman (603788) | about 9 months ago | (#46247871)


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!

Whats wrong with init? (2)

Viol8 (599362) | about 9 months ago | (#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.

Re:Whats wrong with init? (0, Insightful)

Anonymous Coward | about 9 months ago | (#46247135)

"I know nothing about this software but I'm gonna bitch, complain and sling shit at it anyway. How dare they move my cheese!"

- Typical Slashtard

Re:Whats wrong with init? (5, Interesting)

causality (777677) | about 9 months ago | (#46247281)

"I know nothing about this software but I'm gonna bitch, complain and sling shit at it anyway. How dare they move my cheese!"

- Typical Slashtard

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

If the existing init systems were causing widespread grief I'd be much more receptive to it. So would just about anyone currently questioning systemd's rapid adoption. Right now the reason for installing it is "everyone else is adopting it as the new standard and it will be increasingly difficult to go against that standard." That's not the best of selling points. It's not like "wow all these problems and limitations I had been experiencing will finally go away!" like you get with truly sensible and evolutionary changes.

If you think that shouldn't matter to anyone, you could explain why you think so. In the meantime, please make an effort to understand the viewpoint of those who disagree with you. Then you stand a real chance of actually addressing the issue, or at least of not embarassing yourself with smug hand-waving and knee-jerk dismissals based on your annoyance that everyone doesn't already agree with you.

Re:Whats wrong with init? (0)

Anonymous Coward | about 9 months ago | (#46247301)

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

Based on having used it or because your cheese got moved? All these distros wouldn't be adopting it if what you say is true, especially Debian. Get back to me when you have a real argument not cliches.

Re:Whats wrong with init? (2)

causality (777677) | about 9 months ago | (#46247613)

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

Based on having used it or because your cheese got moved? All these distros wouldn't be adopting it if what you say is true, especially Debian. Get back to me when you have a real argument not cliches.

So you prefer to repeat yourself rather than address the real root cause of the remaining resistance to systemd? You definitely missed an opportunity there.

I said I question systemd's adoption. I didn't say I was against it, nor did I say that other people shouldn't use it. Even that offends you, and you resort to a form of "everyone else is doing it!" (the antithesis of thinking) to justify yourself. This is why you are smug.

I reasonably put a valid question to you and you weren't prepared for that at all. That's a shame, because if systemd is truly so wonderful, its adoption could only be harmed by advocates like you.

Re:Whats wrong with init? (0)

Anonymous Coward | about 9 months ago | (#46248187)

So you prefer to repeat yourself rather than address the real root cause of the remaining resistance to systemd? You definitely missed an opportunity there.

You didn't answer the question. So, yes, I will repeat it until you give an actual answer not one of the many cliches from the "I simply hate Lennart" crowd.

I said I question systemd's adoption. I didn't say I was against it, nor did I say that other people shouldn't use it. Even that offends you, and you resort to a form of "everyone else is doing it!" (the antithesis of thinking) to justify yourself. This is why you are smug.

Offended by what? Some ignoramus parroting tired cliches? Don't make me laugh.

Re:Whats wrong with init? (1, Informative)

Narcocide (102829) | about 9 months ago | (#46248273)

Look, you coward, systemd is written by someone who can't grock grep. I thought Debian could do no wrong too, but apparently no organization is impervious to beligerant ignorance.

http://ewontfix.com/14/ [ewontfix.com] (posted elsewhere in this discussion by someone else, this is the well-organized counter-argument you claim to be willing to hear. read it then fuck off)

Re:Whats wrong with init? (1)

Anonymous Coward | about 9 months ago | (#46247207)

Parallel start is something already doable in Debian stable, you have to enable some flags in rcS script and install an script that parse the LSB headers in the rc init scripts, and organize them in in deps. Everything combined enables a parallel startup.

But the point here is not 'just' parallel startup. For what I've seen, the systemD init has some technical advantages when troubleshooting, logging and doing some other stuff. It's the combo that helps and there were some nice technical discussions here https://wiki.debian.org/Debate/initsystem/systemd

Re:Whats wrong with init? (5, Interesting)

EmperorArthur (1113223) | about 9 months ago | (#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.

Re:Whats wrong with init? (0)

Anonymous Coward | about 9 months ago | (#46247333)

Start-stop-daemon [unix.com] makes for reasonably clean init scripts. It takes care of the details of managing the service so you only have to write a simple case statement in the script [github.com] .

Re:Whats wrong with init? (5, Interesting)

tlhIngan (30335) | about 9 months ago | (#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.

Re:Whats wrong with init? (3, Interesting)

causality (777677) | about 9 months ago | (#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.

who uses run-levels? (1)

Anonymous Coward | about 9 months ago | (#46248291)

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.

While I'm an Linux admin now (and previously did a lot of Solaris stuff), I've also had a lot of experience with BSD.

There are three states that most systems are in:
* starting up
* shutting down
* single-user
* multi-user

I think BSD got it right in this regard as the extra complexity of run-levels isn't use much (if it at all).

Re:Whats wrong with init? (0)

Anonymous Coward | about 9 months ago | (#46247287)

I heard a few things like:
- safety (proper locking between dependencies and concurrent runs of the same command)
- flexibility (how precisely you can define your dependencies and events)
- speed of booting

Re:Whats wrong with init? (1, Troll)

gweihir (88907) | about 9 months ago | (#46247371)

The only thing wrong with init is that a cretin named Poettering did not create it. As this person wants to set himself a statue, this is apparently reason enough. There are tons of things wrong with systemd though, not the least of it that it completely ignores UNIX philosophy and violates KISS.

Incidentally, systemd is unstable, hard to debug, hard to configure, complex, thinks binary log formats are acceptable and the same cretin brought us pulseaudio.

Re:Whats wrong with init? (3, Informative)

fishybell (516991) | about 9 months ago | (#46247653)

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.

Re:Whats wrong with init? (2)

Billly Gates (198444) | about 9 months ago | (#46248729)

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 an example and send an email to you. You could try to do this with conventional scripts but it would be a lot more difficult

I am not experienced enough to qualify whether systemD is a good implementation as upstart also is event driven and somewhat sysV init compatible. But this is why Sun and Apple are phasing out init with event driven systems like this.

like conceeding that air is necessary (2, Insightful)

Virtucon (127420) | about 9 months ago | (#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.

Re:like conceeding that air is necessary (4, Insightful)

raxx7 (205260) | about 9 months ago | (#46247357)

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.

Re:like conceeding that air is necessary (1)

causality (777677) | about 9 months ago | (#46247669)

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.

Re:like conceeding that air is necessary (1)

joebok (457904) | about 9 months ago | (#46247525)

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.

Works for me (1)

Slashdot Parent (995749) | about 9 months ago | (#46247241)

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

Nevertheless, the decision is for systemd (0)

Threni (635302) | about 9 months ago | (#46247321)

Sentence fragment.

Stupidity is contagious (0, Flamebait)

gweihir (88907) | about 9 months ago | (#46247335)

That is the only explanation I can come up with for this. Personally, I am in the process of moving to Gentoo to avoid the systemd-plague.

Re:Stupidity is contagious (0)

Anonymous Coward | about 9 months ago | (#46247617)

What a well-reasoned, logical position you have taken. Couldn't be bothered to provide any rational argument behind why systemd is a plague, eh?

Re:Stupidity is contagious (1)

gweihir (88907) | about 9 months ago | (#46248421)

The shortcomings of this monster are rather obvious to anybody halfway competent.

Re:Stupidity is contagious (1)

SargentDU (1161355) | about 9 months ago | (#46247767)

systemd is also on gentoo, so you may have to resort to older distributions / source code.

Re:Stupidity is contagious (1)

gweihir (88907) | about 9 months ago | (#46248409)

It is there, but it is not mandatory.

Re:Stupidity is contagious (0)

Anonymous Coward | about 9 months ago | (#46248565)

Better move to BSD. Gentoo already has systemd with Gnome depending on it. Even Slackware might make the move eventually, Patrick told it in an interview:

LQ) Right now, there are a number of potentially intrusive technical changes coming to some of the major distributions. How do you feel some of these will impact Linux in general and Slackware specifically? Are there any you would considering merging into Slackware? (55020 & tuxrules)

volkerdi) Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle. Wayland, by comparison, seems fairly innocuous, assuming that they'll be able to implement network transparency either directly or through some kind of add-on compatibility layer. Again, another thing that most desktop users don't have a lot of use for but many users can't do without. I like X11, and would probably stick with it if moving to Wayland meant losing that feature, even if Wayland's rendering method carried with it some benefits like reduced rendering artifacts or increased video performance. I guess we'll just have to see what the overall benefit is when it's far enough along to make such comparisons.

source: http://www.linuxquestions.org/questions/interviews-28/interview-with-patrick-volkerding-of-slackware-949029/

So, it looks like systemd is the future for Linux, until something better comes.
Of course, people who don't like that can still put together a distro with something else as PID1, it's still free software after all. But I seriously doubt the people who care with passion have enough manpower to propose a real alternative.

systemd violates the UNIX philosophy (4, Insightful)

bzipitidoo (647217) | about 9 months ago | (#46247339)

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.

Re:systemd violates the UNIX philosophy (4, Informative)

joejor (578266) | about 9 months ago | (#46247497)

Here's a pretty good treatise on the shortcomings of systemd: http://ewontfix.com/14/ [ewontfix.com]

Re:systemd violates the UNIX philosophy (0)

Anonymous Coward | about 9 months ago | (#46248539)

I quite agree with the idea of critical core places having an extremely simple and provably correct hyper-visor of sorts to hand off to and be configured by more complex, permitted to fault processes.

Re:systemd violates the UNIX philosophy (1)

zixxt (1547061) | about 9 months ago | (#46247587)

Amen!

Re:systemd violates the UNIX philosophy (3, Insightful)

broken_chaos (1188549) | about 9 months ago | (#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.

Re:systemd violates the UNIX philosophy (1)

Anonymous Coward | about 9 months ago | (#46248097)

Does udev really need to depend on systemd?

Yes, and systemd needs to depend on journald, and vice versa, and PulseAudio and Gnome must depend on them, too. Ideally everything should depend on everything.

If you design your services well, with clear and separate responsibilities, modular design, and clearly defined interfaces, some people may choose not to use them. In fact, they may decide that it's poorly written, buggy unstable crap. They may try to replace them with services that work instead. Or if you accidentally produce something useful, they may try to run your stuff on other operating systems. All of this must be prevented.

Re:systemd violates the UNIX philosophy (1)

kreigiron (1529463) | about 9 months ago | (#46248129)

If UNIX philosophy is an issue, Buy a Mac (or download your favorite BSD) and use an actual implementation of UNIX, let's remember that GNU's not UNIX, and Linux is UNIX-like, we cannot ask for anything that's never been promised.

Re:systemd violates the UNIX philosophy (0)

Anonymous Coward | about 9 months ago | (#46248201)

I agree. Its a monolithic tool.

Why I don't like systemd: (2, Insightful)

wonkey_monkey (2592601) | about 9 months ago | (#46247381)

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

Re:Why I don't like systemd: (4, Informative)

Anonymous Coward | about 9 months ago | (#46247453)

put this line in your .bashrc file

alias service='systemctl'

Re:Why I don't like systemd: (1)

causality (777677) | about 9 months ago | (#46247705)

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

I can only imagine your irritation at using non-words like "rm", "cd", "ln", and "ls". At least they're short?

Re:Why I don't like systemd: (1)

Trepidity (597) | about 9 months ago | (#46248073)

My guess is it's a takeoff on the classic sysctl [freebsd.org] .

why not the new thing? (5, Insightful)

dAzED1 (33635) | about 9 months ago | (#46247423)

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.

Re:why not the new thing? (1)

dAzED1 (33635) | about 9 months ago | (#46247451)

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

Re:why not the new thing? (1)

jbolden (176878) | about 9 months ago | (#46247709)

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?

Re:why not the new thing? (4, Informative)

broken_chaos (1188549) | about 9 months ago | (#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.

Re:why not the new thing? (1)

Anonymous Coward | about 9 months ago | (#46248209)

Wow. Excellent critique. No upgrades without reboot? I don't think so. I'm sticking with Sysv.

Re:why not the new thing? (0)

Anonymous Coward | about 9 months ago | (#46248755)

At least the BSDs can remain stable, while Linux pursues faster unstable boot times.

Sigh. (-1, Flamebait)

zixxt (1547061) | about 9 months ago | (#46247659)

Ubuntu is just another in a long list of Linux distribution sellouts sucking Lennart Poettering's tainted jizz coated code.

Gentoo, Slackware, BSD please save us.

Re:Sigh. (4, Interesting)

caseih (160668) | about 9 months ago | (#46248321)

Yes if you think systemd is bad, either rip it out on your machine or roll your own distro. Or move to FreeBSD. It's available now, and it runs great. So no need to whine. Just move to an operating system that fits your personal parameters. More likely you'll stick with your current distro and whine and moan about something that you don't well understand.

On the desktop side of things, I've been watching Linux struggle for years to do simple things like deal with removable media and USB devices. For a while there was hal, then udev, and now systemd. And finally things are actually working, and working rather well. Mostly thanks to udev, but systemd now builds on that. I know many people don't mind manually mounting devices and loading modules to make usb devices work (I don't mind, really). But it's nice to have things automatically work.

And really systemd on the service isn't that bad an idea either. Fine-grained logging is very useful and conventional syslog is still available and will always be there. Process supervision is something that's been needed for a long while now.

about time (0)

Anonymous Coward | about 9 months ago | (#46247789)

ubuntu has not been so cutting edge anymore. maintaining the rc was so 80's. easy to monitor,simple to recover, loggging, vm friendly can't think why waited so long

I was shocked, just shocked. (1, Funny)

Anonymous Coward | about 9 months ago | (#46247859)

I was immediately surprised to read this. I just couldn't believe it. I read it a couple of times to make sure I read it right. I just can't believe people still use *buntu.

Nuts, upstart syntax is so easy (4, Insightful)

exabrial (818005) | about 9 months ago | (#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.

Fuck yes. (0)

Anonymous Coward | about 9 months ago | (#46248445)

I didn't see this coming. This is a massive boon. I was planning to jump ship to Debian as I was fully expecting Ubuntu to go all NIH and stick with Upstart.

I think Upstart is better than sysvinit, but I've had serious trouble as there are several things it simply can't do, and could never do, unless perhaps it got cgroup tracking support (and it still doesn't have that). Meanwhile, systemd came out of nowhere and - I tried it, and it was significantly better for what I needed, and that is server-side stuff too.

This is a very encouraging decision. It's too late for 14.04 LTS, but the next LTS should have it I think.

This should also replace all the scripts in the initramfs. At the moment, that's a bit of a pain, in both Debian and Ubuntu, and Ubuntu wanted to move Upstart into the initramfs. This should pre-empt that and properly deprecate Upstart.

Still, thanks to the people behind Upstart for an interesting approach. I can't help but feel that it does things the wrong way round though, and that's still the case even now. People hate Lennart, but systemd is damn good.

Wasn't there a revote? (1)

MurukeshM (1901690) | about 9 months ago | (#46248533)

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?

Variety was good (0)

Anonymous Coward | about 9 months ago | (#46248661)

Upstart was nice. Maybe if they release it under a BSD license some other project will pick it up. I am hoping to see something come out from OpenLaunchd though.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?