Lennart Talks Up systemd's SD-Boot + Boot Loader Specification

[skeevy420]

They all should contribute to Lilo

IMHO, you just won the thread.

I don't know what that's so freaking funny, but it just is and I can't stop laughing.

[frank007]

IMHO, you just won the thread.

I don't know what that's so freaking funny, but it just is and I can't stop laughing.

They all are so tired of their wallpaper that want always something new.

[Britoid]

Why doesn’t Lennart contribute improvements to Grub? It is already so much more featureful and has been tested in the field with actual hardware for 24+ years? Making yet another boot loader is going to increase the maintenance burden and splits/dilutes the developer effort and bug tracking capacity of users in the future, similar to when Lilo was actively maintained.

Most of GRUBs functionality is made redundant by the EFI Firmware. GRUB afaik isn't even a native EFI bootmanager, requiring a shim to load it.

In the future, I don't see it being the default anymore outside of MBR installs. I would also imagine dropping MBR support is probably next after dropping 32bit images.

[Terrablit]

Just popping in to mention that MBR is a partitioning structure and not a firmware implementation. So on on axis, you've got BIOS vs EFI, and on the other, you've got MBR vs GPT. They are different, but sometimes people get them confused, because GPT is included in the EFI specification, and a lot of legacy BIOS implementations can't boot from GPT.

Let's try to not get sloppy and conflate the two.

[skeevy420]

Just popping in to mention that MBR is a partitioning structure and not a firmware implementation. So on on axis, you've got BIOS vs EFI, and on the other, you've got MBR vs GPT. They are different, but sometimes people get them confused, because GPT is included in the EFI specification, and a lot of legacy BIOS implementations can't boot from GPT.

Let's try to not get sloppy and conflate the two.

Took the words right out of my mouth....wait...off of my fingers

[stan]

They should contribute to the same code base, whichever happens to have the best tested hardware compatibility and track record, so as to build on other people’s hard work and not let it go to waste. Right now that boot loader is GRUB. If LILO has won out back in the day, then I would say contribute to LILO. If systemd-boot had 24+ of use and was known to work well, I would say contribute to systemd- boot. Just look at the mess that Yaboot left behind. It’s now unmaintained, and the transition to Grub is extremely painful for Linux distros on PowerPC hardware. In fact, Debian PPC has tried to switch over to Grub for 3 years and it still doesn’t work well. If the Yaboot developers had just contributed all their efforts to Grub to begin with, we would now have a bootable and working Debian PPC image. When you split and dilute developer effor, you get multiple half decent projects instead of one great one.

[milkylainen]

let the haters start their parade

Depends on what shit you're using.
From this side it looks more like this to me:
"Here comes the snakeoil peddlers... One remedy to cure all."

Does ring a bell, doesn't it?

[stan]

Most of GRUBs functionality is made redundant by the EFI Firmware. GRUB afaik isn't even a native EFI bootmanager, requiring a shim to load it.

In the future, I don't see it being the default anymore outside of MBR installs. I would also imagine dropping MBR support is probably next after dropping 32bit images.

You mean GRUB functionality like native native ATA and USB support to have available as a backup when buggy EFI implementations can't read your hard drive or USB drive? How about in a couple of years when EFI is replaced by the next great firmware, ModernFW. Will you want to throw away all the previous work and start a new bootloader that works for this and only this?

Also, I thought RedHat, which has now been bought by IBM, is going to try to work better on PPC like RaptorCS motherboards. Will they make a bootloader just for PPC (after all, systemd-boot just works for EFI), so that they can have the pleasure of maintaining yet another architecture-specific bootloader? BTW, GRUB already works on RaptorCS boards.

[Britoid]

You mean GRUB functionality like native native ATA and USB support to have available as a backup when buggy EFI implementations can't read your hard drive or USB drive? How about in a couple of years when EFI is replaced by the next great firmware, ModernFW. Will you want to throw away all the previous work and start a new bootloader that works for this and only this?

Also, I thought RedHat, which has now been bought by IBM, is going to try to work better on PPC like RaptorCS motherboards. Will they make a bootloader just for PPC (after all, systemd-boot just works for EFI), so that they can have the pleasure of maintaining yet another architecture-specific bootloader? BTW, GRUB already works on RaptorCS boards.

This makes zero sense. ModernFW provides a UEFI interface, so it's unrelated. UEFI isn't a firmware, it's an interface. Actually, ModernFW itself is based on TianoCore.

Modern PowerPC implementations also provide a UEFI interface (infact Fedora on 64bit ARM uses UEFI), so there doesn't need to be a specific boot manager. sd-boot "should" work there too.

You're confusing boot loaders and boot managers.

[kaprikawn]

Lennart gets a lot of criticism, most of it warranted because he's a particularly prickly guy. But he seems to hate Grub with a passion, and that makes him ok in my book.

Why doesn’t Lennart contribute improvements to Grub? It is already so much more featureful and has been tested in the field with actual hardware for 24+ years? Making yet another boot loader is going to increase the maintenance burden and splits/dilutes the developer effort and bug tracking capacity of users in the future, similar to when Lilo was actively maintained.

He addressed that in the video :
1) He has contributed to Grub, they didn't accept his patches.
2) Grub is a steaming pile of crap, it really is truly awful. It's massively overcomplicates something that really needs to be simple. Scripts that create other scripts which in turn creates something that Grub loads vs a couple of simple config files.

Systemd-boot is way better than Grub. I know Grub can load some configs that systemd-boot cannot, and if you're in that situation and want/need to use Grub then fair enough. But I'm much happier now I don't have to use Grub, it really is the worst.