Originally posted by edmon
View Post
Announcement
Collapse
No announcement yet.
systemd Lands SD-Boot, Its EFI Boot Manager & Stub Loader
Collapse
X
-
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
-
Originally posted by BradN View PostWhat 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
-
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
-
Originally posted by BradN View PostWhat 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
-
Originally posted by nanonyme View PostWell, 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
-
Originally posted by Kano View PostIf 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
Comment