ISO isn’t useful in the author’s use-case. That’s fine, it is their project to do as they will. ISOs may still have uses elsewhere, such as PXE boot or just a near universally mountable read only container.
The author’s point to the age of the original ISO standard is irrelevant. Many old technologies are reliable and widely adopted, which in and of itself may make it superior to more modern technologies.
Author’s project, author’s will. But that was difficult to read due to their attitude and beyond the author’s use case, didn’t provide a reason for universally retiring ISO.
These days I tend to just run a local mirror of NetBoot.xyz for personal use. Not needed to use PXE booting professionally for around 10 years but I’m sure others out there might still be using it.
I do agree with you that universally retiring ISO is a bit dramatic. However I do think their usefulness is greatly diminished these days.
I'm not sure it does require loading the entire image. Servers (Dell/HP) that allow remote mounting iso images will use HTTP-Range requests to be able to 'seek' the disk. I _thought_ (but honestly don't remember) iPXE was capable of range requests too.
Having PXE has been helpful getting Linux on newer laptops. Saves messing around with usb sticks.
> I maintain that the ISO format has "had it's day" and needs to be retired.
Replace “format” with “file <for booting computers>” and most rebuttals would go away. There will always be edge cases, but this is again the author’s project, so their word is god.
This can also be a justfticaion to hold back technological progress on better formats, so it's a double edged sword. I won't speak for ISOs, but there's many widely adopted and highly unreliable file formats that make me wish they were dropped as hard as Flash was.
For the the web standards have replaced the use cases have improved the situation
Had the USB stick and related softwares for formatting been around sooner .img may have easily won the battle between standards. Unfortunately, CD-ROM was released 1985 and USB flash drives only started really showing up in the early 2000s. We have no way of knowing the counterfactual.
> Many old technologies are reliable and widely adopted, which in and of itself may make it superior to more modern technologies.
not as arguing that the tech is inherently better in itself, but that being popular for a long time carries benefits, mostly of the form "everything can use this" - consider FAT32, which I think we can all agree is... a product of its time (that seems like a nice way of putting it?), but which remains invaluable because (virtually) everything can read/write it.
That sentence did not end the way I expected given its start.
Survivorship bias does imply that old (surviving) standards are unusually good. That's because standards from the time would have a range of suffering qualities, and the really exceptionally good ones are much more likely to survive in use a very long time.
There are certainly decisions that have been made over the last 30 years that don't make sense in light of today's storage/power/ubiquity-of-connection that are just incumbent now.
At least we can slowly displace C with other languages, but those limitations were already obsolete in the early 1990s, and we are still wading through countless CVEs caused by them.
Ubiquitous adoption is an advantage for a given class of technology. This isn’t survivorship bias, it’s simply consumers finding a given technology useful to them and continuing to use it. Survivorship bias would have required ISO or img to fail and neither have failed (survivorship bias requires a non-survivor).
I can port an ISO between OSes from the early 90s through today. I can’t reliably do that with img as it may not use a universally accepted file system.
(And I did happen to burn a NetBSD ISO for a G4 last month from my M2 Air)
And, no, UDF isn't great either, but I wouldn't say it "has to die": it's a pretty convenient distribution format due to being widely supported, as it's really simple to implement.
So, this mostly seems to be a rant against live-CD-style Linux distros, since those are hard on maintainers (plus: toxic community multiplier)? On the one hand that might be true, on the other hand, the 'hey, here is how you get an ext4 or whatever filesystem in RAM' tooling around that is so mature and convenient that it's hard to see why, and I can't distill any real arguments from this...
I think the author speaks about the particular Linux distro, and with implications for more Linux distros which use live images on USB sticks* for booting and also* as a removable durable storage.
I think that the whole rant should be namespaced under "Live distro images" / "Puppy Linux", like "Why ISO image format should be retired from the live images of Puppy Linux", and not in the general case.
Admittedly that was some years ago, but you can still find fresh Github issues of lost souls who still use bootable ISOs
The first 3 parts aren't that complicated (literally a few sectors with fixed content, maybe a few pointer fixups), and no reason IMHO to want to kill off ISO. Generating that actual file system is the hard work, but also required for live-USB distros, which circles back to the point being made in the article eluding me...
ISO-9660 is good at the thing it was designed for, which is a read-only media. If it was made for USB sticks it would have indirect-blocks so that files could be trivially expanded.
It's not clear what the author thinks it the "death" of ISO-9660 would entail. It's not like it's the subject of constant development or is mandatory for anything other than optical discs. Perhaps he thinks he can influence a sudden and widespread removal of ISO-9660 modules from OSes, FUSE, and archive utilities?
Also not sure what's so difficult about it, I thought for the USB-stick case all you do is dd it onto the dev-node and you're good to go? IDK, maybe I'm wrong here, like I said I prefer using CD-R discs on the very rare occasions that I need to install a new linux distro because the alternative is backing up my entire USB stick so I can overwrite it with a new FS and then restore it from backup. And also I always have stacks and stacks of CD-Rs on hand because they're cheap as fuck and I need them for an old video game console which is the subject of my primary hobby.
The real alternative is to buy a few $5 USB sticks for the express purpose of installing Linux. Trying to use the same sticks for personal data and OS installs is an unnecessary headache with so many cheap and huge USB keys around.
If you want to burn CDs it should be to have more durable copies of some data, as USB keys have been known to lose data when left powered off for many months or years. I think I have never lost data that way but it is hard to tell if I did, on my oldest USB keys.
The posts make a lot more sense once I make that substitution. There are other errors too (for example, there's nothing stopping you from adding additional partitions in the hybrid case).
But I'm pretty sure there are quite a few "partition/filesystem/distro UUID/key/whatever" things that need to be wiped if you boot from an image directly, and this needs to be considered very carefully. Installing an OS twice should NOT be byte-for-byte identical, and if it is that's a security/reliability problem.
But /etc/ and /var/ in particular need to be system-specific regardless (even though you may be used to thinking of them as being on the same filesystem as /usr/).
System-specific bits like /etc/machine-id get created by the booted system; the installer doesn't need to create them.
Maybe there needs to be an "en_ISO" ("en_UN"?) locale that has:
1. Currency of "$"
2. Numbers with decimal point as "." and group separator as "," and leading zero on (absolute) values between 0 and 1
3. Day names of Monday->Sunday and the equivalent abbreviations
4. Month names of January->December and the equivalent abbreviations
5. Times in 24 hour HH:mm:ss format
6. Dates in ISO8601 yyyy-MM-dd format.
7. Timestamps in "pure" ISO so yyyy-MM-ddTHH:mm:ss[.ssss] and with a "Z" or ±HH[:mm] for timezone adjustments.
So I get it Etcher for someone who wants to do it on a USB stick is probably as easy if not easier than using cat or dd. I reckon I can probably create the ISO file with Etcher too. But I’ve installed countless distros and never had to download Etcher since I could always point the virtual CD to an ISO file.
Bonus point. I don’t need to learn anything about file systems and partitions and block sizes… it just works. I have no idea how these bootable medias work since I never had to make one.
That was one specific ISO in one specific use case. There’s probably a GUI that does all this automatically now. That one time, though, I would’ve sold a kidney for a dd-able image.
And of course I'm going to fit in the mold of an entrenched, elderly, "old timer", digging in his heels and I'll re-state a fossilized opinion:
In general, the ISO9660 format is great for distributing disk images for this reason: it's a mature, international, cross-platform standard.
This is not important for a Linux distro that can be set up with ext3/4. But if you distribute something with wide compatibility, you'll still consider making it ISO9660, because a Mac user can roll with it,* and a Linux user will have no problem, nor will a Windows user run into difficulty mounting and reading it.
Likewise, if you wish to generate this filesystem image, any of the above systems, and more, will have an app to create a standards-compliant ISO9660 image. In fact, most of the apps will help with staging all your data and assembling it into a nice package, that you'd otherwise want to make something like a build script to go from a bundle of files and data to a finished ext4 image.
But for Easy, and any other Linux distro, we've long ago phased out actual optical discs (my elderly fossilized brain recalls Knoppix as a revolutionary "live CD only" distro) so swapping in ext4 images may liberate some devs and support techs.
*I don't know actually--do Macs have built-in tools for ISO mounting? They had their own sort of ".dmg" file for "mount as a disk, install this software package", last I checked. And one popular extension is ".img", so Linux distros--stop confusing Mac users!
In general, the ISO9660 format is great for distributing disk images
for this reason: it's a mature, international, cross-platform standard.
MacOS can indeed mount supported ISO 9660 images from the Finder. One of the big advantage of ISO 9660 (and I assume UDF) is that the superblock does not conflict with the HFS superblock so you do both with relative ease. The other big one is that ISO 9660 is quite simple to implement compared to the alternatives.
Permissions are supported. I'd even say they are supported more than it is reasonable. It resulted in some rather painful mistakes when preparing a media if you're not experienced enough. I'm speaking not of an OS distribution, but rather of a quick CD you burned to share some files with your friend in 2004. You could make files only readable under root, unless CD is re-mounted with specific options which probably aren't available to a non-root user in the first place. You could set suid/sgid bits. You could set a userid which is useless on a target machine (can be remapped when mounting of course).
Whereas all you really wanted in the first place was just "r" (not even "rrr") for data files and "rx" (again, not "rxrxrx") for binaries and directories.
Curiously reading "man mkisofs" now I see there's an option "-r" which is like "-R but reasonable". This would've helped me a great deal back then, I wonder if it existed and I just wasn't aware.
Doesn't Linux give non-root users read access to the CD's block device? And with that, couldn't you read whatever files you wanted anyway?
That is not true at all, not even in the original version of iso9660.
And tou might argue UTF16 is a problem, but it is _strictly_ better than most UNIXy filesystems, that _do not standarize a character set at all_ and therefore leave that big part of the problem to you. Not hard to find ext images with mojibake...
That is not true at all, not even in the original version of iso9660.
it is _strictly_ better than most UNIXy filesystems
UTF-16 isn't great, and perhaps defensible at the time, but big endian UTF-16 is just asinine.
This is Microsoft in the 90s so we all know why we have competing incompatible extensions. Or rather, why there are exactly two competing extensions: the one every non-MS operating system uses, designed by the 9660 working group itself and released as an open IEEE standard; and then the proprietary MS one.
Anyway, as you can see, ISO is not limited to "8.3".
> NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here.
No, the opposite. If anything, ZFS is the exception, and I'm not particularly sure you are correct there either, as it will likely break some Linux users. But I can count the list of file systems that standardize a encoding with my two hands; _every other filesystem_ does not impose one. Not even FAT does...
Yes; it's supported by the same disk image framework as DMG. It's no longer usable for creating bootable images for Apple computers, though.
In a certain sense you're right that in practice dumping the bytes of a disc into a file is what gave people the files, but those discs did have a structure to them. I think what's being said here is that constructing an image in the iso 9660 structure is past its time
> EasyOS ships as a .img file, that is written to a drive. Barry stopped shipping EasyOS as an ISO file from early 2020.
A basic example tends to be CDs with copy protection; ISO can't properly handle the protection (since the format doesn't support it), whilst the .cue/.bin format is a more accurate representation of the disk.
You often don't need the disk in .cue/.bin, but in some cases you do want to store the copy protection as well (for example, with PSX emulation or if you very specifically want to digitize the disk itself, rather than the data on it.)
https://www.iso-accelerator.co.uk/news/post/how-many-iso-sta...
"The ISO Standards Catalogue comprises more than 25 thousand standards"
Maybe the author could start out by specifying which ISO standard they're refering to?
I have a blueray writer, but 50GB isnt really enough to backup files, 25GB definately isnt. The disks are a nightmare to get hold of, and unlike USB sticks, nothing can play the media on them, and the players that theoretically could intentionally do not by design.
Bootloaders are dodgy even without such a complication. Freeing oneself from all this may give just a moral sense of deliverance...
Windows has been multi-GB bootable ISOs for over a decade at this point.
You donʼt take into account case of booting real ISO on an old hardware. If it doesnʼt know DVD, chance of UDF support in BIOS is vague. More so, itʼs possible to barge in to a system without "no-emulation" support so the real boot part will be limited to 2880M due to floppy emulation.
Yep, all this is very old. UDF and no-emulation support appeared circa 2000. Bootable USB sticks appeared appoximately the same couple of years. En mass, these systems had been gone circa 2010. (Iʼm even slightly confused I still remember all these barriers, among with CHS addressing, geometry translation, etc.) So each boot media creator has to select what part of this legacy is to be supported... or drop it at all and orient only to a common base for last ~10 years.
Please do. Because this is weird.
I have absolutely no stick in this fight. I have always found it a bit weird to use iso images on usb sticks, so I'm with him there. But clicking through to his article about why iso needs to die, where he goes into the practical advantage of the img format, which is that you can have a writeable partition and still use the entire usb and not just the boot image, it's immediately obvious why you might not want that.
I mean, having a bootable usb that you can also write to is fantastic if you want to have a portable installation with everything you like that you can take with you anywhere. But if you just want a read-only medium from which to install something to dozens of machines, you don't want anyone writing to it.
So I think these are simply two different use cases.
People, mention the numbers please.