Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Alan Cox]

> You keep talking about what is done about patents in other parts of
> the free software world as though it is a good model to follow. It
> isn't - it is a complete disaster.

Its been a very successful disaster for many years then.

> The only weapon we have to fight patents right now is our collective
> ability to find smart solutions to problems. The "every vendor for
> themselves" approach that you seem to be so keen on makes that
> collective approach pretty much impossible.

The vendors can only talk to one another with lawyers present, so this is
an irrelevant argument to the public kernel. We've proved that already in
the fact you can't even discuss implementation details with the list.

> You talk about media players and other software being crippled in the
> US and other countries as though this is a good thing. You talk about
> vendors ripping out large slabs of functionality as though you want it
> to happen.

It is what the vendors will do regardless.

> to make it work despite the patents. It has been so disheartening over
> the years to see people say things like "oh, the XYZ codec is
> patented, we can't use that". Patents don't work like that. They
> patent very specific steps, and if you learn to read them properly
> then you can find ways to get the functionality you need without just
> applying an axe to a whole slab of useful features.

This misses the fact that if the vendor thinks sueing you is a business
opprtunity they will do so anyway. Why should they care if the patent is
valid - its not relevant to most of the legal process so it still has the
desired slowdown and expend money approach

> Let's stop whining about the unfair patent system and start fighting
> back!

How is shipping something labelled as vfat that doesn't work properly
"fighting back". It's "trying to make the users think our code is crap".

If you wanted reliable working approach surely tridgefat should read long
names but only create new short names ? That keeps you in spec, as I
understand it avoids the alleged possible patent infringement and works
for all devices ?

> oh yes, I've seen it, but unlike you I didn't jump with joy at the
> sight of Linux users losing features because of the patent system. I

I find the assumption that losing features to patents makes me "jump for
joy" rather offensive.

> fumed at the fact that the vendors and projects involved did not have
> the knowledge and skills to apply a more subtle, and much more
> effective, approach to beating patents. 

Many of the things removed are not patent related. Patents are only one
issue. Stuff gets removed for many reasons including a few cases of "they
sue everyone who does this regardless of validity so we don't XYZ"

> Then join me in trying to fight the patent system for real.

I've spent over ten years doing that. Those ten years have taught me

- if you give in to a patent thug they will simply try to bully you
  further
- if you limit functionality silently or in an unreliable way the blame
  falls on the software supplier not the patent holder or the governments
  who made the bad laws (or the judges of course as software patents
  in many states aren't really of political origin but judicial
  over-reach)
- if you delete stuff from base packages you hurt people in the rest of
  the world unneccessarily
- patents are a tiny part of the process anyone shipping any software
  commercially on a scale worth lawsuits goes through reviewing.

That is why I want to avoid any process which cripples the base kernel,
and anything which gives users broken software without them knowing it is
feature limited and why.

The patches you've proposed break stuff. It's mildly funny that MS is
trying to force us into a workaround that randomly crashes MS boxes but
that doesn't make it a good idea to merge such a change. Nor is it a good
idea to call something vfat which is not vfat.

This isn't about pain either - it is about users knowing what they are
getting.

So instead of regressions can we be a little bit less clever and a little
bit more reliable and do "FAT which reads and honours existing longnames"
and give it a name other than vfat.

That would give us absolute on media compatibility, accessibility from
all devices (which is the important bit) but some naming limits for new
file creation.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/