Why the ISO format has to die | Hacker News Reader

Why the ISO format has to die

easyos.org

95 pointsauraham91 comments

The author could use a bit of humility.

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.

I personally wouldn’t recommend ISOs for PXE booting longer. It requires loading the entire disc into memory first which is going to be slower than purpose built netboot images.

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.

> It requires loading the entire disc into memory first which is going to be slower than purpose built netboot images.

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.

In fairness, last time I used ISO with PXE was on BIOS systems. More recent iPXE kernels (if that’s even the right word) might support seek.

I wouldn’t use PXE at all! But I’ve been out of the computer imaging business for a long time, now. The folks that do that where I work simply activate Windows with Intune on first boot from the manufacturer, similar to how Macs are activated.

PXE is still useful when you want to setup ~200 servers which are freshly installed in your racks and they have no OS on board, or when they need to be reinstalled in ~10 minutes, so you can revive another cattle in short order.

In my former industry, and my former line of work, we would never trust the integrity of an OS image on an SSD delivered from the manufacturer by standard courier (not e2e receipted CoC) without some means of verifying it on the receiving end e.g. checksum. Easy to do with network hardware, harder with PCs. Much simpler to just PXE-blast all the devices when they arrive.

It's quite a different world with Windows Autopilot pre-provisioning from the OEM. These images are customized to your specs, there's no Candy Crush shipping on pre-provisioned devices.

Windows Autopilot uses a PXE boot, where appropriate.

But how do you get Windows installed on the computer, for example if the disk is replaced?

Back to the manufacture it goes! Not a big deal in a medium to large business. I'm unsure how a small business would deal with it, but the smaller you go, the less likely you'd have a standardized image.

I think you probably skimmed my comment because I said personal use.

Having PXE has been helpful getting Linux on newer laptops. Saves messing around with usb sticks.

A good example of old and reliable technology is MIDI. They have been trying to replace it by buggy and overly complex standards for decades. Yet, the old 5-PIN MIDI cable (and associated protocol) keeps rocking.

I think I read the article s bit differently. The headline is a bit click-bate, but in the article they never state that the format has to die in general, but that this distribution has killed it of, with explanations on why that is.

I agree, the author appears to conflate file and format. From a complete reading of this post and the author’s previous post on this topic, I read it as discontinuation of distribution of the ISO file, but in both posts they use the wording “ISO format” almost interchangeably.

> 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.

Right, the expanded title would be ".iso format" not "ISO 9660 format".

>Many old technologies are reliable and widely adopted, which in and of itself may make it superior to more modern technologies.

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.

You are right, but I think the other reply is basically saying we should not try to fix solved problems. If we have a working and reliable solution that isn't the property of one specific entity or domain, there's not a compelling reason to call for change.

There never was a good reason to drop Flash.

You're probably remembering flash games fondly. Flash as an enabler of creative teenagers. But back then flash was used for a lot more; it was pretty common for entire websites of businesses to be built as terrible flash apps. Want to look up a local business's hours, menu, phone number? You had to have flash installed, had to navigate whatever harebrained animated UI the owner's nephew had created, and hope it didn't crash your browser. Never accessible, never performant unless you had a very powerful computer, and it would always spin up your fans. Less savvy users wouldn't be able to identify the problem and would leave flash pages open in the background, then conclude they had to buy a new computer just to get work done again.

It was a binary plugin with supported platform at the whims of Adobe, it often had security bugs and sandbox escapes, it had bad performance and killed mobile battery.

For the the web standards have replaced the use cases have improved the situation

Adobe ownership is a perfectly good reason

While the original ISO standard may still have its use cases, your argument involves survivorship bias - just because a technology has been around a while doesn't make it superior. Your false belief that its long life in a group of other standards - is rather a coincidence that is in correlation to its long life and not a cause of it.

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.

I would read

> 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.

> your argument involves survivorship bias - just because a technology has been around a while doesn't make it superior.

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.

The potential problem though is that the surviving standard may have been the best for a reason that's no longer relevant.

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.

For example, the inherent unsafety of many C operations and a long list of undefined behaviors in the language, which was meant to improve compile times on long forgotten processors whose performance would no longer suffice to manage a LED lightbulb.

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.

Didn't say superior, useful. The rest of your comment in quintessential angry performative hn.

When discussing whether something should be killed, survivorship isn't a bias — it is evidence. Otherwise the whole process of evolution by natural selection would just be ongoing "survivorship bias".

