Feeds

back to article Linux chief calls for FAT-free Microsoft diet

Microsoft and TomTom might have settled over patents, but that hasn't stopped one Linux advocate from calling on manufacturers to adopt a "FAT-free diet". Jim Zemlin, Linux Foundation executive director, has said those who implement File Allocation Table should undertake a wholesale review and strip a technology from their …

COMMENTS

This topic is closed for new posts.

Page:

Flame

What exactly is the problem here?

For all the whining and complaining about how Microsoft is using this to attack Linux, I just don't get it.

I completely understand the attacks on FAT as a technology. It isn't perfect and even Microsoft doesn't use it anymore. It was an innovative kluge for tricking systems into supporting long file names even when they weren't built to handle them. But that kluge is still has value for supporting the huge diversity of systems running in the world today.

In the end, however, I don't see how Microsoft's efforts to license this technology to systems using Linux (NO prevent them from using it) qualifies as an "attack." If they wanted to attack Linux, Microsoft has better ways of going about it.

0
0
Go

ext2

There are free ext2 drivers for both Windows and OS X, it's native in Linux, I know FreeBSD supports it and suspect the other BSDs do as well. As I understand it, ext3 is just ext2 with journaling, so they're mutually compatible.

We could do worse.

0
0
Flame

Get a Grip.

EXT2 gets you a bit more metadata than FAT, notably UIDs, and can handle larger files, but that's it, and neither of those are that important on embedded systems.

What ARE important on embedded systems are driver size and storage overheads, and FAT wins on those counts. A 4K allocation size might seem to improve on FAT's efficiency, but the increased number of allocation pointers becomes surprisingly significant, As do unused inode instances/

Some flash products, including Disk On Chip and CF have their wear levelling validated for usage on the FAT, why should a developer use a different file system and risk burning the drive's life span?

Many of the comments above have demonstrated a surprising ignorance of FS design and even the difference between a file system and a physical device. Can you all fuck back off to slashdot please?

0
0
Flame

Get a Grip.

EXT2 gets you a bit more metadata than FAT, notably UIDs, and can handle larger files, but that's it, and neither of those are that important on embedded systems.

What ARE important on embedded systems are driver size and storage overheads, and FAT wins on those counts. A 4K allocation size might seem to improve on FAT's efficiency, but the increased number of allocation pointers becomes surprisingly significant, As do unused inode instances/

Some flash products, including Disk On Chip and CF have their wear levelling validated for usage on the FAT, why should a developer use a different file system and risk burning the drive's life span?

Many of the comments above have demonstrated a surprising ignorance of FS design and even the difference between a file system and a physical device. I expect better of el-reg'ers Can you all fuck back off to slashdot please?

0
0
Gold badge
Boffin

all those "Why is MS so bad" questions

It depends who you are.

For end users this is academic. You will only care if whatever gizmo you bought (or its memory storage thingy) cannot be read by you PC.

For developers.

It's no longer a question of *just* the source code for the software. If you want to store LFNs Microsoft style IE in parallel with a short version and split into chunks your company has to get a license from MS for the privilege. If someone wants to fork a copy of your source (you got it under GPL2) *they* have to negotiate with MS for the privilege as well (unless you included it in you MS agreement. Giving 2 groups of people. Those with rights, and those without. Can you say "Divide & rule"?

The real killer is exchangeable storage. Does anyone make flash devices with an internal chip that can fool a Windows PC into thinking its looking at FAT/LFN drive but store the data in a *totally* different way?

0
0

Simple

Simple, a fat12 micro rom with an autorun.inf and an ext2 driver, just like some wireless usb and others.

0
0
Happy

Put the driver on a tiny fat partition

and then reformat it

easy

0
0
Silver badge
Linux

Linux licencing FAT/LFN

Actually, AC @ 21:49 might be onto something.

Perhaps Linus should approach MS with a view to licencing FAT/LFN. I reckon they could do it under the same terms that MS originally used to licence Mosaic all those years ago.

There, problem solved.

0
0
Anonymous Coward

Microsoft-free Linux diet

How about vendors distributing Linux-based devices with an ext3-based filesystem along with the EXT3 Windows driver on an install CD? Windows users can access the Linux filesystem on the device through the EXT3 Windows driver whereas Linux users can directly mount the device filesystem.

0
0
Flame

I'd like to suggest

that most of Micky-Soft's tech falls into the realm of poor reinventions,

and that FAT is nothing special in this regard.

~D

0
0
Gold badge
Boffin

AC@21:49

It depends who you are.

If your an end user this is academic. You will only care if whatever gizmo you bought (or its memory storage thingy) cannot be read by you PC.

If your a developer.

It's no longer a question of *just* the source code for your software. If you want to store LFNs Microsoft style IE in parallel with a short version and split into chunks for more efficient storage your company has to get a license from MS for the privilege. If someone wants to fork a copy of your source (you got your original source under GPL2) *they* have to negotiate with MS for the privilege as well (unless you included it in you MS agreement. Giving 2 groups of customers. Those with rights, and those without. Can you say "Divide & rule"?

Avoiding the MS method of file and LFN storage (while honouring Windows file requests) can lower your companies per unit hardware price. Which means more profit or unbeatable pricing. Thinking about this sort of question before you start is a Development Manager level issue.

0
0

FAT replacement

Well I would replace the FAT file system on flash devices with say Ext2 (and there is an addon to add support to Windows too.

Ext2 is supported by MacOS (I believe) and Linux natively.

Hopefully alot of manufacturers will learn from this and will realise that following Microsoft isn't always in their interest and will choose a standard filesystem (I'd go for Ext2).

