23 ms·

Systemd 252

103 points by rascul 4y ago

boncho 4y ago
Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
- tsujamin 4y ago
  +1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage
  - Avamander 4y ago
    You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.
  - normaler 4y ago
    systemd-networked + systemd-resolved is also really awesome. It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link. e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.
- europeanguy 4y ago
  I'm not a Linux expert, but I thought that systemd was generally hated?
  - tkuraku 4y ago
    Seems pretty great to me. Never understood the hate.
    - nomel 4y ago
      I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.
  - zargon 4y ago
    > bedrock of delight It might be sarcasm?
    - deleted 4y ago
      [deleted]
  - plaguepilled 4y ago
    I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
- Scarbutt 4y ago
  Alpine linux seems to be doing fine without systemd.
  - stevefan1999 4y ago
    But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
    - HNDV 4y ago
      >never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland. musl is developed by people with that sort of break-everything attitude : https://twitter.com/RichFelker/status/994629795551031296 https://twitter.com/RichFelker/status/994629795551031296 There is a world of pain that awaits anyone with the expectation that this sort of distro could be used on a workstation. Musl is really meant to be run.. with software vetted by communities like https://suckless.org/ https://suckless.org/ Meaning things like dwm, dmenu, st. Which may or may not be one's cup of tea. It certainly ain't mine.
      - biorach 4y ago
        That's an inaccurate and quite uncharitable representation of what musl is about.
      - blueflow 4y ago
        Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one. The glibc 2.26 release with the ucontext breakages made me stick with musl. Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.
- qbasic_forever 4y ago
  I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
  - cat_plus_plus 4y ago
    Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
    - pjmlp 4y ago
      Yes, because it has been such a success conquering the desktop workloads.
  - lrvick 4y ago
    You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.
    - dTal 4y ago
      If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work, you will hit one of these problems very quickly.
      - lrvick 4y ago
        Can you give an example? Even modern AAA games run as well, and often better, on Linux these days.
- okasaki 4y ago
  I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
  - boudin 4y ago
    lxd is not part of systemd.
  - Avamander 4y ago
    Why is lxd touching that file?
  - chris_wot 4y ago
    How is that a systemd issue?
    - tyingq 4y ago
      systemd-resolved
      - encryptluks2 4y ago
        Never had this issue. Sounds like they need to recreate the symlink.
        tyingq 4y ago
        It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_resolved/ https://linuxcontainers.org/lxd/docs/master/howto/network_br...
        lmz 4y ago
        Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible? > you should notify resolved of the domains that LXD can resolve You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.
- conradev 4y ago
  From an outsider perspective these stick out to me as most important: - Unified logging subsystem - On-demand launching, memory limits, and general resource management - Advanced security features, i.e. sandboxing, DynamicUser - Well thought out and implemented given the constraints (feels like Linux quality) In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system. On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices
- blueflow 4y ago
  "rock-solid". Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.
  - encryptluks2 4y ago
    That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.
- esarbe 4y ago
  Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.
  - effie 4y ago
    What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
    - esarbe 4y ago
      Portable services are a systemd thing: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/ In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd. https://wiki.archlinux.org/title/Systemd/User https://wiki.archlinux.org/title/Systemd/User User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions. I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account. Systemd does all the usual things, like logging, supervision, resource quotas, and so on.
- pluijzer 4y ago
  ...the year of the Linux Desktop I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety. What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
  - AnIdiotOnTheNet 4y ago
    > Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
- tapoxi 4y ago
  I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.
  - AnIdiotOnTheNet 4y ago
    I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show. [0] and of course the efforts of the WINE project and proton.
    - tristanbvk 4y ago
      You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.
      - AnIdiotOnTheNet 4y ago
        There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc. Don't succumb to fanboyism.
        tristanbvk 4y ago
        Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
  - fullstop 4y ago
    It's also worth mentioning that the Steam Deck uses systemd as well.
