Really...
|
| Author | Content |
|---|---|
| cabreh Jan 09, 2012 9:10 AM EDT |
Let's see... ExFAT is patented by Microsoft so the author is wondering why it isn't included in the kernel. Did said author forget about all the companies now paying tribute (as in money) to Microsoft for the right to use Linux (and Android) due to other possible patent issues? |
| JaseP Jan 09, 2012 9:51 AM EDT |
It isn't so much whether support can be built into the kernel, as much as what work-around can be built into the kernel. It's my understanding that the current FAT32 support in the kernel uses an intentionally "broken" support for long filenames, that only writes the long filename instead of both the long and the short. It thereby bypasses the M$ patent. Kernel support for the exFAT (built in support, rather than 3rd party kernel module) may do something similar. So, he isn't completely off base in making a comment like that... Just, not entirely clear in distinguishing a patent avoiding hack with full blown support. And if that's what he means, it's a bit disingenuous to compare a work around solution to a fully licensed and supported one... |
| Jeff91 Jan 09, 2012 3:35 PM EDT |
The source is Phoronix. The same place that has reported Steam is coming to Linux at least a dozen times. ~Jeff |
| Ridcully Jan 09, 2012 6:26 PM EDT |
Okay.....please explain someone, because I am now more than a little confused. My understanding is that FAT or a form of it, is used in the file storage area of digital cameras and also USB sticks.....My computer running Linux can immediately read and write to them both.....So FAT is already supported ? Yes ? So, the points being made above are to do only with exFAT ? and is that FAT32 ? Retires left stage to gibber gently. |
| skelband Jan 09, 2012 6:40 PM EDT |
Isn't it something to do with long filename extensions that Microsoft added to the FAT spec? |
| JaseP Jan 09, 2012 7:47 PM EDT |
ExFAT, I know little about, other than that even detecting it correctly in 'nix requires an updated gParted... FAT32's patents have to do with writing both long & short filenames, simultaneously. Linux gets around this by only writing the long one. That only breaks compatibility on older Win boxes. ExFAT does some kinda trick to get more content & larger partition size... |
| Fettoosh Jan 09, 2012 8:24 PM EDT |
I believe there are two different patents. One for the algorithm which converts file names between short/long, this one is avoided in Linux by just using long names. The other is for extending the file system table to increase the partition size beyond the normal FAT32 See here I don't believe exFAT is officially supported in Linux because of its patent, and this article is nothing more than an advertisement for a commercial driver. |
| Ridcully Jan 09, 2012 9:38 PM EDT |
@Fettoosh, JaseP and skelband......thanks. One thing is for sure, I don't need exFAT.......and I sure as heck won't be investing in any commercial drivers. My days of contributions to Microsoft's profits are long, long gone. |
| Khamul Jan 09, 2012 11:27 PM EDT |
You can say you don't need exFAT, but there's a slight problem: exFAT is required by many digital devices now, particularly DV cameras. The reason is that these devices need to be able to write huge data files, but FAT32 has a 4GB file-size limit. So if you have a 32GB flash card in your camera, and want to be able to fill it up with a single recording, that obviously won't work with FAT32, which is the last FAT filesystem supported by Linux. Because of this, the DV camera makers IIRC all use exFAT now, and there's usually no way to switch back to FAT32; they just expect you to use Windows. So if you don't have a DV camera (or maybe an older one without this problem), then you're OK, but if you want to buy a new DV camera for filming your kids or making an indie movie or whatever, and you want to be able to use it with Linux, you'll have to buy a license to that commercial driver unfortunately (unless it's possible to download the code for the standard Linux driver and compile it yourself while giving the middle finger to the USPTO and MS; don't know about that). The other problem is that flash memory cards are getting bigger and bigger all the time. 16 and 32GB are pretty common now, and before long it'll be 64 and 128GB (you can probably already get these, but the price break seems to be at either the 16 or 32GB size, and the bigger ones are prohibitively expensive for something that's easily misplaced). It won't be long before makers of other devices start "standardizing" on exFAT because of FAT32's limitations with large files and large drives, and then we're going to really have some problems in Linux-land. |
| Ridcully Jan 10, 2012 12:04 AM EDT |
Quite right Kamul.....I don't have a DV camera and see no likelihood I will ever have one, or the requirement for one....But I do take your point. I suspect that a "work around" will arrive sooner or later.....or the patent (if valid) expires, or is challenged and invalidated (I don't know if such a challenge has taken place)....or whatever. For the moment though, I remain an interested onlooker. |
| gus3 Jan 10, 2012 8:07 AM EDT |
FWIW: Many cameras also impose an 80-minute limit on a single video file. |
| Fettoosh Jan 10, 2012 10:41 AM EDT |
I am not sure if there is work being done in the Linux world to create a special file system for storing data on consumer electronic devices. With all the different file systems supported on Linux, there ought to be one. The community just can't keep MS & Apple controlling that area. With all the threats to security & privacy, the community must have one. A number of CE manufacturers are already using Android/Linux, it makes sense to use a file system that is native to the OS. Since the majority of people are still using Windows on desktops/laptops, the file system needs a good driver not only for Linux, but also for both Windows, & Apple. The driver should also be included on the CD that comes with such devices. I don't think it is too late. |
| JaseP Jan 10, 2012 11:09 AM EDT |
All that's (really) necessary in Linux is to be able to read, and/or delete exFAT partitions... DV cameras can connect as a block device & be read that way. You can handle partition creation and file manipulation on the device itself. Plus, many of these kinds of devices (like phones) have a software layer that allows them to emulate a USB mass storage device. I'm guessing M$ uses exFAT in their telephone OS... Which is why it's been said that SD cards become "unreadable" in other devices after WP7 has set them up. ExFAT is also, apparently, used for OEMs to create "hidden" recovery partitions on HDs & SSDs. Point is, when gParted (updated) is used, you can identify & delete exFAT partitions. I think you may even be able to read them too. PS: @fetoosh: BTRFS,... but it's not quite ready for prime time yet,... since there are fatal errors on devices that don't properly support flushing. |
| Fettoosh Jan 10, 2012 11:24 AM EDT |
@JaseP Are you saying we really don't need to be off the MS treadmill? What about CE Manufacturers who want to use Android/Linux on their DV cameras? TVs? etc.? Are you OK with all that? [Edited] @JaseP: I saw your PS after I posted this comment. |
| JaseP Jan 10, 2012 12:00 PM EDT |
I'm way OK with Android based cameras, etc. But I don't believe Android supports exFAT,... I could be wrong. I believe Android supports FAT32 long filenames & Linux partition formats only... Some OEMs may include 3rd party support for NTFS and/or exFAT... I suppose, using a kernel module shim & proprietary code, to get around GPL issues. |
| tuxchick Jan 10, 2012 12:32 PM EDT |
When exFAT was announced a couple years ago it was hailed as yet more Microsoft lock-in horsecrap. Two years later, yep. In fact I railed against it my own self: http://blog.linuxtoday.com/blog/2009/08/some-answers-fr.html exFAT is just FAT64; another brain-dead uber-simple FAT filesystem. It doesn't rate a patent, or any kind of eye pee protection since it's just an extension of crappy antique FAT filesystems. The industry could have just as easily gone with a FOSS filesystem like ext2/3, and modified it so that Uncle Joe doesn't have to worry his pretty little head about permissions and ownership. Or something else, anyway there was no need for exFAT other than to guarantee a needless flow of money to Microsoft. Khamul is right-- any Linux user who wants to use modern multimedia devices is stuck with the Tuxera driver. exFAT is useless and stupid, and another example of the unholy influence MS still exerts on the whole tech industry. I predict that someday soon Ballmer is going to wake up and go "We don't need to produce and sell actual products--our global protection racket is doing just fine." gparted can detect exFAT. That is all. It cannot read it. There is no FOSS option for exFAT. |
| Fettoosh Jan 10, 2012 2:33 PM EDT |
Quoting: I'm way OK with Android based cameras, etc. But I don't believe Android supports exFAT My point was about not being solely dependent on MS proprietary file systems and you seem to be OK with being dependent on MS exFAT since we can read access it. The whole point is about a file system for CE devices that can be read & written to on Linux without being encumbered by any patents, especially MS ones. |
| flufferbeer Jan 10, 2012 2:41 PM EDT |
@tuxchick Yes indeedy, and I bet that the M$ Borg is already desperately trying to "interoperate" with Android, exFAT and all. Sheesh... my 2c |
| Khamul Jan 10, 2012 4:09 PM EDT |
I wouldn't be too surprised if many Android or Linux embedded devices simply licensed and used the Tuxera driver. On an expensive item like a DV camera (they're not that cheap yet), a few dollars per unit for licensing isn't that big a big deal for the mfgr, and it's not hard for the embedded developers to build it into their software build. But it keeps Linux users from interoperating with their device without having to go buy that same driver (and then muck around with trying to get it to work with their distro, possibly not such an easy task depending on how Tuxera packages this thing). |
| JaseP Jan 10, 2012 4:10 PM EDT |
Quoting: ... without being encumbered by any patents, especially MS ones. Well, that's the trick, isn't it?!?! OK with it?!?! No. I'm just jaded/realistic, whatever you want to call it... Work-arounds are fine by me, if they are functional. If not,... civil disobedience is always an option. |
| gus3 Jan 10, 2012 4:23 PM EDT |
"When civil disobedience is appropriate, obedience is uncivil." --me |
| cr Jan 10, 2012 7:23 PM EDT |
Quoting: gparted can detect exFAT. That is all. It cannot read it. There is no FOSS option for exFAT. Yet. If this goes on, I can see that code getting cleanroom-reimplemented (the same way Phoenix Technologies broke the IBM BIOS lock for Compaq by generating a comprehensive specification, then tossing it over a Chinese-wall to the coders) and the result parked on offshore servers in drop-in form (*.deb) just like the patent-laden bits of codecs are now. Frankly, given the mess that has been Linux audio, I'm wishing that had happened to the mixdown version of OpenSoundSystem a decade-plus ago. Somebody like RedHat should have bought that outfit out and GPL'd the code, so we didn't have to put up with a blocking single-signal-source driver down at that level, and they didn't have to put up with trying to sell a toy-system OS when it came to sound. |
| jdixon Jan 10, 2012 11:48 PM EDT |
> I can see that code getting cleanroom-reimplemented That doesn't work with patents. Only copyright. |
| cr Jan 11, 2012 2:50 AM EDT |
Quoting: That doesn't work with patents. Only copyright. True, but offshore does. The cleanroom reimplementation walks it from Tuxera to GPL, where "cleanroom" can mean "email the spec to FUSE coders in another country where patent laws are sane". |
| Ridcully Jan 11, 2012 3:17 AM EDT |
@cr......Brazil ? I seem to recall that it was Brazil sites that hosted libdvdcss for a long time when it was difficult to get that library elsewhere. |
| cr Jan 11, 2012 4:16 AM EDT |
@ridcully: <shrug> Wherever, the more the more permanent. At one time I had a tee shirt with the dvdcss algorithm screened onto it, doing my part in carrying around a piece of can't-touch-this. Is there an RFC for messaging-by-tee-shirt? Particularly an in-your-face message to somebody who's flipped their evil-bit? |
| jdixon Jan 11, 2012 6:01 AM EDT |
> YTrue, but offshore does. Yes, but that;'s another issue entirely. If you're offshoring to a place that doesn't recognize the patents, there's no need for a clean room implementation. |
| cr Jan 11, 2012 8:27 AM EDT |
@jdixon: I can't see those offshore Debian repos knowingly accepting packages containing code which has been "given preemptive reallocation of ownership". Quite aside from the legal taint to the copyleft stance, there's the moral repugnance. Nahh, it's gotta be clean code, and code-to-spec, Phoenix-method or not, is the traditional Linux way to do that. |
| cr Jan 11, 2012 8:59 AM EDT |
Addendum: I'll just say that I don't see such a reimplementation-from-spec killing Tuxera's market, either. As Khamul envisioned, I can see mfgrs licensing and using Tuxera's code, assuming it does the job right and they keep up with the kernel revisions, to avoid patent liability. The reimplemented code on the offshore servers, meanwhile, allows Linux users to get full use of the hardware they own. If my guess is right about FUSE (I've not studied it), so long as FUSE is kept up-to-date on the kernel, FUSE abstracts those ABI changes away from the userland virtual filesystem handling, leaving the exFATso devs to concentrate on getting their code to work right and maybe match MS bug-for-bug (like Samba did) if needed. Any speed loss from going through the FUSE layer is miniscule for a desktop; one more thing the mfgrs pay Tuxera for, to get kernel-level handling of exFAT in embedded systems where resources like CPU bandwidth and buffer-space are scarce. The only real loser, then, is MS, whose trollbooth on the USB datastream might bring in some money but doesn't lock out Linux. |
| JaseP Jan 11, 2012 12:06 PM EDT |
Don't confuse clean room with work around. Clean room AND work around are needed to deal with patents, to help avoid willful infringement. But clean room, only, are necessary for dealing with copyright. Work around solutions accomplish the same end result as the patent subject matter, but do it on a manner different than described in the patent. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!