6 ms·

Do we really need even more stuff delegated to systemd? What's wrong with grub?

gmueckl 7y ago
The only thing wrong with grub is that it allows you to boot almost anything, it seems. For normal people, that is its greatest feature.
fsh 7y ago
Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.
- imglorp 7y ago
  Maybe it stick with the gummiboot name instead of inciting that other riot.
- Izkata 7y ago
  In that case, why was it merged in at all?
  - pengaru 7y ago
    Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
    - ghostpepper 7y ago
      Are there actually a lot of shared components between systemd (the init system), systemd-boot, and systemd-(everything else in systemd)?
      - pengaru 7y ago
        I haven't audited systemd-boot specifically but just look at bootctl.c's "" includes [0], those come from the systemd source tree, and very little is in the src/boot/ subdir. Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel. Poke around [1] [2] [3] for some idea of what's there. [0] https://github.com/systemd/systemd/blob/master/src/boot/bootctl.c#L15 https://github.com/systemd/systemd/blob/master/src/boot/boot... [1] https://github.com/systemd/systemd/tree/master/src/basic https://github.com/systemd/systemd/tree/master/src/basic [2] https://github.com/systemd/systemd/tree/master/src/libsystemd https://github.com/systemd/systemd/tree/master/src/libsystem... [3] https://github.com/systemd/systemd/tree/master/src/shared https://github.com/systemd/systemd/tree/master/src/shared
    - danellis 7y ago
      Which components are shared between userland and the UEFI environment?
      - qqssccfftt 7y ago
        Whatever magic is powering the ability to just run ``systemctl kexec`` and have it automatically reboot into the same kernel you selected at boot without going through UEFI again.
        yjftsjthsd-h 7y ago
        kexec works fine if you invoke it directly and tell it what kernel+initrd to use, regardless of bootloader; if anything, I'd consider it a failing that systemd can't manage to control a kexec without controlling the bootloader as well
      - pengaru 7y ago
        I don't really understand what you're asking. Edit: Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want: https://github.com/systemd/systemd/tree/master/src/boot/efi https://github.com/systemd/systemd/tree/master/src/boot/efi
    - AnthonyMouse 7y ago
      > Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? I think this is the exact reason why the people who hate it, hate it. You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours. Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do. > It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general. That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change. In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative. Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
    - Brian_K_White 7y ago
      You can't describe all this tight-coupling, and at the same time still claim it's fully separate.
  - sedatk 7y ago
    I think systemd will eventually become a standalone operating system.
    - BenjiWiebe 7y ago
      I'd run it.
  - inshadows 7y ago
    So that Lennart gets commit rights and veto power, obviously.
  - nickik 7y ago
    Why is BSD one project? Sometimes people like to put lots of software in the same repo.
- BasicObject 7y ago
  So you're saying I can pull an SSD with a working Windows 10 installation from another computer and plug it into a GNU/Linux system running systemd-boot and it will boot Windows 10? (Ignoring any potential driver issues that may arise from the difference in hardware and [most likely] violating the Microsoft EULA)
  - osamagirl69 7y ago
    I am not sure why you would want to start with an install of windows from a different machine, but yes booting to a different hard drive has been supported for a long time. You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
    - yrro 7y ago
      > You just chainload to the windows boot manager on the other disk Isn't this impossible with bitlocker?
e12e 7y ago
Clearly this is a change of pace, though. While adding a bootloader to your init/RPC message bus/syslog/cron-system might add a bit of bloat to that lean (modular) megolith - this here is presumably more about adding init into your bootloader - which probably will add quite a bit of bloat and unwanted tight coupling... Hm, is it still April 1st?
coribuci 7y ago
> Do we really need even more stuff delegated to systemd? What's wrong with grub? It's a standalone program. I'm looking forward for systemd-x11. I think in the future we will get rid of GNU/Linux. We will have systemd-linux.
- lainga 7y ago
  perfect for systemd-hurd. the microkernel does barely anything, it's all delegated to systemd
voldacar 7y ago
soon linux will be systemd-kernel
- nickik 7y ago
  What an original joke. Congratulation.
  - voldacar 7y ago
    cope
    - nickik 7y ago
      I will if you shut up