I said “may”, not “must”. Please don’t put words in my mouth — you have no idea what my beliefs are behind your keyboard. Thanks.

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)

What a strange article. What's called an 'ISO' is, these days, pretty much a thin wrapper for an UDF file system -- you can definitely use it differently as well, but I'm pretty sure nobody has created, say, an ISO9660 plus Joliet plus El Torito image in the past decade or so.

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 *.iso, referring to the customary extension of ISO9660 image files.

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.

Oh I'm sure people still use El Torito today! I remember having to go through that to boot my hobby OS.

Admittedly that was some years ago, but you can still find fresh Github issues of lost souls who still use bootable ISOs

Yeah, but I'd call that 'remnants of El Torito'? You basically have tooling to burp out the MBR, boot catalog and UEFI FAT32 shim, all pointing at the native code that can read your actual (very-much-non-ISO9660) file system into RAM and bootstrap it, and you're good to go on USB, ISO, or whatever.

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...

Live CD is mainly replaced with live USB, even if it is called the same nickname.

Whatever dude, I actually do still use CDs but it's not like I care about your distro anyways so go ahead.

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.

>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.

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.

I think the author is confusing "ISO format" with "read-only install media".

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.

Why would it be a security problem if installing an OS twice was byte for byte identical? Don’t distributions (like Fedora Silverblue) already do this?

Mainly cryptographic keys like the SSH host key, or stored RNG state. But this can very easily be mitigated using `cloud-init` or similar.

I'm not sure if they actually share /usr or unconditionally rebuild it on each device (after all, they do need to handle different sets of installed programs).

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/).

> But /etc/ and /var/ in particular need to be system-specific regardless.

System-specific bits like /etc/machine-id get created by the booted system; the installer doesn't need to create them.

You can just leave those entirely empty these days.

"ISO format" could mean a lot of things, I'm happy this is not about the date format (ISO 8601)

That needs more use! It needs to be an easy to use locale on Linux, and KDE needs to respect the locale which version 6 still doesn't!

There is (used to be?) locale of "en_DK" (or English language for Denmark) that combined English month/day names with ISO8601 dates.

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.

8. DIN A4 paper size

9. Metric units where possible

There are many ways in which ISO files are useful. You have native support in Linux and Windows (you can mount). You usually also have support in virtualization or emulation software like VMWare Parallels, VirtualBox, HyperV…

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.

According to:

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?

Damn straight. One time I wanted to use an ISO with a USB stick and it turned into such a giant pain in the ass that I wrote up all the instructions. I still get a ridiculous amount of traffic on this blog page: https://honeypot.net/2011/10/11/making-dos-usb.html

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.

But you can get what you want without needing to kill off ISOs for people who need that format instead, with a hybrid ISO, like most other Linux distros already do.

Did you try https://www.ventoy.net/en/index.html? Ever since I found about it a few years ago ISO has been painless.

I would say that's fine for Easy to drop their ISO9660 distribution format. The rationale makes good sense.

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.

ISO 9660 is a standard, yes. But what's actually standardized by ISO 9660 is exceptionally limited. Filenames are limited to 8.3 with a quite small character set literally just A-Z, 0-9, _, and a single dot. There are competing long file name standards, Microsoft's uses big endian UTF-16 as is tradition. The RockRidge extensions define support for POSIX semantics, unsure how well supported the POSIX permissions are.

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.

> The RockRidge extensions define support for POSIX semantics, unsure how well supported the POSIX permissions are.

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.

> 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.

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?

> Filenames are limited to 8.3

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.

ISO 9660 Level 1 specifies 8.3, Levels 2 & 3 allow up to 30 characters. There is room in the structure for longer names but that is not standard compliant which is why you have competing extensions for LFNs.

   it is _strictly_ better than most UNIXy filesystems

NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here. Joliet being UTF-16 isn't better it's roughly the same. RockRidge allowing UTF-8 isn't much better because most stuff will still encode RockRidge with big endian UTF-16.

UTF-16 isn't great, and perhaps defensible at the time, but big endian UTF-16 is just asinine.

> which is why you have competing extensions for LFNs.

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...

Double-clicking on an ISO file on macOS mounts it provides the file system is recognized. Read-only though.

I think Windows does the same

> I don't know actually--do Macs have built-in tools for ISO mounting?

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.

Apple’s New Disk Image Format used the img extension. Fortunately not something you see anymore.

