Hacker News Reader

Comment by RcouF1uZ4gsC | Hacker News Reader

Windows 95 was a marvel of pragmatic engineering. While it won’t win any awards for purity, it did a great job of delivering real value to people while still allowing their old programs to run. FAT32 was a major part of that.

View on HN

Except this wasn't the original Windows 95, this was OSR2:

"FAT32 was introduced with MS-DOS 7.1 / Windows 95 OSR2 in 1996" [1]

OSR2 fixed many nasty problems with the orig. Windows 95 which was released in the summer of 95. The next Windows 9x version was 98.

When I see people talk about Windows 9x I feel like they don't remember the negative. BSOD were common in Windows 9x. The first Windows version with which I've had a stable, satisfying experience was Windows 2000 (at work I did use some version of Windows NT 4; it could've been the network but it had quirks and was slow. Had to be early 10 min just to fire up computer).

[1] https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

Indeed. Windows NT (and OS/2) were better from a purity standpoint but they were too far ahead of their time due to their high ram requirements (a whopping 4 megabytes per 16-bit application run!). It took a half a decade for hardware to get sufficiently better and cheaper for the compromises of the Windows 95 era to no longer make sense. Also, it's funny how now with Docker we're going back to this multi-tenancy process isolation model (which was the major secret sauce of Windows 95) instead of running everything in full blown VMs.

The difference is we had threadding back then, and we also had a more robust set of databases & support libraries.

Now everyone is reinventing wheels. poorly.

That 4MiB per application assertion is not true of OS/2. 4MiB was minimal physical RAM requirements for 32-bit OS/2, which I myself ran on a 4MiB machine for a while, but it did not scale up from that by number of applications run, let alone by number of 16-bit applications.

It's a real shame there is no modern and open equivalent filesystem. Instead you get your choice between legally encumbered exFAT, legally encumbered NTFS, and a bunch of unix filesystems where permissions screw up the universal R/W.

You could chmod 777 the fs by default. That's not the problem. The problem are the proprietary os not recognizing the filesystem despite it being free to use and well documented. It's a commercial strategy, not a technical problem.

We could have way better than fat32 on cards. Ms and apple just don't want to make that any easier for you.

There's also the umask, which by default will create all new files without write permission for anyone but the original UID. So now you have to either change your umask or do a chmod after creating a new file.

In linux you can set the umask to a certain value for usb storage devices when automounting, so again, the other os could do it. Still not a technical problem.

The feature you are talking about only applies to FAT or NTFS filesystems.

In other words, even if only Linux existed you couldn't have a universally R/W usb stick without FAT or NTFS.

You can with bindfs minus a perf penalty

But honestly i would be fine with ms making ntfs a free open standard so we can get better support for it.

With ZFS you can set the property to just inherit ACLs and ignore umask. What you’re describing is just a problem with a specific implementation (lack of feature).

If I follow you, I don't think MS and Apple are the problem here.

Storage vendors are going to use the lowest common denominator because of all the older hardware out there that wouldn't work with a newer filesystem.

And most of the people buying USB thumb drives and whatnot are just going to use whatever the drive comes with.

You don't follow me. It would be super easy for ms and apple to adopt a better lowest comon denominator.

I'm always mildly surprised that UDF, the filesystem for DVD discs, isn't used more on USB sticks. It's r/w on the major three operating systems. The only downside is that I think you need to create it in the first place on Linux. (Maybe macOS can format UDF too?)

The major OSs all behave differently depending on if the media with the UDF volume has a partition table or not, among other strange implementation quirks, because nobody expects it to be used outside of optical media.

But since UDF reserves the first 2 KB, you can put a partition table on your medium, and let the first partition start at sector 0. Usually partition programs complain about this, but the file system driver lets it pass.

True, but it's a hack. And as far as I can UDF still suffers from the unix permissions issue.

There used to be a bug in the Linux version of the filesystem that prevented partitions of above 70MB or so to be created (shortints FTW!); however, that is fixed now.

Far worse is it that there is no good, unencumbered (looking at you CDDL license) version of UDF fsck.

Are you trying to imply the CDDL code is somehow “encumbered”?

Reply on news.ycombinator.com