deleted 4y ago
[deleted]
KingOfCoders 4y ago
I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.
- xdfgh1112 4y ago
  Hey, someone rediscovered xinetd
  - klodolph 4y ago
    I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).
  - oblio 4y ago
    > Hey, someone rediscovered xinetd 1. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Replacing inetd was a systemd design goal. 2. Snark for someone learning is a bad move.
    - xdfgh1112 4y ago
      It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.
  - athrun 4y ago
    It's challenging to restart a service without dropping connections with xinetd. Even more so when the process is misbehaving, has children, and is not exiting cleanly.
  - KingOfCoders 4y ago
    Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.
shrubble 4y ago
People who want to use it can use it. I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.
- deleted 4y ago
  [deleted]
- ohCh6zos 4y ago
  I have absolutely fallen in love with FreeBSD after Debian and Arch stopped being what I wanted. It feels closer to what I wanted than a proper Linux.
  - shrubble 4y ago
    I have found FreeBSD to be very coherent as a Unix; and the documentation is very well written. Jails, once understood, seem very good also, even if not perfect.
stopdropnhotpot 4y ago
systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.
- otabdeveloper4 4y ago
  - xdfgh1112 4y ago
    That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)
    - otabdeveloper4 4y ago
      > killing all user processes on logout This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.) The idea is you'd run batch jobs and services explicitly via systemd-run.
      - effie 4y ago
        Why is systemd developers preventing sysadmins/developers from something they want to do on their own/assigned machines a "good default"? Why is their systemd-run idea valid and decades of established unix practice is not? This is really bonkers, don't invent or repeat "rationale" from the vendorthat obviously is anti-user and makes no sense.
        otabdeveloper4 4y ago
        Security by default is usually a good default, yes. systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place. Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?
cat_plus_plus 4y ago
Is the project a new site sponsor or something? :-) I get it that systemd has some benefits - faster startup, more reliable production administration. And at the same time it's not everyone's cup of tea - for example, many believe that the strength of UNIX is many simple and interchangable commands rather than big monolithic code base controlled by a single team. Anyway, there have been 251 previous versions of systemd, so it's not clear to me why this one is special and deserving of our attention after another systemd related story yesterday?
- panick21_ 4y ago
  You do understand how Hacker News voting works?
  - twic 4y ago
    Yes. Clicks on the voting arrows go to the HN backend, which routes them to systemd-votecount, which then generates article rankings and publishes them over D-Bus, from which the backend picks them up and renders them as HTML.
    - russfink 4y ago
      You, kind person, have won the Internet.
- Denvercoder9 4y ago
  > Anyway, there have been 251 previous versions of systemd Trivia: when udev (which was at v182) was merged into the systemd project, they skipped from v44 to v183 to align the version numbers; so there have only been 112 previous versions of systemd.
Timja 4y ago
I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell. Having logs in plain text is beautiful. Having to use special software to read logs is hell.
- Octabrain 4y ago
  You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool. Just to clarify: I'm not a fanboy, I'm just pragmatic.
  - lakomen 4y ago
    > journalctl is really great too until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.
    - fullstop 4y ago
      Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc. Why would you limit what can be done based on the current abilities of a rescue system?
- tenebrisalietum 4y ago
  So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell. - You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash. - systemctl daemon-reload - systemctl start whatever.service Not hard.
kosolam 4y ago
I use systemd and I like it. Because it works. Every question that pops up I can easily find the answer by googling.
teddyh 4y ago
> • At shutdown, systemd will now log about processes blocking unmounting of file systems. Nice.
k_bx 4y ago
I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?
- mariusor 4y ago
  I think generally people view timers as a net superior alternative to crons: they have better logic for the times, they support dependencies, they support randomized delays, etc. Why do you think they're a real mess?
  - k_bx 4y ago
    I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.
    - dinosaurdynasty 4y ago
      The arch wiki has really good documentation on them. And they are so much more debuggable than cron it's insane, they are a lot easier for anything non-trivial.
      - effie 4y ago
        What is there to debug in cron??? It periodically runs processes, it is simple and solid as rock.