Isn't the .iso "format" just a byte-by-byte dump of a disc? Just like how a .img is a byte-by-byte dump of... whatever drive? What does it mean that that one of these "formats" to "die"? How do you kill a "format" that's just a straight copy of something?

Nah, there are specific formats for isos. The full spec name is ISO_9660 https://en.wikipedia.org/wiki/ISO_9660

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

I don't think that's what they're referring to? If that's what they mean, then it's very confusing -- and makes me think if they themselves are confused. It's like saying "we should stop shipping Joliet files" or "we should stop shipping UDF files", which makes no sense. ISO 9660 is a filesystem, not a "file format". Yet they write:

> EasyOS ships as a .img file, that is written to a drive. Barry stopped shipping EasyOS as an ISO file from early 2020.

It's possible I misread it, but fair point on the .img file call out. I suppose I used to refer to .iso files as a file format given that's how I used to interact with them so that terminology read as natural to me.

I presume they mean the standard hybrid ISO9660 LiveCD format that Linux distros tend to use. There's a lot of nuance there that I haven't touched in years but needless to say between having multiple boot paths (I think like three--El Torito, BIOS boot sector, and UEFI) and very different media (CDROMs are, well, ROMs, thumb drives are writeable) there can be some complexity if you want to handle some more sophisticated portable OS stuff than just "run the OS installer". I'm sure this is particularly important for persistence, which can sort of be done with "traditional" live media but requires some special effort.

Not quite; there's cases where a .iso will actually miss certain data, since they're just dumps of what the OS recognizes as data; you tend to lose some metadata in the process. It's usually irrelevant (especially for data storage disks, which are most of the medium), until it isn't and then the format stops working.

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.)

The disc (as in a CD disc) has a format specification that is recognized by the boot firmware. That is what is being copied byte-by-byte, such that the USB drive appears as if it was a CD ROM.

See https://news.ycombinator.com/item?id=40733040 for previous discussion on this decision. tl;dr: it's not hard to support hybrid ISOs, and there are still a lot of legitimate reasons to want an ISO.

As somebody who deals with game ISOs all the time (whether old PC games or old console games), I'm left mildly confused by the comments saying ISO is irrelevant. There's tons of media out there where the sane way to distribute them is as an ISO.

No, the format has not to die. Just some of its usages.

Yes. I think there is likely better options to make bootable USB sticks. And those should be used instead. But for making data CD or DVD. ISO is entirely reasonable. Quite limited case nowadays, but still reasonable.

Theres probably a fairly good back story here around how all the encryption garbage basically killed blueray - it won the battle, lost the war.

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.

What a useless page. Maybe put less effort into insults and put the actual explanation front-and-centre rather than burying it in a linked page.

Really I would have concur with the author if dealing again and again with a need to fit the media contents into 650MB (if it is intended to be put at real ISO) or to guarantee how combination of 1) realmode bootloader + 2) UEFI bootloader + 3) ISO-only thunk + 4) UDF volume bizarrely interlace in a single byte stream.

Bootloaders are dodgy even without such a complication. Freeing oneself from all this may give just a moral sense of deliverance...

You're not limited to 650MB provided you use UDF rather than ISO 9660. UDF supports up to 16 EiB. It's still a "real" ISO, but obviously you'd need to stay within DVD size limits to use physical media.

Windows has been multi-GB bootable ISOs for over a decade at this point.

> You're not limited to 650MB provided you use UDF rather than ISO 9660.

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.

Windows shipped on DVDs. I'm not sure why you made your comment. Of course a system must support it, and plenty of ~20 year old systems did.

Was expecting gripes about ISO 8601 format

What's his actual objection though?

This is just a rant.

> Barry will continue the rest of this page writing in the first-person.

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.

isnt the ISO "format" just a disk image, same for .img, when you run `dd if=file(.iso|.img) of=/dev/sda` you're just copying the bytes from one file to the other, so what really defines the .img or .iso "formats" other than the file extensions?

I came in here thinking I was about to witness some slander against the ISO8601 date time format.

I don't think that tools like ReaR (Relax and Recover) would agree with retiring ISOs..

The installation guide has about 27,000 words. Doesn't sound too easy to me.

(9660)

*ISO disk image format I was thinking about film.

I thought first it was about ISO8601, but it’s about ISO9660.

People, mention the numbers please.

Reply on news.ycombinator.com