I'm not old, my beard just came out gray while I was waiting for all those USB sticks to boot since USB1 ;)
Kauler is brilliant.
I couldn't have gotten as far as fast once I found Puppy, because quite simply the fewer megabytes the size of the distribution, the faster the bootup.
And there was nothing else as small that booted all the regular Linux ways (including from FAT32 using Syslinux), and was worth being a user after you were booted :)
As for ISOs, more perfect images would be great.
For one thing they're wonderful for consistency, starting with the fundamental structure of partitioning & formatting which is copied bitwise identically from the master to the target as it overwrites the whole target. Simultaneously with all the user-oriented files within the file system, ideally it's like a forensic copy.
Also sometimes the boot files are finicky, or take a while to get right, and once it really works as robustly as possible on the master device, it would be perfect if every target device needed no attention whatsoever even though booting is very important to pay attention to. Not only will the exact user boot files be there on the target's resulting filesystem, the hidden boot records will too whether they are part of the filesystem or not. And further, the boot files in the filesystem will be at the exact same sector locations as the master. So will all the other files & folders. You can't get much more identical than that.
With bitwise copying, even the unused space within the filesystem will be copied verbatim from the master to the target, whether it contains zeros or vestiges of previously deleted data. And the filesystem is not even actually completely there until the bitwise image has finished copying to the target.
Just like an ISO was when you actually were burning to CDs, maybe at an earlier time than you were writing any USB drives.
And images are usually way faster than copying the exact same files by using an OS to copy them to a freshly formatted filesystem the regular filewise way. Whether copy & paste or CLI.[0]
I went through images backwards and forwards, have gotten a lot of reliable use out of it.
And you really can end up with equivalent performance either way.
When you do end up with the same performance that is :\
Turns out identical is not what you want with USB sticks.
more background
No matter of any "hybrid" approaches (even before UEFI) trying to make an ISO that could be directly copied to USB, modified ISO's are just not very good at copying to USB sticks and having them functionally boot like an ISO is supposed to do. Even when all the files and folders on the target end up fully accessible, performant, and error-free. It can be a frustrating thing.
Image files have a problem too, the hardware that the master image was saved from may be so dissimilar to the target media, that performance of that particular target, perhaps when interacting with other supposedly-compatible hardware such as motherboards, will be abysmal compared to the master device, and unpredictable across various motherboards.
Not such a big deal with HDDs and barely noticeable with SSDs but can really bring otherwise-satisfying USB devices to their knees. Sometimes yes, sometimes no. All targets within the same SKU as the master but some have slightly different controllers, firmware, or memory chips? Ruh-roh. Differernt SKUs on the USBs? I wouldn't be that confident any more.
Depends on how you handle the image file.
As long as you treat it like a standard ISO and mount it before copying filewise to a previously-prepared filesystem on a bootable USB stick, you should be fine :\
More or less what Rufus does automagically, he is brilliant too.
It does kind of defeat the purpose of having an image that's supposed to be copied bitwise directly to a target though.
Using dd or Etcher is so much quicker but then you're just playing the odds.
Decades ago for USB booting I used to think images were ideal.
But I was wrong.
Completely wrong.
Wrong about standards and I'm a standardization guy. How much more embarrassing can you get?
If it's supposed to be Linux (no matter whether DVDs or USBs become obsolete) ISOs boot using Isolinux, HDDs SSDs & USBs boot equivalently using Syslinux, and you can do it over a network using Pxelinux. These have all been very stable references for very long.
ISO files are an even older standard than Isolinux, which makes it even more fundamental so it's always been golden. Now I realize that. Everything that continues to trace back to this standard has a remaining chance to perform at least as reliably over the long term as ISO's have already performed so far. The continuity among Linux distributions using ISOs so far will be unmatched for decades to come no matter what happens. And ISOs were made for direct copying bitwise to their target media. Too bad it's just not right at all for very many USB sticks, so instead you have to first mount the ISO and copy the files & folders to an already-bootable previously-prepared USB drive. I'm not going to be regularly copying ISOs bitwise to optical disk devices any more (if I can avoid it), so in the future (starting quite a while ago) I'm not likely to use an ISO for what it was originally intended to do, if at all. Doesn't seem like anybody's going to be using ISOs to burn directly bitwise to media any more, which is the only reason ISO became the Linux standard for distribution to begin with, so why are ISOs needed going forward at all?
Too late, ISO (as the name implies) is now more valuable as a standard than it ever was for burning discs.
So now the further you go into the 21st century you really need the ISO's to keep working, more so than ever ! Even if nobody's burning discs. You can't make this up :]
And after exhaustively confirming that images are far less reliable for copying bitwise to USB sticks compared to ISOs when using optical, it leaves us back where we started without a worthwhile image file type than can always be overwritten to a USB whole-hog and have it boot. But at least you can still do it with DVD's using ISOs if you really have to, no different than ever.
Probably because an IMG (just like an ISO) is a filetype entirely focused on only one thing, writing it to a target device to make a perfect clone of the bitwise data pattern from one drive to another. Or to copy back to the same drive during a restoration event. Can't mistake that, it's either a true copy or not. Even if IMG is way older than ISO, it worked for floppies no different than it does today. The motherboard still just responds to whatever bit pattern it finds on the boot device, regardless of MBR, UEFI, EXTx, NTFS etc. I didn't think too much about it either, but there's a lot more electronics in between the motherboard and the bits residing on the storage medium for a USB than there was for a floppy. And a lot more "chance" for variation. Too bad IMG is not a standard filetype. But as long as it can be overwritten to the same device it came from and result in a perfect restoration from backup, it's job is accomplished with flying colors, and it almost never fails.
So if you're worried about the age of the filetype, IMG is so much more elderly than ISO that it was almost repressed bad enough to be forgotten (since not everybody wanted you to make perfect clones), which is probably why nobody came along to extend it for anything beyond everyday floppy use. Floppies worked just fine and were interchangeable without a detailed functional standard IMG filetype at all. But without a standard, IMG is just a filetype in name only which is why it's still the right file extension to use when you are going to be overwriting a whole drive of any kind with it later. That's exactly what it's for, and nothing else. And after a lengthy famine, there are now more brilliant tools that mount and handle wildly diverse IMG files simply because they are known to be a complete drive image. So all an IMG needs to do is behave like a drive image (as long as a particular IMG does that, no standard needed), it can be mounted and people are so much more familiar with VMs which helps a lot for those who've never used a floppy yet.
Barry is brilliant but others are too.
IMG works about as good on a whole hard drive as it did on a floppy, lots of USB's too when you're getting lucky. Hard drives have so much more in common with each other but they're not perfect either. But it's not ever been expected to work every time when the master and the target are less-than-identical hardware.
Remember at one time almost every IMG file was targeted to deploy on floppy media, approximately 1.44mb in size, containing 2880 sectors. Worked fine without a filetype standard then, and anything other than 2880 sectors would trigger the question "exactly what hardware am I supposed to write this file to?"
The thing about standards is, lots of people struggle if they aspire to meet a standard. You may or may not quite make it. But nobody says just because you conform, that you have to stop right there.
People generate millions by exceeding a standard when others are not. They can match others' work but others can not match theirs.
GRUB has got to be able to work too, it's under constant maintenance and has way more modern features.
And this Limine bootloader looks really promising. It has nowhere to go but up.
They've all got to work on every kind of Linux at least, with any other OS's being icing on the cake !
Less than that could be the result of a bug, maybe even a defect.
[0] Which filewise sometimes amount to a mere fraction of the GB actually transferred when done imagewise.
