Announcement

Collapse
No announcement yet.

systemd Lands SD-Boot, Its EFI Boot Manager & Stub Loader

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

  • #31
    Originally posted by edmon View Post
    it looks that devuan is getting in shape. soon we all will stop to care if systemd is integrated toilet sink in it.
    If Devuan decreases amount of anti-systemd trolls, I welcome it with open arms

    Comment


    • #32
      Originally posted by edmon View Post
      systemd is integrated toilet sink in it.
      But it's optional! You don't have to use it if you don't want to!

      Comment


      • #33
        Originally posted by steveriley View Post
        But it's optional! You don't have to use it if you don't want to!
        do you really believe that systemd is optional????

        Comment


        • #34
          What gets me with this whole systemd thing (although admittedly not having tried any of that software) is exactly what's being mentioned in this thread - fingers in too many pies. I don't understand why people rag on the guy so much for pulseaudio - it's not *that* bad, and it's just an audio server implementation. That's perfectly fine with me, and I run PA myself. It helps get audio out to our LTSP terminal (along with X forwarding that nobody wants to think about with wayland/etc).

          But the way systemd is turning into a monolithic project that handles more than just service startup is starting to get a little concerning. It's not as though our options are directly being taken away, but rather slowly degraded and made more difficult to use as more software expects the systemd stuff and workarounds are needed. I've got some major gripes with grub2 but at least it's not forced on me. Now they want to manage a security chain when booting the system? I don't get it - the kernel has to trust the bootloader because the bootloader can do whatever it wants. Likewise userspace has to trust the kernel. And all this crap has to trust whatever abomination is running in SMM or whatever they hide in the chipset/CPU these days.

          My point is, they shouldn't need to be involved with a bootloader, for that security aim, at all. If they wanted to take the angle of verifying integrity of services files before running them, that does kinda make sense to be part of an init system. And it would make sense to have this process start from a signed kernel/initrd, but again, signature checking the initrd only needs to happen - there's no reason that systemd has to have any say in HOW it's signature checked or even be associated at an organizational level.

          Comment


          • #35
            Originally posted by BradN View Post
            What gets me with this whole systemd thing (although admittedly not having tried any of that software) is exactly what's being mentioned in this thread - fingers in too many pies. I don't understand why people rag on the guy so much for pulseaudio - it's not *that* bad, and it's just an audio server implementation. That's perfectly fine with me, and I run PA myself. It helps get audio out to our LTSP terminal (along with X forwarding that nobody wants to think about with wayland/etc).

            But the way systemd is turning into a monolithic project that handles more than just service startup is starting to get a little concerning. It's not as though our options are directly being taken away, but rather slowly degraded and made more difficult to use as more software expects the systemd stuff and workarounds are needed. I've got some major gripes with grub2 but at least it's not forced on me. Now they want to manage a security chain when booting the system? I don't get it - the kernel has to trust the bootloader because the bootloader can do whatever it wants. Likewise userspace has to trust the kernel. And all this crap has to trust whatever abomination is running in SMM or whatever they hide in the chipset/CPU these days.

            My point is, they shouldn't need to be involved with a bootloader, for that security aim, at all. If they wanted to take the angle of verifying integrity of services files before running them, that does kinda make sense to be part of an init system. And it would make sense to have this process start from a signed kernel/initrd, but again, signature checking the initrd only needs to happen - there's no reason that systemd has to have any say in HOW it's signature checked or even be associated at an organizational level.
            Well, PA with its software mixing resulted in significantly higher CPU usage for us people who according to Poettering don't exist who had hardware mixing in their sound cards. Granted, it's no worse than Windows but Linux had clearly the most CPU-efficient sound stack assuming you bought the right card. I've since decided though that I may prefer the per-app volume control to near-zero CPU usage during playback

            Comment


            • #36
              All hail systemd.

              At some point companies are going to quit f**king around and actually make Linux a first class citizen. Systemd is a step in that direction. Along with GL-Next.

              If you have a problem with systemd then fix it yourself and submit a patch or just use PClinuxOS.

              Comment


              • #37
                Originally posted by BradN View Post
                What gets me with this whole systemd thing (although admittedly not having tried any of that software) is exactly what's being mentioned in this thread - fingers in too many pies. I don't understand why people rag on the guy so much for pulseaudio - it's not *that* bad, and it's just an audio server implementation. That's perfectly fine with me, and I run PA myself. It helps get audio out to our LTSP terminal (along with X forwarding that nobody wants to think about with wayland/etc).

                But the way systemd is turning into a monolithic project that handles more than just service startup is starting to get a little concerning. It's not as though our options are directly being taken away, but rather slowly degraded and made more difficult to use as more software expects the systemd stuff and workarounds are needed. I've got some major gripes with grub2 but at least it's not forced on me. Now they want to manage a security chain when booting the system? I don't get it - the kernel has to trust the bootloader because the bootloader can do whatever it wants. Likewise userspace has to trust the kernel. And all this crap has to trust whatever abomination is running in SMM or whatever they hide in the chipset/CPU these days.

                My point is, they shouldn't need to be involved with a bootloader, for that security aim, at all. If they wanted to take the angle of verifying integrity of services files before running them, that does kinda make sense to be part of an init system. And it would make sense to have this process start from a signed kernel/initrd, but again, signature checking the initrd only needs to happen - there's no reason that systemd has to have any say in HOW it's signature checked or even be associated at an organizational level.
                systemd isn't just an init system, it's a common base OS layer, that's at what? 70+ binaries now? with a service manager that just so happens to also be called systemd. Effectively the systemd project is shifting Linux over to a more BSD style of development under its umbrella for better or worse. The only reason there's lock-in at all is because the non-systemd crowd apparently isn't large enough to have enough developers to create/maintain alternatives to the interfaces that systemd provides that desktops are moving to rely upon because the old ones were crappy and are now unmaintained (namely logind replacing consolekit), and the current efforts on anything at all along those lines are effectively a result of the BSDs.

                Comment


                • #38
                  Originally posted by nanonyme View Post
                  Well, PA with its software mixing resulted in significantly higher CPU usage for us people who according to Poettering don't exist who had hardware mixing in their sound cards. Granted, it's no worse than Windows but Linux had clearly the most CPU-efficient sound stack assuming you bought the right card. I've since decided though that I may prefer the per-app volume control to near-zero CPU usage during playback
                  Have you tried OSSv4? Low cpu + per-app volume control.

                  Comment


                  • #39
                    If you use a system without PA then you can have got lots of extra problems for new apps like Steam which require the functionality. Why on earth would you toy around with something else? To gain 1% cpu or what?

                    Comment


                    • #40
                      Originally posted by Kano View Post
                      If you use a system without PA then you can have got lots of extra problems for new apps like Steam which require the functionality. Why on earth would you toy around with something else? To gain 1% cpu or what?
                      To return to interface chaos (which is labeled freedom), before PA happened, that is.

                      Comment

                      Working...
                      X