- esarbe 4y ago
  I concur with siblings suggestion of systemd timers. Works like a charm. Has jittering and nice tui.
- loudmax 4y ago
  Systemd timers are more complicated than cron, but there's a reason for the complexity. Once you've put in the extra effort to understand the logic, they're really powerful. If you don't want the complexity, then just run crond.
gorgoiler 4y ago
It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.
- HeckFeck 4y ago
  It happened for PulseAudio, perhaps something compatible but leaner can emerge for systemd.
  - phoronixrly 4y ago
    It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.
    - McDyver 4y ago
      Just because the project is moving, doesn't mean it's moving in the right direction. What I like about linux in general, is that there are lots of small tools, with a reduced and specific scope, that do their job well. Systemd seems to want to do and control everything.
      - rainbow29822 4y ago
        I don't understand this comment. Systemd is a lot of small tools with a specific scope that do their job well.
- ciupicri 4y ago
  From the logind.conf man page [1]: > KillUserProcesses= > Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below. > In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1). > Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1). [1]: https://www.freedesktop.org/software/systemd/man/logind.conf.html https://www.freedesktop.org/software/systemd/man/logind.conf...
stevefan1999 4y ago
I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.
- twic 4y ago
  I think it's because there were other alternatives that solved the same important problems, while being much simpler and less intrusive.
- lakomen 4y ago
  The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, reading and parsing logs the same. There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. The above doesn't represent my personal opinion, it's a representation of what reasons people might have.
  - TacticalCoder 4y ago
    > There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff removed). I use Devuan on my main desktop PC and I've got exactly zero problem. That's the thing: many "sell" systemd as some mandatory machinery but it simply ain't. Ultra-light containers (like Alpine-based ones) run fine (and faster) without systemd. Desktops do run fine without systemd (I'm running Devuan on my workstation and Debian on my laptop: it's basically the same experience). For certain types of servers I can understand some see benefits in running systemd. Neither IBM / Red Hat nor Microsoft should be those setting the terms of what is or is not an acceptable "PID 1" for Linux. The day Linux becomes "systemd Linux" is the day I'll switch to a BSD. I don't mind that systemd exists as long as people still have the choice to run a non-systemd Linux. The kernel should be orthogonal to systemd and there should be Linux distros packaged without systemd. And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.
captainmuon 4y ago
About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.
- Macha 4y ago
  The kernel initramfs only mounts the root partition - parsing fstab and running mount is handled as part of init. This means that an init system needs to support split-usr by ensuring it can go without the contents of /usr at least long enough to bootstrap (which requires special treatment of the mounting scripts/units) or else avoid using /usr at all
- dsr_ 4y ago
  I believe that the end goal of systemd is to end Linux distributions as anything other than a flavor. This will not work completely, but it may work well enough that non-systemd linux will be considered an unusual eccentricity.
  - LeSaucy 4y ago
    One could make the argument we are already there.
  - marcosdumay 4y ago
    Until some eccentricity works well enough that everybody adopts it. Then it's only a matter of barriers and lock-in... And systemd imposes a lot of those.
- VLM 4y ago
- deleted 4y ago
  [deleted]
- HNDV 4y ago
Woodi 4y ago
Welcome to C: ...
rfmoz 4y ago
SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
- fullstop 4y ago
  launchd or perhaps, more likely, upstartd.
  - rfmoz 4y ago
    UpstartD was the good alternative offered by Canonical, but Redhat finally won with their SystemD.
    - xyzzy_plugh 4y ago
      upstart was terrible. I wanted upstart to win, I invested a ton of personal and professional energy into making it win, and it was all a terrible mistake. The design was simply backwards. systemd was right from the start.
