systemd vs openRC on Gentoo: a completely non-technical user’s perspective

Today has been a boring day. The weather has kept me indoors (not that I’m complaining). With that, I decided to finally scratch my systemd itch: to install it on Gentoo and see, very briefly, what the fuss is all about.

Now, I notice that a lot of people are extremely opinionated about software. Many hate systemd based on the fact that it’s a new init system that breaks away from UNIX tradition, and attacks the problem in a completely new way. Systemd also consolidates a number of ‘needs’ into the one software solution, replacing the infamous ConsoleKit and your system logger with its own home-grown alternatives; just to name two.

A lot of people tend to hate Lennart Poettering, and this hate tends to carry onto his software (or is it the other way around?). People have their reasons, and that’s fine, but I don’t get politically involved. What I really wanted to check out with systemd were its oft-touted ‘aggressive parallelisation capabilities’ which should decrease the boot time significantly. Building on this, systemd — for a couple of years now — has been promoted as the way forward for init systems: fast, modular, and standard.

In the Gentoo world we use OpenRC: a great little gem that uses the traditional sysvinit and extends it with a great numbers of features. I personally really like OpenRC for its simplicity and speed. But is it faster than systemd?

Well, these timings aren’t scientific. But systemd booted my system (after the kernel had finished booting) in about 11 or 12 seconds. With parallel booting enabled, OpenRC did it in 9-10 seconds. Heck, even if they booted my system in the same (or in a comparable) amount of time I would consider that significant. Because after all of the news about systemd being The Next Big Thing, OpenRC has for a long time been able to do a lot of what is important in systemd. It’s roaring fast, it’s easy to configure and it doesn’t suffer from the startlingly common case of ‘feature creep’.

This has changed my perspective on the init system that I use for Gentoo. I don’t care what it is. Both systemd and OpenRC are fast, and I’ll go with whatever the developers think is best in this situation.

Now, to address some potential critics: am I a Poettering basher? I wouldn’t say so. I even use PulseAudio by choice. But for Gentoo, I’m not interested in systemd when we already have something brilliant in its place.

That concludes my completely unscientific, loosely-structured discussion about systemd on Gentoo. Feel free to comment about my poor professionalism below.

