Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

391–400 of 460 posts

Re: No more boot loader: Please use the kernel instead

#391
post #116

A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some more explicit criticism at https://lwn.net/Articles/981149/ and I think that's a much more interesting set of concerns.

I have to say I find Lennart's arguments quite unconvincing. As another person said, the vast majority of people just want default boot to the most recent kernel (which this proposal could do well). But then when it comes to the other points, yes I want to be able to reliably boot into other systems, but both systemd-boot and grub are notoriously bad at detecting other systems on disks (both use install-time detectio…

Not that it retracts from your argument but rEFInd can handle detecting bootable USBs afaik. It's just not enabled by default

Re: No more boot loader: Please use the kernel instead

#392
post #373

Earlier quoted context omitted.

He's saying the opposite: Host has integrated graphics, VM has dedicated GPU.

How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…

> and the g had an iGPU.

So you are contradicting yourself.

Re: No more boot loader: Please use the kernel instead

#393

It's something you can do since a lot of years. I used to do so 10 years ago, when I've got the first motherboard with UEFI. But is it useful? It saves a minimal time in the boot sequence, but at what cost? The bootloader (being it grub, or something more simple as systemd-boot) is useful to me for a couple of reasons: - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, yo…

> - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start Do people really dual boot a lot in 2024? It was a good use case when virtualization was slow but decades after the CPU started shipping with virtua…

I dual-boot on my personal desktop. I mostly use Debian, but there's a Windows partition for games and a few other Windows-specific things. The GPU in it was way too expensive to justify buying two, and I use it under Linux for ML, hash-cracking, etc.

My original plan was to do everything in a Windows VM, but there was too much of a performance hit for some of my purposes, and VMWare doesn't allow attaching physical disks or non-encrypted VMDKs to a Windows 11 VM, so it's actually easier to have a data drive that's accessible from both OSes with dual boot than it would be with a VM.[1] I'm still disappointed about that.

[1] Using HGFS to map a host path through to the VM is not an option because of how slow that is, especially when accessing large numbers of files.

Re: No more boot loader: Please use the kernel instead

#394
post #373

Earlier quoted context omitted.

He's saying the opposite: Host has integrated graphics, VM has dedicated GPU.

How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…

Most AM5 CPUs have integrated graphics. It's also quite common on Intel.

Re: No more boot loader: Please use the kernel instead

#395
I use whatever i want :P that's the nice thing about FOSS. I'll move on to the new cool hipster thing when I feel like it and if I see value in it..

Though generally I prefer the approach of "extend what we have with new features" over "rip out all out and start from scratch" so I spend my time mostly with the BSDs which don't jump full steam ahead into the whatever's the new thing.

Even though something like systemd is undoubtedly better in many things, I also have to wrap my head around it, see how to get at the logs, build those unit files etc. On the BSDs I don't have to bother with that and just keep working as I was and which was not broken for me.

The point is, something new doesn't only have to offer a tangible benefit for me to be worth it. It has to be such a big benefit for me that it offsets the hassle of getting my head around all the new stuff and most of the new Linux inventions fail at this.

Re: No more boot loader: Please use the kernel instead

#396
post #335

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…

EFI stub is an existing kernel feature, not related to systemd-boot. Of course, everything can be wired together with systemd.

but it doesn't cover any of the unmentionable features that are so bad on grub. they will either be implemented in the kennel or the stub, because well, people will need dual boot, weird crypto, etc.

exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?

Re: No more boot loader: Please use the kernel instead

#397

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…

systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather tha…

This seems like it could be a good use of rump kernels, although I don't think anyone has made a bootloader based on NetBSD rump yet. I've heard of efforts to rumpify Linux but I don't know if they are continuing. This seems like it could offer the benefits of each approach. The rump kernel paper has this brief paragraph on bootloaders:

> The lowest possible target for the rump kernel hypercall layer is firmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical firmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.

Re: No more boot loader: Please use the kernel instead

#398
post #266
post #118

Earlier quoted context omitted.

Does Windows not ensure that the UEFI boots back into Windows when it does an auto-reboot for updates? There's a UEFI variable called BootNext which Windows already knows how to use since the advanced startup options must be setting it to allow rebooting directly to the UEFI settings. Given that Windows tries to restore open windows to make it look like it didn't even reboot, I'm surprised they wouldn't make sure tha…

No, it doesn't. Even a sysprepped image of Windows (which thus runs Setup to install drivers and finalize the installation) doesn't change the boot order on UEFI machines. I think just the installer does this when you first install Windows.

That's so weird. Normally I don't want my OS changing what is booted into on a whim, but going back into the same OS for cases like these just seems like sane behavior to me.

Re: No more boot loader: Please use the kernel instead

#399
post #373

Earlier quoted context omitted.

How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…

> and the g had an iGPU. So you are contradicting yourself.

This is a fundamentally dishonest take. I provided three specific CPUs that varied by just the letter at the end where some had an iGPU and some didn't. I am being honest that some have it but that it isn't ubiquitous.

Re: No more boot loader: Please use the kernel instead

#400

relevant comments from Hector Martin over on Mastodon at https://social.treehouse.systems/@marcan/112754303893998372 > Reminder that not all platforms support or, indeed, can support kexec() sanely at all. Like ours. kexec() requires the ability to reset all peripheral state and that is impossible on Apple Silicon because firmware is loaded by earlier boot stages and cannot be re-loaded later to the reset state witho…

Sounds like Apple sorted itself out by themselves, while suffering from the limitation. So the correct response to this concern is "Okay. And? Apple will just sort itself out for themselves". I mean, what else can anyone do? Nothing because "but Apple?"

This discussion is about how to boot Linux, not how Apple's OSes do things on their devices. Booting Linux on a Macbook is the affected scenario.
Post reply on HN