6 ms·
I realize the decision is said and done but can anyone share in easy to understand terms what the big deal is with systemd?
by fosco 9y ago
I realize the decision is said and done but can anyone share in easy to understand terms what the big deal is with systemd?
- dsr_ 9y agoSystemd is an init system that tries to do everything: system init, hardware monitoring to load drivers on demand, configure networking, rerun failed jobs, service management, and it comes with a binary-format logger. The claimed advantages of systemd are mostly relevant, IMHO, for mobile devices that change configuration often. It brings no particular advantage to servers or desktops, unless you tend to swap out lots of peripherals on your desktop. The disadvantages are partially political -- systemd tries to take over every job it can; the originator has made it clear that his vision is for every system function to be handled by systemd -- and partially philosophical: it used to be the case that most subsystems were independent of each other, so that they could be replaced more or less easily if the sysadmin had different needs. The current stable Debian still makes it possible to run a different init system with just a line of package installation and a reboot.
- chimeracoder 9y ago> The claimed advantages of systemd are mostly relevant, IMHO, for mobile devices that change configuration often. It brings no particular advantage to servers or desktops, unless you tend to swap out lots of peripherals on your desktop. Systemd provides huge advantages for administering desktops and servers as well. I'd actually go so far as to say those are the main reasons that systemd won (it's the default init system for all of the top ten Linux distributions by marketshare).
- gsaga 9y ago>Systemd provides huge advantages for administering desktops and servers as well Can you list some of them?
- oblio 9y agoCreating unit files is trivial and you're sure that you're getting high quality service supervision, unlike with home grown scripts. Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. There's also other parts I'm probably forgetting right now, but in general having a standard interface for service interaction is really, really useful. Sometimes I get the impression that Linux folks underestimate the benefits of standardization. For example there's still no good, standard way to check the exact name and version of a distribution. If they can't agree about something as banal as that... (I think there is a convergence towards /etc/os-release, but when was the first distro launched? 1992? :) )
- dozzie 9y ago> Creating unit files is trivial [...] Unless you expect anything but most trivial use cases, e.g. some user-owned directory under /var/run (/run). Then you need to wild-guess at what combination of options needs to be set. Good thing that those options are at least described in docs. > Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. syslog already was standard. We gained nothing really from journald.
- oblio 9y agoQuick, how do I see the logs for the currently running services from the random OSS project foo and the random commercial project bar? What do I type in my terminal?
- dozzie 9y agoSo? How do you tell between commercial and OSS projects in journald? And about that "quick" part, I'd rather have a way to do that that's either easy to recall or easy to re-develop. journald's magical incantations that don't compose to any consistent language (unlike Vim or Emacs keybindings, for instance) nor are the same as in virtually any other software are not convenient by any stretch. I have my memory cluttered enough by half a dozen of different languages I use, their runtimes, runtimes of languages I don't write in but need for some software I run, twice that of DSLs and specialized languages, options and functions of dozens of services, wire formats of network protocols, management procedures of various Linux subsystems, and so on. I don't need an option to a command to tell me what you ask, I can work my way through grep/sed/awk faster than you read man page, thank you very much.
- eikenberry 9y agoOne big advantage is user services/daemons. I've recently converted most everything I used to start in .xsession to systemd user services and it worked very well. I did it mostly as a way to learn about systemd, but I'm happy with the results and it makes it much easier to diagnose issues and maintain a consistent environment.
- napsterbr 9y agoThis is a meta comment about the sister thread. I know flame wars are discouraged (and maybe that wasn't parent's goal), but I have to say I always enjoy these discussions here on HN (and lobsters too). Even though it is an old discussion (and will probably remain this way for a long time), the arguments are almost always purely technical and create a good picture of the pros and cons of systemd. As someone who migrated away from Linux before the systemd inception, I'm always learning a lot on "flame wars" like these. So thanks, I guess, and please keep the technical arguments coming :) Edit: s/OP/parent/