Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.
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.
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/boot...
[1] https://github.com/systemd/systemd/tree/master/src/basic
[2] https://github.com/systemd/systemd/tree/master/src/libsystem...
[3] https://github.com/systemd/systemd/tree/master/src/shared
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:
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.
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.
Isn't this impossible with bitlocker?