wayx 7y ago
I share the systemd concerns, but grub is too large and complex for many people. The first Linux distro I used still had LILO when it was being phased out. I felt that I mastered LILO in a very short time. I've never had that feeling with grub, which is a small OS with slightly chaotic config files spread out over many directories. I found it easier to set up a direct EFIstub boot than reinstall grub via live CD when my BIOS somehow had broken the Debian install.
- yjftsjthsd-h 7y ago
  I liked the old grub, personally; it, too, felt like a system that you could actually wrap your head around. While grub2 is probably more capable and better supported in terms of hooking into the system (since it's meant to regenerate the config out of scripts every time it needs to be configured), I personally moved on to syslinux, which is very much like the old grub was, albeit more capable.

The only thing wrong with grub is that it allows you to boot almost anything, it seems. For normal people, that is its greatest feature.

fsh 7y ago

Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.

imglorp 7y ago
Maybe it stick with the gummiboot name instead of inciting that other riot.
Izkata 7y ago
In that case, why was it merged in at all?
- pengaru 7y ago
  Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
  - ghostpepper 7y ago
    Are there actually a lot of shared components between systemd (the init system), systemd-boot, and systemd-(everything else in systemd)?
    - pengaru 7y ago
      I haven't audited systemd-boot specifically but just look at bootctl.c's "" includes [0], those come from the systemd source tree, and very little is in the src/boot/ subdir. Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel. Poke around [1] [2] [3] for some idea of what's there. [0] https://github.com/systemd/systemd/blob/master/src/boot/bootctl.c#L15 https://github.com/systemd/systemd/blob/master/src/boot/boot... [1] https://github.com/systemd/systemd/tree/master/src/basic https://github.com/systemd/systemd/tree/master/src/basic [2] https://github.com/systemd/systemd/tree/master/src/libsystemd https://github.com/systemd/systemd/tree/master/src/libsystem... [3] https://github.com/systemd/systemd/tree/master/src/shared https://github.com/systemd/systemd/tree/master/src/shared
  - danellis 7y ago
    Which components are shared between userland and the UEFI environment?
    - qqssccfftt 7y ago
      Whatever magic is powering the ability to just run ``systemctl kexec`` and have it automatically reboot into the same kernel you selected at boot without going through UEFI again.
      - yjftsjthsd-h 7y ago
        kexec works fine if you invoke it directly and tell it what kernel+initrd to use, regardless of bootloader; if anything, I'd consider it a failing that systemd can't manage to control a kexec without controlling the bootloader as well
    - pengaru 7y ago
      I don't really understand what you're asking. Edit: Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want: https://github.com/systemd/systemd/tree/master/src/boot/efi https://github.com/systemd/systemd/tree/master/src/boot/efi
  - AnthonyMouse 7y ago
    > Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? I think this is the exact reason why the people who hate it, hate it. You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours. Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do. > It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general. That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change. In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative. Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
  - Brian_K_White 7y ago
    You can't describe all this tight-coupling, and at the same time still claim it's fully separate.
- sedatk 7y ago
  I think systemd will eventually become a standalone operating system.
  - BenjiWiebe 7y ago
    I'd run it.
- inshadows 7y ago
  So that Lennart gets commit rights and veto power, obviously.
- nickik 7y ago
  Why is BSD one project? Sometimes people like to put lots of software in the same repo.
BasicObject 7y ago
So you're saying I can pull an SSD with a working Windows 10 installation from another computer and plug it into a GNU/Linux system running systemd-boot and it will boot Windows 10? (Ignoring any potential driver issues that may arise from the difference in hardware and [most likely] violating the Microsoft EULA)
- osamagirl69 7y ago
  I am not sure why you would want to start with an install of windows from a different machine, but yes booting to a different hard drive has been supported for a long time. You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
  - yrro 7y ago
    > You just chainload to the windows boot manager on the other disk Isn't this impossible with bitlocker?

e12e 7y ago

Clearly this is a change of pace, though. While adding a bootloader to your init/RPC message bus/syslog/cron-system might add a bit of bloat to that lean (modular) megolith - this here is presumably more about adding init into your bootloader - which probably will add quite a bit of bloat and unwanted tight coupling... Hm, is it still April 1st?

coribuci 7y ago

> Do we really need even more stuff delegated to systemd? What's wrong with grub? It's a standalone program. I'm looking forward for systemd-x11. I think in the future we will get rid of GNU/Linux. We will have systemd-linux.

lainga 7y ago
perfect for systemd-hurd. the microkernel does barely anything, it's all delegated to systemd

voldacar 7y ago

soon linux will be systemd-kernel

nickik 7y ago
What an original joke. Congratulation.
- voldacar 7y ago
  cope
  - nickik 7y ago
    I will if you shut up

wayx 7y ago

I share the systemd concerns, but grub is too large and complex for many people. The first Linux distro I used still had LILO when it was being phased out. I felt that I mastered LILO in a very short time. I've never had that feeling with grub, which is a small OS with slightly chaotic config files spread out over many directories. I found it easier to set up a direct EFIstub boot than reinstall grub via live CD when my BIOS somehow had broken the Debian install.

yjftsjthsd-h 7y ago
I liked the old grub, personally; it, too, felt like a system that you could actually wrap your head around. While grub2 is probably more capable and better supported in terms of hooking into the system (since it's meant to regenerate the config out of scripts every time it needs to be configured), I personally moved on to syslinux, which is very much like the old grub was, albeit more capable.