Mike

0
0

FAT-free Linux

Maybe a little pressure on the European government to force Microsoft to include the Ext3 driver in its products?

0
0

FAT needs to stay, even though it sucks

The real issue here is Software Patents. FAT needs to become an open standard. Problem is, as pointed out by many above that there are a lot of third party/embedded things that *ONLY* understand FAT, and they must continue to support FAT because of the majority of Window$ machines out there. If Linux loses FAT, then I can no longer read the SD card from my camera, nor can I put files onto my MP3 player. Also, I would be prevented from taking files from a Window$ box, stuffing them onto a thumb drive, and importing them into a Linux box, or vice/versa.

It may even be possible that FAT has pre-Micro$oft roots.

0
0
Gold badge
Thumb Up

@Mike Gravgaard

"replace the FAT file system"

I think your missing the point. It's not how the data is stored on the device. Its how you make an *unmodified* windows PC read it, without needing to store your data in FAT format, or write LFN's in FAT format.

If you can pull off this joint feat you retain market share, remain fully GPL2 compliant and avoid paying Microsoft license fees up front and per unit. You can sell your hardware cheaper and still retain your profit margin.

You may find this a little more challenging than you think.

0
0
Anonymous Coward

@Peter D'Hoye

"What manufacturer will put an FS on his product that windows can't read or write? Indeed..."

Why would windows need to read it? You plug the satnav/camera/whatever into the PC with a USB cable and the software that came with the device does the reading.

The idea that end users won't install the software CD shipped with the device is laughable. The problem I have is discourage EUs from installing every CD that comes their way. And if there's some retard who can't RTFM then I'm sure the shop they bought the device from will put them right.

And if a company as popular as TomTom started using a different FS how long do you think it would be before MS had a driver sorted?

0
0
Gold badge
Thumb Up

AC@10:35

"and the software that came with the device does the reading."

Works for me. But.

People using specialised products are likely to *expect* to need a special app to talk to it.

For products which store or generate generic files (MP3, JPG, MPG etc) they expect to handle file management through the OS, which at present is Windows. Case in point. My digital camera. Of course it came with a CD of picture management SW which I lost. Stick USB cable into PC and I got a drive of JPG's to view. It seems to generate file names automatically so LFN may be unnecessary

I'm an EU (in this case) I did RTFM. It worked because the mfg probably has licensed off MS.

Not owing MS is a good policy but difficult to implement. Working out what your product *should* do in situations like this is a product development issue. Working out *how* to do it is a SW Development issue. It would be interesting to find out how Archos (who IIRC are well into Linux) handle this.

Its trickier than it looks.

0
0
Linux

It's not technology; it's attitude.

FAT came about when Billy designed the DIsk Extended BASIC for the Altair 8800 (on 8-inch, single-sided, single-density floppies, capacity 256kb). It was simple and compact enough for such small volumes, not to mention drivers simple and small enough to share elbow room with the rest of the system in a box with 16Kb of RAM. (Yes, hard to believe it. The 8080A and Z-80 had 16-bit memory addressing, hence a maximum of 64Kb of RAM accessible directly, but memory was expensive and lots of systems ran with 16K.)

I'm not sure what kind of filesystem CP/M-80 had, but when Microsoft edged out Digital Research for the contract to provide operating systems for the new IBM PC (sad story about Gary Kildall there), FAT came along with it. Quarters were still cramped. The 8086/8088 could address more RAM but still not a lot (640K I believe, hence Billy's embarrassing quote that nothing would ever need more than that), and double-sided double-density 5-1/4" floppies held somewhat less than a standard floppy does now.

So, FAT made sense then, but it's a living fossil now.

So, why not, as said here by many, scrap it for something better?

Look at Linux and NTFS. M$ has stubbornly refused to disclose even the minumum information about that filesystem needed to design a third-party driver for it. Why? It's not the kind of technology that others would seize upon and exploit competitively. It seems to me that they want to frustrate any attempt to access their media with anything not their own.

Sure, drivers for other OSes can be had, but that's only useful for user-created volume (granted, the most common case). Microsoft is not likely to start supporting any non-M$ filesystems and wherever they control the design of things, if history repeats, they will go out of their way to avoid using anything they can't control.

There are people who are pathological control freaks. The same can be true of corporations.

0
0
Gold badge
Thumb Up

@Ray Simard

"It's not technology; it's attitude. "

Quite so. And it's one that works for them *very* well. Unthinking developers will continue to use FAT & may pay (or get their boss to license) LFN support. MS has no incentive to make this easy. Any company that does not want to pay off MS or get grief from their lawyers has to work for it. With the benefits I have outlined. Its a tricky problem, but not an apparently exciting one. Hence the status quo persists. I believe it will persist until someone adept enough becomes fascinated by the challenge of subverting Windows in this area enough to make it happen. *only* a license free solution will work. Anything else would exchange MS license fees (global gigacorp) for Joe Coder (Head Office, Cornhole Indiana) license fees. Why bother?

In the real world that is what users mean by "Ubiquitous computing."

0
0
Silver badge
Linux

@nobby EXT2/3 FS under windows

Ideally a nice transparent driver should be created for windows, but in the meantime you can try :

http://tombuntu.com/index.php/2007/08/14/ext3-file-systems-in-windows/

there are a couple of other EXT2 apps out there if you google around

0
0

Page:

This topic is closed for new posts.