• SavvyWolf@pawb.socialEnglish
    12710·
    12 days ago

    “I hate systemd, it’s bloated and overengineered” people stay, perched precariously on their huge tower of shell scripts and cron jobs.

    • Damage@feddit.it
      493·
      12 days ago

      huge tower of shell scripts and cron jobs.

      That’s bloat. I start all my services manually according to my needs. Why start cupsd BEFORE I need to print anything?

    • corsicanguppy@lemmy.caEnglish
      317·
      12 days ago

      “I hate systemd, it’s bloated and overengineered”

      And built poorly by people who don’t work well with others and then payola’ed onto the world.

      people stay, perched precariously on their huge tower of shell scripts and cron jobs.

      Fucking UNIX is shell scripts and cron jobs, skippy. Add xinetd and you’re done.

      • HubertManne@moist.catsweat.com
        71·
        11 days ago

        yeah I just hate the move away from flat text files honestly. Its one thing I did not like about windows NT with the registry. databasing up the config.

        • Laser@feddit.org
          62·
          11 days ago

          Which part of systemd’s config is not text-based? The only “database” it uses for configuration is the filesystem

          • HubertManne@moist.catsweat.com
            31·
            11 days ago

            well its text but its just a bit more complex of a flat file. like yaml. like one thing I really liked about cisco ios was how the config file the commands where pretty much the same thing. granted thats not unix but its the simplicity level that is ideal to me.

    • barsquid@lemmy.world
      192·
      11 days ago

      If systemd was only managing services there would be less opposition. People opposed don’t want a single thing doing services and boot and user login and network management and…

        • barsquid@lemmy.world
          112·
          11 days ago

          IDK, ask them. There are some in this thread. I’m addressing the strawman argument that people against it are luddites set in their ways over their beloved cron jobs.

    • azertyfun@sh.itjust.works
      82·
      11 days ago

      Wait until you learn about debhelper.

      If you use a debian-based system, unless you have actively looked at the DH source, the one thing that built virtually every package on your system, you do not get to say anything about “bloat” or “KISS”.

      DH is a monstrous pile of perl scripts, only partially documented, with a core design that revolves around a spaghetti of complex defaults, unique syntax, and enough surprising side effects and crazy heuristics to spook even the most grizzled greybeards. The number of times I’ve had to look at the DH perl source to understand a (badly/un)documented behavior while packaging something is not insignificant.

      But when we replaced a bazillion bash scripts with a (admittedly opinionated but also stable and well documented) daemon suddenly the greybeards acted like Debian was going to collapse under the weight of its own complexity.

      • wax@feddit.nu
        3·
        11 days ago

        Oh yes, fuck dh with a rusty pole. I’ve had to paclage some stuff at work, and it’s a nightmare. I love having to relearn everything on new compat levels. But the main problem is the lack of documentation and simple guidelines

  • rtxn@lemmy.worldMEnglish
    372·
    12 days ago
    [     *] (3 of 3) A stop job is running for User Manager for UID 1000... (1m12s / 3m)
    • renzev@lemmy.worldOPEnglish
      14·
      12 days ago

      I’m more of a runit guy, but I started using Alpine recently, and I have to say, openrc is also pretty nice!

      • msage@programming.dev
        15·
        12 days ago

        What “scares” me the most is the journal… for some reason it takes too long to get specific unit logs, and should anything break down in it, there is no way for me to fix it. Like logging has been solved forever, and I prefer specific unit logs to the abomination of journalctl.

        But like unit files are everywhere, and systemctl at its core is a nice cmd utility.

        • Possibly linux@lemmy.zipEnglish
          5·
          11 days ago

          The thing with journalctl is that it is a database. Thus means that searching and finding things can be fast and easy in high complexity cases but it can also stall in cases with very high resource usage.

          • jj4211@lemmy.world
            9·
            11 days ago

            Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.

            • Possibly linux@lemmy.zipEnglish
              45·
              11 days ago

              Plain text is slow and cumbersome for large amounts of logs. It would of had a decent performance penalty for little value add.

              If you like text you can pipe journalctl

              • msage@programming.dev
                3·
                11 days ago

                But if journalctl is slow, piping is not helping.

                We have only one week of very sparse logs in it, yet it takes several seconds… greping tens of gigabytes of logs can be sometimes faster. That is insane.

              • jj4211@lemmy.world
                1·
                11 days ago

                As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.

          • msage@programming.dev
            3·
            11 days ago

            But why?

            I just can’t grasp why such elementary things need to be so fancied up.

            It’s not like we don’t have databases and use them for relevant data. But this isn’t it.

            And databases with hundreds of milions of rows are faster than journalctl (in my experience on the same hardware).

  • cley_faye@lemmy.world
    51·
    11 days ago

    systemd, as a service manager, is decent. Not necessarily a huge improvement for most use cases.

    systemd, the feature creep that decides to pull every single possible use case into itself to manage everything in one place, with qwirks because making a “generic, do everything” piece of software is not a good idea, is not that great.

    systemd, the group of tools that decided to manage everything by rewriting everything from scratch and suffering from the same issue that were fixed decades ago, just because “we can do better” while changing all well known interfaces and causing a schism with either double workload or dropping support for half the landscape from other software developer is really stupid.

    If half the energy that got spent in the “systemd” ecosystem was spent in existing projects and solutions that already addressed these same issues, it’s likely we’d be in a far better place. Alas, it’s a new ecosystem, so we spend a lot of energy getting to the same point we were before. And it’s likely that when we get close to that, something new will show up and start the cycle again.

    • lightsblinken@lemmy.world
      2·
      11 days ago

      agree. i find the dns resolver in particular a dumpster fire of shitfuckery. name resolution was shitty, but a solution based on wrapper is just ugh.

    • platypus_plumba@lemmy.world
      1·
      9 days ago

      Learning how Systemd manages the network was a total mindfuck. There are so many alternatives, all of them being used differently by different tools, partially supported. networkd, Network Manager… There were other tools, they shared similar files but had them in different /etc or /usr folders. There were unexpected interactions between the tools… Oh man, it was so bad. I was very disappointed.

      I was really into learning how things really worked in Linux and this was a slap to my face because my mindset was “Linux is so straightforward”. No, it is not, it is actually a mess like most systems. I know this isn’t a “Linux” issue, I’m just ranting about this specific ecosystem.