legulere 4y ago
That's a pretty long list of small changes, but nothing really sticks out. I don't really see any ground of discussion about this.
xarthna 4y ago
I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost. That said, if one wants to use it, then use it. However, there are alternatives which I would love to see receive more adoption. I've been extremely happy with my Artix [1] system running s6 [2] init. 1. https://artixlinux.org/ https://artixlinux.org/ 2. https://skarnet.org/software/s6/ https://skarnet.org/software/s6/
- TheFreim 4y ago
  Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.
  - xarthna 4y ago
    Mostly because of the philosophy of the software's author. This was the selling point for me. It is incredibly small scoped by design, easy to understand, and is very explicit in it's actions. It is not as "user friendly" as other inits, though the author is currently working on making it more accessible. It practices separation of mechanism and policy, it attempts to do less than more, and it know when to stop and not introduce scope creep. All by design. I won't ever have to worry about it becoming a system layer and reaching into my network stack, or making policy decisions for me. I'm sure other available init systems have their selling points - but to be honest, after reading s6's reasoning and design goals I was sold. I'm happy to report that after a year and a half I'm pleased with the decision.
    - TheFreim 4y ago
      Thank you for this information. I was leaning towards other init systems for the potential future where I switch to artix simply due to recommendation, I will reevaluate at some point. Thanks again.
t43562 4y ago
I'm enjoying dinit in artix. I think Artix is not terribly mainstream but the dinit part of it seems easy to deal with so far. It would be interesting to see it get polished in a different distro. Living without systemd is sometimes a rough choice at the moment but I think it can be polished.
- E39M5S62 4y ago
  Take a look at Chimera Linux - https://chimera-linux.org/ https://chimera-linux.org/ . It's a desktop-focused distribution that uses dinit. It'll be one to watch once it stabilizes.
rektide 4y ago
Small detail, but interesting to see varlink capabilities added. systemd-resolvd gains "monitor" capabilities via the lightweight json rpc system varlink. definitely useful just for monitoring dns broadly, seeing whats happening on the system. there's probably some more specific creative uses folks could hack together here.
effie 4y ago
> it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions ... -- Lennart Poettering - Red Hat, Inc. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

103 points by rascul 4y ago

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

tsujamin 4y ago
+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage
- Avamander 4y ago
  You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.
- normaler 4y ago
  systemd-networked + systemd-resolved is also really awesome. It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link. e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.
europeanguy 4y ago
I'm not a Linux expert, but I thought that systemd was generally hated?
- tkuraku 4y ago
  Seems pretty great to me. Never understood the hate.
  - nomel 4y ago
    I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.
- zargon 4y ago
  > bedrock of delight It might be sarcasm?
  - deleted 4y ago
    [deleted]
- plaguepilled 4y ago
  I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
Scarbutt 4y ago
Alpine linux seems to be doing fine without systemd.
- stevefan1999 4y ago
  But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
  - HNDV 4y ago
    >never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland. musl is developed by people with that sort of break-everything attitude : https://twitter.com/RichFelker/status/994629795551031296 https://twitter.com/RichFelker/status/994629795551031296 There is a world of pain that awaits anyone with the expectation that this sort of distro could be used on a workstation. Musl is really meant to be run.. with software vetted by communities like https://suckless.org/ https://suckless.org/ Meaning things like dwm, dmenu, st. Which may or may not be one's cup of tea. It certainly ain't mine.
    - biorach 4y ago
      That's an inaccurate and quite uncharitable representation of what musl is about.
    - blueflow 4y ago
      Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one. The glibc 2.26 release with the ucontext breakages made me stick with musl. Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.
qbasic_forever 4y ago
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
- cat_plus_plus 4y ago
  Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
  - pjmlp 4y ago
    Yes, because it has been such a success conquering the desktop workloads.
- lrvick 4y ago
  You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.
  - dTal 4y ago
    If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work, you will hit one of these problems very quickly.
    - lrvick 4y ago
      Can you give an example? Even modern AAA games run as well, and often better, on Linux these days.
