7 ms·
What “technical” concerns do I have with systemd?
- illumen 12y agosystemd should really include pulseaudio, and nginx. Oh, it already has a httpd in there.
- rossj 12y agoAnd it's own database which is mentioned in http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69...
- metafex 12y agoAnd it supports QR-codes for kernel panics!
- angersock 12y agooh ffs
- justizin 12y agoQR codes for kernel panics is actually brilliant, because it encodes the data which would otherwise just be serialized to screen in a manner that makes it portable.
- MertsA 12y agoThat actually might be nice but don't get your hopes up, systemd isn't actually part of the linux kernel as some conspiracy nuts would have you believe. The systemd project can't possibly just add random stuff to kernel panics, all of that code is in the kernel, not userspace. I think a little while ago there actually was some work done on making kernel panics display a QR code but I doubt it'll ever be merged in if it's even done.
- justizin 12y agoI think you're right, but if that's so, then apparently all of the features the OP claims to be bloat in systemd are questionably in systemd at all, and the entire discussion is moot.
- rasz_pl 12y agoIm pretty sure Poettering is working hard on Kinect integration as we speak.
- chronid 12y agoYou forget its own reimplementation of dhcpcd, IIRC.
- Someone1234 12y agoMaybe they should add a kernel, then it would be the "systemd OS with Linux compatibility."
- gyre007 12y agoI'm glad people still remember Pulse Audio :-) What a piece of.......software ?
- stefantalpalaru 12y agoI managed to avoid it completely on Gentoo until recently when skype decided that the only way to deal with sound on Linux is through PulseAudio. I like to think that a knowledgeable neckbeard suggested PortAudio and the info got mangled in transit :-)
- antientropic 12y agoYou are referring to systemd-journal-gatewayd, which has a dependency on libmicrohttpd, a 93 KB web server. You don't have to run it - it's an optional unit, that even when enabled is activated on demand. You don't even need to build it, since it can be disabled with a configure flag. If systemd-journal-gatewayd were a separate package, nobody would complain about it. So why is it such a big deal that it comes included in the systemd source tree?
- deleted 12y ago[deleted]
- RadioactiveMan 12y agoAs a user of linux on the desktop, I've never felt a moment of concern over the fact that it takes longer to boot than did Windows. I'm not sure who is panicked by this and I'm distressed that we would solve all of our problems with init by embracing systemd. If Gnome requires systemd, lets drop Gnome.
- hyperpape 12y agoAs a user of computers, I have never once felt that boot time was adequate for any device I have owned.
- pessimizer 12y agoAs another user of computers, it's pouring if I have to boot up more than one or two groups of things a week. If it ever takes more than 3 minutes, there's something wrong with the hardware.
- colanderman 12y agoYou must be young. Back in the good ol' days computers booted instantly. Apple ][, Commodore 64, I'm looking at you.
- hyperpape 12y agoMy first computer was a Mac Plus, so it appears I just narrowly missed the good ole days.
- knd775 12y agoMy rMBP is the first device that I have used yet that I feel boots quickly enough. I mean, it's a few seconds. And that's on top of the fact that I rarely actually turn it off. SSDs are really necessary to have tolerable boot times.
- nine_k 12y agoI wonder why booting a computer may be a concern for a desktop user at all. With hibernation being polished enough (on Linux and elsewhere), one mostly puts a computer to sleep, then continues exactly where left. Boot times may be important for cloud instances, though; the faster you can spawn more nodes to accommodate a load spike, the better. But cloud instances are usually pretty stripped-down, and often get spawned form pre-configured images where much of the discoverable stuff is hardcoded.
- pestaa 12y agoIntegration comes with a huge price. I'm a beginner sysadmin, and therefore not really knowledgeable about the recent changes in Linux -- however I've seen FreeBSD in production(ish), and it was indeed a more pleasent experience. Paths, configuration, the package system, the documentation (!) all felt nicer.
- metafex 12y agoIf you find FreeBSD docs nice, check out the OpenBSD manpages. For me they set the bar for nice documentation.
- drdaeman 12y agoI believe it's more about tight vs loose coupling, not integration. The contrast is, systemd's parts are relatively tightly coupled together (in a way one can't easily pull, say, journald and use it autonomously, with other init), while, traditional init systems are bunch of loosely coupled mostly autonomous modules that happen to reliably work together thanks to standards' glue (so, they're integrated as well). I could be wrong on this, though. Just my thoughts.
- keithpeter 12y agoI suspect the 'standards glue' is an important aspect of all this. With loosely coupled modules and standardised glue you can update components separately on different time scales and be reasonably confident that they will still integrate with other components. Tighter coupling with rapid integration in functions and therefore changes in glue makes it harder to work piecemeal. Distributions have very different time lines. Pity the packager stuck trying to back port patches to an earlier version of the system when the upstream project(s) is(are) pushing out security updates based on the current versions and their current glue/api. Of course it will work and work well. Redhat are betting their major product on this set of modules. The problem will be the load on other projects working around this.
- copper_rose 12y agoHe's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: "I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."
- the_mitsuhiko 12y ago> He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: [Citation needed] From where I stand, systemd is what I always wanted on a server.
- e7620 12y agoWhat feature of systemd did you always wanted on a server?
- zarvox 12y agoI'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart. For me, it's a combination of things: 1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph. 2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job! 3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks. 4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them. 5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status. It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
- IshKebab 12y agoSo... none? Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing. Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
- RadioactiveMan 12y agoWhat do you find to be painful in using linux on a desktop without systemd?
- teacup50 12y agoNetwork configuration. You don't need systemd to solve that, though!
- DLister 12y agoIt pretty painless in my experience but i guess your millage may very on that.
- vezzy-fnord 12y agoHow does systemd help with this? The networkd component is still underdeveloped and unfinished, and meant for container setups, primarily.
- MertsA 12y agonetworkd is still under development but if you're running a version of systemd that has it, it's already very nice so long as you don't need wifi. Right now I'd recommend it over NetworkManager for users who don't mind config files instead of using a GUI if they have access to it. It just works and it's automatically triggered by udev right when the hardware appears on the bus and sets everything up without the pile of shell scripts that is the status quo right now.
- teacup50 12y ago
- andolanra 12y agoSomething that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely. But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.) The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader. [1]: http://smarden.org/runit/ http://smarden.org/runit/ [2]: http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html
- antientropic 12y agoWhat mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implemented in other programs, such as journald, udevd, logind and so on. Of course, some of the components sometimes need to talk to each other, but generally via well-defined (D-Bus) interfaces - e.g., pam_systemd registers user sessions with logind via a D-Bus call, and loginctl asks logind about current user sessions, also via a D-Bus call. What's wrong about that architecture? Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)
- 12y ago
- lovelearning 12y agoAssuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?
- q3k 12y agoGentoo still has OpenRC as the „preferred” init system.
- e7620 12y agoSlackware, CRUX, Funtoo and Gentoo are some distros that follow traditional Unix paradigms and unlikely to adopt systemd.
- peterwwillis 12y agoPatrick has not ruled out using systemd. But if that does happen, I will personally write a tool to drop-in replace all of systemd and return the original sysvinit functionality, and make it work for every distro.
- agwa 12y agoDebian has only made systemd the default, and getting sysvinit back is as simple as running `apt-get install sysvinit-core`. Removing systemd might have consequences for GNOME, but that's not a concern on servers. There is a significant enough anti-systemd contingent in Debian (not to mention Debian also supports kfreebsd, where systemd doesn't run) that I'm confident sysvinit will remain a viable option for servers and non-GNOME desktops on Debian. Even GNOME desktops may work on Debian without systemd thanks to the work being done on systemd-shim.
- lovelearning 12y agoReally appreciate that overview. It does seem that even if the author's concerns are true, we still have good alternatives available.
- 12y ago
- jessaustin 12y agoWhy weren't any of these objections heard back before Canonical knuckled under? Was upstart even worse? I really enjoyed the "impotent rage" piece linked in TFA's comments.
- lmm 12y agoSystemd didn't used to be this invasive. There have been "better init" options for many years, none of which gained much traction. So most of us figured the community as a whole wasn't very bothered. IMO systemd has only achieved "popularity" by using some very underhanded tactics.
- angersock 12y agoIs this a classic Poettering thing? How'd PulseAudio get stuck in so much stuff? Is this a pattern?
- chronid 12y agoIt's not really a "Poettering" thing. More like a "Red Hat" thing. They control (= their employee are mantainers and developers of) most linux core userspace programs/libraries, starting from Udev and Dbus and Upower, they/their developers make the choices that matters in that regard. It's how OSS operates.
- colanderman 12y agoupstart is terrible in its own special way. Beside that it loses track of anything with a more complicated structure than, say, fingerd, its "dependency" system is wholly back-asswards: a job specifies which other jobs to start when it is ready (as opposed to a job specifying which jobs should be ready before it starts).
- disordr 12y agoWhatever happened to the old unix philosophies of KISS, and if it isn't broken, don't fix it. Granted, as many other have pointed out, SysVinit definitely has its pain points and could use improvements, but there are some other init systems people can use without having systemd shoved down our throats. It's been a while since I've played with *BSD, but it might be the time to start seriously looking at it again. Or switch to slack/debian and keep my old-fashioned init system.
- steanne 12y agodebian is switching to systemd. the only big holdout i've heard of besides slackware is gentoo.