[tjoff]

I have no idea how I would install EasyOS in my hypervisor. Well, I could probably boot from a Live linux ISO and then install it from there.

And on actual hardware I can mount an ISO over IPMI but I would not immediately be able to install EasyOS that way.

Also, the argument that you can store state isn't always an advantage. When I boot a Live ISO I never ever want to save anything, a clean state is one of the features of a Live ISO.

I don't know what EasyOS is, and it is for sure possible that it lives in a niche where it never makes sense to have an ISO. But I don't get the crusade against ISO.

>There are some multi-boot tools, that enable putting many ISO files on the one USB-stick; however, the ISO format does not have any intrinsic avantage, these boot managers could also be made to boot image files.

Well, they don't. Maybe that ought to be a hint?

[mtlmtlmtlmtl]

Never heard of EasyOS either so I looked it up. It's definitely in a pretty interesting niche:

In a traditional "full" installation, the filesystem occupies an entire partition, with the usual /etc, /bin, /usr, /proc, /sys, /tmp, etc. Easy does not install like this. Easy installs to hard drive in what we call frugal mode, which occupies just one folder in a partition, allowing to co-exist with whatever else the partition is used for. Installation is so simple: Just copy three files 'vmlinuz', 'initrd' and 'easy.sfs' into a folder in any ext4 partition, and that's it, Easy is installed. All that remains is to create an entry in the boot manager. [1]

Generally seems to be a highly stripped down, security focused Linux distro. No systemd, polkit, or even PAM. Heavily container oriented. Feels a bit like a lighter alternative to Qubes OS.

[1]: https://easyos.org/about/how-and-why-easyos-is-different.htm...

[yellowapple]

So basically the same deal as Tiny Core Linux, then.

[marcosdumay]

Well, the article is correct that there is nothing unique to ISO on your comment. You can achieve all of that with an EXT-4 or NTFS filesystem too.

Our tooling evolves in some strange ways. The only reason you want an ISO is because some software insists that it can't use a simpler FS the same way. It's like the software that insisted on saving things into floppy drivers even after no computer had them anymore.

Of course, that software existing may be a good reason for the author to keep the ISO packaging. Or maybe not, I have no idea what is his context. But what you describe is a deficiency on your software, and not any intrinsic benefit from ISOs.

[tjoff]

Obviously, but with that logic the only unique thing with his solution is that it doesn't work well in the software ecosystem of our time. Not a great selling point.

It is more than fine to opt at not supporting ISO, but the arguments put forward for this crusade are not convincing.

[JohnFen]

> the arguments put forward for this crusade are not convincing.

I agree. They read like "I don't want the additional work of creating ISOs" to me. Which, honestly, is plenty good justification for not making them on its own. There's no need for further justification.

[prmoustache]

Why wouldn't it work well with your software ecosystem. All hypervisors allow booting from a disk image. If not you wouldn't be able to boot your installed OS!

[theamk]

ISO is great at keeping things immutable - most OSes auto-mount inserted USB sticks r/w by default, so your ext4 USB rescue stick cam be broken by one accidental mouse drag, or by a typo in "rm" command. And even if you fix one OS to not mount it r/w, it will still happen if you insert into your friend's PC.

On the other hand, ISO is guaranteed to be immutable, you need some real effort to break it.

[brazzy]

Immutability is not a property of the ISO file (system) format, it's a property of having it live on an optical disc.

But most computers these days don't have drives for optical discs, and if your ISO is merely a file on a USB stick, then it can be broken just as easily.

[winternewt]

Maybe in theory, but not in practice. Because no ISO fs implementation has support for writing to a mounted image.

I'd argue that even in theory the immutability is kind of a property of the image format, since it doesn't have file or free space fragmentation. So whenever a file grows or shrinks you have to regenerate the entire image.

[tremon]

This is not true, ISO9660 was designed to be a read-only filesystem: it has no concept of slack space nor sectors in the traditional sense. Every file and directory entry on ISO9660 consists of a single extent (contiguous number of sectors). If your file or directory entry needs to grow beyond its current size, you must create a new copy of the entire entry and append it to the image.

The only writable filesystems that use the same allocation strategy are log-based flash filesystems, but they also have support for quickly scanning the filesystem to get the most recent snapshot state. Again, ISO9660 does not have that because it was not designed to be writable.

[brazzy]

The point is that an ISO image is just a file, and if that file is on a USB stick, it can be accidentally overwritten or deleted, same as any other file.

And if someone really wanted to (in a black hat scenario), it would absolutely be possible to rewrite an ISO image on the fly to modify individual files.

[theamk]

No, once written to USB stick, ISO image is not a file anymore, it is a sequence of blocks outside of any filesystem. This means you need to use special raw disk tools (like dd) to modify it, and you can no longer operate on it using file managers, "ls", "mv", "rm" and all the related stuff.

You are correct that in black hat scenario, one could rewrite ISO image on the fly - after all, that's what I do when I upgrade my bootable USB stick to latest version.

But while ISOs are not perfect protection against malware, they are _great_ against accidental modification. On my PC, when I insert USB stick, the window pops up right away, and it takes 1 (one) mouse drag to make drive unbootable. No such problem exists with ISO images.

[dicytea]

While this article claims that it works with Ventoy, recent posts (by the same author himself) suggests that things aren't so clear and sunny: https://bkhome.org/news/202303/easyos-455-does-not-work-with...

A good final half of the article is spent on blaming Ventoy's developers and users for holding it "wrong". And here I am left still wondering what is so bad about ISOs.

[burnte]

Agreed. The author is discounting the ease of use argument, which frankly is the last argument you should make, especially when the cost is effectively ZERO. Frequently good enough is really good enough.

[bragr]

I skimmed the docs for multiple hypervisors (qemu, vmware, virtual box, hyper-v), it looks like only Qemu can directly boot the raw image, but everything else can convert the raw image to a native format and then boot it. It does take an extra, often command line only step to get it booting though which is less than ideal.

[anonymousiam]

This is a feature of QEMU and not the raw image itself. Most hypervisors have a preferred image format. The two most popular ones for QEMU are qcow2 and raw. Others such as vdi and vhdx can be easily created with the qemu-img tool, which allows easy conversion between image formats. I've successfully run the same raw image in QEMU, VirtualBox, HyperV, and VmWare just by converting it and booting it.

[tjoff]

Assuming you even have access to the storage repository where your disk images reside. Which you don't immediately do in many cases.

Yes, for sure it can be done. But unless you have a habit of doing it it is likely going to be much quicker to boot from a live ISO and do it from there. And by then it all seems rather ridiculous.

[dale_glass]

Seems easy. Import it as a disk image, and that's it.

I just tried under libvirt. It doesn't work as a virtual CD, so just add a virtio disk and point it at the image.

[tjoff]

For sure when that works that is easy. I don't have that option and don't know how common it is in actual hypervisors and not desktop VM software.

[yellowapple]

If it works for libvirt then that's at least one pathway for an "actual hypervisor" (in this case KVM).

[eptcyka]

Your hypervisor can boot from any file with bytes in it that the bootloader will handle. There's no dependency on the file being in ISO format.

[rezonant]

> Well, they don't. Maybe that ought to be a hint?

The author was saying that these tools already do support booting image files, not that they could be modified by the tool authors to add support.