31–40 of 86 posts
If you don't provided a convenient means to test your tiny OS, I'm not going to jump through hoops that could've been automated and solved at the scale of 1 release process vs. N users.
> So, I am repeating, there are no use-cases where the ISO format has an advantage over a Linux distribution as a drive image file. The perceived advantages are only due to ignorance. This is paradoxical statement: overcoming said ignorance (read: ease of use) is by definition an advantage (actual, not just "perceived")
If the governance of this tiny distro is bad, don't worry, there are a million other tiny distros to choose from.
I often feel we missed a chance to make booting from removable media real easy. If we had built ISO support into EFI, you could just copy an ISO (like a container) to a MBR or GPT partitioned thumb drive and boot it - no magic tools required, no bits to set. Yes FAT32 has a 4gb limitation, but there is nothing saying that couldn't be fixed with future versions of EFI, or by using multiple partitions on thumb drive. E…
Ventoy is a magic tool that does exactly this, if you weren't aware.
They replace the iOdd virtual CD USB device in all virtualized cases. For physical servers, the iOdd virtual ISO USB drive is very handy.
Earlier quoted context omitted.
That's the point of the "hybrid-iso" format; you can dd(1) it to a USB drive and it will boot, and you can burn it to a CD/DVD and it will boot. P.S. there's no reason to use dd(1) for this; cp(1) works just as well and is usually faster, since it can autoconfigure the block size.
To make a windows bootable USB you need windows. Doing dd (or cp) will make a device that boots the installer but ultimately will fail to install.
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 feat…
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.
For the specific case of "burning" some Linux distro's installer to a USB drive, I've always found those .img files much easier to deal with than ISO files, simply because a single dd(1) invocation is all I need to "burn" the image onto my drive. I figure this is probably the vast majority of people who install Linux from a physical device rather than network booting. (I have dealt with PXE about a decade ago but I c…
That's the point of the "hybrid-iso" format; you can dd(1) it to a USB drive and it will boot, and you can burn it to a CD/DVD and it will boot. P.S. there's no reason to use dd(1) for this; cp(1) works just as well and is usually faster, since it can autoconfigure the block size.
/path/to/device
I guess I've been lucky not caring about the block size
I've always wondered, why are CDs a specific ISO file system and not just whatever the intended target can read (FAT32 / HFS(+)) like other media? Is it just that the write once nature of the media makes pre-composing the file system a pain?
I suspect the ISO standard was more of a product of the traditional electronics industry than the computer industry.
I've always wondered, why are CDs a specific ISO file system and not just whatever the intended target can read (FAT32 / HFS(+)) like other media? Is it just that the write once nature of the media makes pre-composing the file system a pain?
I think it's sort of the opposite. Read-only/write-once file systems can be simpler because they don't have to be structured in a way that allows things to change. For instance, full file systems generally need to deal with files that are laid out in a non-contiguous manner on the disk since files may change in size after creation.
I think the other aspect is that in the early days of CD-ROM a lot of folks envisioned there would be a lot of use cases that transcended a single operating system so having a universal file system for them was useful. And while some of the grander visions may not have won out, distributing plain data (photos, clip-art, etc.) on CD-ROM was a common use case and benefited from a cross-platform filesystem.
I'm surprised that didn't come up in the original article or comments here on HN.
(I am aware of course of non-persistent in-memory worms, and the fact things can persist in places other than the filesystem, but I presume they are much rarer.)