Spotify position in support of systemd in the default init debate

https://lists.debian.org/debian-ctte/2014/01/msg00287.html

by possibilistic • 13 years ago

234 166 13 years ago

lists.debian.org

Shish2k7• 13 years ago

Currently using systemd on debian myself, with a few of my own custom .service files and a lot of falling back to sysvinit compatibility -- would love to see more upstream packages contain .service files. Things like "automatically restart if the service dies uncleanly" being handled by the init system are a godsend compared to managing init.d scripts which try to do that job themselves (things like "service start" getting into an infinite restart loop, then "service stop" says "service is not running", because the init script is stuck in a loop but the service itself hasn't been spawned...)

peterwwillis2• 13 years ago

init scripts were originally designed to be "dumb" scripts that only performed one simple task. other scripts could then be written around them reliably, without wondering what the script might be doing in the background other than loading some options and running a program.

with modern service management, a lot of extra "intelligence" has been added to how programs are executed and managed. this leads to levels of complexity and uncertainty that eventually lead administrators to hacking the hell out of the system to be able to use it reliably, usually disabling advanced features so they can control such features themselves.

on top of that, automation of service restart is a solved problem since... decades ago? it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think.

krakensden2• 13 years ago

it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think.

All the more reason to solve it once instead of in a billion different and differently awful addon packages.

Plus, systemd is actually better at this than supervisord, daemontools, etc., already because of its cgroup usage- it can reliably kill all children before restarting, even if the process forks.

Finally, I encourage you to read the systemd docs: http://www.freedesktop.org/software/systemd/man/systemd.serv...

they are quite nice, and show that, in fact, thought has gone into it.

unfortunately, once such a function is added to your init system, people use it all over the place

I'm not super on board with this view- for almost everyone, if apache goes down, they want something to restart apache because the problem was probably transient and having apache being down is a Big Problem. Plus, most modern supervisors know about things like "restart throttling".

bkor9• 13 years ago

A lot of Uncertainty and Doubt you're raising there... I'm wondering if you actually used systemd?

alextingle• 13 years ago

/etc/inittab?

bryanlarsen• 13 years ago

Upstart also has features to handle this scenario. For my purposes, I don't really care whether they choose upstart or systemd, just as long as the init.d scripts go away.

jethro_tell2• 13 years ago

It's the cgroups man.

josteink• 13 years ago

I've always liked Linux for the simplicity of services and how they're handled through simple, clear and very understandable init.d scripts.

Any distro which takes them away stops being my friend.

thwarted• 13 years ago

I've never seen an init.d script that tried to restart something automatically, and attempting to do so within the script itself is folly. Any init.d script that gets into an infinite loop would be deleted immediately. The init.d script should be starting a daemon and then it should exit. If restarting a service like this is required, then the init.d script should spawn something that monitors the daemon (there are numerous tools that do this). Recent syslog-ng comes with one built in.

There's so much confusion over /etc/rc, /etc/init.d, /etc/rc?.d, init(8), inittab(5), initscript(5), what they are and how they are related. Getting the machine setup an in a usable state should be divorced from the services that the machine runs, but this is a fine line. Personally, I consider a machine "usable" if the filesystems are mounted, the machine is network accessible, and a configuration management system starts and/or sshd is running so one can login (and even then, this last one is not a strict requirement). Service management beyond that should be handled as just another process running. It's unfortunate that systemd is being pushed as an init(8) replacement, and doesn't seem to support running as a service itself. This being the default, with the option to replace init(8), would most likely lessen the controversy and reduce risk as systemd is developed and rolled out. "Look, you've been doing process management of individual services with systemd already, and you see the benefits; did you know that systemd can also replace init, to get those benefits system-wide?" It's not presented like that, however.

lamby• 13 years ago

This sort of thing actually happens a fair amount, albeit usually without a "celebrity" company and often without the organisation even being named.

It's actually a difficult email to write (especially if you are disagreeing with a proposed change) as it can easily come across as a sort of childish blackmail.

_delirium6• 13 years ago

Yeah, it seems like it could range from positive to negative depending on the precise tone and implications. On the one hand, if a large Debian user believes that some decisions will make lives easier for them and others harder, them explaining why they think so gives useful input to Debian that they can use to better server their users. Of course, one large company's interests might be outweighed by other considerations (and considerations of other users), but it's useful input to have either way. On the other hand, written in slightly the wrong way it can come across as bullying... "as one of your largest users, we strongly suggest you make this decision or we will have to pursue alternatives". Even more tricky in cases where the user is also a significant supporter of a project (whether through staff resources, donations, etc.).

This one seemed reasonably written to me. It was a little light on the technical details of why specifically Spotify finds systemd works best for their use case, but the three bullet points do give some information.

ersii• 13 years ago

Well, to put some perspective into their "weighing in" on the issue: the guys at Spotify really do care about Free/Open Source Software. (Especially Noa, for what I've noticed).

I interpret their "weighing in" on the issue as a balanced and constructive feedback claim to the community, from a community member.

I think it's great when people participate and especially when they go full disclosure; iesaying who they are and from where and especially why (in a positive/constructive way).

wpietri• 13 years ago

Two things I love about this: ops guys getting involved in the debate, and the fact that Spotify has somebody who's job is to be open-source ombudsman.

dima55• 13 years ago

The debate moved to the CTTE long ago. Stuff like this is noise at this point.

girvo• 13 years ago

While you're right, don't be such a grump. It's cool that some business try and stay involved in this :)

possibilistic2• 13 years ago

Debian.org's server seems to be having trouble. This is getting traffic from both HN and /r/linux.

Cache: http://bugs.debian.org.nyud.net/cgi-bin/bugreport.cgi?msg=35...

runjake• 13 years ago

I'm confused about debian stable vs testing vs unstable. Is there a branch that keeps relatively recent versions of packages and is reasonably usable as a daily driver?

dfox• 13 years ago

Yes there it is, it is exactly what unstable is. Packages in there are reasonably recent and generally match upstream in functionally. There are occasional compatibility problems between packages but that is something that you cannot avoid if you want to have "relatively recent versions".

mwilliamson• 13 years ago

I tend to prefer using testing for getting recent packages on a desktop -- packages automatically migrate from unstable to testing if no bugs are reported within 10 days, which tends to mean a slightly more stable system, but still with reasonably recent versions.

sampo• 13 years ago

So unstable is reasonably stable?

p4bl02• 13 years ago

I use Debian on all my computers. The stable branch for servers and testing for others. Debian testing is sufficiently up-to-date for my taste. The very few things that are not can usually be installed anyway through backports or other repository. The last case I had (but that's a perhaps once in a year scenario) was with Batteries [1]. I needed version 2.1 but Debian testing only has 2.0, what I did is simply to install Batteries through opam [2] rather than apt-get install it.

[1] http://batteries.forge.ocamlcore.org/

[2] http://opam.ocaml.org/

sandGorgon6• 13 years ago

do you ever use a PPA ? Most of the custom repos are meant for ubuntu and I cant ever find any which will respond to "sid" or "jessie" or something.

networked• 13 years ago

Is there a branch that keeps relatively recent versions of packages and is reasonably usable as a daily driver?

Recently, I've been looking for an alternative to Debian testing or unstable for the desktop that doesn't stop getting updates during the stable freeze and doesn't break afterwards. It seems like the best option here is one of the rolling release distributions based on unstable like aptosid or siduction; I am downloading an aptosid ISO right now to try it out.

Can anyone here relate their own experiences with those?

dspillett• 13 years ago

"Testing" is probably what you want.

Unstable is all relatively recent but likely to break regularly: it is its job to break so problems are found before packages are moved on.

Testing is less up to date but should be pretty stable. Before each new release Testing is frozen except for changes to fix problems (i.e. new new packages or version updates, except where an update/patch fixes a problem that isn't deemed insignificant for release), once the freeze is complete and the result declared ready the current Testing becomes the new Stable. It used to be that Testing did not necessarily get timely security updates like Stable, so it was strongly recommended against for production and/or public use, though this is no longer the case except for a period after a new release.

"Stable" is just that: it changes as little as possible, updates generally being only to fix security problems or other significant bugs that are found. This means that packages which see a lot of active development can become quite out of date with respect to new/updated features.

TylerE• 13 years ago

That said, unstable isn't really THAT unstable...it's generally (at worst) no worse than the non-LTS versions of Ubuntu or Fedora etc

kybernetyk• 13 years ago

Is there a branch that keeps relatively recent versions of packages and is reasonably usable as a daily driver?

For workstations where I usually want new packages I use unstable. It's not really "unstable" (IIRC Ubuntu is based on it) and has always up to date packages and bug fixes in short time. An unstable installation didn't break for me once in the last 4 years.

The problem with testing is that bugs need too long to get fixed (weeks to months). It's the testing environment for the next stable release so it doesn't really change too often and the packages aren't really the newest versions.

For servers I'm driving stable because I'm rather conservative with servers.

forgottenpass3• 13 years ago

I'm confused about debian stable vs testing vs unstable.

As the joke goes: unstable means testing, testing means stable and stable means old.

JoshTriplett• 13 years ago

I've always heard it joked that "unstable is two letters from usable, and stable is one letter from stale". (I personally run unstable on laptops/desktops and stable on servers, and appreciate both.)

Karellen2• 13 years ago

Debian "unstable" is the "bleeding edge" version. New packages go in there on a pretty frequent basis, and things change often. Sometimes there is breakage. I would strongly advise against running this unless you're capable of and willing to fix serious breakage every now and then. And dealing with package upgrade conflicts. Sometimes you can't just "update everything", because someone just uploaded X version 2.1, only package Y has a strict versioned dependency on X <= 2.0, so you need to decide what you want.

I used "unstable" on my desktop for a while, but once every 2-3 years I'd end up with a bug that would break the early boot process, and I'd have to muck around with rescue disks and chroots and reconfiguring grub and the like. So I'd advise against this, unless you want to actually get involved in the Debian project.

Now I run "testing" on my desktop. When packages have been in "unstable" for a certain period of time (typically 10 days, although this is changing) without having a Release Critical (RC) bug filed against them, and if the move won't break any other packages, then "unstable" packages migrate to "testing". It's fairly up-to-date, although sometimes a large group of packages that need to transition all at once will take a while to synchronise.[0] And there are explicit "transitions" for some widely-used base libraries when they undergo ABI changes.[1] But you generally don't need to worry about this, as it'll mostly happen behind the scenes.

Still, if you're going to run "testing", I would still recommend installing apt-listbugs, which will tell you if there are any new RC bugs in any packages you're about to install/update (e.g. that were discovered only after the package migrated to testing), and allow you to decline the update.

Then, every couple of years or so, Debian is "frozen" for a few months, and no new updates are allowed that don't fix RC bugs. Once all the RC bugs have been fixed, and these fixes have all migrated to "testing", that version of "testing" becomes the new "stable". ("unstable" and "testing" can get a bit out-of-date during this time, but generally not too badly). "stable" is then "stable" in that it doesn't change at all, except for security updates, until the next "stable" is released a couple of years later. (There is also "backports" which packages newer releases of some software to go on top of stable, but you can't really rely on anything in particular getting a backport version.) This is handy for large deployments where you need to support users who will freak if their menus move around, or servers, or if you want to create your own distro and need an unchanging base platform to work from.

If you're moderately technical, and want fairly up-to-date shiny, I'd recommend Debian "testing". If you're interested in Free Software in and of itself, I'd definitely recommend it.[2]

[0] https://release.debian.org/migration/ [1] https://release.debian.org/transitions/ [2] http://www.debian.org/social_contract

chimeracoder2• 13 years ago

Thanks for the detailed breakdown.

I currently run Arch on my main computer (and have for the past few years), Ubuntu on a few others, and have dabbled with some other distros for fun. I'm thinking of giving Debian a shot for my main computer, though.

How would you compare unstable and/or testing to Arch (if you have any experience with it)?

pilgrim689• 13 years ago

People will recommend "testing" to you but I would advise against it... My path was: stable->testing->stable, because while on testing random stuff would break (laptop wouldn't sleep when I shut the lid, UI glitches, etc.). Plus, on testing I had to frequently update packages I didn't care about updating. I use stable now and when I need a recent package I now instead: compile from source/find backports/use a vm/vagrant

It's the price I pay for a stable system. Vagrant for my dev environments makes "stable" a much easier choice.

zx2c4• 13 years ago

So that you don't kill their cgi bug tracker, here's the static archive:

https://lists.debian.org/debian-ctte/2014/01/msg00287.html

_delirium6• 13 years ago

Tangent, but the 2nd point is intriguing. How does one use cgroups to set up resource limitations? Is there any kind of decent front-end? I've seen the kernel documentation (https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt), but how do I use it? For example, if I wanted to give some shell users limited accounts where they can't use more than 512 RAM and some CPU quota each, I gather cgroups can do this, but I haven't been able to figure out how to set something like that up. (Yes, I know you could handle that use-case by giving each user their own virtual machine and let VMWare or Xen or Virtualbox handle the RAM/CPU quotas, but that's often not what I want.)

icebraining2• 13 years ago

This answer explains how to create a cgroup witht he quota and then assigning the user to it: http://unix.stackexchange.com/a/34335

_delirium6• 13 years ago

Excellent, thanks! cgrules/cgconfig seems to be what I was looking for.

Fwiw, it looks like those files don't do anything in the default Debian install; you have to install cgroup-bin to pull in the daemons that consult them.

mseepgood• 13 years ago

Tangent, but the 2nd point is intriguing. How does one use cgroups to set up resource limitations? Is there any kind of decent front-end? I've seen the kernel documentation, but how do I use it?

Use systemd: http://0pointer.de/blog/projects/resources.html

Systemd makes these kernel features finally usable.

_delirium6• 13 years ago

That looks interesting for some use-cases, but I don't see a way to use it to assign limits to users, or to processes that aren't started as systemd services. What I have in mind is that I give someone ssh access, they run R or matlab or from the command line, but limited to 512mb (or 1Gb or whatever) of total memory.

WestCoastJustin3• 13 years ago

You're in luck -- I've done a screencast on cgroups where I explain what they are and how you can use them @ http://sysadmincasts.com/episodes/14-introduction-to-linux-c...

Also, it is all command line at this point, but there are some concepts floating around about creating a gui @ http://mairin.wordpress.com/2011/05/13/ideas-for-a-cgroups-u...

sandGorgon6• 13 years ago

could you double check your screencast ? My understanding is limited, but I think Systemd ver 205 changes the cgroup interaction methodology - basically systemd is a single point entry into the cgroup api. You cannot touch cgroup any other way except through systemd. FYI - this is not systemd taking arbitrary control but what the upstream kernel recommended.

My understanding is that Fedora 20 (which uses systemd 208 ) will be impacted by this, as will most other distros. However jessie is proposing systemd 204, so your method might still work.

eliasmacpherson• 13 years ago

change their shell to a bash script that calls bash and has a call to ulimit in it(this will affect everybody though I think). there's another program called cpulimit that you could use.

here's some cgroups resource limiting "resources":

http://dustinoprea.com/2013/11/05/better-resource-throttling...

http://www.janoszen.com/2013/02/06/limiting-linux-processes-...

_delirium6• 13 years ago

ulimit only assigns per-process limits though, not per-user. Afaict you need cgroups to limit users' total usage across processes.

sandGorgon6• 13 years ago

I have been investigating this over the past couple of days for a pet project of mine (a local college needs to setup a programming competition - need to resource limit compile jobs).

The way that systemd handles it is three-fold:

One, in the .service file, you can put in resource constraints [1] - which will be honored by a service on startup.

The second way is to create a .slice file which is exactly that - a slice in the cgroup hierarchy and where you can assign some resource limits (where it is bound by the slices above it in hierarchy). All services that are assigned to this slice will SHARE that cgroup resource constraints. For your specific requirement, this is the way to go. Create a user.slice (to affect all user accounts) or a user-<some uid>.slice to affect on an individual basis (still will inherit from user.slice).

The third way is to invoke systemctl set-property (with properties defined in [1]) to affect an already running process.

What I am attempting to use is systemd-run [3] to start transient processes (not background services) with resource constraints. However, I have filed an enhancement request on some missing features here [4] . Feel free to star it up !

[1] http://www.freedesktop.org/software/systemd/man/systemd.reso...

[2] http://www.freedesktop.org/software/systemd/man/systemd.slic...

[3] http://www.freedesktop.org/software/systemd/man/systemd-run....

[4] https://bugs.freedesktop.org/show_bug.cgi?id=73685

mrud• 13 years ago

There is runguard [1] from the DOMjudge project. It may be able to do what you are looking for.

[1] https://github.com/DOMjudge/domjudge/blob/master/judge/rungu...

sergiosgc2• 13 years ago

Have a look at online judges created by various universities for the ACM intercollegiate programming contest (ACM ICPC). Back in the day I used the one from the university of Valladolid, but I can't seem to find the source code now.

cakeface• 13 years ago

I highly recommend that anyone interested in systemd who doesn't know much about it read Lennart Poettering's initial descriptions of it. I knew very little about Linux init systems and I found this incredibly interesting and informative. http://0pointer.de/blog/projects/systemd.html

pingswept• 13 years ago

Thanks for that. Very interesting read.

pekk2• 13 years ago

It's a lot easier for one systemd-loving company to switch to RHEL/CentOS/Fedora than for everyone else to deal with problems with systemd.

systemd is at least controversial enough in ways that matter to Debian (portability off Linux, etc.) that I think it's nice not to have a monoculture here.

nailer2• 13 years ago

Really? I've been away from Linux for a few years, but it used to be my career. I recently checked out systemd to make a service on a CoreOS box.

systemd replaces so much overlapping logic, has config files for services rather than scripts, and uses an existing known config format. Basically everything that sucked about SysV init. What's not to like?

Edit: I see you've added portability off Linux. That's a very small concern, and certainly lower than 'deep Linux integration' for most Linux users.

pekk2• 13 years ago

Being better than SysV init is not something systemd has a monopoly on...

Portability off Linux isn't a small concern for the Debian project as far as I know

Red Hat related distros are very good distros based on systemd and are still available, it isn't necessary for Debian also to adopt systemd in order for people to use and enjoy it

justin66• 13 years ago

I see you've added portability off Linux. That's a very small concern, and certainly lower than 'deep Linux integration' for most Linux users.

It didn't help systemd's popularity that the people behind it have tried to do disgusting stuff like convince GNOME to make GNOME dependent on it, which doesn't just effect "portability off linux" but the portability of GNOME. (I don't believe they got that one through)

Shish2k7• 13 years ago

In its defence, the portability problems are largely because the linux kernel has awesome features (ie, cgroups) and other kernels don't -- I think it's better for the world if we encourage the other OSes to add cgroups-like APIs to their kernels rather than hold linux back

riffraff• 13 years ago

on the other hand wouldn't that imply that people can't innovate with other solutions in the same space (groups') because they are locked into it by the init system depending on it?

Sanddancer5• 13 years ago

Should the linux world have adopted the FreeBSD jail API rather than spinning their own lightweight containerization API?

bkor9• 13 years ago

What systemd problems? Please elaborate.

agumonkey2• 13 years ago

From linux conf australia 2014 : the 6 stages of systemd http://www.youtube.com/watch?v=-97qqUHwzGM‎

jethro_tell2• 13 years ago

Yeah, that was me as well.

rodgerd5• 13 years ago

The most remarkable thing about doing this talk was how many people have told me, either before (on hearing what I was talking about) or after, that they had various strong opinions on the topic, but hadn't spun up systemd on their servers.

The most gratifying was the number of people who said they'd give it a try after the talk.

agumonkey2• 13 years ago

Was it based on previous software shipped by L.P (pulseaudio was a difficult exercise to say the least) ? or just because of change of decades old SystemV habits that felt heavy and potentially scary ?

ForHackernews• 13 years ago

Who's responsible for changing the titles on these threads?

You've removed the interesting bit: That it's Spotify's ops people putting in their two cents.

shawabawa3• 13 years ago

the title changing policy here is terrible. If the majority of the discussion is based on the post title either delete the entire post or leave it. Changing the title is just confusing

simias• 13 years ago

There are a couple of false positives but I think the policy is generally beneficial, it prevents a lot of title-baiting.

asperous• 13 years ago

I agree-- the title on this post is wrong and should be changed. It should be "#727708 - tech-ctte: Decide which init system to default to in Debian. - Debian Bug report logs"

dfc2• 13 years ago

The spotify bit is the least interesting thing to me.

jeorgun• 13 years ago

It's the only unique bit, though. Nothing they're saying about systemd is exactly new material, whether for Debian or anyone else.

thepumpkin19792• 13 years ago

I submitted it, the title was changed and so was the author. What's going on here.

orik• 13 years ago

Did they actually change the author of the post? I don't see it in your submission history anymore.

ricardobeat• 13 years ago

If you submit a duplicate URL, HN "accepts" it then redirects you to the earlier posting.

sp332• 13 years ago

If you submit a link that someone else already posted, it just counts your "submission" as an upvote on the older post.

tbarbugli• 13 years ago

why on HN top op the page comments are always not about the content but about meta / secondary stuff ?

ps. please dont be mean, do not upvote this!

forgottenpass3• 13 years ago

Out of all the people commenting on #727708, The Spotify post is a rep from an organization with systems to administrate. Just like almost every other not-ctte, not-init maintainer person on that list, so it makes sense for Spotify to comment, but not really worth giving undue weight to their post in the larger debate currently happening on debian-ctte.

If you want a better picture of debian's init decision, the bug got punted to ctte to decide on, so check out the ctte ml archives for December [0] and January [1]. Russ Allbery and Ian Jackson are the most vocal CTTE members on the list and support systemd and upstart respectively. The thread "Bug#727708: init system other points, and conclusion" is where Ian [2] Russ [3] start making the case for their preliminary conclusions.

Edit: If there are other things worth pointing out on the list put 'em here. I've really only been skimming the posts for the last few weeks. They're also considering openRC, but it appears not to be a real contender. Tollef Fog Heen is a debian systemd maintainer and has posts worth reading on both what systemd actually is and what the impact of different decisions.

[0] https://lists.debian.org/debian-ctte/2013/12/ [1] https://lists.debian.org/debian-ctte/2014/01/ [2] https://lists.debian.org/debian-ctte/2013/12/msg00182.html [3] https://lists.debian.org/debian-ctte/2013/12/msg00234.html

dfc2• 13 years ago

The recent discussion on lwn.net is also interesting:

Positions forming in the Debian init system decision: http://lwn.net/Articles/578208/

ekyo777• 13 years ago

rohansingh3• 13 years ago

I should point out that while this is theoretically the official position of our infrastructure team here at Spotify, we've also got a lot of opinion and debate internally (like you have on any topic among a large team of engineers).

One other fun problem Spotify is going to tackle is how we're going to handle systemd vs. upstart if/when we transition from straight-up Debian to Ubuntu.

asdfaoeu• 13 years ago

Why are you transitioning to Ubuntu?

the_mitsuhiko• 13 years ago

One other fun problem Spotify is going to tackle is how we're going to handle systemd vs. upstart if/when we transition from straight-up Debian to Ubuntu.

After two years of upstart I am wholeheartedly regretting ever touching it. It's broken by design and currently in such a bad way that you actually might have to reboot the machine to fix it.

Upstart is the main reason I'm considering dropping ubuntu for something else.

fournm• 13 years ago

Russ's points are an incredibly well thought out and written discussion of systemd vs upstart and worth reading for anyone who needs background on the two.

latchkey• 13 years ago

The bigger question here for me is why Spotify needs 5000 physical servers.

brokenparser• 13 years ago

Not only that, but why with that many servers pages (playlist top, artist/album details, etc) are often very slow to load.

Patrick_Devine• 13 years ago

I have to admit, I was dragged kicking and screaming into the new init world, and really didn't want to leave SysV init. I haven't used systemd, but I have been using upstart and it's grown on me.

After reading this post, I did look at: https://wiki.debian.org/Debate/initsystem/upstart

Which does spell out some reasonable pros and cons of both systems. I'd say the biggest problem with upstart (and possibly the deal breaker) is the licensing terms. Yes, it's open source, but no, I really don't want to have to fill out Canonical's contributer license agreement if I want to contribute. I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that.

There are some tools out there for upstart, but one thing which would be really nice would be a built in command for visualizing the init graph in ascii. It doesn't have to be fancy, just enough to know where your init script is going to be called in the boot process.

hansjorg• 13 years ago

I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that

That is about copyright, not about the license. Organizations who requires this includes the FSF and Mozilla for example. See:

http://www.gnu.org/licenses/why-assign.html

bkor9• 13 years ago

But FSF/GNU contributions are guaranteed to stay under a Free Software license. Canonical is not similar. Not at all the same situation. Further, IMO FSF/GNU/Mozilla are also bad for requesting this.

warp• 13 years ago

The FSF doesn't require this for all GNU projects. Each GNU project can decide if they want to require a CLA or not.

andor• 13 years ago

I'd say the biggest problem with upstart (and possibly the deal breaker) is the licensing terms.

Upstart isn't even a real solution for Ubuntu: they still use SysV init scripts for many daemons (I don't know why exactly). Because upstart cannot monitor daemons that it started through init scripts, it's not reliable for process monitoring...

Also see: https://wiki.debian.org/Debate/initsystem/systemd#Upstart

chimeracoder2• 13 years ago

I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that.

Because they want to be able to have the benefits of proprietary code for themselves (being able to provide their own software under a proprietary license to other parties), without allowing anybody else that same ability.

If it were under the GPL and each contributor retained their copyright over their submission (as is the case with the Linux codebase), this wouldn't be an issue. But by having complete ownership over all the code in the codebase, Canonical is free to change the license at any time they choose.

lvillani• 13 years ago

If it were under the GPL and each contributor retained their copyright over their submission

DISCLAIMER: I'm not a lawyer, everything I say below may be totally wrong.

As far as I know, this is exactly what happens. Canonical's Contributor License Agreements stipulates a form of joint copyright assignment where both Canonical and the author have ownership over the contribution, thereby creating two source trees: one on which Canonical has full control over, the other owned by the collective of individuals who contributed to the project (just like the Linux kernel).

Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. The FSF does something similar for their project, so does Node, Apache, etc. Canonical's CLA used to be nasty but since they started using the Harmony Agreements I think their terms are reasonable.

Personally, as long as they don't ask me to relinquish all and every right on my contribution and/or ask for unreasonable provisions, I'm fine with a CLA.

codingtheone• 13 years ago

I think this is the most important bit "dependency model of systemd is easier to understand, explain and work with than the event based counterpart of upstart.". IMO upstart is over-engineered to say the least.

colanderman• 13 years ago

Glad I'm not the only person who thinks upstart is back-assward. I've never understood how its model of "start a service iff all its dependencies are running" makes any sense: it (a) starts random other services I don't care about, just because their dependencies are met, and (b) forces me to manually track down and start all of a service's dependencies in order to start it.

Though I'd be glad if someone could explain to me how it does make sense.

CameronNemo• 13 years ago

(a) makes sense because it is assumed that if you have the job enabled, you want it to be started. If you do not care about those services, just disable them.

(b) is indeed a PITA.

beefhash• 13 years ago

I don't understand how this is still anything to discuss. systemd is the only option; GNOME is already using it for some parts and will probably not hesitate to integrate it even more deeply to push Poettering's agenda.

Whether or not the sysadmins want to learn systemd and regardless of whether it's the technically superior super-init system (you can't really call systemd an init system anymore), it's going to be forced down our throats anyway. What's with the holdup?

Nursie• 13 years ago

GNOME is far from the only FOSS desktop these days. A desktop that demands you have a specific init system is not onw I care to use.

bkor9• 13 years ago

Systemd provides various things that desktop environments want to use. This is not limited to GNOME. I talked to Enlightment and they're going to make more use of various bits (e.g. user session). Similar with KDE.

Dismissing it entirely like you're doing and pretending this is about forcing: good luck with that. Just like distributions were forced to use it right? Not merit, just pushed?

Try coming up with something concrete. Until that the lack of specifics in your posts tells me enough.

dinkumthinkum• 13 years ago

The person that wrote is a "Free Software ombudsman" ... Pretty serious stuff we got going in software now. :)

trump• 13 years ago

Keep in mind, this is coming from the same company that gives their devs root: https://www.youtube.com/watch?v=pts6F00GFuU#t=169

Otherwise, I agree with their endorsement of systemd.

mwcampbell• 13 years ago

Just saw this interesting post by Noa at Spotify (speaking on his own behalf) later in the thread, about the trade-off between monoculture on the one extreme, and effort spread too thin between competing solutions on the other:

https://lists.debian.org/debian-ctte/2014/01/msg00306.html

bitwize4• 13 years ago

Systemd is the Linux init system. Using anything else at this point is folly. This debate is a tempest in a teapot stirred up by whiners and haters who are resisting what the community overwhelmingly supports as a technically superior, easier, and designed-for-Linux init system.

akira25012• 13 years ago

It's better than SysV init, but there are a dozen other init's out there, all with different properties. Not everyone cares about "linux on the desktop," and not everyone thinks that freedesktop.org is doing the best job as far as that goes either.

bitwize4• 13 years ago

It's better than SysV init, but there are a dozen other init's out there, all with different properties.

And none of them leverage Linux's features as extensively as systemd. By the Linux init system, I mean the one overwhelmingly supported by most of the Linux community, and the one which is best designed to work with Linux.

Not everyone cares about "linux on the desktop," and not everyone thinks that freedesktop.org is doing the best job as far as that goes either.

Who's talking about desktops? Systemd is not a freedesktop project, and it was designed to make server administration easier by offering much finer grained control and monitoring of system services with a much better interface. Many of its most controversial features -- such as binary log files -- don't make sense except in a server context where the tampering-attestation features of systemd-journald make it a far more secure solution than plain text logs.

You should really read Lennart's essays and blog posts about systemd to get a clearer picture of its tremendous advantages.

Whatever you do, you'd best get used to systemd. It has all but won.

myrandomcomment• 13 years ago

Both systemd and upstart have added a level of complexity I would prefer to avoid. The simplistically of sysvinit is greatly missed.

But then again I am an old fuck so..

bkor9• 13 years ago

The complexity is there, you just don't see it. Systemd handles all types of services. Sysvinit does not. Systemd abstracts a lot, making it easier per service (by putting more in systemd). In sysvinit a lot is copy/pasted across services. IMO making everything more error prone.

mmagin• 13 years ago

What made me hate upstart was that it still is willing to get the default runlevel from /etc/inittab, but it doesn't bother to emit warnings to the user that the rest of /etc/inittab is completely ignored, at least on the version of CentOS I was using. I think it's particularly user-hostile design for any program to accept configuration that does nothing (excepting whatever comment syntax a particular config file uses.)

I would vastly prefer if it either made lots of complaints about the ignored lines in inittab, or even if it it failed hard -- because then I would have to fix the problem immediately.

I have used systemd, but never actually poked around at its configuration (having just run Debian with it as a desktop user), so I can't properly judge it yet.

Spotify position in support of systemd in the default init debate

Related Stories