Announcement

Collapse
No announcement yet.

Systemd 244 Released With New Init System Features For Black Friday

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by LoneVVolf View Post
    Many reasons, but the main one is that systemd takes control away from local admins.
    Local admins don't usually have a weird-ass UEFI setup that requires them to override "automatically discovering and mounting root, /home and /srv partitions, as well as discovering and enabling swap partitions"

    Could you explain exactly what you were trying to do? What in this automount functionality was a problem for you?

    systemd.gpt-auto-generator is an example of a generator I don't need and don't want, but there's no mechanism to disable any generator.
    add systemd.gpt_auto=-1 and/or rd.systemd.gpt_auto=-1 to your kernel commandline parameters.
    https://www.freedesktop.org/software...generator.html
    "Those options take an optional boolean argument, and default to yes. The generator is enabled by default, and a negative value may be used to disable it. "
    Last edited by starshipeleven; 01 December 2019, 05:24 AM.

    Comment


    • #52
      Originally posted by LoneVVolf View Post
      I am somewhat paranoid according to friends, but not delusional or "have no clue" .
      Let us be the judge of that.

      Comment


      • #53
        Originally posted by starshipeleven View Post
        Local admins don't usually have a weird-ass UEFI setup that requires them to override "automatically discovering and mounting root, /home and /srv partitions, as well as discovering and enabling swap partitions"

        Could you explain exactly what you were trying to do? What in this automount functionality was a problem for you?

        add systemd.gpt_auto=-1 and/or rd.systemd.gpt_auto=-1 to your kernel commandline parameters.
        https://www.freedesktop.org/software...generator.html
        "Those options take an optional boolean argument, and default to yes. The generator is enabled by default, and a negative value may be used to disable it. "
        Also:

        Originally posted by systemd.generator(7)
        […]
        Generators found in directories listed earlier override the ones with the same name in directories lower in the list. A symlink to /dev/null or an empty file can be used to mask a generator, thereby preventing it from running.
        […]

        Comment


        • #54
          Originally posted by ermo View Post

          If you're a pragmatist, systemd has already won, since it was designed by pragmatists for pragmatists.

          For purists, the most common stance I've seen is that systemd as a concept is ok-ish, but that the implementation is *terrible*. The most common complaint is that systemd is stuffing too much functionality into PID 1. As a reminder, the kernel starts PID 1 after it finishes doing whatever it is kernels do to initialise system hardware etc. and PID 1 will then stay running until the point where the system is turned off/rebooted. If PID 1 crashes, it will take the whole system with it, so it stands to reason that it is a good idea to have PID 1 be as simple as possible (or so the argument goes). The other complaint I've seen is that systemd tends to absorb functionality that was traditionally separate from the init system and the service manager.
          Can you please explain/list all this "stuffing too much functionality into PID 1." and "The other complaint I've seen is that systemd tends to absorb functionality that was traditionally separate from the init system and the service manager."
          I think you are possibly confusing add-ons to the project which are totally optional and nothing to do with PID1 - but if you have examples of non-PID1 functionality in the init side of systemd, i'd be interested to know what they are.

          Comment


          • #55
            Originally posted by LoneVVolf View Post
            Many reasons, but the main one is that systemd takes control away from local admins.
            Control is only taken away from illiterates who can't be bothered to read the fucking manual.

            Originally posted by LoneVVolf View Post
            Code:
            man systemd.generator
            systemd.gpt-auto-generator is an example of a generator I don't need and don't want, but there's no mechanism to disable any generator.
            Yeah, really?

            systemd.generator(7):

            /run/systemd/system-generators/*
            /etc/systemd/system-generators/*
            /usr/local/lib/systemd/system-generators/*
            /usr/lib/systemd/system-generators/*
            <...>

            Generators found in directories listed earlier override the ones with the same name in directories lower in the list. A symlink to /dev/null or an empty file can be used to mask a generator, thereby preventing it from running.
            Truly, systemd is one of the most configurable pieces of software I've ever dealt with. Its configurability is only eclipsed by software with Turing-complete configuration.
            Last edited by intelfx; 01 December 2019, 08:48 AM.

            Comment


            • #56
              Paranoid: check
              Clueless: check
              Delusional: check

              Well, it seems I was spot on. Multiple solutions have been posted already, you could also simply remove the generators.

              Systemd absolutely does not take control away from admins. What it doesn't do though, is turning clueless people into competent people. If this was your reason for opposing systemd, you are indeed delusional.

              Comment


              • #57
                Originally posted by rtfazeberdee View Post

                Can you please explain/list all this "stuffing too much functionality into PID 1." and "The other complaint I've seen is that systemd tends to absorb functionality that was traditionally separate from the init system and the service manager."
                I think you are possibly confusing add-ons to the project which are totally optional and nothing to do with PID1 - but if you have examples of non-PID1 functionality in the init side of systemd, i'd be interested to know what they are.
                Kind of what I was wondering. It makes sense to me for the init process to be a service manager when the entire boot process is entirely managed through services. If the service manager was somehow separated from the init system in this case... what should the init system even do if the service manager crashed?
                If the concept was only "ok" and the implementation was "terrible"... What would be the correct implementation?

                Comment


                • #58
                  Originally posted by rtfazeberdee View Post

                  Can you please explain/list all this "stuffing too much functionality into PID 1." and "The other complaint I've seen is that systemd tends to absorb functionality that was traditionally separate from the init system and the service manager."
                  I think you are possibly confusing add-ons to the project which are totally optional and nothing to do with PID1 - but if you have examples of non-PID1 functionality in the init side of systemd, i'd be interested to know what they are.
                  I'm firmly in the pragmatist camp, which means I'm fine with systemd and happily use it on the Linux boxes I run.

                  The first two or three pages in this link should give you a decent exposé of the arguments against systemd that I referenced. Keep in mind that I merely stated that those were the two most common arguments against systemd I've seen -- not that I agreed with them. YMMV.
                  Last edited by ermo; 01 December 2019, 12:41 PM.

                  Comment


                  • #59
                    Originally posted by starshipeleven View Post
                    There is no punishment, just no fucks given.
                    Yeah, and that's the problem. Basic human psychology attitude shift: from underdog revolutionary to arrogant aristocracy

                    Originally posted by starshipeleven View Post
                    You shouldn't talk of things you don't know.
                    Maybe I simply know better. Even Poettering seems to happily state that systemd internal API's are not stable.

                    Originally posted by starshipeleven View Post
                    Your vision is wrong.
                    Slowlaris died long ago, Openindiana is a hobby OS, BSDs are on the way towards becoming hobby OS.
                    BSD is actually gaining users thanks to systemd and increasing bloat in general purpose distros.

                    Originally posted by starshipeleven View Post
                    Linux is progressing, and has active development going on in major areas, and plenty of butthurt people shit talking about it in forums.
                    Their terms are pretty good for most actual users and administrators.
                    Also SUSE's.
                    Even Canonical is more active and useful than all BSDs combined.
                    Considering that the only decent thing the GNU project maintains is the GCC, I don't see that as a bad thing.
                    More talking of things you have no idea of.
                    Is it "progressing" or "running in circles", "chasing it's tail" or "reinventing itself over and over"?

                    Originally posted by starshipeleven View Post
                    But I'm sure you have no idea of what GNU project does at all and you are just talking out of your ass about ideological stuff.
                    Lol. "Talking out of your ass about ideological stuff" coming from a guy (or girl?) who routinely calls Solaris "Slowlaris" and attacks relentlessly everyone who dare criticize systemd. I am still unsure if I am dealing with ideological conviction or religious.

                    Originally posted by starshipeleven View Post
                    Lol, you complain about the Linux community because there are a few heavy weights but most stuff works regardless of their whims and people can still enjoy all flavors of systems but you are ready to embrace a monolithic OS (it's exactly as monolithic as systemd) made exclusively by and for Google, because it's totally not going to push everything they want down your throat with 0 opposition just like Windows does, regardless of the license.
                    Those heavyweights cannot control the direction of development in BSD. That's the difference. Although most of them (excepting RHEL) are still contributors.

                    Originally posted by starshipeleven View Post
                    If you don't like it fork it.... lolololol. Except you can't outcompete Google with a handful of friends coding in weekends.
                    What a fucking joke you posted
                    From you mixing together "fork" and "Google" I am pretty sure you didn't even understand what I wrote. These two things weren't even closeby to eachother in my post, still you managed to mix them up. Drunk?

                    Comment


                    • #60
                      Originally posted by arokh View Post
                      Did debianxfce just reincarnate into this aht0 character? Like always, the only ones opposing systemd are paranoid, delusional and have absolutely no fucking clue.

                      Meanwhile, I just booted into systemd 244 and it's a delight. I can now decide in a service what CPUs it should run on, very practical.

                      PS: Screw these "minorities" everybody is suddenly talking about, they can all move to Devuan which seems like the right place for them.
                      Personal insults are primary reason I stopped being "Premium user" last month. No point supporting site who cradles such users. "When you lack arguments, just go toxic and call names."

                      Comment

                      Working...
                      X