25 thoughts on “systemd vs openRC on Gentoo: a completely non-technical user’s perspective

  1. Nice post!! I was thinking about installing Systemd, but… after read it, I am not going to install it. Thanks for share your experience =D
    Saul Hidalgo

  2. OpenRC faster than systemd? That’s interesting. Are you launching any DE or just vt?
    I’ve switched to systemd about 6-8 months ago cuz of the speed. I am auto logging into KDE and my boot time is 9 seconds to restored session with konsole and dolphin (which handles most of my needs). Plasma fires up 3 seconds later and I have fully usable KDE. The fastest I was able to achieve with OpenRC was about 20 seconds.
    Wondering if I should give OpenRC another shot.

    • I wouldn’t be so quick to jump back onto OpenRC if you have found systemd to be much faster. I for one can’t wait until we have better support for systemd on Gentoo, but in my highly unscientific testing of a parallel, arguably optimised OpenRC boot and an unmodified systemd boot, I did find OpenRC to be negligibly faster. I should point out that the system I was using at the time was an old HP 6930p EliteBook laptop with about 1.9GiB of RAM and a Core 2 Duo processor.

      I have no doubts that if I were to have a proper look at systemd and optimise the services it was booting, it would be much faster than OpenRC. But at the same time on my new desktop system OpenRC is only taking about 6 or 7 seconds – parallel – to start up.

      I was booting up to KDE but I ignored the time it took to load KDM; I was only timing until KDM began to show up. So in the end, whichever works better for you is probably the better option. I do, however, think that systemd will be the future of Linux init systems.

      • The thing I don’t like about systemd is the growing number of dependencies. Last night I decided to update my “stage4” (stage3 + systemd + paludis + few other tweaks) and it’s trying to pull in all kinds of new packages, which I am rather not fond of. I’ve also seen a few posts about tweaking the runlevels, which should be another avenue to explore. Just my 2 cents.

  3. The thing I don’t like about systemd is the growing number of dependencies. Last night I decided to update my “stage4” (stage3 + systemd + paludis + few other tweaks) and it’s trying to pull in all kinds of new packages, which I am rather not fond of. I’ve also seen a few posts about tweaking the runlevels, which should be another avenue to explore. Just my 2 cents.

    • That’s a fair enough complaint; you tend to hear frequently that people are concerned or at least frustrated with the continuously growing size and number of dependencies of systemd, but in this case I think we need to consider just one key point: that systemd has evolved from just attacking the problem of the init daemon, and has extended itself in a modular way to also cover the functionality of a ConsoleKit that actually works, a logging daemon to reduce the proliferation of the many logging daemons and many more features that you expect the system to look after.

      As such, I think the growing number of dependencies is to be expected; and while those of us who prescribe to minimalism will approach this with hesitant caution, systemd has shown itself to be particularly stable and good at what it does. It has had the chance to start afresh with what we now know and design a universal system daemon from scratch to address these modern realisations. What I’m trying to say is that I wouldn’t mind if systemd had a lot of dependencies; it covers a lot of functionality, and especially in the case of its ConsoleKit replacement logind, it does it well and it does it properly.

      Finally, systemd is said to be designed with strong modularity and a flexible build system (although I’m not really sure about this from first-hand experience, since I’m only taking the word of Lennart on this). I take comfort in knowing that systemd, handling something as crucial as init and with all of its functionality, is not running the one process; that would be moronic. Rather, systemd seems to just be the umbrella of functionality, and that’s about it.

      Thanks for your comments; you may have just spurred me on to take another look at systemd.:)

  4. Thanks, I totally agree. Openrc is not broken, why fix it? I jsut don’t see any advantages to switching. I also don’t want to learn the controls to a new init system for no reason. I’ll go with whatever the devs decide since they are more wise and powerful than I ofc but I hope that openrc support sticks around for a long while.

    • I agree, it’s a struggle to justify switching your init system to the new-fangled technology when the current technology works pretty well anyway, but it seems that systemd has a very strong architecture; it’s code is stable and thus far quite secure; it’s fast and parallel by default; and uses modern technologies found in recent Linux kernels.

      Granted, OpenRC already does a lot of this without all of the systemd-esque hype. OpenRC can be ridiculously fast, and it’s very, very simple to use and look after in my opinion.

      I’ll see no reason to switch my init system unless the Gentoo devs provide a solid upgrade path, perhaps in similar vein to the Arch Linux devs. And I will really see no point in kicking up a stink; systemd is anything but a bad technology, and if the devs say ‘switch to systemd’, I would trust them. After all, it’s an init system; not a desktop environment or an operating system.

  5. Pingback: Gentoo vs Arch package base

  6. I have been using Arch Linux and systemd for some time, I was planning to move away from Gentoo for good (which I use since 2006 as my main system, and before, FreeBSD since 1995). I am very angry with Gentoo, I know I can’t complain because I didn’t help. But systemd is really scaring me away (and the binary upgrades too, even though at first they seemed a relief).

    systemd really is unbearable, because it is an all-or-nothing. And it really is imposed on us, do you want to run Gnome? I happen to like Gnome 3 a lot, even though it’s a pity they take ideas from OS X, which transform a simple DE into a stupid DE. So, if you want you will soon have too run systemd, such as you have to run udev, udisks, upower, polkit, consolekit, hal before and dbus (I’m surprised one can get away without avahi, which is the only one of these which I like).

    And what is wrong with systemd? Well, the name says it all. It aims to replace all basic system daemons and scripts. We can envision a world with the kernel, the glibc, systemd and applications. This is anti-Linux. Do you want to chose which syslogd you use? Which cron? Etc, etc, etc… Do they say it’s modular? What does that mean, that they have separate source files for each daemon they replace?

    Large programs have lots of bugs. The number of bugs grows a lot faster than linearly with the size of the program. Good engineering practice can help, but… You don’t even see that in these programs. You see overly ambitious design, excessive complexity, requirements invented out of thin air, and you see people making tabula rasa of what others have done before.

    You like pulseaudio? Well, I can’t imagine why it’s standard these days. IMO, it barely works and not very well. I frequently used network setups, with several protocols, pulseaudio always crashed on me, I patiently waited for the bugs to get fixed, maybe no one was using the same features as I was. Jack existed before. Jack worked, didn’t crash, was written with latency concerns, had a large user base among audio professionals, was available to all of us non-professionals. Today it’s difficult to get other programs to work with jack.

    I like avahi, because I understand it, but it really is no more than a draft of an idea. You still need the libmdns-compat which is supposed to be deprecated, nss_mdns, etc, lots of doubtful quality components which show that avahi is not finished. And almost nothing uses it really.

    I know it’s not from the same author, but NetworkManager?! It fills a most needed role, even because distro-specific tools have no GUI integration, and laptop users need that. But it is of the same quality. Overly ambitious goals, they can’t recognize when they have a release (we’re still on 0.9 something), they put in a lot of things which don’t work, the code is a mess (I tried to correct stuff in it), it has no architecture. Something which could be a very simple state machine of state machines… state is actually managed by the instruction pointer, if you don’t believe me, go see it.

    So, while I am angry with Gentoo, because I’m tired of people who are not the developers of one package saying which version is stable and which one is unstable, I’m tired of unmasking packages and tired that gcc 4.8.1 (a compiler!!) is hard masked… I’m not moving away from Gentoo, because I still see more freedom here than elsewhere…

    Now, the pressure is because of the speed of systemd, and I had 5-7 seconds boot times with it (2.5″ HD). OpenRC is right philosophically, I hope it has the speed to resist.

    • Quite frankly, many of your points are non issues to me. Yes, I need to have installed the u* and *kit packages, and it may well be cleaner. But is it ruining my Linux experience? Not the slightest. What would you rather: that they were all bundled into the same program like the u* packages once were, or like systemd is consolidating a lot of functionality within itself?

      With systemd I’m quite sure that you could still use your preferred logger — but I wouldn’t get so fussed about it. Maybe I’m being naïve, but I don’t understand why this is all so heartbreaking and tragic. With regards to modularity, I mean that configuration switches for a lot of the functionality exist. With many points you raised, I feel as if they are again non-issues for the user experience.

      But what you raised about GCC was most puzzling. There is and has almost always been failed building of packages across major versions. The Gentoo bugzilla is filled with GCC porting trackers, past and present. If you would rather unmask the latest and known-not-to-work-with-everything GCC compiler, unmasking it isn’t a labour-intensive process. If you would want to help get GCC 4.8 unmasked in the main tree, the bugzilla has the details.

      If I were remotely as good at development and software design as the folks who do create very good software, I would begin voicing critiques as a way forward and help where I could in the here and now. I do think user feedback is still important for current developers to take notice of, but I don’t see much to complain about right now. If you’ll excuse this bare-bones response (it’s early morning :)) I do appreciate your comment, and I do see similar complaints flying around the linuxsphere. I feel that while I may be less critical of the way Linux systems are, at least there are those around who are nitpicking to hopefully have a cleaner and better system for all. The point, however, is not to just see what is and what ought to be, but rather work from what is towards what ought to be.

      • I also appreciate your motivating arguments for contributing and I agree I sounded a bit tragical. Let me just explain my complaints about gcc and the conservativeness of Gentoo (and most other distros).

        You see, it’s very hard for a programmer to wait for the latest version of his language implementation. gcc 4.8.1, in particular. gcc 4.8.1 is the first compiler to fully implement the new C++’11 language standard, clang is following shortly after. It took from 1994 to 98 for the modern C++ to stabilize. C++98 opened new ways for people to write code and people began to explore. A lot of exploring went on in the boost libraries community and eventually it became clear to all that some new features were needed for the language to be cleaner. This went on during the 2000s, everybody waited for features to be adopted for a future standard, which slowly started to happen. Then finally the comitee approved the new standard, but we’ve been waiting years for those things. But we have to wait two more years for fully compliant implementations. And now I will have to wait two more for the Gentoo maintainers to consider gcc stable, under criteria on which I totally disagree.

        gcc has one of the most specialized and professional teams you can find anywhere. That is very tested and peer-reviewed code. Then come the distro maintainers are declare what the gcc considers a “release”, a stable release, and declare it unstable, because they tried to rebuild every application they know and some application failed to compile. Typically, they do this regardless of whether the error is in gcc or in the application. The same thing happened with boost. In Gentoo, the only unmasked version of boost was 1.35 for a very long time. boost also has a very specialized community. There are huge test suits that verify that old funcionality still works in new releases. All libraries are extensively peer-reviewed too. Not so many Linux desktop applications use boost, most Gnome stuff is C, or old-style C++, not modern C++. However, they really did that because some application which name I don’t even remember, something really obscure and with a limited user base, failed to compile with the other version.

        And that is the problem with distros. Most of their testing was basically compiling stuff. Because they are compiling stuff written x years ago, they find the x years ago compiler more stable, even if it’s not the compiler.

        And that’s what makes a programmer’s life difficult. And programmers are disconsidered as users. There were probably more C++ programmers using boost and Gentoo than users of the application that failed to compile and led to that long stagnation of boost in the ports tree, still it was boost which was deemed unstable by the Gentoo maintainers. As to contributing, mind you in what regards boost, I did what I could and suggested corrections for the ebuild regarding debug libraries, but the repository isn’t public, no one in the Gentoo C++ group took care of it, probably no one understood enough the subject to understand the problem. A few years latter, recently, they closed the bug I opened with a non-solution.

        People should listen to those who have authority, who know their subject really well, and in the case of gcc that is the gcc team, and all of us outside know very little. gcc is easy to compile. It compiles itself, so it should work pretty much anywhere and it has little dependencies. It is stongly connected to glibc, but they test the integration themselves (both teams).

        I switched from FreeBSD to Gentoo because I started using laptops more often and Linux always supports the latest hardware first, as many manufacturers contribute the drivers themselves (Intel, particularly, very quickly). But Gentoo is becoming more and more incompatible with software development. You don’t see that on FreeBSD and don’t you think that because of being more bleeding-edge it fails more often as a desktop environment, it doesn’t. So, what value is the paternalism of distro maintainers?

        Programmers need the latest version of their language tools and libraries because it helps them more and because they need to write according to the latest standards, so that their code doesn’t become stale so fast.

        Sorry, for the testament, but I think I’ve explained myself better. I also misread the title of your article (I read technical). I found your article trying to search for info on whether Gentoo was going to adopt systemd.

      • Thanks for taking the time to reply — and I think you’re right about distro maintainers sometimes being too paternalistic. The whole GCC argument rings true with me when it took Gentoo a very long time to stabilise GCC 4.6. It is absolutely frustrating to have to settle for second best because someone else decides that the package isn’t stable enough. But on the other hand, a working GCC is vital for a working Gentoo; perhaps they’d rather be more careful than risky.

        For me this policy has only pushed me to running 100% on the unstable branch on which I have never had a problem (if anything, problems so trivial that I cannot even remember them). The whole idea of having a distro built from the ground up only to end up having packages that are functionally stable but not marked as such, because of the maintainers and the stabilisation policy, is hard to swallow. There will be, however, those who prefer to trust in others, thus the stable branch — I imagine — is quite useful to a number of people.

        I digress, the whole development tools issue and old packages was what pushed me to Arch, but I ended up being back on Gentoo within the month. Thankfully I haven’t yet needed C++11 support outside of toying around, but this would be completely unacceptable for those who do. It would only reinforce the ‘Gentoo is a hobbyist distro’ comments.

      • Basically, they should consider the relevance of the package which does not build because of the new compiler or library versus the relevance of the compiler or library itself and also consider which is wrong, the compiler or library, or the application which became broken. And they don’t do that. They decide that if a build breaks with a new compiler that it is a compiler bug.

  7. Hello togehther,
    I have tested systemd for 3 days on my gentoo, too. The switching process (set USE=systemd), the kernel-preparation and the installation of systemd, and, uninstallation of “udev” were going without any problems. The system – Yes, I thought, I bought a new processor, even though, I run one of the fastest processors: I7 Extreme Edition… – From ready-booted kernel, there were 4 seconds(!!!) To the command-prompt. This is – amazing!!! A JUMP!
    This time, with OpenRC-Using – 10-12sec.
    But further: (You mean rightly… lets see the “constraints”…
    Network-connection, kdm, Systemlogger (syslog-ng) apache2 (local installation) and mysql didnt work.
    Therefore my network is static, I could’t do the way by “systemctl enable/start $…” I had to learn how these scripts (I remember: if Install using openrc, automatically a init.d/$script is installed!) are created.
    I could get to work: network.service with static-ip-address. But every reboot, had to reactive it, although it was “systemctl enabled”!!)
    KDE worked finde after I “systemctl enable kdm.service” and the same for acpi.service. (fglrx)
    Apache worked fine, but MySQL… I probed, expertised a plenty of configuration-files, that I found for gentoo in the internet, probed those for arch, tuned they for gentoo (the paths primarily meant).
    MySQL didn’t run (in more cases, he started, stopped, gone in fail-state, stopped, started, stopped, started) – I asked in forums, I got the impression, that NOONE WANTED to help!
    But, without MySQL continued the tests.
    But for MySQL could get to work even syslog-ng and other related services… But… I was wondering… Have the services enabled… surprisedly… the boot process from up from the finished kernel booting, wasn´t “so so amazing faster” anymore… Not faster than OpenRC😉

    I returned to OpenRC yesterday!!! And I will stay!!! Systemd is an “unix-principe”-UNLIKE thing: ALLiNOne/interfering/complicate (WHY doo all in one but not omplete a set with init.scripts??!! From where should users know, how to script these!!! – should the become programmers???!!!)
    NO! systemd may take place in a commercial system like Windows. Where system-processes aren’t shown and all is made by one firm, or commanded by. Such ideas like systemd, I think, is the DEAD for a community like Linux is! Like Canonical by Ubuntu: Shuttleworth issues, and “community” follows…
    Sorry, but this is my belief.
    As the author of this blog already said: Feel free to comment my unprofessional knowledge…

  8. I wonder if people criticising systemd actually read anything what Pottering said.
    You claim, that systemd is complex software – it really is. But it replaces even more complex and even more broken “softwares”. It makes them fast, managable, efficient. init is responsible for starting daemons. To start some daemons, hardware detection is required – so its no question why systemd needs to absorb udev. Whats the point to keep it seperate, if it will be operated by scripts in a much less efficient way and have larger size anyway? Starting daemons is bound to login – ConsoleKit is essentially broken, allowing ways to exploitation that are unfixable, unless the init system is aware of the whole. Due to it becoming much more than “init”, its named “systemd”. Easy analogy here – its started with head optimisation and landed as “human”. But some have still illusion that “head”, “arms”, “brain”, “spine”, “legs” glued by scripts make the organism alive. Reanimated – maybe, but not alive. Its just a list of organs, each of them trying their best, where they should instead try to “live best together”. Together. Thats the goal of systemd, and its accomplished very well. How MacOSX solved the same goal by the way?..

    There is another example, why Unix way, taken to extreme, produces more problems than solutions. If the system is composited of many small programms, each of which tries to accomplish its target in best way instead of trying to coexist together in a best way – and only then do its job, then when each of the parts gets updated (and they do, a lot), system gets periodically broken. In fact, classic UNIX is so broken, there is hard to find optimal version that has most of the support and is mostly unbroken. With system, which ecosystem tries to co-exist as one under higher priority than doing the job best in individual boxes, there is no such problem – it simply works!

    Some say “better” is enemy of “good”, so I personally uphold Pottering decisions to be quite visionary and correct. But, supporters of half-broken “good” will always hate it. Thats normal state of things. Let the time point out the winner.

    • I have been using systemd for the last couple of months, due to lack of options.

      I think you’re totally right in saying that systemd replaces even more broken softwares — though not complex, simplistic ones, really. I don’t know why people call Poettering visionary. The need for a unified approach to a lot of things, console, resource management, power, etc, has been quite obvious.

      It is easy for systemd to do a lot of things better than the tools it replaces, they were really bad and arcane for PCs and laptops. But I don’t know why it would bundle a lot of unrelated stuff about system configuration and, unfortunately, it’s not a lot better either.

      What it allows in terms of console configuration is still a bit behind what you could do with OpenRC or any other distro’s rc. Network configuration too, if you don’t use NetworkManager. Power management, which is one of the things I find quite ridiculous that there isn’t a unified approach, is totally inexistent on systemd. The services/targets/etc are a bit complex, maybe it’s fine, I still don’t see it in its entirety.
      It absorbed udev, but udev isn’t that good either, it is limited, permits very little, and systemd doesn’t improve it.

      What is so much compiled code good for, then?

      It is _slightly_ faster than OpenRC with parallel boot on my system. To the console, that is. It says on my system (I use many partitions) 3.4s kernel + 15.2s userspace. With OpenRC I would get on that order of time…
      However, gdm-3.8, which can only work with systemd, is a _lot slower_ than gdm-3.6 and OpenRC. So, all in all, on my system, I have to wait some 20 seconds more than I had with OpenRC.

      I had to rewrite all my power management scripts and hook them to udev rules and systemd sleep target.

      Because it is unified, systemd’s view about what is a system and how it should be configured is a lot more limited than OpenRC’s. Is it suitable for a PC? yes. For a laptop? not quite due to lack of power management (the entire concept is missing). For servers? well, what kind?

      So, what did I gain? Nothing, most stuff is still behind OpenRC.
      Why did I change? Well, because I had to. It still was less work than trying to maintain an old installation of gnome-3.6 on gentoo.

      Why would gnome-3.8 depend on it?

      Nothing improved. It is only features that were removed. Before, I was able to not suspend my laptop on lid closed on the console, and suspend it on gnome, a configuration which I liked. Now it is impossible. Moreover, if I want to change the behaviour, I can no longer use gnome-tweak-tool. Have to change a systemd config file and make it re-read it.

      Contradicting what I say before, one thing I like is journald: because the log may be volatile (not stored on disk), it’s perfect for laptops while on battery.

      I am happy that systemd is a lot more reliable than pulseaudio, which keeps crashing. One of the things I was afraid about systemd was the track record of its author.

      So, what do you find so visionary about Poettering?

      • One thing beforehand, PulseAudio never crashed for me. I suggest you fire a bug if it does for you, for that sounds like a broken sound driver. A lot of people complained when Pulse came out and what it tried to achieve was essentially – uniting all that was inbefore and doing it right. To accomplish this, it has to drop a lot of plugins. For Alsa, for sdl, for openal, for esd, for timidity/allegro, for wine, for phonon, … and so on. And people were complaining about Linux audio before, Pulse came and did it better than OSS. Due to being quite ambitious ofc it had bugs and due to legacy support ofc a lot of configuration files must be updated. And then Ubuntu just took still unstable Pulse – and misconfiguring it. People complained again, but hardly anyone what was the source of all these problems. Solving problems does introduce some pain and more so if lead distro does everything wrong. But in the end, it worked out. For me, Pulse misbehaved only once – when playing h264 in HD on P4, it took just a bit of too much CPU bandwith and I had to reconfigure its sampler to lower quality. But thats it. Not claiming Pulse was bug-free, its still misconfigured in Wine, thanks to Wine devs ignorance.

        Why does Gnome-3.8 depends on systemd. The answer is quite easy, its same as why it depends on Pulse… Ability to log-in/out, manage power, start daemons. Before Systemd, Gnome was dependent on a variety of stuff to acomplish that. Now, systemd replaced that stuff and took place as a dependency. There are a lot of people that resist systemd, just for the sake of resisting. Oh well, its opensource anyway.😉
        Gnome-tweak-tool happens to be in a dire need of patching, btw.

        Also, what I love about Pulse, NetworkManager and systemd, is that one can configure anything easily, without scripting or hacking in. That is also possible, but its done in a sane easy to use, way. I hardly imagine everyone writing own power management scripts, binding networking. In times of Knoppix first releases, maybe, but today it looks like a waste of time. I find it much more convinient to browser mentioned software source and patch it to personal needs than to require everyone to take the hard way. That doesn’t make one look as professional, it makes his system of choice look like hard burden to maintain. I am for mouseclicks and applications writing text configs, that for explicit editing of text configs and shell spaghetti, but you personal milage may wary.

        Whats the problem with Poettering’s track record? I don’t think he murdered any wives, so..(excuse me some sarcasm).

      • Oh, you sound really partial to me! I don’t want to carry a discussion endlessly, but I think it wouldn’t be fair to go without saying what kind of crashes I have with pulseaudio.

        One of the things I like about these audio servers is the ability to play audio on the network. It’s really useful: you have one stereo in the house and you stream audio to it while sitting on the couch with your laptop. Over the years, I’ve had all sorts of setup, all sorts of server connected to a stereo, and pulseaudio has been consistently unreliable over the years, the least problem being hicks. More recently, I got an Airport Express router, which also has this capability avoiding having a heavier server on. A few years ago, one version of pulseaudio worked fine with it, over time it stopped working (it crashes client programs, which have no responsibility as they should be oblivious to the network setup). I have mostly waited, this is not something related to my hardware, audio drivers, so it must affect a lot of people. Now, it hasn’t been working for quite a few years already, and I really no longer expect it to. I think it’s pointless to file a bug, I don’t think anyone’s really working on pulseaudio. I think they just consider it a finished work.

        The problem which esd solved was mostly having more than one program playing sound back then. When they replaced it with pulseaudio, they certainly chose a much more powerful program. Still, there were alternatives. There was jack, which also aimed at low latency requirements for professional audio (realtime use), apart from fulfilling all other requirements, including network audio and immediate availability of mixers, equalizers, etc. Of couse, if windows and mac osx didn’t fulfill those needs, why would they choose a professional alternative for the linux desktop? That’s another example of how limiting it is when people imitate.

        Also, to be fair, the problems I described with NetworkManager were mostly related to dual stack configuration. And here I really tried to debug, and followed the code while seeing the log, so I really think that’s not how a state machine should be coded, by encoding the state transitions as control flow in a program. That is extremely hard to maintain, hard to read, and really I see nothing good about that choice. It has been better for me latelly, but for a long time, each time a release came out I had to try it and choose if I would mask it.

        Just to contradict you, one thing I like about systemd is that it can only be configured though scripts and text files:-). I can easily put these under version control, which would not be useful if they were binary. Also, with NetworkManager sometimes the configuration files change just to change a timestamp, which not only sounds stupid but makes version control difficult.

        Again, gnome depending on systemd, to start daemons? Manage power when there isn’t any power management? All it does with systemd is sending the command to suspend, etc! Look, pragmatically, gnome-3.8 with systemd, at least on Gentoo, is still doing a lot less than gnome-3.6 without it — at least with pm-utils, even unconfigured, there was minimal power management.

        I’m honestly trying to live with systemd. I appreciate some improvements, I agree that the problems they’re addressing are relevant for modern desktops. But it is a retrocess with regard to OpenRC in many respects. And it’s a lot more complex, some of the optimizations they do to the boot process, such as reading files ahead… are sophisticated but sound too complex, too early. We will see how maintainable systemd is in the long run.

        About it being open-source: of course I would prefer seeing a new generation of OpenRC. But who has time to do it? And scripts are not necessarily slower than C programs, not on the type of programs you find at boot, I/O intensive and system-call intensive. Scripts have very few bytes. The C equivalent of some scripts is a much longer and much more complex program. Shell script is a very expressive dynamic language which allows to write complex things in very few lines. The overhead of the interpreter may be compensated by the small size of the scripts, if you can speak of the overhead of the interpreter for boot scripts.

  9. My complaint with systemd is the byzantine syntax of systemctl. Gone are the days when you just do a simple “system nfsd start” or “chkconfig nfsd off”. On my Fedora box systemctl -h displays 120 lines of options(!) Worse, IMHO, than the Solaris svcadm syntax.

    • Again, this is an old and completely unscientific comparison. Systemd was barely configured correctly.

      I now have lightning fast bootups on systemd.

Have your Say

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s