• Damage@feddit.it
    532·
    3 days ago

    Ok so I’m just my own system administrator, yet I like systemd because I remember how much less… reliable the former alternatives were on my computers.

    BUT. I dislike having to learn more commands just to read my logs, and systemd timers are awfully complicated when I just needed what cronjobs already did.

    • Laser@feddit.org
      91·
      3 days ago

      You can use systemd with the classic logging tools by installing and enabling their respective service if you prefer. This will forward all messages to them. You even get a more comprehensive log than before systemd as the latter will even forward the messages that were sent before the logging service was started.

      Edit: similarly for cron, you can still use the classic tools. I see their appeal in ease of configuration. Though in my opinion, systemd timers are more powerful and better integrated (don’t ask me why, I made that assessment years ago) so I accept that increased complexity.

      For logs, I actually prefer the systemd journal though

    • Amon@lemmy.worldOP
      41·
      3 days ago

      Yeah but you can use journalctl on literally everything from binaries to units to cron jobs with the same interface. You don’t need to find the log file just punch it into journalctl

  • FrostyCaveman@lemm.ee
    261·
    3 days ago

    Coming from software development, the systemd controversy is starting to feel more familiar as I learn more of it.

    It really reminds me of what happens sometimes in backend web systems development when an overly complicated framework takes over a programming language community. Getting anything done no longer becomes about using the tools to interact with HTTP, or the language runtime (if relevant), or anything else absolutely essential to the task at hand - it’s about learning the framework itself and its peculiarities, its specific abstractions and semantics wrapping real concepts.

    An example is Spring Framework. One does not simply write a little bit of code to cache something in memory at the place one needs it, no! One must use a ProxyFactoryBean to apply a CachingInterceptor, in the bean configuration XML of course! (Of course being Java, you have the extra layer of indirection and fakery as the Java community is/was full of people obsessed with shoving everything possible into a design pattern for cred.)

    One does not simply read a systemd log file using cat, nor filter with grep. One must use journalctl with its specific arguments to filter by specific things. Because the logs are binary or something. I feel like I’m not learning Linux/UNIX anymore, I’m learning systemd.

    I do like systemd’s unit system, with its whole dependency graph for reaching certain targets, etc. However, given the nigh ubiquity of systemd, I’ve not really had much of a chance to learn any alternatives, so it seems I must simply get used to it regardless.

  • Doombot1@lemmy.one
    271·
    3 days ago

    I love hate love hate love systemd!

    It’s great sometimes but trying to deal with systemd-related objects in an OpenBMC Yocto project has been an absolute nightmare. Like many things, it’s got ups and downs.

    • Justin@lemmy.jlh.name
      1·
      3 days ago

      yeah, networkd isn’t better than Network Managar or just static IPS imo.

      Also, resolved is horribly buggy and unusable. Tried for a while and switched to dnscrypt proxy 2 instead

  • Hugin@lemmy.world
    81·
    3 days ago

    So yeah the bird was me. But back in the day there was linux with a bunch of config files and windows with the registry.

    It could be a pain to deal with config files but it was nowhere near as bad a dealing with the gigantic mess that was the windows registry. So someone trying to move linux away from one of the things that made it better then windows to a windows like system seemed like a horrible idea.

    Combine that with the main systemd guy coming off as a bit of a jerk online and the resistance is understandable.

      • ricecake@sh.itjust.works
        18·
        3 days ago

        Pretty sure they meant the whole “do one thing, do it well, and prefer composition” part.

        But I’m more interested in what parts of systemd don’t follow the file metaphor, and what things you think shouldn’t follow that metaphor? How would you interact with those things?

        • Amon@lemmy.worldOP
          54·
          3 days ago

          journalctl. I don’t give a damn as to where the logs are, and I just have tell journalctl to give me the logs for whatever I want.

          • ricecake@sh.itjust.works
            7·
            3 days ago

            That’s all fine and good, but that’s not quite related to the “everything is a file” metaphor. The data is still stored in files and accessed using conventional io and the command itself is routinely piped to other commands.

            Everything being a file is extremely pervasive in unix, and I couldn’t think of what systemd was doing that went in opposition to the metaphor.

  • lazynooblet@lazysoci.alEnglish
    51·
    3 days ago

    It adds more functionality but makes adminstration more complicated.

    Like I was reading posts on Lemmy yesterday that the reason Nextcloud file sync is preferred over seafile for some is because seafile stores the data in a format that can only be read by seafile. This is what systemd does.