okasaki 4y ago
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
- boudin 4y ago
  lxd is not part of systemd.
- Avamander 4y ago
  Why is lxd touching that file?
- chris_wot 4y ago
  How is that a systemd issue?
  - tyingq 4y ago
    systemd-resolved
    - encryptluks2 4y ago
      Never had this issue. Sounds like they need to recreate the symlink.
      - tyingq 4y ago
        It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_resolved/ https://linuxcontainers.org/lxd/docs/master/howto/network_br...
        lmz 4y ago
        Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible? > you should notify resolved of the domains that LXD can resolve You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.
conradev 4y ago
From an outsider perspective these stick out to me as most important: - Unified logging subsystem - On-demand launching, memory limits, and general resource management - Advanced security features, i.e. sandboxing, DynamicUser - Well thought out and implemented given the constraints (feels like Linux quality) In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system. On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices
blueflow 4y ago
"rock-solid". Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.
- encryptluks2 4y ago
  That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.
esarbe 4y ago
Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.
- effie 4y ago
  What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
  - esarbe 4y ago
    Portable services are a systemd thing: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/ In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd. https://wiki.archlinux.org/title/Systemd/User https://wiki.archlinux.org/title/Systemd/User User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions. I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account. Systemd does all the usual things, like logging, supervision, resource quotas, and so on.
pluijzer 4y ago
...the year of the Linux Desktop I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety. What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
- AnIdiotOnTheNet 4y ago
  > Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
tapoxi 4y ago
I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.
- AnIdiotOnTheNet 4y ago
  I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show. [0] and of course the efforts of the WINE project and proton.
  - tristanbvk 4y ago
    You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.
    - AnIdiotOnTheNet 4y ago
      There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc. Don't succumb to fanboyism.
      - tristanbvk 4y ago
        Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
- fullstop 4y ago
  It's also worth mentioning that the Steam Deck uses systemd as well.

deleted 4y ago

[deleted]

KingOfCoders 4y ago

I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.

xdfgh1112 4y ago
Hey, someone rediscovered xinetd
- klodolph 4y ago
  I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).
- oblio 4y ago
  > Hey, someone rediscovered xinetd 1. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Replacing inetd was a systemd design goal. 2. Snark for someone learning is a bad move.
  - xdfgh1112 4y ago
    It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.
- athrun 4y ago
  It's challenging to restart a service without dropping connections with xinetd. Even more so when the process is misbehaving, has children, and is not exiting cleanly.
- KingOfCoders 4y ago
  Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.

shrubble 4y ago

People who want to use it can use it. I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.

deleted 4y ago
[deleted]
ohCh6zos 4y ago
I have absolutely fallen in love with FreeBSD after Debian and Arch stopped being what I wanted. It feels closer to what I wanted than a proper Linux.
- shrubble 4y ago
  I have found FreeBSD to be very coherent as a Unix; and the documentation is very well written. Jails, once understood, seem very good also, even if not perfect.

stopdropnhotpot 4y ago

systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.

otabdeveloper4 4y ago
- xdfgh1112 4y ago
  That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)
  - otabdeveloper4 4y ago
    > killing all user processes on logout This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.) The idea is you'd run batch jobs and services explicitly via systemd-run.
    - effie 4y ago
      Why is systemd developers preventing sysadmins/developers from something they want to do on their own/assigned machines a "good default"? Why is their systemd-run idea valid and decades of established unix practice is not? This is really bonkers, don't invent or repeat "rationale" from the vendorthat obviously is anti-user and makes no sense.
      - otabdeveloper4 4y ago
        Security by default is usually a good default, yes. systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place. Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?

cat_plus_plus 4y ago

Is the project a new site sponsor or something? :-) I get it that systemd has some benefits - faster startup, more reliable production administration. And at the same time it's not everyone's cup of tea - for example, many believe that the strength of UNIX is many simple and interchangable commands rather than big monolithic code base controlled by a single team. Anyway, there have been 251 previous versions of systemd, so it's not clear to me why this one is special and deserving of our attention after another systemd related story yesterday?

