It was more than just "install Linux without its own partition". It was "install Linux in a directory like C:\LINUX like a normal DOS application and start it from MS-DOS like a normal DOS application".
It's hard to overstate how important that was at the time. If you had a system running MS-DOS (like most people), with or without Windows 3.x (which also started from MS-DOS like a normal DOS application), you could install Linux without changing anything on your system, and if you didn't like it, you could simply delete the corresponding directory and everything would be gone. That (together with small Linux distributions which ran from a pair of floppies) made it much easier and low-risk to try Linux, and IMHO was one of the things which helped it gain enough marketshare and mindshare to later stand on its own.
(That was my own path with Linux: I started running it as a "normal DOS application" with UMSDOS and LOADLIN, then I moved to a dedicated partition with ext2 and LILO, and finally I discarded MS-DOS completely and gave the whole disk to Linux.)
> WSL runs Linux programs under a different kernel by replicating the syscall interface
Only WSLv1 did this. WSL 2 is very boring architecturally, it just runs a full Linux machine in a HyperV VM domain.
Yes, DOS was basically a boot loader and utilities. The EFI shell is modeled the same way, though DOS had fewer address bits available. Netware also used it in this fashion, as a boot loader that may/not initialize hardware.
From memory, the next stage of the OS would simply write itself over DOS in memory, move the instruction pointer and go.
With LOADLIN, the Linux kernel completely replaced MS-DOS in memory. To get back to DOS, you had to reboot. Since MS-DOS was a single-task operating system (that is, you weren't normally running anything else at the same time, other than perhaps a few utility TSRs), and it booted quickly (other than the slow memory counting in the BIOS if you had that enabled), that was not a big deal.
There was a whole entire (simple, limited) operating system to work with (MS-DOS) to use for sorting out any issues with booting the "real" operating system, and that bootloader-OS worked well with the hardware, and was familiar to the people using it -- at that time.
I used it for a long time (longer than most, I'm afraid). The method provided for systems that would [hopefully, and almost-alwaus] successfully boot MS-DOS, whereafter the boot environment was easy to manage and sort out so that a real operating system (Linux) could be loaded and run.
Back then, given any working PC, it was trivial to make an MS-DOS boot floppy, and therefore it was also trivial to make a Linux system boot up with loadlin.
After that, I used LILO for a time: LILO worked great if everything was in order, but it tended to fall down hard if things weren't just-so.
And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
tl;dr, I dearly miss the seemingly-simple concept of using a "real," common, minimal-ish operating system as a bootloader. I've been told that UEFI provides something similar to what MS-DOS and loadlin provided, but I haven't found a single utterance as to how that's actually supposed to work. Working within UEFI seems to be mostly a dark black box in common use, and the boot environment should never be a black box.)
For smaller ISOs, you can even just stuff it on your boot partition and have e.g. the arch install ISO as a permanent boot option should you ever need to debug. I have the Arch ISO there, in the off-chance that I massively screw up and have no spare computer to prepare an image/aid in debugging.
> And then: GRUB. I still hate GRUB.
I'm not a huge systemd fan, but systemd-boot just works. Configuration is trivial and does not require rebuilding, so you can change settings from anything that can mount your EFI system partition.
It does have one annoying quirk, and that is that if your forget to fill in your loader.conf (needs a default entry and timeout which is commented out by default in e.g. Arch), then it silently fails.
> I've been told that UEFI provides something similar to what MS-DOS and loadlin provided,
To some extend - if you drop to the EFI shell (assuming your firmware includes one, otherwise you can bring your own), you can navigate supported filesystems and load ramdisks and kernels and such.
It can host fancier apps too, but I haven't done more than just read files and load OS's. Useful when you effed your system and your bootloader.
Feels redundant, and I enjoy having the disk space back. An external flash boot drive has saved me countless times, and is useful for other stuff. On it I now use Ventoy, which I heartily recommend. So much better than imaging the whole drive.
[0]: ... when installed, but the installation process is awful. For GPT, it's just a FAT partition with the ESP flag and a few Ventoy files on it, and yet you need to run "installers" as root to "prepare" the drive. It should just have been a tarball and a few trivial commands - not a thousand lines of bash shelling out to a custom C partitioning tool...
You just put several isos on it once a year. It’s usually not installed, just run. Any live distro can download additional tools as needed. And really any from the last five years are fine, partition tools and text editors haven’t innovated recently. Maybe you’d want the latest btrfs tools possibly, if so download.
A cheap 64GB! flash drive dedicated to the purpose and put on a keychain works well. Think I looked for 32GB but needed to go 64 to get usb3.2+ transfer speed, which I also recommended. Still so cheap! Great for test driving new distros too.
I agree about ventoy, but only had to install it once, and already blocked it out, haha. Hopefully someone strips it down and adds a lite version to debian.
Live images aren't the same thing, I don't think: Sure, I can do all kinds of useful stuff with them, and they're vaguely as familiar as any other Linuxey-thing is.
But AFAIK there is no Linux equivalent to loadlin, so I can't use a live image as a flexible environment from which to run a bootloader like I did with MS-DOS over a quarter of a century ago.
There's kexec (https://www.man7.org/linux/man-pages/man8/kexec.8.html), which allows loading a Linux kernel from within a running Linux kernel.
I guess I have some work to do instead of just bellyache about the good old days, then.
Thanks! (I think.)
GRUB might disappear in the future. You might already switch to systemd-boot (which is basically gummyboot if my understanding is correct?).
But Lennard Poettering & co is working on UKI (unified kernel image) that should make linux bootable from UEFI directly (no grub or other boot loaders needed).
I didn't dive that much into UKIs but if my understanding is correct an UKI should be a bundle comprising a linux kernel, an initramfs and a few more things, packed as an executable that UEFI can launch.
This should simplify a few things (like cryptographic chain of trust) and make some things smoother.
I'm not sure if having yet another implementation of EFI booting Linux kernels, such as UKI, especially if done without support from the kernel developer community, will bring anything but useless competition and strife. The whole kdbus controversy comes to mind.
Especially if you already compile your own kernels, IMHO, there's almost no excuse not to use EFISTUB other than if your specific firmware isn't compatible with it for whatever reason.
Configuration is just a single line: "Boot with power options" "ro cryptdevice=UUID=XXXXXXXXXXXXX:root root=/dev/mapper/root initrd=amd-ucode.img initrd=initramfs-linux.img quiet amd_pstate=active"
EFISTUB is a Linux config option that has to be specified at compile time, so you do have to compile your own kernel if the distro you're using doesn't already enable it, but I compile my own kernels anyway so this is fine.
It is technically a bootloader. However it looks inside of itself for the kernel, ramdisk, and kernel commandline [0]. This means that you can use objcopy to put an existing kernel and ramdisk into a standalone EFI executable; without needing to recompile anything.
Dracut even has a "--uefi" option that will do all of that automatically.
[0] Although if secureboot is disabled, you can override the cmdline from the EFI if your firmware exposes that functionality.
(And actually, that usually worked OK. They didn't fight. The filesystem shims, where necessary, weren't always the most reliable, but the operating systems themselves and the applications associated with them were generally pretty chill together.)