If Debian manages to actually use systemd by default, that may have interesting implications for Ubuntu which I think is the only major distro using upstart. All depends on how deeply would systemd be integrated of course, since Ubuntu already rewrites most of the system startup scripts for use with upstart anyway. I'd like to see some comment from Canonical people about how that would affect them.
The anxious parties are mostly the BSDs and maybe Ubuntu.
Other using systemd is not a problem for anybody. The problems start once the higher-level stuff (X.org,Wayland,Gnome,KDE,gdm,etc) requires systemd. The question is whether the anxious parties have enough devpower to maintain portability layers and especially the BSDs may not.
However, by Adams Law of Slow-Moving Disasters [0] these problems will be resolved in time.
One of my concerns with systemd is that kernel interfaces for input and display devices will begin to assume its presence, negatively affecting my ability to use /dev/input/event* or /dev/fb* in embedded systems.
That's the way Mac OS X is written. They certainly haven't bundled the entire universe into a single master "system daemon" project.
A few, off the top of my head:
configd: A configuration store that handles storing (and monitoring changes to) configuration. It supports arbitrary plugins, such that other dependent systems can inject their own implementation code if necessary. It depends on kernel notification APIs and network notification APIs that are implemented at a different level.
launchd: Starting/stopping/restarting services, on-demand and on a schedule, per-user and system-wide.
diskarbitrationd: Handles mounting/unmounting of file systems, and notifies clients of changes to mounted file systems.
opendirectoryd: Handles namespacing of local and remote user/data directories. This includes LDAP, local user accounts, etc.
mDNSResponder: Used to be just the mdns daemon, now handles all name resolution and local caching.
All of these things have been iterated on independently over time, are loosely coupled with each other, and do not create tight bindings between Mac OS X and open source software, nor do they require huge non-portable changes to open-source software.
The precursor to opendirectoryd was netinfo, which also used to handle name resolution and caching. Later releases of Mac OS X moved name resolution into directory services, and then eventually into mDNSResponder. launchd replaced system starter (similar to initd/rc), cron, and a number of other services, but maintained 'perfect' backwards compatibility with the standard configuration file formats (eg, crontab(5)).
These are just a few of the (independently maintained, internally) projects/daemons that Mac OS X layers together to produce the desktop. You don't need a huge monolthic project to tackle all these problem domains, as evidenced by the fact that Mac OS X works.
You also benefit from laying these projects cleanly, as it allows them to tackle what they're good at, provide a stable interface, or even be swapped out entirely later.
> Actually, launchd replaces init, inetd, crond, atd, and watchdogd.
That's not a "system daemon". Let's break it down:
- init: start/stop services
- inet: start/stop services
- cron: start jobs on a schedule
- atd: start jobs on a schedule
- watchdogd: restart services
Notice the commonality? launchd launches services, possibly on a schedule.
> I mean where do you think systemd got the idea from? :)
systemd is monolithic and system-invasive in ways that launchd never could be, or that anyone wants it to be. Just take a look at the systemd feature list[1]: Quota handling, swap handling, encrypted disk handling, kernel module loading, graphical UI, syslog replacement, console/keyboard configuration, X11 integration, fsck handling, serial console handling, and more!
Systemd is a crazy kitchen sink of a project. It's no wonder that it's non-portable, and I can't imagine trying to evolve the components of a system that came to rely on it. The minute you want to change how an OS subsystem works (eg, such as the automounter), you'll have to dig into the non-portable/non-abstracted systemd code.
Notice the commonality? launchd launches services, possibly on a schedule.
And so does systemd. The other stuff is handled by separate daemons that are part of the overall systemd project. See? Separate processes! That means it's not tightly coupled at all!
Personally, I feel that systemd is a shitfest -- so bad I switched back to slackware from Arch, being more than willing to sacrifice bleeding-edge distro releases and dependency management just to avoid it -- and that the unix way is how things should be developed. It's been a while since I've really been on top of Mac OS X internals, but if what you say is true they're doing a much better job of remaining modular and loosely coupled than Lennart has been.
But the CADT hivemind has declared the traditional Unix model obsolete. They tend to do a lot of throwing out babies with the bathwater, then rationalize it by saying obviously they were children no one wanted, and aren't we overpopulated enough as it is. I don't think Lennart is particularly innovative in this regard; he learned the game from the GNOME team. When the rationale for your black hole in my /usr/lib is called "Let's Make Unix Not Suck", you know you're a special breed of arrogant.
systemd can boot quite a bit faster than just 5 seconds. In any case, do you have any specific complaints? Your post is pretty long but lacks specifics.
Beyond that, the fact that the basic fundamental underpinnings of a Linux system are large monsters that try to do everything, and depend on dbus and libthis and libthat, is deeply offensive. So is the fact that despite there being many daemons in "systemd", they all depend on each other so that to get the benefits of one you have to take them all. It's the GNOME style of programming. I've hated GNOME since 1999 when it first came out, but I didn't worry too much about it since I never used it. But if this crap becomes the norm at a basic system level, it obviates the reason I got into Linux in the first place: to have a clean and useful Unix system that does the minimum it needs to do and otherwise stays the hell out of my way.
> systemd can boot quite a bit faster than just 5 seconds.
So can other operating systems, no monolithic kitchen sink of systemd required [1].
[1] I realize that having 69 totally interdependent and non-portable daemons is considered "non-monolithic" in systemd-land, but I live in the real universe.
Other init systems are just as bad. It is not like the scripts and executables used in sysvinit or upstart are any more portable than the systemd executables (which are not daemons). They are usually less portable since many of them are distro specific.
If anything you should call systemd out for inventing another standard to solve the problem of there being too many standards.
Because, as the parent said, as higher level projects, starts requiring systemd, the BSDs will either have to port over systemd and replace their init system, or keep around patches to go around systemd requirments for every application that needs it. Neither is desirable and would take non-trivial effort.
Because (as qznc stated) they are worried that various applications will start to rely on systemd features so that BSD either will have to maintain a compatibility layer or be stuck with old software.
footnote: because the maintainer (Lennart Poettering) is religiously anti-portability.
This is a shame, because it makes for brittle software, even when targeting the same platform where APIs do shift and improve over time.
To quote:
> In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!
I find this to be extremely cringe-worthy; I can only hope that a Linux monoculture isn't the future of open source development.
I hate with a passion having to work on just about any platform besides Debian/Linux. Call it what you will, I'm just very comfortable and satisfied with how Debian/Linux works. That being said, to be anti-portability is just plain unprofessional. Just having a second non-gcc compiler to test against for, say C++, is a blessing in that it's bound to make you rethink how you code and to catch problems well before they happen. The more platforms you can test against, the better your code will be. And much as I love Linux, I would hate to see it stagnate and become the only OSS option. I think Poettering has had an attitude problem for quite some time, and unfortunately he doesn't seem to be getting any better.
Do you really think BSD would replace their init system with something not BSD licensed? Seems like a pointless exercise to slow down progress just for theoretical usecase.
Which is part of my point; although BSD is not my personal license of choice, I really think it would be a bad idea to have Linux distros (or apps higher in the stack) be incompatible with the BSDs, eg by requiring something Linux specific (eg, systemd). I'm not a big fan of systemd; I really think is too wide in scope, and making the logs binary doesn't make sense to me. It might be more acceptable to me if they dual licensed it (GPLv3 and BSD) so that it could be ported to and used in the BSDs (among other systems); that would also give the bonus of improving the code (which making it portable almost always does). Alas, none of these concerns are likely to be addressed satisfactorily.
PS - So-called "theoretical" use cases have probably been the number one source of bugs (especially security holes) in the history of software. "Oh, don't worry about checking array bounds, nobody would be stupid enough to write too much data!"
The choice between 'portability' and 'ifdefs' is a false dichotomy. There are far cleaner ways to achieve portability, and ifdefs are almost always a sign of 'doing it wrong'.
See, for example, Kernighan and Pike talking about portability in The Practice of Programming.
Code coverage tools are available. Porting software to other platforms is just one crude, but very effective way of testing different code paths, some you can't even see (unless you are in the habit of stopping at each compile stage and checking things such as the compiler's assembler output . . . ).
> The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.
False dichotomy; simply don't make abundant use of #ifdefs.
Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary.
The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
> Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths.
No. A proper approach to abstraction:
- Reduces complexity by reducing interdependency between subsystems.
- Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing.
- Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on.
> Might be fine for a lot of projects, but this is just something to boot up your system.
Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable).
Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
Even if systemd becomes default in Debian, probably there'll be ways to replace it with other system/service manager because of the Hurd and kFreeBSD ports. In Google Summer of Code 2013 there's even porting OpenRC to Debian: http://wiki.debian.org/SummerOfCode2013/StudentApplications/... .
Canonical will learn that soon enough anyways, with everything surrounding Mir. And I'm glad. Their current way of doing things reminds me a lot of how GitHub works with open source, with the major difference that where GitHub builds completely new systems when they're needed/the alternatives aren't up to par, Canonical builds them all over the place, when many times it would be better if they contributed to the existing projects (Wayland, systemd) and expect the same community support that GitHub gets surrounding their open source code (Resque, Chronic, Jekyll, etc).
It's kind of disheartening that Canonical keeps trying to "disrupt" existing open source projects by muscling their way behind their own projects, developed in secret, with little to no community input. /rant
This is a common complaint about Canonical. But your post is misleading at best.
upstart forged a new path at a time when systemd didn't exist. Ubuntu pioneered it in order to solve a specific problem for which no other solution existed at the time (desktop boot speed).
You can complain that Ubuntu has not switched to systemd if you wish, but it is systemd that went down its own path, dragging other upstream projects with it (eg. udev).
Red Hat switched to upstart initially, and has now decided to drop it in favour of a new project (systemd).
Lennart works almost alone, his "open intentions" are to explicitly not support the wider open source community (like non-Linux kernels and non-GNOME desktops), and he "contributes" to virtually nothing but his own inventions of questionable technical merit.
I don't see anything wrong with a single developer concentrating on a few projects? How many developers do you know that make significant contributions to many different projects?!
Do you have a source for you claim that lennarts explicitely not supports non-Gnome? I think it is pretty clear that he doesn't support non-Linux, but why is that wrong?
On the other hand: What i don't like about Canonical is their latest move to first pretend to support Wayland and then mysteriously presenting Mir all the while spreading bullshit about how Wayland is not good enough.
> I don't see anything wrong with a single developer concentrating on a few projects?
Neither would I, if they were projects worth concentrating on or of any meaningful long-term value to the community.
> I think it is pretty clear that he doesn't support non-Linux, but why is that wrong?
systemd invites/demands dependencies on its own, unique interfaces that do not and will not exist outside Linux. This retards progress of other projects in supporting non-Linux systems.
> What i don't like about Canonical is their latest move to first pretend to support Wayland and then mysteriously presenting Mir all the while spreading bullshit about how Wayland is not good enough.
Red Hat began to support Upstart before switching to their in-house systemd and spreading bullshit about how Upstart is not good enough.
Why is it OK when Red Hat tries to come up with new things but not Canonical? Do you work for one of these companies?
> Looking into the git contributions he is not even the one who contributed most!
No, not working for any of them. See my comment that it's still incorrect saying Lennart does all the work.
You can easily check the git yourself, go ahead.
Even taking out udev shows Kay Sievers contributing nearly as much as Lennart. It also shows many other people contributing. That there is a main developer that does a lot of work is not something negative about a project, isn't it?!
> their latest move to first pretend to support Wayland
In November 2010 [1].
> and then mysteriously presenting Mir
In March 2013 [2].
Technologies change. The best path to follow can change. Switching paths over two years is surely acceptable and reasonable for any company. Claiming that Canonical "pretended" is false and misleading - or do you have any evidence of this?
> Looking into the git contributions he is not even the one who contributed most!
Others have already rebutted this: udev accounts for most other contributors, leaving Lennart for the vast majority of systemd.
Do you have anything to say that isn't deliberately misleading?
Development of Mir started 9 months earlier. So they basically lied into the face of the whole Free Software community and the Wayland developers who counted on their support by not communicating their change of heart.
Explicitly not support other desktops? That's wrong, systemd is supported by various desktops. In any case systemd is different level, a desktop should add support, not the other way around. Obviously best if a systemd developer helps out with that effort in a desktop, but suggesting systemd project needs to have knowledge/support for desktops is crazy. It doesn't support GNOME, GNOME has support for systemd!
Various desktops were forced to adapt to systemd's insanities. This is different from systemd attempting to be a good citizen and support existing mechanisms.
Just because I pointed out flaws in your arguments doesn't make it ok to respond like this. Please refute what I said based on clear references and without name calling such as "insanities".
E.g. you said: "forced": prove it. Also, you didn't back up your previous claims, just made different claims.
Thank you, I've read Lennart's shameless lies on this and many other matters. The truth in this particular case was revealed by Steve Langasek in the recent debian-devel thread[1]. Almost 80% of the systemd code is by Lennart.
Nope, that is changing the wording to suit yourself. He started the project and is able to work full time on this.
A Mageia packager contributed some very good patches towards systemd. He's not in the email on debian-devel, while he monitors systemd , works with Lennart and others, etc.
Our Mageia packager is not included. One of the patches he wrote: During the development of the journal he fixed a really important journal memory bug. Took a lot of effort to figure out, etc.
But the arbitrary '100 patches' is introduced. Seems rebuttal is pretty biased.
PS: Upstart has had 17 contributors. Systemd has 15 people with commit access. Systemd seems way more viable.
That's just not true, you are talking bullshit here.
You can look into the git repository yourself and see who contributed most lines. And it was Kay Sievers, not even Lennart Poettering.
edit: @nknight followup:
Did you even look into git for yourself?
Even with excluding udev the top contributors are:
613 Fabiano Fidêncio
812 Lukas Nykryn
929 Auke Kok
1138 Simon McVittie
1149 Marc-Antoine Perennou
2125 Dan Horák
2215 Thomas Bächler
3619 Harald Hoyer
7924 Michael Biebl
18850 Zbigniew Jędrzejewski-Szmek
30226 Tomasz Torcz
168803 Kay Sievers
170196 Lennart Poettering
Kay Sievers wrote udev, which Lennart swallowed into systemd and proceeded to make unusable outside his own pet configurations. Exclude the pre-existing udev, which was and should have remained a separate project, and it's all Lennart.
It feels like you are implying Kay didn't work with Lennart. it's simply not true. The systemd mailling list was created in May 2010 and Kay was already registered and posting there. Check the archives. They were working on systemd from the start in a RedHat-Suse joint effort.
Also udev merge into systemd would have not happened without Kay's consent.
And I don't understand why people get downvoted just beacuse they correct you.
I did not downvote, but my guess is because you obviously did not read the email linked to which showed the numbers with udev excluded.
udev and systemd are two separate projects who happen to live in the same repository (nothing wrong with that!) so you have to remember to exclude udev when looking at contributors for systemd.
I did read it. What does it tells you ? Well that Lennart did the commit of the first original. Has it occurred to you that they could have work together on the design ? That Kay might have reviewed/coded all or part of the prototype ?
The git can not show that. And unless Kay himself state the contrary we will not know. Lennart says Kay was associated to the project from the start. If it were not true, wouldn't have Kay said something by now ?
I don't always agree with directions Lennart goes, or on the methods. But that does not justify ferocious ad hominem attacks I've read.
I do not support the idea that Pottering wrote it without consulting people, but what is certain is that he wrote almost all of the code himself and since your comment talked about looking in git I assumed you were talking about code authorship.
Actually it's Redhat that went their own lonely path after trying out upstart and switching away, if I remember correctly. (RHEL 6 had it, to be precise)
However, it's not a lonely path in this case, because they chose to govern it in a contributor-friendly manner: no contributor license agreements, commit privileges for non-RH developers (non-RH developers are the majority), cross-distribution collaboration, FOSDEM presence etc. In short: They managed to build a healthy community around the project.
