Distributors ponder a systemd change
Distributors ponder a systemd change
Posted Jun 13, 2016 6:18 UTC (Mon) by anselm (subscriber, #2796)In reply to: Distributors ponder a systemd change by elvis_
Parent article: Distributors ponder a systemd change
No, he suggested that you should use a distribution that provides the required hand-holding if you can't be bothered to learn some pretty cool new stuff like systemd (which would incidentally come in useful in a few other places, too). Not quite the same thing.
Seriously, if you're that worked up about this, we're talking about one switch that you need to flip to make the issue at hand go away, and that's only if your distribution doesn't do it for you already. We can quibble endlessly about whether changing that default was a great idea, and there are reasonable arguments on both sides – but as far as I'm concerned, “That's not how we used to do it in 1980” is one of the less reasonable arguments.
Posted Jun 13, 2016 7:14 UTC (Mon)
by jrigg (guest, #30848)
[Link] (8 responses)
There's a big difference between "can't be bothered" and "don't have time".
Posted Jun 13, 2016 7:36 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (7 responses)
That's a lame excuse if ever I heard one.
Learning the basics of systemd takes one or two hours, tops. It's not exactly rocket science. That would cover the various types of unit files, what they contain and where they're located, how service activation works, the systemctl command and its more important subcommands, and an overview of ancillary software such as journalctl or systemd-logind. It should certainly give one enough knowledge to be dangerous and to build upon incrementally as required. There's what I would consider a reasonable primer on systemd in this manual from the tuxcademy project (although I'm biased because I wrote it myself), and Lennart Poettering's blog and the documentation on freedesktop.org are also worth a peek.
Given the importance of systemd in current and future Linux systems, one would be more than justified in considering these two hours a reasonable investment (for some people it would also be worth it just to learn enough about systemd to not appear ignorant in discussions on LWN.net). Think of it as alternative entertainment on an evening when there's nothing interesting on TV.
Posted Jun 13, 2016 10:50 UTC (Mon)
by johannbg (guest, #65743)
[Link] (2 responses)
People that approach and view systemd as a new technology with new concepts adapt to it quicker than those with any background in any legacy init system in which they more often than not approach systemd as an legacy init system and apply legacy init system concepts that are not applicable to systemd ( and expect same and similar outcome or behavior ) like for example the concept of "run levels" which does not exist in systemd but the concept of boot targets does etc.
Posted Jun 13, 2016 12:22 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
In my experience as a Linux instructor, one or two hours of systemd instruction is adequate to provide the basics for people who would otherwise be using System-V init as system administrators. Building on that, it is certainly more feasible to spend another couple of hours teaching somebody how to write a systemd service unit file for a new service and to integrate that into an existing setup, than it is to spend a couple of days teaching them enough shell scripting and distribution-specific minutiae to be able to write a robust System-V init script for a new service and to integrate that into an existing setup, on one single distribution. (The next distribution is going to be subtly, or not so subtly, different.)
For an upstream project, it is reasonable to invest the time to produce a good systemd-based configuration, which by now is likely to be applicable with few if any changes to a large number of platforms, because the effort for that is going to be smaller, in the long run, than the effort required to test and tweak new versions of their application (or application stack) on a huge number of subtly different legacy environments that all require some degree of individual adaptation.
Posted Jun 13, 2016 16:01 UTC (Mon)
by johannbg (guest, #65743)
[Link]
Daemon vs socket activation, path used in type units and simply the name of the component ( apache vs httpd for example ) etc still differs between distributions and that problem will never be solved unless unification in the core/baseOS can be achieve so those upstream(s) that actually care and ship initscripts of any kind are still dealing with that issue.
Posted Jun 13, 2016 12:38 UTC (Mon)
by jrigg (guest, #30848)
[Link] (2 responses)
It's easy to say that's purely a problem for the distros, but system upgrades are painful enough without having to learn several different versions of things in preparation for the next one.
Posted Jun 13, 2016 20:58 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jun 14, 2016 13:05 UTC (Tue)
by jrigg (guest, #30848)
[Link]
According to this, https://www.freedesktop.org/wiki/Software/systemd/MyServi... the way to allow realtime scheduling for users for a specific service is to add ControlGroup=cpu:/ to its [Service] section. The ControlGroup= option was removed in systemd 205 (July 2013) but the document hasn't been changed. That's an example of what I was referring to.
To be fair it's only one specific example, but it did contribute to my decision to stick with sysvinit-core on my Debian systems for the time being.
Posted Jun 13, 2016 13:23 UTC (Mon)
by paulj (subscriber, #341)
[Link]
That's the basics of good system maintenance.
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
You awareness is incorrect. Systemd is committed to backwards compatibility, so my units from 2012 still work just fine.
Distributors ponder a systemd change
Distributors ponder a systemd change