Some time ago I stopped releasing EasyOS as an ISO file, from then onward as a drive image file only. This has been contentious, and I receive emails from people lamenting the demise of the ISO. So, I should post some thoughts why I made this decision. Not an exhaustive rationale, just some thoughts while I think of them right now…
The ISO9660 file format is very old, going right back to 1988, and has since then had enhancements bolted on, see the Wikipedia ISO9660 page. In addition, there is the “hybrid ISO”, enabling booting from a USB-stick, and on top of that enhancements to enable booting from either or both legacy-BIOS and UEFI firmware computers, see here.
I think I agree. ISO files have become a bit of a headache lately, and I’d much rather just use a straightforward image I can dd to a USB drive.
Erm, most of that article is “rubbery logic”.
ISO9660 file format is old, but it’s standard, and you don’t have to bother with any of the extensions unless you really want to. It only becomes a “hodge podge of changes bolted on” if that’s what you want your ISO to be.
Note that “hybrid ISO” is not an actual standard. It’s a hacky pile of crap that violates ISO9660 specs (which explicitly state that the first 16 sectors must be zeroed, likely so that old drives have “lead in time” to get themselves synced and don’t need extra logic for the “seeked backwards to before the disk’s start” case) while also failing to work properly for USB (where things like partition tables need correct info for CHS for BIOS, or correct disk size for GPT to get the secondary/backup partition table at a location that actually complies with the UEFI/GPT specs). It can’t be “guessed correctly” by any kind of image file (without device knowing the specific device’s characteristics).
A drive image file, in comparison, can also not work properly – it’s the same hacky pile of crap as “hyrbid ISO on USB” where you can not get it right. Correcting the originally wrong information on first boot is likely to cause compatibility problems with various system’s firmware on first boot, plus potential compatibility problems with any OS that sees the device before it gets booted. In other words, this “fix our stupidity on first boot” solution is just another hacky pile of crap (being used to hide problems caused by the first hacky pile of crap). The only correct way to do it (to maximize the chance that it’ll actually work on all computers rather than just most computers) is to provide some kind of tool to create the image to suit the drive (like Microsoft does); but then you either need some way of booting an OS to run the tool which is painful.
Creating a USB-stick that is (temporarily) “mostly unusable” (mostly unused) is considered to be acceptable any person with more than 3 brain cells; because you use it once then reformat it. There’s no sane reason to care about the “mostly unused for an extremely short period of time” space. Also; now; most ISO images are used for things like virtual machines and not actually burnt onto a real physical CD; so the “(temporarily) mostly unusable/unused space” problem doesn’t even exist for the most likely scenario.
Of course the “obviously always better” approach is to provide both ISO and the hacky pile of crap. It’s not like creating a bootable ISO image is difficult (or that suitable tools haven’t existed for decades already). It gives me the impression that Barry is just making up bullshit to justify their home-grown flavor of hacky crap with no valid reason (other than being lazy and sucking) to discontinue ISO.
Brendan,
Yeah, ISO isn’t hard to support and my OS build scripts still support it. But it’s true hard disk images and ISO images were never designed to boot as one and it’s a total hack, like compiling a binary that is in both linux elf format and windows PE format. It’s interesting that it the ISO/HD hack actually works at all, in large part because the partition tables are mostly empty/unenforced bytes, but nether of the technologies were designed to work together.
It takes no effort to to continue to build ISOs automatically, but the author clearly assumes nobody uses them anymore.
I’d still say that I prefer ISOs when booting into VMs because it keeps the drive mappings predictable. If you start with a HD boot image to install to a secondary HD image and then remove the first HD image…between the bootloaders and file mounting, some things can get mixed up. There is ambiguity as to whether the HD image/bootloader on the initial disk is supposed to be a permanent primary or if it’s only for installation after which the second disk is meant to become the new primary on next boot. With CDs the concept of booting via secondary boot mediums is perfectly natural.ambiguity.
Anyways, I don’t know how many people are using CDs/ISOs these days. I agree with you Brendan that he hasn’t provided a technical reason or deficiency not to release ISOs other than he just stopped caring.
Reminds me of this C runtime library:
https://github.com/jart/cosmopolitan
(The same EXE) “…that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.”
Nothing wrong with “polyglot” binaries or even source code that is valid for different platforms or programming languages. And “hybrid” images do work in practice. I don’t think many people will care if an older CD-ROM drive cannot parse the header file. It is unlikely that computer will be able to boot the included OS anyway.
“the author clearly assumes nobody uses them anymore”
Well, the author should know better. This kind of thinking is what can make our lives harder by unnecessarily disrupting known processes. Some well proven, well known and still very much widely used standards are still here for a very good reason. Both approaches the author talks about are old enough and known enough. The author dropping one of them does not benefit his user base, since their options have just been reduced. As he also states, it’s simple enough to build both versions, so, trying to reason that one of them is just too old or too stupid, and it shouldn’t be used anymore is not a valid argument. It’s not hard to build, people know it, and use it (yes, they do), so it should be provided.
I read the article and it mentioned that he retired ISO format because the drive-image-file is more suitable for a feature of EasyOS: persistent storage. Using drive-image-file to boot EasyOS from an USB stick, the user can save data into the same USB stick. The user can’t do that if an ISO image is used to boot.
You’re right (that persistent storage is a likely motivator); but…
Half the time people are using it as a toolbox to fix another OS, or are just trying it out before installing the OS properly (which could include using an actual CD to install the OS on a USB-stick properly), or are using it in a portable “no tracking” way for security reasons (e.g. just to access online stuff with the knowledge that they might lose the USB stick and don’t want whoever ends up with the USB stick to get any information); and don’t need or want any persistent storage.
The normal/easy way to deal with it is to just use a RAM disk (and maybe provide the option of mounting something else, like a networked file system); so there’s very little difference (for tools, applications, etc) between a version of the OS intended for read-only media and a version of the OS intended for read-write media.
In other words; wanting to support persistent storage (for some people) is not a valid reason for not supporting ISO (for other people).
Brendan,
Many servers have the ability to remotely mount ISOs using built in remote ip KVM functionality. Many external KVMs can do this as well by emulating a CD-rom.
https://clients.swiftnode.net/index.php?rp=/knowledgebase/9/Mount-ISO-to-KVM-over-IPMI-Lantronix-Spider.html
So if you have a server at an offsite data center, you can manage the whole OS and even do remote installs. Without ISOs admins would loose this ability. This is admittedly a niche use-case, but one that nevertheless makes ISOs extremely compelling for some.
You are right.
IPMI, iDRAC, or even PI-KVM will boot remote floppy or ISO images. But I don’t remember seeing a “generic USB” option so far.
Whilst the market is small and the use-case is not exactly publically known, it’s hardly “niche”, when there’s likely millions of sysadmins out there that will need this functionality at least once a year.
ISOs are also handy for manual (or many scripted) VM builds – you don’t have to worry about converting the virtual disk into *just* the right format for the target (eg, the number of slightly different, incompatible VMDK formats out there is irritatingly high), uploading it into the store and then building an image around it, and hoping it boots. You just point the virtual CD drive at the ISO and away it goes.
And when you have a quirky setup where something just won’t boot, usually the most reliable way of getting the software into the machine is going to the old CDR spool and burning a disk.
FWIW, disk images seem to work OK in HP’s ILO if you mount them as a floppy from the KVM app/page. The process I used to create my own (which is kinda ugly):
– Create a QEMU VM with a raw disk
– Boot and install whatever OS (I think it was CentOS) FROM ISO!! 🙂
– Take the RAW image and mount as a floppy in ILO
Being R/W worked for what I was doing, but generally is annoying. I don’t want my install media for servers getting subtlly (or not subtly) modified. I’ve actually seen a mounted ISO via iLO get changed/corrupted during an install process. I have no idea how that worked, but we had to make sure to always make a copy of the ISO, use it for the install, and then delete it because it’d never work correctly again.
MattPie,
I don’t know if I’m understanding you right, are you suggesting that ILO does not enforce a floppy size limit and that therefor you can (ab)use the virtual floppy option to map a hard disk image to it instead?
That’s interesting and a bit surprising that the local BIOS and OS would accept this.
That’s bizarre. ILO shouldn’t even be opening the ISO as writable IMHO.
dungsaga,
Even if persistent storage is a consideration there’s no technical reason that persistent storage cannot be placed on any arbitrary writable disk partition.
Had the author checked, he would have found that he was not the first to solve this exact problem and I’ve personally used persistent storage from a bootable CD with no problem.
https://www.pendrivelinux.com/knoppix-linux-live-cd-and-usb-flash-drive-persistent-image-how-to/
You could install new software and everything…now personally I’d just install it locally at that point, but the fact remains there’s no technical reason persistent storage must be mounted on the CD. Persistence storage in EasyOS could work just as well as it does in other CD bootable distros, but he probably just didn’t care because he lacks the motivation to support CDs and didn’t think about the solution.
Also, like Brenden said, for some users booting into a clean environment is actually desirable and the read only nature of CDs could be a pro and not a con. Either way I find the author does not have a good technical reason to deny users the ability to use ISO other than he just doesn’t want to bother with it any more, which of course is his prerogative.
Alfman,
I agree that the read-only nature of ISO image and its wide support are good reasons to keep using it. But the article pointed out that the author wants persistent storage on the same USB stick used to boot up. He doesn’t want to ask the user where to save data. And he uses a disk image containing 2 partitions (1 for boot, 1 for persistent storage) instead of hybrid ISO.
This is unfortunate. Because hybrid ISO is also a disk image containing the ISO image in a partition. He can add another partition here and have the best of both worlds.
dungsaga,
There’s nothing technically stopping EasyOS from being able to do both as other distros have done. He’s dropping ISOs not because they’re negatively impacting EasyOS but because he’s completely lost interest in supporting CD-roms. And you know what that’s fine, it’s his project and his call. But it doesn’t mean his call is right for everyone else…
https://forum.puppylinux.com/viewtopic.php?p=43788#p43788
https://forum.puppylinux.com/viewtopic.php?p=43826#p43826
I don’t see the problem the author alludes to as being a huge issue for anybody. One solution could just be to automatically default to USB storage when booted from a USB drive. There’s really a bunch of solutions, but I think his mind was already set on dropping CD roms anyways.
This is something I have found to be very useful in Haiku too. The ability to write to a mounted drive that is a file is very useful.
Earl C Pottinger,
This was quite useful for me too back in the day when I was a windows user and wanted to try out linux without having to reformat windows partitions. For someone who’s just picking up linux (or Haiku, etc) this is a viable solution with minimal modifications to the host environment.
All these can be fixed if you use something more sophisticated than DD to generate the USB disks.
Even Windows has an open source* ISO tool that will generate a bootable USB (NTFS if I recall correctly), by expanding the contents to a new partition. (* open source, since they were found copying a GPL’ed project).
If you use a modern tool like Rufus, YUMI, or even unetbootin, ISO or images do not matter as much.
For reference:
Rufus: https://rufus.ie/en/
Unetbootin: https://unetbootin.github.io/
YUMI: https://www.pendrivelinux.com/yumi-multiboot-usb-creator/
YUMI is especially good to build your own multi-disto “swiss army knife” USB solutions.
I have no opinion on ISO files other than viewing them as a container which a given tool can read and/or write to a given medium. As long as the support is there it doesn’t matter one bit to the generic user what is behind this as long as it works. Some material will continue to be stored in ISO format or need to be written to ISO format so it’s a good idea to keep this functionality around. The code space required is trivial.
From the comments in here it seems the author may not have considered context or knock on effects of declining to continue providing ISO support. It can be a bit like stripping out “junk DNA”. That “junk” actually does something…
Interesting! It’s a bit of shame though if you want to boot EasyOS. No go, apparently.
U-turn in 5…4…3…
https://www.theregister.com/2021/12/10/friday_foss_fest/https://www.theregister.com/2021/12/10/friday_foss_fest/
HollyB,
I think your link pasted incorrectly:
https://www.theregister.com/2021/12/10/friday_foss_fest/
https://www.ventoy.net/en/index.html
Yes, there are many good tools to manage bootable USB drives. Ventroy seems to be new for me, thanks for the link.
Funny he advocates moving forward and dropping old things, yet his own website doesn’t even have support for ipv6?
EasyOS is based on the UNIX OS design. He’s clearly picking and choosing.
ipv6 is 26 years old
NaGERST,
I never was able to get it at home (unless you count ipv6 over ipv4 tunneling). All these years after IPv6 day and so many of us still depend on IPv4 🙁
As a retro enthusiast i prefer ISO standards to be followed so that they do not pull a bullshit move like on the mac where some images was in HFS and not browsable on other systems.