I studied computers at college in the 90's and it was 99% os side and 1% of hardware abstraction(x86 ) , recently i got into hacking arm cortex devices and one of the first things i had to learn to write was a boot loader for diagnostics , then i got into bigger device like mips , arm v8 etc and all need a form of u-boot/bootloader which gives the system a fail over option, since then I've been writing bare metal code and love it!
Hi Dj Ware , your knowledge is unique coz you know the history , saw the history and the most importantly you able to explain complex subjects in simple terms. Out of all Yt Linux channels your is my favorite. I wish if u could continue to making this videos. Thanks you.
Another great video DJ but I'ma hafta stick with my good ole bootloader. In programming, I've learned that patience isn't optional, its required, thus waiting for Grub to post and boot....meh no biggie. Also this being fairly new on the scene, I imagine someone like John Hammond would have an exploit for it over a weekend ... More risk than worth in ny humble non-biased opinion. 🤘🏼👦🏻
Since many years i use rEFInd on all my machines and let refind pick the efi executable kernel directly from the root filesystem. This is since i transfer my customised linux setups via partition images to other machines without the need for recreating grub/systemd. Thats very comfortable, so i think they should mix nmbl with refind as the boot manager. Perfect!
As I recall, the forth interpreter existed in all of the SUN PROMs, even the low end workstations, at least after the UltraSPARC transition. I can’t remember about the machines before that. However, to your point, the POST on those machines reached out to firmware in the actual expansion cards so what you could do in the forth interpreter in terms of diagnostics and configuration did depend on what the cards supported in their firmware and the cards intended for servers tended to have fancier firmware, as I recall. Not something I’ve thought about in 20 years, so my memory is a bit fuzzy now.
You know what? I had exactly this question when I learned linux, and guess what? I couldn't believe the answer when I read EVERYWHERE that it's just "POST, then BIOS, then LILO, then kernel" and 3 out of 4 had explanations, but not LILO, and being autistic, I could never put a checkmark there. But now I can, thank you SO MUCH!!! It very well may be that after the current wave of newcomers has subsided, in 20-30 years, we would have ended up with a 10 million strong corpus on solving Knapsack 0/1 LeetCode problem, but there would not be any explanation for bootloaders, leaving us in a state of "church of science" Azimov style, cargo culters implementing bootloader "because it's in the scriptures". But now, now there's hope there is this video in the corpus, and a young acolyte can question the dogmas to kick start renaissance. Anyway, jokes aside, thank you so very much for this gem :)
She was 100% correct in her explanation of the term "bootstrap". It does indeed come from the old saying "to pull one's self up by the bootstraps", and when used in the context of software just refers to a self-starting process.
@@CyberGizmo Well, I think your response in general is a characature of her presentation, as if she doesn't know anything at all about the things you talked about. And it really seemed like you were laughing in her face as if she doesn't know what she's talking about. Pretty much every point you mentioned was addressed in either her presentation or blog post. For example, with the kexec path, you can load a different kernel, and there's always a fallback. She's well aware this is not a new idea. Perhaps the main goal of nmbl is to make the boot process more secure, and really this is the first iteration of that idea that she acknowledged needs refinement and welcomed feedback. Some of the main points that you didn't address are the security vulnerabilities with GRUB, ease of code maintenance, because at the moment kernel and bootloader code are duplicated, and increased security scrutiny because there is far more security scrutiny on the kernel than bootloaders.
Love the shirt DJ! Yes I'm still doing some research there. Like anyone who likes to run _different_ operating systems and system architectures, I appreciate having one standard bootloader everywhere. I've unhosed systems from just the grub prompt way too many times. People who don't like waiting for the bootloader can already configure it not to wait, or use the EFI entrypoint, or even coreboot. If I were worried about boot time, I'd try to move the DRAM training out of the firmware and into the kernel, where it can be done in parallel with other boot tasks. Oh! Also, sometimes the newest kernel just won't boot. Having the option to run the last working kernel is very helpful. More options for booting the kernel is great, though, especially for those firecracker-style VMs.
I like your take on this and you absolutely give very valid points. Especially given the history of it all. But I must admit I think we should always have a critical eye on legacy systems/software/solutions. Just because it was a good idea 40 years ago, and has been a good idea for 40 years since, does not mean it's still the most optimal solution. So I definitely root for nmbl in that regard. Time will tell if it really is better, or not.
It's interesting. It'd be nice to be able to rice something more completely. Right now I'm working on a star trek LCARS theme for grub 2. There are sore points I've noticed. No animation or high fidelity audio.
I started looking at booting direct to kernel at one time, and mostly I think the loader need to stay because it enables update images to be applied and reverted such as in android bootloader, it would be preferable to boot into like syslinux system so you have a lot of flexibility and then hand off the boot to a different kernel chromeos flex has a interesting way of doing that, and can have a lot of benefits. Coreboot, Libreboot are also great options, and both allow booting directly into the kernel, the kernel params I think are becoming more unbound, I think it is awesome you could put your kernel directly in the bios memory, and boot quickly however it was like interest somewhere when I wanted the fastest cold boot time without using any sore of sleep or hibernate.
Good morning DJ. I have been watching this with curiosity. Thanks for covering it. I still have questions as to how they would manage snapshots and such. I just don't see the need for any of this.
Me either and EFI boot already took out a step from the old BIOS based one so now there are 3 steps to boot into the kernel...that is probably adding a second maybe 2 to the boot time, I can live with that. And Good Morning, Act!
11:36 Bootstrap Abstraction I am not sure if each CPU has its own bootstrap sequence. I assume that after the power is on (at the processor level) the processor just jumps to a memory address to execute codes.
One of My Arm machines uses Uboot and it is very different from how an X86 boots using BIOS/EFI: Odroid N2+ wiki.odroid.com/odroid-c4/software/boot_sequence#:~:text=Boot%20sequence-,Stage%20%231:%20Power%20cycle,to%20figure%20out%20the%20location.&text=The%20bootloader%20in%20the%20eMMC,does%20not%20have%20the%20bootloader.
@@CyberGizmo I beg apology for my poor English and my poor Logic. My points were that after power-on, any CPU initializes itself and begins execution of the vector memory. The final objective is to load the Operating System. Therefore, I wondered why the boot sequence must differ between Intel and Arm-based systems.
Well then tell me how I can use an encrypted disk with UEFI, because everytime I try it, I have to leave the UEFI partitions wide open and that is a non-starter for me
my solution would be boot a minimalist initramfs and then decrypt the drive, that's a really good option if you ask me, you don't expose anything important
There is a talk by that Bryan guy, an engineer who was in Sun back in the day. He argued against bootloaders. But it was quite technical and the topic is very low on the stack. Went over my head. He also said computers are very complicated, and that he still faced difficulty learning all about them despite the decades, or something to that effect. Well if he faces difficulty what chance do I have?
You shouldn't have to worry about it, unless you have a screw loose like I do and actually did the manual one line at a time program load ONCE, and never wanted to do it again :)
Yea, it is a good idea. The boot strap does not need to wait to see if you are going to boot another operating system, you selected it, and you can hit a selection key beforehand in any case to override it. Linux itself has several stages to the boot process, none of which are really required. It could perform all of its configuration beforehand and write a simple binary image of the result to disk and then just load that during boot. With all the speed increases for modern disk media, the system could come up in just a few seconds.
@@ducky1681consider the time wasted learning nmbl's extraction of your login for your distro if you forget it....accessing libraries from boot....things easily mitigated via Grub's bootloader rn. I mean I don't see any enormous benefit. If your too impatient to even wait for a bootloader, my guy, your in the wrong field, this I assure you. 😅
Just wait until that person who wants this gets to troubleshoot a driver issue and cant figure out what is causing it, then spends 8 hours before they give up.
I use ukis and entries into uefi for all my machines. Arguably, systems that need the functionality and redundancy of a bootloader can and will use one, but for end users who wont be spending any time at all debugging anything, it doesnt seem necessary.
I can understand the need for faster makeup from sleep on laptops, but that lag often lies in the bios speed. I hardly ever boot my workstation so boot times arent something i see that often
Pre-x86 computers’ ROM had enough code to start up the OS on supported media; or had the OS in ROM itself, think 8-bit basic machines. The x86 ROM never had this, for whatever reason, so the boot loader was needed to compensate for that missing functionality. I’m partial to Sun/Mac forth boot but that’s an side effect of growing up on Sun’s. TRS-80 had code in ROM for disk boot, as did Apple “C600G”, Mac, Amiga, ST, etc. UEFI should really be able to directly boot to kernel at this point and skip the whole boot loader nonsense. If a Rpi can do it, x86 should be able to.
Systemd-boot is taking over on the corporate side of Linux usage now because GRUB didn't want to support decrypting luks2 encrypted drives. systemd-boot did and is now the de-facto for anything laptop related from corporates.
@@polinskitom2277 that's true unfortunately. grub is on Death's door with Debian, Arch, and Fedora really wanting to switch away from it as it's too much of a hassle to troubleshoot (especially with the "bootloop to system firmware" problem still affecting machines here and there on random)
Of the list of issues nmbl tries to address based on the Fedora blog post, I consider speed the least interesting one. How often does one actually power up or reboot a machine, and how much does a faster boot time matter? That would surely depend on individual use cases. In the areas I work in, it doesn't matter at all. Critical systems are spread across multiple servers, possibly multiple locations around the globe, and it doesn't matter to me if rebooting individual machines requires an extra minute. Also, I will take reliability over raw speed any day of the week, but that may be just me.
Can you please explain how Grub works .. I think its very restrictive and i dont really understand always end up permanently blocking space on HDD .. cant clean it cant use it
I always liked how Mac system did it till I think system 9. You could format a disk with a certain flag set and file copy a system folder over to it and and it was pretty much bootible. You told finder to look at that disk and it would check the disk and say yep, do you want to boot from it.
I can boot Unified Kernel Image on archlinux just fine. And it's fast. But don't replace the bootloader with this, two seconds of less boot time but no way to troubleshoot if anything goes wrong for the average user.
couldn't i just use a USB bootloader when I need it? I mean I don't carry my screwdriver and wrench with me everywhere I go. Just for when I need it. O-O
@@PragandSens Yeah, in effect you can always do that. What I mean is the boot menu should be there by default and optionally removable. And I mentioned average Joe who might not be knowing anything about grub or and other bootloader.
What about dual boots or more.. let's say I have multiple os-es I want to boot into. I am a total noob, so I don't know how that would work. But I rather have a grub bootloader, if only for dual booting or triple booting, etcetera. I mean I know how to do that with Grub, but not with nmbl.
Once a long time ago I had a week long class on the IBM mainframe boot sequence. Since at that time I could read the hex for the CPU and data CPU it was very enjoyable. Seeing your stock video of young people pretending to have a clue makes me shake my head in disgust and think of 2001: th-cam.com/video/cHWs3c3YNs4/w-d-xo.html Maybe I'm ageist, sexist, racist, and just plain *ist but this stock video seems totally out of place like most things today.
I ... don't get your point. bootloaders like LiLo and GRUB were created for the simple reason that the BIOS wasn't capable of doing more than loading the contents of the boot sector and running that, and a boot sector isn't capable of enough complexity to load a full-scale modern kernel, so another stage of bootloader was required as an intermediate with enough complexity to access the main filesystem to load the full kernel, and make chices about which kernel/OS to load. UEFI is now capable of this, including kernel version fallback via EFI boot menu, so why keep the intermediary? also, the GRUB bootloader can still exist as well, as an EFI boot option, in case you need some feature of the bootloader for experimentation (for example, I'm not sure how EFI can handle kernel command-line options). You went over a lot of history, which whilst true, is no longer relevant in modern PCs. And... what were you saying about needing different kernels for different architectures because of different boot process? as if the different memory/hardware/ISA don't already require completely different kernels?
I guess this is one where I can't really follow your arguments. For starters you give a lot of historic context, where I don't really understand the reason this is relevant for a decision today. But I guess I'll will revisit that. Then you give the reasons that are relevant today, which are, AFAICT: * not failing the system boot when messing with the system * Immutable OSs have different kernels etc anyways, how to deal with that * the bootloader abstracts over different architectures I will address them in that order: 1. * in many situations there would be fixes that you can use if you messed up your system. I'd say that this likely already happens, with many things not loading. * But perhaps more importantly, what do you win when you can boot a failing system to grub? At least I can not navigate grub well. Likely grub will start with a different keyboard layout to start with (I remember that being a problem with disk encryption a few years ago). But I've still got no idea how to navigate the grub environment and achieve what I want, and I don't intend to read documentation and try to learn it while fixing my system, thats likely just going to end up with me making things worse. Even the few situations where I've got other startup issues, like a fstab mount failing validation, there I've got at least a regularish bash, but I still struggled doing stuff when that happened. * so you know what my solution is when my boot fails and I can't get to the system? Get a live OS USB and fix the issue from there. chroot ftw, that way I've got pretty much all my stuff in place. So yeah. At least for people like me, the ability of the system to crutch along isn't helpful. In the past this was probably a big win, but now we've got fast enough USB Sticks and robust enough software that live OS's are a thing, and people are used to a whole lot of layers of abstractions and less aware of the lower level, so that solution doesn't help us. 2. Yeah maybe. I mean, still, you could probably easily work around that. Nmbl has 2 versions. Booting straight to the final unified kernel image (UKI), or using another UKI as bootloader menu - or maybe the 'main' (same) one, I don't know how that's implemented precisely, but the point of the me je is to select between different boot configs, so obviously there are going to be a situation where you've got different systems. Then simply exchange that boot system in a different (optionally atomic) process. And even if there is some deeper issue I don't see. So what. As a matter of fact atomic systems are still a niche, and I'm not yet entirely sold that they're the future. This would not be the first incompatibility between different solutions. It's not great, but it's life. 3. I'm not sure I really get that. As I said before, nmbl has 2 configs. One of them is just a rebranding of an existing system, that being booting straight to the final UKI. So, that being the case, obviously these abstractions will already have to be present. Regarding the historic context: So yeah, okay, in the past they had a bootstrap process (as in creating a toolchain for the system, not starting the system) that inspired/led to the boot process. That is interesting, but I don't really see the relevance here for arguing against nmbl. This is again obviously not what is done today. Today we do have cross compilers, and I see no reason that this should not be the process we use today to create a toolchain for new hardware. I'm not sure if you advocate for that, but if you don't, and simply wanted to bring this historic information to our attention, then I'd say there should be a stricter separation between it and the arguments against nmbl. I had difficulties finding one. My 2 cents: I was very interested in what I've seen from nmbl so far (in eg. Broadies video). I'm also not sold on it being a good idea, despite what my points might imply, but I'll follow it with interest, and should it work well for others I might try it. And my interpretation of what nmbl offers is this: * it brings awareness to the existing boot to UKI process * it offers the ability to get better or rather more familiar tooling during the boot process. Or, from the developer side, it avoids duplication. If grub wants to do anything over the network it needs an entire network stack of its own. Such features make grub fat and complicated. If we're gonna be stuck with a complicated beast I'd rather it be a beast I know... Well better at least.
1) it shows the context for needing BootLoaders 2) it shows we already did the direct boot into the OS and it doesnt work and 3) it tells what a bootstrap actually is
One simple sentence, you are overloading the kernel with unnessary tasks, no one has said you cant do it, but I hope you have a good and complete kernel on your live USB you will need it, trust me. Been there done that, got the t-shirt and the lumps...not a good idea, anyone experienced with OS design will tell you that is not the right approach.
One other thing, the boot loader code disappears once the kernel is going, do you really want 1) all that code and 2) security keys from Secure Boot remaining in memory? A person involved in cybersecurity for example has to get it right everytime, a hacker only has to get it right once....remember Linux kernels are monolithic, all code is bound into one executable. There are some part of the boot which run in what we used to call REAL mode, you dont want any of that addressable (loadable) once the kernel divides the computational environment into system and user space
@@CyberGizmo that first comment is about the historic context, right? 1st and 3rd point are fair enough. 2nd point I'm not so sure about. They booted directly to the compiler because they did not have cross compilers, so yeah, it wasn't the right way, but that's no argument against using direct boot for other purposes.
@@CyberGizmo Re 2nd comment You doubtlessly have more experience than me. And you're not entirely wrong. But grub is already a complex beast, and it has networking etc. There's a reason I actually switched to systemd-boot, it's much simpler to do the tasks that matter. There is often a conflict between simplicity and familiarity. Looking at things in isolation, it's usually best to choose the simplest tool for any task, but this would mean that we've got a bunch of tools of increasing complexity. And I have not got a kernel on that drive that I can replace stuff with. Just an OS. With arch-chroot. So if my boot should be borked, I boot from the USB, unlock my encrypted drive, then do an arch-chroot, and I can do most of the stuff that I'm able to do in my regular terminal. I can't possibly do such stuff with something like grub. So yeah. It's not simple. But it's familiar to me, I know how things usually behave. A simpler system that's unfamiliar to me might lead to me deleting important stuff or similar.
I studied computers at college in the 90's and it was 99% os side and 1% of hardware abstraction(x86 ) , recently i got into hacking arm cortex devices and one of the first things i had to learn to write was a boot loader for diagnostics , then i got into bigger device like mips , arm v8 etc and all need a form of u-boot/bootloader which gives the system a fail over option, since then I've been writing bare metal code and love it!
Hi Dj Ware , your knowledge is unique coz you know the history , saw the history and the most importantly you able to explain complex subjects in simple terms. Out of all Yt Linux channels your is my favorite.
I wish if u could continue to making this videos.
Thanks you.
Another great video DJ but I'ma hafta stick with my good ole bootloader. In programming, I've learned that patience isn't optional, its required, thus waiting for Grub to post and boot....meh no biggie.
Also this being fairly new on the scene, I imagine someone like John Hammond would have an exploit for it over a weekend ... More risk than worth in ny humble non-biased opinion. 🤘🏼👦🏻
The initial discussion about mainframe system design reminded me of Tracy Kidder’s Soul of a New Machine (granted, that’s about a mini computer)
Since many years i use rEFInd on all my machines and let refind pick the efi executable kernel directly from the root filesystem. This is since i transfer my customised linux setups via partition images to other machines without the need for recreating grub/systemd. Thats very comfortable, so i think they should mix nmbl with refind as the boot manager. Perfect!
NMBL should just be dropped instead of rEFInd and UKI in my opinion. I haven’t seen it do anything that those to don’t already do.
@@Knirin exactly, refind should be integrated in uefi😄
As I recall, the forth interpreter existed in all of the SUN PROMs, even the low end workstations, at least after the UltraSPARC transition. I can’t remember about the machines before that. However, to your point, the POST on those machines reached out to firmware in the actual expansion cards so what you could do in the forth interpreter in terms of diagnostics and configuration did depend on what the cards supported in their firmware and the cards intended for servers tended to have fancier firmware, as I recall.
Not something I’ve thought about in 20 years, so my memory is a bit fuzzy now.
You know what? I had exactly this question when I learned linux, and guess what? I couldn't believe the answer when I read EVERYWHERE that it's just "POST, then BIOS, then LILO, then kernel" and 3 out of 4 had explanations, but not LILO, and being autistic, I could never put a checkmark there.
But now I can, thank you SO MUCH!!!
It very well may be that after the current wave of newcomers has subsided, in 20-30 years, we would have ended up with a 10 million strong corpus on solving Knapsack 0/1 LeetCode problem, but there would not be any explanation for bootloaders, leaving us in a state of "church of science" Azimov style, cargo culters implementing bootloader "because it's in the scriptures".
But now, now there's hope there is this video in the corpus, and a young acolyte can question the dogmas to kick start renaissance.
Anyway, jokes aside, thank you so very much for this gem :)
She was 100% correct in her explanation of the term "bootstrap". It does indeed come from the old saying "to pull one's self up by the bootstraps", and when used in the context of software just refers to a self-starting process.
THink what you want, but I was there in the old days and I say she got it partially right as I explained
@@CyberGizmo Well, I think your response in general is a characature of her presentation, as if she doesn't know anything at all about the things you talked about. And it really seemed like you were laughing in her face as if she doesn't know what she's talking about. Pretty much every point you mentioned was addressed in either her presentation or blog post. For example, with the kexec path, you can load a different kernel, and there's always a fallback. She's well aware this is not a new idea. Perhaps the main goal of nmbl is to make the boot process more secure, and really this is the first iteration of that idea that she acknowledged needs refinement and welcomed feedback.
Some of the main points that you didn't address are the security vulnerabilities with GRUB, ease of code maintenance, because at the moment kernel and bootloader code are duplicated, and increased security scrutiny because there is far more security scrutiny on the kernel than bootloaders.
Love the shirt DJ! Yes I'm still doing some research there.
Like anyone who likes to run _different_ operating systems and system architectures, I appreciate having one standard bootloader everywhere. I've unhosed systems from just the grub prompt way too many times. People who don't like waiting for the bootloader can already configure it not to wait, or use the EFI entrypoint, or even coreboot. If I were worried about boot time, I'd try to move the DRAM training out of the firmware and into the kernel, where it can be done in parallel with other boot tasks.
Oh! Also, sometimes the newest kernel just won't boot. Having the option to run the last working kernel is very helpful.
More options for booting the kernel is great, though, especially for those firecracker-style VMs.
I like your take on this and you absolutely give very valid points. Especially given the history of it all. But I must admit I think we should always have a critical eye on legacy systems/software/solutions. Just because it was a good idea 40 years ago, and has been a good idea for 40 years since, does not mean it's still the most optimal solution. So I definitely root for nmbl in that regard. Time will tell if it really is better, or not.
Excellent video. I now better understand the pros of bootstrapping. I can imagine it is also useful for multiboot on the same disk.
It's interesting. It'd be nice to be able to rice something more completely.
Right now I'm working on a star trek LCARS theme for grub 2.
There are sore points I've noticed. No animation or high fidelity audio.
I started looking at booting direct to kernel at one time, and mostly I think the loader need to stay because it enables update images to be applied and reverted such as in android bootloader, it would be preferable to boot into like syslinux system so you have a lot of flexibility and then hand off the boot to a different kernel chromeos flex has a interesting way of doing that, and can have a lot of benefits. Coreboot, Libreboot are also great options, and both allow booting directly into the kernel, the kernel params I think are becoming more unbound, I think it is awesome you could put your kernel directly in the bios memory, and boot quickly however it was like interest somewhere when I wanted the fastest cold boot time without using any sore of sleep or hibernate.
You're right and I forgot about the Open Bios yep they need a bootloader thanks for the addition!
Good morning DJ. I have been watching this with curiosity. Thanks for covering it. I still have questions as to how they would manage snapshots and such. I just don't see the need for any of this.
Me either and EFI boot already took out a step from the old BIOS based one so now there are 3 steps to boot into the kernel...that is probably adding a second maybe 2 to the boot time, I can live with that. And Good Morning, Act!
11:36 Bootstrap Abstraction
I am not sure if each CPU has its own bootstrap sequence. I assume that after the power is on (at the processor level) the processor just jumps to a memory address to execute codes.
One of My Arm machines uses Uboot and it is very different from how an X86 boots using BIOS/EFI: Odroid N2+ wiki.odroid.com/odroid-c4/software/boot_sequence#:~:text=Boot%20sequence-,Stage%20%231:%20Power%20cycle,to%20figure%20out%20the%20location.&text=The%20bootloader%20in%20the%20eMMC,does%20not%20have%20the%20bootloader.
@@CyberGizmo I beg apology for my poor English and my poor Logic. My points were that after power-on, any CPU initializes itself and begins execution of the vector memory. The final objective is to load the Operating System.
Therefore, I wondered why the boot sequence must differ between Intel and Arm-based systems.
Modern boot loader is called UEFI. It is neither GRUB2, nor efi-grub2, nor systemdboot, but UEFI. All of required diagnostics are there.
Well then tell me how I can use an encrypted disk with UEFI, because everytime I try it, I have to leave the UEFI partitions wide open and that is a non-starter for me
@@CyberGizmo you cant. Not with grub2 not with UEFI boot stub can all partitions be encrypted.
my solution would be boot a minimalist initramfs and then decrypt the drive, that's a really good option if you ask me, you don't expose anything important
@@PragandSens UKI (unified kernel image) does just that. UEFI and secure boot - included.
There is a talk by that Bryan guy, an engineer who was in Sun back in the day. He argued against bootloaders. But it was quite technical and the topic is very low on the stack. Went over my head.
He also said computers are very complicated, and that he still faced difficulty learning all about them despite the decades, or something to that effect. Well if he faces difficulty what chance do I have?
His company provides hardware for data center infrastructure fyi. Oxide.
You shouldn't have to worry about it, unless you have a screw loose like I do and actually did the manual one line at a time program load ONCE, and never wanted to do it again :)
Yea, it is a good idea. The boot strap does not need to wait to see if you are going to boot another operating system, you selected it, and you can hit a selection key beforehand in any case to override it. Linux itself has several stages to the boot process, none of which are really required. It could perform all of its configuration beforehand and write a simple binary image of the result to disk and then just load that during boot. With all the speed increases for modern disk media, the system could come up in just a few seconds.
I like seeing the bootloader! Don't fix what's not broken.
@@AshNonokPlays I'd argue it is broken, adds a bunch of boot time
Agreed, I like my Grub 🐛!
@@ducky1681consider the time wasted learning nmbl's extraction of your login for your distro if you forget it....accessing libraries from boot....things easily mitigated via Grub's bootloader rn. I mean I don't see any enormous benefit. If your too impatient to even wait for a bootloader, my guy, your in the wrong field, this I assure you. 😅
@@ducky1681stop and smell the roses some time.
Just wait until that person who wants this gets to troubleshoot a driver issue and cant figure out what is causing it, then spends 8 hours before they give up.
I use ukis and entries into uefi for all my machines. Arguably, systems that need the functionality and redundancy of a bootloader can and will use one, but for end users who wont be spending any time at all debugging anything, it doesnt seem necessary.
I can understand the need for faster makeup from sleep on laptops, but that lag often lies in the bios speed. I hardly ever boot my workstation so boot times arent something i see that often
How about just loading a snapshot of registers and ram and run it.
Pre-x86 computers’ ROM had enough code to start up the OS on supported media; or had the OS in ROM itself, think 8-bit basic machines.
The x86 ROM never had this, for whatever reason, so the boot loader was needed to compensate for that missing functionality.
I’m partial to Sun/Mac forth boot but that’s an side effect of growing up on Sun’s.
TRS-80 had code in ROM for disk boot, as did Apple “C600G”, Mac, Amiga, ST, etc.
UEFI should really be able to directly boot to kernel at this point and skip the whole boot loader nonsense. If a Rpi can do it, x86 should be able to.
I'm fine with systemd-boot disappearing together with all other Poettringware, but other than that, let's keep 'em.
Systemd-boot is taking over on the corporate side of Linux usage now because GRUB didn't want to support decrypting luks2 encrypted drives. systemd-boot did and is now the de-facto for anything laptop related from corporates.
@@polinskitom2277 that's true unfortunately. grub is on Death's door with Debian, Arch, and Fedora really wanting to switch away from it as it's too much of a hassle to troubleshoot (especially with the "bootloop to system firmware" problem still affecting machines here and there on random)
@@polinskitom2277 i didn't know that... Good to know, ty.
hahahaha dude, the nmbl project is planning to use systemd-stub, so no removal of systemd yet haha
Of the list of issues nmbl tries to address based on the Fedora blog post, I consider speed the least interesting one. How often does one actually power up or reboot a machine, and how much does a faster boot time matter? That would surely depend on individual use cases. In the areas I work in, it doesn't matter at all. Critical systems are spread across multiple servers, possibly multiple locations around the globe, and it doesn't matter to me if rebooting individual machines requires an extra minute. Also, I will take reliability over raw speed any day of the week, but that may be just me.
Can you please explain how Grub works .. I think its very restrictive and i dont really understand always end up permanently blocking space on HDD .. cant clean it cant use it
Good idea
I like the boot loader
I always liked how Mac system did it till I think system 9. You could format a disk with a certain flag set and file copy a system folder over to it and and it was pretty much bootible. You told finder to look at that disk and it would check the disk and say yep, do you want to boot from it.
I love this channel.
I can boot Unified Kernel Image on archlinux just fine. And it's fast. But don't replace the bootloader with this, two seconds of less boot time but no way to troubleshoot if anything goes wrong for the average user.
couldn't i just use a USB bootloader when I need it? I mean I don't carry my screwdriver and wrench with me everywhere I go. Just for when I need it. O-O
@@PragandSens Yeah, in effect you can always do that. What I mean is the boot menu should be there by default and optionally removable. And I mentioned average Joe who might not be knowing anything about grub or and other bootloader.
What about dual boots or more.. let's say I have multiple os-es I want to boot into. I am a total noob, so I don't know how that would work. But I rather have a grub bootloader, if only for dual booting or triple booting, etcetera. I mean I know how to do that with Grub, but not with nmbl.
there's an application called boot-next
Slow Linux boots are a problem?
yes for my OCD brain
interesting
Once a long time ago I had a week long class on the IBM mainframe boot sequence. Since at that time I could read the hex for the CPU and data CPU it was very enjoyable.
Seeing your stock video of young people pretending to have a clue makes me shake my head in disgust and think of 2001: th-cam.com/video/cHWs3c3YNs4/w-d-xo.html
Maybe I'm ageist, sexist, racist, and just plain *ist but this stock video seems totally out of place like most things today.
oh the one when they were working on the proposal, yeah team building, rah rah...
I ... don't get your point.
bootloaders like LiLo and GRUB were created for the simple reason that the BIOS wasn't capable of doing more than loading the contents of the boot sector and running that, and a boot sector isn't capable of enough complexity to load a full-scale modern kernel, so another stage of bootloader was required as an intermediate with enough complexity to access the main filesystem to load the full kernel, and make chices about which kernel/OS to load. UEFI is now capable of this, including kernel version fallback via EFI boot menu, so why keep the intermediary? also, the GRUB bootloader can still exist as well, as an EFI boot option, in case you need some feature of the bootloader for experimentation (for example, I'm not sure how EFI can handle kernel command-line options).
You went over a lot of history, which whilst true, is no longer relevant in modern PCs. And... what were you saying about needing different kernels for different architectures because of different boot process? as if the different memory/hardware/ISA don't already require completely different kernels?
I guess this is one where I can't really follow your arguments.
For starters you give a lot of historic context, where I don't really understand the reason this is relevant for a decision today. But I guess I'll will revisit that.
Then you give the reasons that are relevant today, which are, AFAICT:
* not failing the system boot when messing with the system
* Immutable OSs have different kernels etc anyways, how to deal with that
* the bootloader abstracts over different architectures
I will address them in that order:
1.
* in many situations there would be fixes that you can use if you messed up your system. I'd say that this likely already happens, with many things not loading.
* But perhaps more importantly, what do you win when you can boot a failing system to grub? At least I can not navigate grub well. Likely grub will start with a different keyboard layout to start with (I remember that being a problem with disk encryption a few years ago). But I've still got no idea how to navigate the grub environment and achieve what I want, and I don't intend to read documentation and try to learn it while fixing my system, thats likely just going to end up with me making things worse. Even the few situations where I've got other startup issues, like a fstab mount failing validation, there I've got at least a regularish bash, but I still struggled doing stuff when that happened.
* so you know what my solution is when my boot fails and I can't get to the system? Get a live OS USB and fix the issue from there. chroot ftw, that way I've got pretty much all my stuff in place.
So yeah. At least for people like me, the ability of the system to crutch along isn't helpful. In the past this was probably a big win, but now we've got fast enough USB Sticks and robust enough software that live OS's are a thing, and people are used to a whole lot of layers of abstractions and less aware of the lower level, so that solution doesn't help us.
2.
Yeah maybe. I mean, still, you could probably easily work around that.
Nmbl has 2 versions. Booting straight to the final unified kernel image (UKI), or using another UKI as bootloader menu - or maybe the 'main' (same) one, I don't know how that's implemented precisely, but the point of the me je is to select between different boot configs, so obviously there are going to be a situation where you've got different systems. Then simply exchange that boot system in a different (optionally atomic) process.
And even if there is some deeper issue I don't see. So what. As a matter of fact atomic systems are still a niche, and I'm not yet entirely sold that they're the future. This would not be the first incompatibility between different solutions. It's not great, but it's life.
3.
I'm not sure I really get that. As I said before, nmbl has 2 configs. One of them is just a rebranding of an existing system, that being booting straight to the final UKI. So, that being the case, obviously these abstractions will already have to be present.
Regarding the historic context:
So yeah, okay, in the past they had a bootstrap process (as in creating a toolchain for the system, not starting the system) that inspired/led to the boot process. That is interesting, but I don't really see the relevance here for arguing against nmbl. This is again obviously not what is done today. Today we do have cross compilers, and I see no reason that this should not be the process we use today to create a toolchain for new hardware. I'm not sure if you advocate for that, but if you don't, and simply wanted to bring this historic information to our attention, then I'd say there should be a stricter separation between it and the arguments against nmbl. I had difficulties finding one.
My 2 cents:
I was very interested in what I've seen from nmbl so far (in eg. Broadies video). I'm also not sold on it being a good idea, despite what my points might imply, but I'll follow it with interest, and should it work well for others I might try it.
And my interpretation of what nmbl offers is this:
* it brings awareness to the existing boot to UKI process
* it offers the ability to get better or rather more familiar tooling during the boot process. Or, from the developer side, it avoids duplication. If grub wants to do anything over the network it needs an entire network stack of its own. Such features make grub fat and complicated. If we're gonna be stuck with a complicated beast I'd rather it be a beast I know... Well better at least.
1) it shows the context for needing BootLoaders 2) it shows we already did the direct boot into the OS and it doesnt work and 3) it tells what a bootstrap actually is
One simple sentence, you are overloading the kernel with unnessary tasks, no one has said you cant do it, but I hope you have a good and complete kernel on your live USB you will need it, trust me. Been there done that, got the t-shirt and the lumps...not a good idea, anyone experienced with OS design will tell you that is not the right approach.
One other thing, the boot loader code disappears once the kernel is going, do you really want 1) all that code and 2) security keys from Secure Boot remaining in memory? A person involved in cybersecurity for example has to get it right everytime, a hacker only has to get it right once....remember Linux kernels are monolithic, all code is bound into one executable. There are some part of the boot which run in what we used to call REAL mode, you dont want any of that addressable (loadable) once the kernel divides the computational environment into system and user space
@@CyberGizmo that first comment is about the historic context, right?
1st and 3rd point are fair enough. 2nd point I'm not so sure about. They booted directly to the compiler because they did not have cross compilers, so yeah, it wasn't the right way, but that's no argument against using direct boot for other purposes.
@@CyberGizmo Re 2nd comment
You doubtlessly have more experience than me. And you're not entirely wrong. But grub is already a complex beast, and it has networking etc. There's a reason I actually switched to systemd-boot, it's much simpler to do the tasks that matter.
There is often a conflict between simplicity and familiarity. Looking at things in isolation, it's usually best to choose the simplest tool for any task, but this would mean that we've got a bunch of tools of increasing complexity.
And I have not got a kernel on that drive that I can replace stuff with. Just an OS. With arch-chroot. So if my boot should be borked, I boot from the USB, unlock my encrypted drive, then do an arch-chroot, and I can do most of the stuff that I'm able to do in my regular terminal.
I can't possibly do such stuff with something like grub.
So yeah. It's not simple. But it's familiar to me, I know how things usually behave. A simpler system that's unfamiliar to me might lead to me deleting important stuff or similar.
NMBL!Oh, what an unfortunate name(I think of NAMBLA🤣)!
what is this diversity utopia in your video clips?
do you know nambla
have a better name
ewwww yeah