Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

exFAT in the Linux kernel

cloudblogs.microsoft.com

Post reply on HN
Print view View original

151–160 of 280 posts

Re: exFAT in the Linux kernel

#151

Post by RaleyField »

chme wrote: post #107
mips_avatar wrote: post #106

Earlier quoted context omitted.

You could use office 365 on your linux machine.

Offering a cloud service to a linux user is like tempting a vegetarian with meat. Linux users often choose Linux because they want to be in control of their data and devices, cloud services are about giving control of that away to companies.

> want to be in control of their data and devices,

The other day there was a thread on HN about which laptop is great for Linux. Tons of people recommended Lenovo, a guy from Redhat said it's even the brand that's used internally and I got a little depressed and smh. Nobody mentioned superfish. Those glorious days of Linux are gone.

Re: exFAT in the Linux kernel

#152

Post by userbinator »

jaclaz wrote: post #8

The IMHO extremely relevant point is in the very end of the actual specifications: https://docs.microsoft.com/it-it/windows/win32/fileio/exfat-... >26-Aug-2019 Seventh release of the Basic Specification, which includes the following changes: Updated legal terms pertaining to the specification, including: Removal of Microsoft Confidential notice Removal of Microsoft Corporation Technical Documentation License Agreemen…

Skimming through the doc, it looks like a modification of FAT32 with some (noticeably more complex) extensions, and not anything resembling what you might envision a "FAT64" to be; a FAT is still a linked list of 32-bit entries, there can still be two of them, and directory entries are still 32 bytes each (although defined in a rather complex way.) There's a separate allocation bitmap, which seems redundant and a waste of space (and code) given that the FAT itself already contains the information in previous versions.

I've written a FAT12/16/32 driver for an embedded system before; and oddly enough, the documentation I had at the time was far easier to understand than this one. I didn't expect exFAT to be this complex, or perhaps the doc is just excessively verbose --- for example, the whole first paragraph of the 4th section is saying nothing more than "there may be 1 or 2 FATs, one after the other, and NumberOfFats is the field that says how many there are" except it takes 5 sentences to do so.

That said, this spec is written in a style that's easier to understand than a lot of the other "open specifications" docs that MS has released, but I suspect that's because this one was once an actual NDA'd implementer's document rather than the others which I've heard may have been released purely for legal reasons related to the antitrust than anything else.

Now if only they'll do this for NTFS...

Re: exFAT in the Linux kernel

#153

Post by userbinator »

xxs wrote: post #139
stevenjohns wrote: post #138

Earlier quoted context omitted.

I would settle for just Skype for Business on Linux. No excuses why it shouldn't be on there... and yet it isn't.

Skype for Business has been replaced by teams which is not much better and pretty much still an awful chat application.

Teams is worse in that it appears to actually be Electron instead of the semi-native (I don't think it's pure Win32, judging by the UI latency and appearance) Skype for Business.

Re: exFAT in the Linux kernel

#154

Post by userbinator »

GordonS wrote: post #68
mda wrote: post #64

So after abusing this bullshit for more than a decade to bully companies. How gracious and generous of them. Oh btw, Satya is the CEO for 5 years.

I think that's pretty unfair - Microsoft has changed enormously in the past 5 years.

MS has changed from proprietary software vendor to a spy-on-the-users-and-try-to-monetise-them services company that's trying to be Google. I don't think that's much of an improvement.

Their code used to be their core value and source of profit; they are open-sourcing a lot of it now because that's not true anymore and they might as well get some publicity out of it. If you look at companies like Google and Facebook who publish lots of open-source, you'll see the same trend --- it's opened because it's not worth anything to keep it secret anymore.

Re: exFAT in the Linux kernel

#155

Post by Spooky23 »

dreamcompiler wrote: post #144
nightfly wrote: post #37

Earlier quoted context omitted.

It's more likely that Microsoft Office will become 100% "cloud" based software.

That's never going to happen. The US government is a huge Microsoft Office customer, and national security-sensitive documents cannot be placed in a cloud that's not completely controlled by the government.

There’s already a US Government Community Cloud for moderate risk (.com) and a US GovCloid for higher risk (.us) workloads.

