Systemd is incredibly versatile and most people, including myself, are unaware of its full potential. Despite its usefulness, it is often overlooked due to controversy and the current state of things when it comes to software development. Begin today your journey thought Systemd's capabilities and discover how to efficiently manage systems with fewer processes than traditionally used.

After a few conversations with people on Lemmy and other places it became clear to me that most aren’t aware of what it can do and how much more robust it is compared to the usual “jankiness” we’re used to.

In this article I highlight less known features and give out a few practice examples on how to leverage Systemd to remove tons of redundant packages and processes.

And yes, Systemd does containers. :)

  • jimakososx@lemmy.ml
    426·
    1 year ago

    systemd brings much functionality. It can’t follow unix philosophy because unix is 50 years old. the whole community drama about this systemd VS sysV VS OpenRC VS whatever comes up, is funny. There are distros that are systemd-free if you wish so much to avoid it.

    • pastermil
      42·
      1 year ago

      There are shrinking in numbers, especially for mainstream distros, tho…

      • rocketeer8015@discuss.tchncs.de
        31·
        1 year ago

        This was refuted long ago. Systemd isn’t a single binary file doing everything, it’s a project that has many different binaries doing many different things. The only difference is that they are developed under one project to ensure they integrate well with each other. What your doing is like complaining that glibc tries to do everything, I mean it does open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more… Xorg would be another example of a project that does many things instead of one very well.

        • michaelrose@lemmy.mlEnglish
          2·
          1 year ago

          Splitting something into multiple executables doesn’t make something not monolithic just like splitting a program into multiple source files doesn’t make it not a monolith. It’s not a monolith when the different component parts can be cleanly factored out, replaced, and used outside of the original context or with different versions of related components This is in fact very hard. Much harder than making a monolith.

          For instance the X11 ecosystem isn’t a good example of a monolith because its designed to make it trivial to swap in different loosely coupled components. You don’t worry about needing your window manager and X11 to come from the same commit so they actually work. You can argue that the toolbox that systemd provides it is worth it but arguing that it’s not a monolith just screams I’m not a developer.