panick21_ 4y ago
You do understand how Hacker News voting works?
- twic 4y ago
  Yes. Clicks on the voting arrows go to the HN backend, which routes them to systemd-votecount, which then generates article rankings and publishes them over D-Bus, from which the backend picks them up and renders them as HTML.
  - russfink 4y ago
    You, kind person, have won the Internet.
Denvercoder9 4y ago
> Anyway, there have been 251 previous versions of systemd Trivia: when udev (which was at v182) was merged into the systemd project, they skipped from v44 to v183 to align the version numbers; so there have only been 112 previous versions of systemd.

Timja 4y ago

I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell. Having logs in plain text is beautiful. Having to use special software to read logs is hell.

Octabrain 4y ago
You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool. Just to clarify: I'm not a fanboy, I'm just pragmatic.
- lakomen 4y ago
  > journalctl is really great too until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.
  - fullstop 4y ago
    Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc. Why would you limit what can be done based on the current abilities of a rescue system?
tenebrisalietum 4y ago
So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell. - You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash. - systemctl daemon-reload - systemctl start whatever.service Not hard.

kosolam 4y ago

I use systemd and I like it. Because it works. Every question that pops up I can easily find the answer by googling.

teddyh 4y ago

> • At shutdown, systemd will now log about processes blocking unmounting of file systems. Nice.

k_bx 4y ago

I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?

mariusor 4y ago
I think generally people view timers as a net superior alternative to crons: they have better logic for the times, they support dependencies, they support randomized delays, etc. Why do you think they're a real mess?
- k_bx 4y ago
  I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.
  - dinosaurdynasty 4y ago
    The arch wiki has really good documentation on them. And they are so much more debuggable than cron it's insane, they are a lot easier for anything non-trivial.
    - effie 4y ago
      What is there to debug in cron??? It periodically runs processes, it is simple and solid as rock.
esarbe 4y ago
I concur with siblings suggestion of systemd timers. Works like a charm. Has jittering and nice tui.
loudmax 4y ago
Systemd timers are more complicated than cron, but there's a reason for the complexity. Once you've put in the extra effort to understand the logic, they're really powerful. If you don't want the complexity, then just run crond.

gorgoiler 4y ago

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.

HeckFeck 4y ago
It happened for PulseAudio, perhaps something compatible but leaner can emerge for systemd.
- phoronixrly 4y ago
  It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.
  - McDyver 4y ago
    Just because the project is moving, doesn't mean it's moving in the right direction. What I like about linux in general, is that there are lots of small tools, with a reduced and specific scope, that do their job well. Systemd seems to want to do and control everything.
    - rainbow29822 4y ago
      I don't understand this comment. Systemd is a lot of small tools with a specific scope that do their job well.
ciupicri 4y ago
From the logind.conf man page [1]: > KillUserProcesses= > Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below. > In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1). > Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1). [1]: https://www.freedesktop.org/software/systemd/man/logind.conf.html https://www.freedesktop.org/software/systemd/man/logind.conf...

stevefan1999 4y ago

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

twic 4y ago
I think it's because there were other alternatives that solved the same important problems, while being much simpler and less intrusive.
lakomen 4y ago
The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, reading and parsing logs the same. There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. The above doesn't represent my personal opinion, it's a representation of what reasons people might have.
- TacticalCoder 4y ago
  > There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff removed). I use Devuan on my main desktop PC and I've got exactly zero problem. That's the thing: many "sell" systemd as some mandatory machinery but it simply ain't. Ultra-light containers (like Alpine-based ones) run fine (and faster) without systemd. Desktops do run fine without systemd (I'm running Devuan on my workstation and Debian on my laptop: it's basically the same experience). For certain types of servers I can understand some see benefits in running systemd. Neither IBM / Red Hat nor Microsoft should be those setting the terms of what is or is not an acceptable "PID 1" for Linux. The day Linux becomes "systemd Linux" is the day I'll switch to a BSD. I don't mind that systemd exists as long as people still have the choice to run a non-systemd Linux. The kernel should be orthogonal to systemd and there should be Linux distros packaged without systemd. And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.