As with all things multicloud and Microsoft, it’s easy to get into trouble in the community cloud.

Re: exFAT in the Linux kernel

#156

Post by grosswait »

dekhn wrote: post #124
notriddle wrote: post #112

Earlier quoted context omitted.

For one thing, that's throughput, not latency. For another, that's probably a desktop, not a smartphone.

That's correct, my metric for performance is throughput I don't really think a desktop vs a smartphone matters much at this comparison, it's just my observation that when people say a fuse filesystem is slow it's just not well-engineered, not that the fuse API is inherently slow

Run a benchmark that measures more than throughput and you'll see the difference. IOPs are usually poor.

Re: exFAT in the Linux kernel

#157

Post by rewgs »

philwelch wrote: post #116
chme wrote: post #107

Earlier quoted context omitted.

Offering a cloud service to a linux user is like tempting a vegetarian with meat. Linux users often choose Linux because they want to be in control of their data and devices, cloud services are about giving control of that away to companies.

Linux is a kernel, it’s not a way of life. Chromebook and Android users are Linux users. People who use web applications that run on Linux servers are Linux users. Developers who use Vagrant or Docker on Mac OS, or Windows Subsystem for Linux on Windows, are Linux users. Microsoft may or may not “love” the tiny subset of users who run Linux-based desktops and are unwilling to use web applications. But that doesn’t me…

You're being pedantic. "Linux users" in a post like this clearly means a specific thing. Context matters.

Re: exFAT in the Linux kernel

#158

Post by dkh »

Big deal! This is right up there with Adobe Premiere on Windows finally getting a ProRes encoder at the top of my list of "Things That Would've Helped My FilmTech Career Around 6 years ago".

1) We finally have a file system that works across operating systems, which is a big deal if you ever do anything in a multi-OS environment.

2) exFAT is heavily used in the film production world, and the convenience of knowing it'll mount properly on any OS so you can duplicate it a few times is much more important than whether or not it's a "safer" file system in general. It doesn't need to survive forever -- the card just has to make it from the camera to the computer on the other side of the set, or survive a trip from one office to another on a shuttle drive that by this point is not the only place that data exists.

Regardless, it's still more mature in general than I remember it when it started to appear in high-end cameras around 2012/2013. When your Blackmagic camera shoots exFAT but isn't capable of deleting files off it without a computer...

3) Should something still go wrong (like, oh, the time I was almost responsible for losing $60k of footage my second day on a job due to unexpected use of exFAT + a truly unfortunate and odd-defying day of bad luck) the fact that Microsoft is implementing it in the kernel should still be a huge help -- it will be a proper implementation (not a reverse-engineered sometimes-working mess), will perform much better than FUSE, and just generally improve reliability. Trust me, when your card with irreplaceable footage won't mount, you'd rather not have to fight that battle on two fronts, with one of them being your Linux implementation.

Re: exFAT in the Linux kernel

#159

Post by philwelch »

rewgs wrote: post #157
philwelch wrote: post #116

Earlier quoted context omitted.

Linux is a kernel, it’s not a way of life. Chromebook and Android users are Linux users. People who use web applications that run on Linux servers are Linux users. Developers who use Vagrant or Docker on Mac OS, or Windows Subsystem for Linux on Windows, are Linux users. Microsoft may or may not “love” the tiny subset of users who run Linux-based desktops and are unwilling to use web applications. But that doesn’t me…

You're being pedantic. "Linux users" in a post like this clearly means a specific thing. Context matters.

It means a specific thing, but the specific thing that it means is insignificant. The basic argument that “if Microsoft really cared about Linux they’d write native Office apps for Linux desktops” is myopic and, in itself, ignores the broader context of what makes Linux relevant in the first place. As you say, context matters—and context is exactly what I was providing.

Re: exFAT in the Linux kernel

#160

Post by naner »

jdsully wrote: post #4

The big deal here is the patent grant. FAT related patents were held over linux like a gun in the Ballmer years. Its a reason Linux was stuck with 8.3 length filenames for so long.

They fired the gun. Linux had to rework the FAT32 implementation in the kernel when TomTom got sued for not paying the Microsoft tax and lost.
Post reply on HN