• somegeek@programming.dev
    231·
    7 days ago

    SystemD works great, but the corporations and politics behind it will ruin Linux if they fully take over. They are already optimizing heavily for IoT just because IBM is heavily focused on IoT

    • FooBarrington@lemmy.world
      81·
      7 days ago

      I’m pretty sure IBM hasn’t focussed on IoT in a long time

      (In the sense that I used to work there and know they’ve both reduced investment in, and fully removed, some parts of their portfolio regarding IoT)

      • somegeek@programming.dev
        36·
        7 days ago

        Just search IBM IoT and look at IBM acquisitions in the last decade.

        Everyone “used to work for that company” on the internet. And even if you used to work there it doesn’t mean you know anything about their business. IBM is more of a Holding now. Like Volkswagen. Just because someone works at audi it doesn’t mean they know anything about Lamborghini.

        https://unixdigest.com/articles/the-real-motivation-behind-systemd.html

        • FooBarrington@lemmy.world
          11·
          7 days ago

          I’m well aware of IBM IoT and their acquisitions, but I’m also aware that most of that stuff happened around 2016-2018, and since then that part of the business has been shrunk down and sold off.

          Believe what you want. I did work in IBM IoT, but what do I know ¯\_(ツ)_/¯

          If you read your own article, you’ll also notice that it doesn’t mention IoT even once. It talks about embedded use cases, which is not the same as IoT. Are you sure you’re not just throwing together unrelated topics?

    • somenonewho@feddit.org
      5·
      6 days ago

      I feel that. I’ve used Linux before systemd but when I went into the “nitty gritty” by using arch systemd had just been implemented and everything I learned about startup services init etc. was systemd based. When I started my career working in servers they were redhat/CentOS so still systemd and when I switched jobs Debian already had made the switch so (most of) the systems at my new job were also systemd based. Of course I learned the basics of init files and even some rc.d but systemd still makes the most sense to me and like you say it’s “comfy”.

  • SavvyWolf@pawb.socialEnglish
    11·
    7 days ago

    Anyone got a good tutorial/guide fir SystemD?

    Figure I may as well try to wrap my head around it if it’s supposedly going to murder me in my sleep or whatever.

      • probably2high@lemmy.worldEnglish
        7·
        6 days ago

        And if you’re not a 50 year-old Linux admin, Arch wiki.

        Edit: don’t be put off by the Arch wiki if you don’t use Arch. 99% of the time, Linux is Linux, and you can follow it for just about anything other than package management.

        • vinyl@lemmy.world
          11·
          6 days ago

          That too but arch wiki sometimes doesn’t list all the possibilities the program can do or not, skill issue if you can’t read.

          • probably2high@lemmy.worldEnglish
            1·
            6 days ago

            skill issue

            I fully own that. But I like the logical ordering of the page sections on the wiki, and if anything is unclear or info is missing there–which it is pretty rare–I’ll hit up man in desperation

  • Tja@programming.dev
    61·
    6 days ago

    I dislike journalctl more than systemd. And I don’t get what’s the advantage of systemctl vs previous solutions, why would that of all things make one reconsider.

    I miss rc.local and crontabs. Now if you excuse me I have a cloud to yell at.

    • Hawke@lemmy.world
      3·
      6 days ago

      The only advantage I see is that it actually seems to keep a better handle on the status of the process/service. The old-style unit scripts would often get out of sync and not realize that a process had died, or if they did they would repeatedly respawn a service that would just die again. Maybe that was less of a problem in later years than I experienced earlier, but it was there.

      The whole init.d system felt very ad-hoc with every script working a little bit differently, giving different output styles, etc.

  • mittorn@masturbated.one
    71·
    6 days ago

    @pewgar_seemsimandroid systemd has a lot of really good things…
    But it’s too complex for init process and even too complex for service manager. Many solib dependencies causes long start, big memory footprint and possibe security issues. Many things might be implemented in some separate services, running with restricted permissions and optionally disabled.
    initng was very similar to systemd, but was very simple and very much faster

  • Matt@lemmy.ml
    6·
    7 days ago

    Try to pass init=<path to any other init system> and you’ll see reduced RAM usage. Systemd is bloated.

    • azertyfun@sh.itjust.worksEnglish
      16·
      7 days ago

      Hell, pass init=/bin/yes and you’ll see even more greatly reduced RAM usage!

      ❯ ps aux | grep /usr/lib/sys | awk '{print $6}' | sed 's/$/+/' | tr -d '\n' | sed 's/+$/\n/' | bc
266516

      So that’s 260 MiB of RSS (assuming no shared libs which is certainly false) for:

      • Daemon manager
      • Syslog daemon
      • DNS daemon (which I need and would have to replace with dnsmasq if it did not exist)
      • udev daemon
      • network daemon
      • login daemon
      • VM daemon (ever hear of the principle of least privilege?)
      • user daemon manager (I STG anyone who writes a user daemon by doing nohup & needs to be fired into the sun. pkill is not the tool I should have to use to manage my user’s daemons)

      For comparison the web page I’m writing this on uses 117 MiB, about half. I’ll very gladly make the tradeoff of two sh.itjust.works tabs for one systemd suite. Or did you send that comment using curl because web browsers are bloated?

      For another comparison 200 MiB of RAM is less than two dollars at current prices. I don’t value my time so low that I’ll avoid spending two bucks by spend hours debugging whatever bash scripting spaghetti hell other init systems cling onto to avoid “bloat”. I’ve done it, don’t miss it.

  • daggermoon@lemmy.world
    5·
    7 days ago

    I’ve used both runnit and systemD and I prefer systemD. Nothing against runnit and I love Void Linux.

  • neox_@sh.itjust.worksFrançais
    3·
    7 days ago

    Well, I think that if declarative configuration is what you’re looking for, the GNU Guix distro with its GNU Shepherd init system might be a more pertinent solution than SystemD

    • lime!@feddit.nuEnglish
      13·
      7 days ago

      some other init systems just use scripts for config, meaning you can just do whatever

        • lime!@feddit.nuEnglish
          2·
          6 days ago

          a config file can do only what the program that reads it allows. if the program that reads the file is just bash…

        • vinyl@lemmy.world
          1·
          6 days ago

          Limits and constraints are set by the program that reads the config, so no, not whatever. The only way that is a thing, if the program stated that the configs can do whatever, which at that point, is a script.

          Also if a config can do what ever, then most likely that’s a security vulnerability.