captainmuon 4y ago

About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.

Macha 4y ago
The kernel initramfs only mounts the root partition - parsing fstab and running mount is handled as part of init. This means that an init system needs to support split-usr by ensuring it can go without the contents of /usr at least long enough to bootstrap (which requires special treatment of the mounting scripts/units) or else avoid using /usr at all
dsr_ 4y ago
I believe that the end goal of systemd is to end Linux distributions as anything other than a flavor. This will not work completely, but it may work well enough that non-systemd linux will be considered an unusual eccentricity.
- LeSaucy 4y ago
  One could make the argument we are already there.
- marcosdumay 4y ago
  Until some eccentricity works well enough that everybody adopts it. Then it's only a matter of barriers and lock-in... And systemd imposes a lot of those.
VLM 4y ago
deleted 4y ago
[deleted]
HNDV 4y ago

Woodi 4y ago

Welcome to C: ...

rfmoz 4y ago

SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html

fullstop 4y ago
launchd or perhaps, more likely, upstartd.
- rfmoz 4y ago
  UpstartD was the good alternative offered by Canonical, but Redhat finally won with their SystemD.
  - xyzzy_plugh 4y ago
    upstart was terrible. I wanted upstart to win, I invested a ton of personal and professional energy into making it win, and it was all a terrible mistake. The design was simply backwards. systemd was right from the start.

legulere 4y ago

That's a pretty long list of small changes, but nothing really sticks out. I don't really see any ground of discussion about this.

xarthna 4y ago

I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost. That said, if one wants to use it, then use it. However, there are alternatives which I would love to see receive more adoption. I've been extremely happy with my Artix [1] system running s6 [2] init. 1. https://artixlinux.org/ https://artixlinux.org/ 2. https://skarnet.org/software/s6/ https://skarnet.org/software/s6/

TheFreim 4y ago
Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.
- xarthna 4y ago
  Mostly because of the philosophy of the software's author. This was the selling point for me. It is incredibly small scoped by design, easy to understand, and is very explicit in it's actions. It is not as "user friendly" as other inits, though the author is currently working on making it more accessible. It practices separation of mechanism and policy, it attempts to do less than more, and it know when to stop and not introduce scope creep. All by design. I won't ever have to worry about it becoming a system layer and reaching into my network stack, or making policy decisions for me. I'm sure other available init systems have their selling points - but to be honest, after reading s6's reasoning and design goals I was sold. I'm happy to report that after a year and a half I'm pleased with the decision.
  - TheFreim 4y ago
    Thank you for this information. I was leaning towards other init systems for the potential future where I switch to artix simply due to recommendation, I will reevaluate at some point. Thanks again.

t43562 4y ago

I'm enjoying dinit in artix. I think Artix is not terribly mainstream but the dinit part of it seems easy to deal with so far. It would be interesting to see it get polished in a different distro. Living without systemd is sometimes a rough choice at the moment but I think it can be polished.

E39M5S62 4y ago
Take a look at Chimera Linux - https://chimera-linux.org/ https://chimera-linux.org/ . It's a desktop-focused distribution that uses dinit. It'll be one to watch once it stabilizes.

rektide 4y ago

Small detail, but interesting to see varlink capabilities added. systemd-resolvd gains "monitor" capabilities via the lightweight json rpc system varlink. definitely useful just for monitoring dns broadly, seeing whats happening on the system. there's probably some more specific creative uses folks could hack together here.

effie 4y ago

> it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions ... -- Lennart Poettering - Red Hat, Inc. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...