[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

[Alan Cox]

>   http://samba.org/tridge/Win98-update.png
>
> When the vendor of an operating system doesn't even bother to display
> a clean "sorry, you don't get updates any more" page for their OS then
> I think it is safe to say that the operating system is dead and
> buried.

There are lots of Win98 systems still alive out there. The "last few" in
the Win98 world is rather a lot due to the original enormous user base.

> that it should be configurable, but I don't think it leads to the
> conclusion that the patch should not be in the upstream kernel at all.

I think we already proved it had no use upstream. Vendors will remove
the code from their source tree if worried about patents so including it
in the base tree is really irrelevant. So I find your argument about this
less than convincing.

The patch serves no purpose but to confuse users and increasingly it is
shown to break systems horribly.

There might have been a limited case for a not-quite-vfat-fs "tridgefat"
etc if it was both more compatible and if the vendors would use the
option. But given its not compatible and vendors won't why bother at all ?

I also note you keep talking about vendors. This is an open list yet I
don't hear a word from the vendors you claim to represent in support of
this patch set, and saying they would enable it. Not one voice seems to
have appeared.

The decision sequence goes something like this

        - do we want to ship the feature because of patent concern
        > do not ship
        - is it less risk to remove the source from our build tree or
          configure it out
        > remove from the tree
        - is there a functionality difference to the user between
          removing or unconfiguring it
        > No

At that point nobody managing risk is going to do anything but remove the
code that worries them. It's additional risk with no return.


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

[Jan Engelhardt-3]

On Wednesday 2009-07-08 09:42, tridge@... wrote:

>What I said in the patch help text is:
>
>  That means that long filenames created with this option
>  disabled will not be accessible at all to operating systems
>  that do not understand the VFAT extensions.
>
>that means you have to choose 8.3 names if you want to copy files onto
>a SD card and have those files visible to digital cameras. That is not
>actually much of a change from how things behave without my patch for
>current 8.3 only cameras. As Jan discovered, cameras tend to be pretty
>fussy about the format of the filenames for files. His particular
>camera wants the filenames to be dscfNNNN.jpg, which means that he
>needed to be careful about choosing file names with current kernels as
>well.

In the large picture, the problem is not so much about devices that
restrict themselves to 8.3, such as DCIM-compatible cameras. They
"only" accept 8.3, so there is no point in trying to use a long
name because the software won't look for it in the first place.

It is much more with devices that are commonly operated with long
names - multimedia players come to mind - and these "always"
want a valid 8.3.

>> Perhaps camera vendors fear patents, too.
>
>quite likely they want to minimise their costs, and not paying for a
>patent license they don't need is one way to do that.

Well and there's always some vendors (the more so the one-product
vendors) not paying the royalities they are supposed to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Alan,

 > There are lots of Win98 systems still alive out there. The "last few" in
 > the Win98 world is rather a lot due to the original enormous user base.

I find it rather ironic that you are advocating leaving the Linux
kernel open to further legal attacks by Microsoft because if we didn't
then we might lose compatibility with an operating system which
Microsoft themselves abandoned a long time ago.

 > I think we already proved it had no use upstream. Vendors will remove
 > the code from their source tree if worried about patents so including it
 > in the base tree is really irrelevant. So I find your argument about this
 > less than convincing.

we've been round this loop before. See my previous emails where I
explained why I think having it upstream is an advantage. See also the
reply from James.

 > I also note you keep talking about vendors. This is an open list yet I
 > don't hear a word from the vendors you claim to represent in support of
 > this patch set, and saying they would enable it. Not one voice seems to
 > have appeared.

I never claimed to represent any vendors. I said that it was my
opinion that many vendors will want to apply this patch, and you seem
to support that opinion as you've several times stated that you think
that vendors will apply it in an unconditional form.

 > At that point nobody managing risk is going to do anything but remove the
 > code that worries them. It's additional risk with no return.

Some vendors may well do that. Some may decide to keep it as a compile
time option. The legal advice that I've seen is that keeping it as a
compile time option is fine.

If it's pulled out of kernel.org trees then:

 - each vendor may end up with slightly different varients. That means
   we could have Linux devices behaving inconsistently.

 - the testing and discussion may end up happening in a less open
   manner. I think the testing and discussion on lkml has been very
   valuable. As you've noted, vendors have not been actively
   participating in these discussions. Do you think they'll suddenly
   decide to start discussing things openly if we move it out of a
   kernel.org tree? You must know how reluctant vendors are to draw
   attention to themselves when it comes to patents.

 - some vendors may decide not to use Linux, and switch to embedded
   windows instead if we don't have a clearly supported way of
   avoiding these patents in the Linux kernels.

 - we'd be setting up the kernel to have a deliberate long term
   difference between what a large part of the user base runs and what
   is tested for kernel.org kernels. As I said previously, I think
   that is poor software engineering practice. I know you disagree,
   but I also know that some other people do agree. I suspect you
   would be more inclined to agree if this patch had nothing to do
   with patents.

I suspect you are right that many vendors would apply it anyway if it
wasn't in a kernel.org kernel. Is that sufficient to stop a new round
of lawsuits? Maybe. If that is what is decided then I guess we'll find
out over the next year or two.

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

[Martin Steigerwald]

Am Mittwoch 08 Juli 2009 schrieb tridge@...:
> Hi Martin,

Hi Tridge,

>  > Have low level filesystem check, repair and cloning tools been
>  > checked against the patch at all?
>
> I have tested chkdsk.exe obvious, and I have reported the bug in
> chkdsk that this testing has found to Microsoft.
>
> I haven't tested tools like ghost or 3rd party tools. I don't actually
> have any of those tools myself, although I guess I could go out and
> buy them. Does anyone on this list have those tools and can let me
> know if they show any problems?

The question before that would be whether anyone has a comprehensive list
of those tools, cause I think there are quite many. Well at least those
from bigger vendors should be tested I think. Paragon, Symantec, ...

And has it been tested with Linux tools such as fsck.msdos, fsck.vfat,
parted and partimage? I think it probably has not much effect on parted and
partimage, but what about the fscks?

>  > I think the patch actively *corrupts* perfectly fine shortname FAT
>  > filesystems and at least for certain use scenarios even those with
>  > long name support.
>
> The patch only changes the values stored for new files created by
> Linux, so I think it is going a bit far to say it "actively corrupts"
> filesystems.

I do not. A filesystem is intact when all of its metadata is intact. This
is at least what I believe and what various fsck tools seem to implement.
Thus even when the patch only changes the values stored for new - or
rewritten? - files it actively corrupts the meta consistency of the whole
filesystem. To me it is like inserting a defective inode into a consistent
Linux filesystem.

> I am looking into the Win9X issued raised by Jan. As I mentioned in my
> mail to him, it seems to work better with some different values in the
> 11 bytes. I'll keep looking at that, although I don't think Win9X
> support is a high priority for anyone any more. After installing Win98
> in a virtual machine I connected it to the windows update service to
> see if there had been updates to the old install images I had, and I
> found it couldn't even connect to windows update, it just throws a
> page full of html errors:
>
>   http://samba.org/tridge/Win98-update.png

I don't believe that Microsoft is still providing updates for Win98. But I
think Windows 2000 might still be in use - I for example have a Win 2000
installation on my ThinkPad T23, although I didn't boot it for about a
year or so. Has it been tested against Windows 2000? I digged for the mail
where you said something about against which Windows versions you tested,
but I didn't find it anymore.

I think information regarding test status of the patch should be collected
in the FAQ.

> When the vendor of an operating system doesn't even bother to display
> a clean "sorry, you don't get updates any more" page for their OS then
> I think it is safe to say that the operating system is dead and
> buried.

It is safe to say much. But still users might not behave according to your
saying or might even not be able to. A potential customer asked us to
migrate a Windows 98 installation into a virtual machine, cause the
software that is running there would not run with any newer version of
Windows. Sometimes people are locked / forced to a specific Windows (or
Linux) version at least is they do not want to pay lots of $$$ to replace
their proprietary special hardware + software combination by something
which is supported on a newer version of an operating system. And for a
coincidence I think digital photos have been involved in that use case.

I skip most of the political stuff. I was not my main point to make. It
has been discussed before. We obviously have different oppinions and thats
just how it is. No need to cycle around our different view points.

>  > If the Linux kernel would be changed to avoid any software patent
>  > issues I am not sure whether it would even be able to boot
>  > anymore.
>
> That argument can be used with pretty much any software (both
> proprietary and free), not just the Linux kernel.

I think this doesn't render my argument invalid. To me it merely says that
also other free software projects shall be careful with politically or
juristically motivated patches. Drastically spoken if everyone decides to
jump out of the window, why should I follow?

> In the case of the GIF patents the correct answer was a concerted
> effort to switch to a new format. That was a fantastic campaign and
> largely successful.
>
> We don't, as yet, have any equivalent campaign to get behind for these
> VFAT patents. The calls for changing to a different filesystem format
> are great, but they fall down in an even worse way than what I have
> proposed on exactly the same issues. This hypothetical new format
> won't work with cheap MP3 players, won't work with Win9X, and almost
> certainly won't work with existing Windows boxes (yes, I know about
> UDF, but if you actually try it you'll see it isn't the panacea some
> have claimed). So in what way is it a solution, even if the new format
> existed?

Its challening, agreed. Especially as for it to be truly multi-plattform
Linux developers, Apple, Microsoft and little device makers would have to
agree on it. Or it needs to be a free software product that can be
installed on any OS really easily. Then you could have a small fat16
partition with a *.exe file and a MacOS X dmg to click on in order to
install the driver for the real new inter-exchange filesystem. But what
about device makers. And what about existing devices? I think it can only
be a slow migration.

> If you can propose a truly workable alternative then I would be
> delighted to never have to think about FAT filesystems again in my
> life.

I did not meant any personal offence. So no need to justify yourself for
what you do. You are just trying to find a workaround for the issue. And I
am pretty sure you believe in what you do to be a viable workaround. I am
not intending to shoot the messenger of a possible workaround. I am just
not a fan of a patch like yours being in vanilla and thats about it ;).

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[Alan Cox]

> I find it rather ironic that you are advocating leaving the Linux
> kernel open to further legal attacks by Microsoft because if we didn't

Now you are being totally inconsistent.

Either leaving the code in the source is not a problem, _or_ if it could
be a problem (for US citizens) then vendors will need to remove the code
from their tree completely.

> we've been round this loop before. See my previous emails where I
> explained why I think having it upstream is an advantage. See also the
> reply from James.

James reply was based on the fallacy that vendors will keep the source in
their tree. They don't do that *today*, look at their trees.

>  > this patch set, and saying they would enable it. Not one voice seems to
>  > have appeared.
>
> I never claimed to represent any vendors. I said that it was my
> opinion that many vendors will want to apply this patch, and you seem

So why have the vendors not commented on list ? If they will want to
apply the patch why don't I see supporting email from them ?

>  > At that point nobody managing risk is going to do anything but remove the
>  > code that worries them. It's additional risk with no return.
>
> Some vendors may well do that. Some may decide to keep it as a compile
> time option. The legal advice that I've seen is that keeping it as a
> compile time option is fine.

I can't comment on the advice I've seen directly, but I will point out
that every vendor I am aware of *removes completely* any source material
which they view with concern. You can download the packages and review
them if you doubt it.

> If it's pulled out of kernel.org trees then:
>
>  - each vendor may end up with slightly different varients. That means
>    we could have Linux devices behaving inconsistently.

The Linux Foundation can manage a reference patch if it wants, or someone
can set up "Linux-USA" or similar git trees on top of the real kernel
one. Git is actually rather good at that.

>  - the testing and discussion may end up happening in a less open
>    manner. I think the testing and discussion on lkml has been very

Less open than "I'm sorry our lawyer says we can't use a non colliding
entry but we can't tell you why", plus of course to one person a "we will
tell you off list", which I understand they haven't.

>    valuable. As you've noted, vendors have not been actively
>    participating in these discussions. Do you think they'll suddenly
>    decide to start discussing things openly if we move it out of a
>    kernel.org tree? You must know how reluctant vendors are to draw
>    attention to themselves when it comes to patents.

I don't actually think they will participate either way - so this
argument of yours doesn't hold water either.

>  - some vendors may decide not to use Linux, and switch to embedded
>    windows instead if we don't have a clearly supported way of
>    avoiding these patents in the Linux kernels.

That is a business problem not a technical one. The people who keep the
out of tree patch need to share and discuss what they are doing. They
need to do that in a framework which allows them to do it right. That
means the Linux Foundation or similar with a lawyer present is the
nearest they can do to "open" any way.

>  - we'd be setting up the kernel to have a deliberate long term
>    difference between what a large part of the user base runs and what
>    is tested for kernel.org kernels. As I said previously, I think

That has always been the case. That is the established practice for all
packages in the open source world today. The kernel is not different. If
you put in special American treatment you need to do the same for Chinese
compliance (No reference to Taiwan as a country or implication thereof in
code page naming etc) and every other country in the world.

It's also an incredibly complicated specialist field. The vendors have
teams of experts working on it who deal with everything. Dumping that on
the community is neither appropriate nor fair. You want to sell Linux
products in the USA, you do the compliance work. Given that deciding what
do about FAT is a tiny spec of the vast red tape you must complete (from
crypto exports to liability insurance) its no real overhead to the vendor.

>    that is poor software engineering practice. I know you disagree,
>    but I also know that some other people do agree. I suspect you
>    would be more inclined to agree if this patch had nothing to do
>    with patents.

No. Red Hat have lots of patches that belong in their products that I
know about - from removing country flags from some versions of KDE to
removing certain crypto algorithms from ssh. None are upstream, none
belong upstream. The kernel is *NOT* different to every other of the
hundreds of packages shipped by vendors.

There is an established practice over many years for this stuff, and it
is contrary to your model of messing with base reference code to meet
random national legislation.

> I suspect you are right that many vendors would apply it anyway if it
> wasn't in a kernel.org kernel. Is that sufficient to stop a new round
> of lawsuits? Maybe. If that is what is decided then I guess we'll find
> out over the next year or two.

Maybe kernel.org shouldn't be hosted in the USA. That seems to be what
the "reduce risk" argument you are making is really saying if you continue
it to its logical conclusion.

No action you take except closing down and going home determines whether
patent lawsuits get filed. You know that. In the US and quite a few other
states patent lawsuits are rarely based on fact, evidence or process.
They are a business tool used to raise costs and hamper rivals. You file
patent lawsuits to force people to use your hardware, to slow down
business rivals who are ahead in a key market and to slow adoption by
creating fear. None of it has anything to do with validity or actual
infringement.

You have about as much need for an actual infringement to file a US
patent law suit as to actually find chemical weapons in Iraq to start a
war.

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

[Jan Engelhardt-3]

On Wednesday 2009-07-08 12:48, tridge@... wrote:
>
> - some vendors may decide not to use Linux, and switch to embedded
>   windows instead if we don't have a clearly supported way of
>   avoiding these patents in the Linux kernels.

I perceive that:
Linux is primarily about doing things the right way, not about making
the largest userbase (it is a welcomed side-effect though).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Alan,

 > James reply was based on the fallacy that vendors will keep the source in
 > their tree. They don't do that *today*, look at their trees.

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.

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.

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.

I don't want that. I want to *fight*.

So how do we fight these and all the other patents that threaten
Linux? We implement the damn functionality anyway, finding a smart way
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.

The patch I've posted is a good first step in showing the kernel
community how to do this. I'd like to see us apply the same approach
outside the kernel too. I'd like to see us produce implementations of
the 'patented' codecs that meet the same high standards for being
clearly non-infringing as the patch that I've posted for VFAT does.

I've been applying this approach in Samba for years, and it
*works*. Samba is extremely functional. We have not once had a user
complaint about a missing feature because of a patent workaround. How
do you reckon we achieved that?

We, as a technical community, have the very best possible set of
resources for actually beating the patent system at its own game. Far
better than any company in the world by a very large margin.

We can also teach patent holders that filing a patent suit against the
Linux community is a _really_ bad idea. Patent holders will soon find
out that when they do that then there will quickly be a public
workaround to their patent posted. That public workaround can then be
used by not just the free software community, but also by the normal
proprietary vendors that these agressive patent holders make their
licensing money off.

So patent holders will learn that taking on the free software
community over patents loses them income from patent licensing. They
risk a huge, very talented, very motivated community of engineers
focussing its attention on their patent and finding a way around
it. They will learn that it is better to go after softer targets.

Short of a political miracle, that is the only way we are going to
beat the patent system.

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

 > So why have the vendors not commented on list ? If they will want to
 > apply the patch why don't I see supporting email from them ?

I'm pretty sure you were at RedHat during a couple of patent
suits. What is the first thing that happened? I bet the lawyers told
everyone not to talk publicly about the patents.

That is standard practice within companies. How should we react to
that? We should react by helping them when they need the help. When we
need the help some day perhaps they will help us.

 > I can't comment on the advice I've seen directly, but I will point out
 > that every vendor I am aware of *removes completely* any source material
 > which they view with concern. You can download the packages and review
 > them if you doubt it.

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
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.

We can teach each other those skills, and we can learn to beat
patents.

So please Alan, think about whether the approach that has been taken
for so long is working. Think about how it stops us using our brains
to solve problems that we're good at solving. Think about how much
worse things may get.

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

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

[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@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

Martin Steigerwald wrote:
> I don't believe that Microsoft is still providing updates for Win98. But I
> think Windows 2000 might still be in use

Definitely.  The mail server belonging to a company that pays me for
embedded Linux work runs on Windows 2000.  I moved it to a virtual
machine about 1 year ago - it's still in use.

> - I for example have a Win 2000
> installation on my ThinkPad T23, although I didn't boot it for about a
> year or so. Has it been tested against Windows 2000? I digged for the mail
> where you said something about against which Windows versions you tested,
> but I didn't find it anymore.

Heh.  I still use Windows 95 and Windows 98 occasionally.  I'm a bit
disappointed to find Samba no longer tests against them :-)

I wouldn't be surprised if Windows ME has fewer users than 98.  98 had
a reputation for being the best of the non-NT series.

> > When the vendor of an operating system doesn't even bother to display
> > a clean "sorry, you don't get updates any more" page for their OS then
> > I think it is safe to say that the operating system is dead and
> > buried.
>
> It is safe to say much. But still users might not behave according to your
> saying or might even not be able to. A potential customer asked us to
> migrate a Windows 98 installation into a virtual machine, cause the
> software that is running there would not run with any newer version of
> Windows. Sometimes people are locked / forced to a specific Windows (or
> Linux) version at least is they do not want to pay lots of $$$ to replace
> their proprietary special hardware + software combination by something
> which is supported on a newer version of an operating system. And for a
> coincidence I think digital photos have been involved in that use case.

I think you've described commercial ancient Windows users.

But I suspect there are more non-commercial users - that ancient PC
someone has in their home which is good enough at running Word 2 for
_their_ word processing needs.  You know the sort of thing: ancient
14-inch CRT still going strong, friend probably replaced the disk 5
years ago and cloned the original working OS, fan's getting a bit
noisy but the old clunker isn't worth replacing just yet.

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

[Paul E. McKenney-2]

On Wed, Jul 08, 2009 at 11:21:33AM +0200, Pavel Machek wrote:
> On Fri 2009-07-03 09:59:35, tridge@... wrote:
> > Hi Pavel,
> >
> >  > That's why we have ethernet checksums.
> >
> > which of course just changes the number of bits. The argument remains
> > the same.
>
> Ok, so what is your estimate of XP crash probability?

Assuming the worst case where the user opens each file in the directory
of interest, the probability depends on the number of long-named files
in the given directory as follows (derivation at EOM):

Files Probability Odds
----- -------------------- -------
32767 3.934446601778345b-1 (39.3%)
16384 1.174969255061134b-1 (11.7%)
 8192 3.076314519945223b-2 ( 3.1%)
 4096 7.780179085651447b-3 ( 0.8%)
 2048 1.950268317016874b-3 ( 0.2%)
 1024 4.87685610530225b-4 (1 in 2,000)
  512 1.218244920604881b-4 (1 in 8,000)
  256 3.039790922077076b-5 (1 in 30,000)
  128 7.569761535306629b-6 (1 in 100,000)
   64 1.877544584847826b-6 (1 in 500,000)
   32 4.61935894834079b-7 (1 in 2,000,000)
   16 1.117587032466174b-7 (1 in 9,000,000)
    8 2.607703180994292b-8 (1 in 38,000,000)
    4 5.587935438151892b-9 (1 in 180,000,000)
    2 9.313225746154785b-10 (1 in 1,000,000,000)
    1 0.0b0

The number of files that people keep in a given directory will vary,
but in my admittedly limited experience, most people tend towards the
low end of this range.  What number of files per directory do you see
on embedded-device memory sticks?

Furthermore, this assumes that the user actually opens each and every file
in the directory.  If the user keeps (say) 1024 files in the directory,
but only opens two of them on any given memory-stick insertion, then
the odds are one in a billion rather than one in two thousand.

[Tridge -- isn't this only for subdirectories?  Or can collisions in
the root directory also result in WinXP bluescreens?]

> >  > It already _was_ perfect before you started patching it.
> >
> > wow, I really didn't expect the objection to my patch to be that VFAT
> > is perfect!
>
> But ... it was, and there is still possibility of just using position
> in directory to avoid collisions completely.

Almost.  The imperfection comes from the fact that storage media are not
totally reliable, so that given enough uses of large enough numbers of
memory sticks, there will eventually be a WinXP bluescreen.  Please note
that people really have reported this WinXP bug.

                                                        Thanx, Paul

------------------------------------------------------------------------

Derivation:

o The patch uses 6 random bytes, with 6 bits each, for
        32^6 = 1,073,741,824 possible combinations.  (Based on code
        in vfat_build_dummy_83_buffer() in the patch Tridge posted on
        June 27th.)

o There are a maximum of 32,767 entries in a VFAT directory.

o In the worst case, the user application will open each and
        every file in the directory.  I don't have any information on
        whether WinXP has a limited memory for recently open files.
        I therefore assume the worst case, namely that WinXP remembers
        every file that it has opened.

o As noted in this thread, the probability of bluescreen is
        given by the infamous Birthday Paradox:

                P(n, m) = (n-1)! / ((n-m)! * n^(m-1))

        Here "n" is the number of possible birthdays (1,073,741,824 in
        this case) and "m" is the number of people (32,767 in this case).
        P(n, m) is the probability of -no- common birthday, so the
        probability of WinXP bluescreen is 1-P(n,m).

        Because I don't want to worry about round-off error, I use the
        arbitrary-precision arithmetic in the "maxima" symbolic-math
        package, which is related to the fabled Macsyma project.  However,
        computing the factorials without cancellation takes too long,
        so we transform the factorials into the binomial function, which
        has a highly optimized maxima implementation.  The equivalent
        but more efficient representation is as follows:

                b(n,m):=binomial(n,m)*m!/n^m;

        Then 1-b(32^6,32767) gives the exact probability of bluescreen
        on a maximal-sized directory, which is the ratio of a pair of
        extremely large integers.  More usefully, bfloat(1-b(32^6,32767))
        gives an approximation in scientific notation.  (Don't forget
        the trailing semicolon that maxima requires.)

        Computing bfloat(1-b(32^6,32767)) takes about 70 seconds on my
        2GHz x86 laptop.

        See below for the actual maxima output, typos and all.

------------------------------------------------------------------------

maxima

Maxima 5.12.0 http://maxima.sourceforge.net
Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) b(n,m):=binomial(n,m)*m!/n^m;
                                    binomial(n, m) m!
(%o1)                    b(n, m) := -----------------
                                            m
                                           n
(%i2) bfloat(1-b(32^6,32767));
(%o2)                        3.934446601778345b-1
(%i3) bfloat(1-b(32^6,2^14));
(%o3)                        1.174969255061134b-1
(%i4) bfloat(1-b(32^6,2^13));
(%o4)                        3.076314519945223b-2
(%i5) bfloat(1-b(32^6,2^12));
(%o5)                        7.780179085651447b-3
(%i6) bfloat(1-b(32^6,2^11));
(%o6)                        1.950268317016874b-3
(%i7) bfloat(1-b(32^6,2^10));
(%o7)                         4.87685610530225b-4
(%i8) bfloat(1-b(32^6,2^9));
(%o8)                        1.218244920604881b-4
(%i9) bfloat(1-b(32^6,2^8));
(%o9)                        3.039790922077076b-5
(%i10) bfloat(1-b(32^6,2^7));
(%o10)                       7.569761535306629b-6
(%i11) bfloat(1-b(32^6,2^6));
(%o11)                       1.877544584847826b-6
(%i12) bfloat(1-b(32^6,2^));
Incorrect syntax: Illegal use of delimiter )
bfloat(1-b(32^6,2^)
                 ^
(%i12) bfloat(1-b(32^6,2^5));
(%o12)                        4.61935894834079b-7
(%i13) bfloat(1-b(32^6,2^4));
(%o13)                       1.117587032466174b-7
(%i14) bfloat(1-b(32^6,2^3));
(%o14)                       2.607703180994292b-8
(%i15) bfloat(1-b(32^6,2^2));
(%o15)                       5.587935438151892b-9
(%i16) bfloat(1-b(32^6,2^1));
(%o16)                       9.313225746154785b-10
(%i17) bfloat(1-b(32^6,2^0));
(%o17)                               0.0b0
(%i18)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[James Bottomley-2]

On Wed, 2009-07-08 at 11:04 +0100, Alan Cox wrote:
> > that it should be configurable, but I don't think it leads to the
> > conclusion that the patch should not be in the upstream kernel at all.
>
> I think we already proved it had no use upstream. Vendors will remove
> the code from their source tree if worried about patents so including it
> in the base tree is really irrelevant. So I find your argument about this
> less than convincing.

You have asserted such, but that's not proof.  If your assertion were
valid, vendors would already have removed all the msdos/vfat code, which
they haven't.

Obviously I have no idea what your ex-employer will do. I also can't
speak for Novell, but very likely what we'll do is leave the decision
for OpenSUSE up to the OpenSUSE community and likely follow the kernel
default for SLE.

> The patch serves no purpose but to confuse users and increasingly it is
> shown to break systems horribly.
>
> There might have been a limited case for a not-quite-vfat-fs "tridgefat"
> etc if it was both more compatible and if the vendors would use the
> option. But given its not compatible and vendors won't why bother at all ?
>
> I also note you keep talking about vendors. This is an open list yet I
> don't hear a word from the vendors you claim to represent in support of
> this patch set, and saying they would enable it. Not one voice seems to
> have appeared.

Why would vendors wish to comment?  Their position universally is that
the FAT32 patents are invalid.  However, they also recognise that
trolling with invalid patents is increasingly becoming a nasty problem
for their customers, and with TomTom Microsoft has shown willing to do
this, so anything that lowers the risk and potential costs to customers
would be a good thing for vendors.

> The decision sequence goes something like this
>
> - do we want to ship the feature because of patent concern
> > do not ship
> - is it less risk to remove the source from our build tree or
>  configure it out
> > remove from the tree
> - is there a functionality difference to the user between
>  removing or unconfiguring it
> > No
>
> At that point nobody managing risk is going to do anything but remove the
> code that worries them. It's additional risk with no return.

I think you might be confusing two sources of risk.  The risk of
actually infringing a real patent is what you're covering above.  The
source of risk in this case is the risk of being trolled with an invalid
patent but have to spend millions of dollars to demonstrate such if it
goes to trial.  The patch mitigates the latter risk by making it
demonstrable at a preliminary hearing that the invalid patent doesn't
read upon the kernel implementation.

James


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

[Alan Cox]

> > I think we already proved it had no use upstream. Vendors will remove
> > the code from their source tree if worried about patents so including it
> > in the base tree is really irrelevant. So I find your argument about this
> > less than convincing.
>
> You have asserted such, but that's not proof.  If your assertion were
> valid, vendors would already have removed all the msdos/vfat code, which
> they haven't.

That represents loss of functionality for loss of risk (a trade off). If
they are going to disable stuff then they'll pull the lot (loss of risk
for free). Remember the GPL requires you provide the *sources* you used
to create the binaries, not redacted ones so if you don't want to provide
feature X for some reason you need to pull it out of your source tree
before you build.

> > - do we want to ship the feature because of patent concern
> > > do not ship
> > - is it less risk to remove the source from our build tree or
> >  configure it out
> > > remove from the tree
> > - is there a functionality difference to the user between
> >  removing or unconfiguring it
> > > No
> >
> > At that point nobody managing risk is going to do anything but remove the
> > code that worries them. It's additional risk with no return.
>
> I think you might be confusing two sources of risk.  The risk of
> actually infringing a real patent is what you're covering above.  The
> source of risk in this case is the risk of being trolled with an invalid
> patent but have to spend millions of dollars to demonstrate such if it
> goes to trial.  The patch mitigates the latter risk by making it
> demonstrable at a preliminary hearing that the invalid patent doesn't
> read upon the kernel implementation.

At that point we get into legal advice I can't comment on in public.
However based on previous discussions about source code and other patterns
suffice to say I don't agree.

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

[James Bottomley-2]

On Wed, 2009-07-08 at 16:37 +0100, Alan Cox wrote:

> > > I think we already proved it had no use upstream. Vendors will remove
> > > the code from their source tree if worried about patents so including it
> > > in the base tree is really irrelevant. So I find your argument about this
> > > less than convincing.
> >
> > You have asserted such, but that's not proof.  If your assertion were
> > valid, vendors would already have removed all the msdos/vfat code, which
> > they haven't.
>
> That represents loss of functionality for loss of risk (a trade off).

Precisely ... that's what this whole thread is about.  Accepting the
lawyer's argument that this patch eliminates the risk of suit under the
FAT32 patents, does the loss of functionality it comes with represent an
adequate reward?

>  If
> they are going to disable stuff then they'll pull the lot (loss of risk
> for free).

I'd agree with that, the problem is the loss of functionality ... and
actually, the best outcome for this would be to come up with a true
light weight filesystem that could replace the rather crap DOS/FAT32 one
in embedded applications based on fully free source and no patent
encumbrances and have it adopted as a universal standard for flash/USB
stick/mmc interchange.

> Remember the GPL requires you provide the *sources* you used
> to create the binaries, not redacted ones so if you don't want to provide
> feature X for some reason you need to pull it out of your source tree
> before you build.

OK, so we disagree on whether providing source code constitutes
contributory infringement.

> > > - do we want to ship the feature because of patent concern
> > > > do not ship
> > > - is it less risk to remove the source from our build tree or
> > >  configure it out
> > > > remove from the tree
> > > - is there a functionality difference to the user between
> > >  removing or unconfiguring it
> > > > No
> > >
> > > At that point nobody managing risk is going to do anything but remove the
> > > code that worries them. It's additional risk with no return.
> >
> > I think you might be confusing two sources of risk.  The risk of
> > actually infringing a real patent is what you're covering above.  The
> > source of risk in this case is the risk of being trolled with an invalid
> > patent but have to spend millions of dollars to demonstrate such if it
> > goes to trial.  The patch mitigates the latter risk by making it
> > demonstrable at a preliminary hearing that the invalid patent doesn't
> > read upon the kernel implementation.
>
> At that point we get into legal advice I can't comment on in public.
> However based on previous discussions about source code and other patterns
> suffice to say I don't agree.

OK, so rather than get into a what my lawyer says versus what your
lawyer says argument, can we get back to the technical aspects of this
and leave the lawyers retained by the vendors to sort out what they
actually do?

James


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

[Alan Cox]

> > That represents loss of functionality for loss of risk (a trade off).
>
> Precisely ... that's what this whole thread is about.  Accepting the
> lawyer's argument that this patch eliminates the risk of suit under the
> FAT32 patents, does the loss of functionality it comes with represent an
> adequate reward?

You are missing the point still.

Ship with problem feature enabled risk high    features high
Ship with problem off but in source risk lower   features low
Ship with it ripped out risk lowest  features low

So the only two logical positions to operate are low feature/lowest risk
and high feature/high risk. So if you decide not to ship the feature it'll
get ripped out entirely.

> OK, so we disagree on whether providing source code constitutes
> contributory infringement.

We disagree whether there is zero risk involved. If there is any risk
then the logical position if you've decided not to enable the feature is
not to ship source for it.

> OK, so rather than get into a what my lawyer says versus what your
> lawyer says argument, can we get back to the technical aspects of this
> and leave the lawyers retained by the vendors to sort out what they
> actually do?

Sure and I'd say the technical issues are simple

- Tridge's patch breaks stuff
- Tridge's patch masquerades as vfat but isn't.

We can fix those by only creating short names (but honouring existing
long ones) and by not claiming its vfat.

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

[H. Peter Anvin]

Pavel Machek wrote:
>
> But ... it was, and there is still possibility of just using position
> in directory to avoid collisions completely.

I was just going to ask this.  Rather than using a random number, we
should use something based on the position in the directory, and I
suspect we should still verify that it is unique (since some FAT
implementation may garbage-collect the directory thereby moving the offset.)

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Jeremy Allison]

On Wed, Jul 08, 2009 at 02:53:27PM +0100, Jamie Lokier wrote:

> Heh.  I still use Windows 95 and Windows 98 occasionally.  I'm a bit
> disappointed to find Samba no longer tests against them :-)

We do run regression tests that emulate Win9x against Samba
and ensure we pass. We also fix bugs reported by Win9x and
OS/2 users with Samba.

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

Hi Paul,

These probabilities are way off. They assume that whatever interaction
happens in XP has infinite memory. The testing I've done indicates
that the memory for this interaction is very small (maybe 3 or 4? it's
hard to know precisely).

I've also confirmed this with lots of testing. If the probability was
39% for any directory size then I would have found it.

In all my testing I did not once produce a XP crash with the full
patch. To produce the XP crash I needed to have a reduced version of
the patch with less randomness.

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

[Paul E. McKenney-2]

On Thu, Jul 09, 2009 at 07:42:27AM +1000, tridge@... wrote:
> Hi Paul,
>
> These probabilities are way off. They assume that whatever interaction
> happens in XP has infinite memory. The testing I've done indicates
> that the memory for this interaction is very small (maybe 3 or 4? it's
> hard to know precisely).

Good to know!  I will rework assuming that the memory is 4, let me
know if you learn more.

> I've also confirmed this with lots of testing. If the probability was
> 39% for any directory size then I would have found it.

This new information will likely reduce the predicted probability of
bluescreen by several orders of magnitude for large directories.  Not
that much effect for small directories, but not a real issue given
how low the probabilities are to begin with.

> In all my testing I did not once produce a XP crash with the full
> patch. To produce the XP crash I needed to have a reduced version of
> the patch with less randomness.

Well, let's see if I can produce a reasonably realistic model.  :-)
(I knew I should have gotten more sleep last night!!!)

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

[Paul E. McKenney-2]

On Wed, Jul 08, 2009 at 03:14:13PM -0700, Paul E. McKenney wrote:

> On Thu, Jul 09, 2009 at 07:42:27AM +1000, tridge@... wrote:
> > Hi Paul,
> >
> > These probabilities are way off. They assume that whatever interaction
> > happens in XP has infinite memory. The testing I've done indicates
> > that the memory for this interaction is very small (maybe 3 or 4? it's
> > hard to know precisely).
>
> Good to know!  I will rework assuming that the memory is 4, let me
> know if you learn more.
>
> > I've also confirmed this with lots of testing. If the probability was
> > 39% for any directory size then I would have found it.
>
> This new information will likely reduce the predicted probability of
> bluescreen by several orders of magnitude for large directories.  Not
> that much effect for small directories, but not a real issue given
> how low the probabilities are to begin with.
>
> > In all my testing I did not once produce a XP crash with the full
> > patch. To produce the XP crash I needed to have a reduced version of
> > the patch with less randomness.
>
> Well, let's see if I can produce a reasonably realistic model.  :-)
> (I knew I should have gotten more sleep last night!!!)

This model assumes a finite memory, so that at least two files out of
a group of "l" recently opened files have to collide to result in a
bluescreen.  I don't trust it yet, but thought I should give people a
chance to poke holes in it.

                                                        Thanx, Paul

------------------------------------------------------------------------

Results

Assuming the worst case where the user opens each file in the directory
of interest, the probability depends on the number of long-named files
in the given directory as follows (derivation at EOM):

Files Probability Odds
----- -------------------- -------
32767 9.15401625433259b-5 (1 in 11,000)
16384 4.576973184985319b-5 (1 in 22,000)
 8192 2.288233388567135b-5 (1 in 44,000)
 4096 1.143843845796893b-5 (1 in 87,000)
 2048 5.716441632059139b-6 (1 in 170,000)
 1024 2.855430941007629b-6 (1 in 350,000)
  512 1.424922525947476b-6 (1 in 700,000)
  256 7.096675510325187b-7 (1 in 1,400,000)
  128 3.520398717286601b-7 (1 in 2,800,000)
   64 1.732259841151157b-7 (1 in 5,800,000)
   32 8.381902831793723b-8 (1 in 12,000,000)
   16 3.911554742174612b-8 (1 in 26,000,000)
    8 1.676380622425006b-8 (1 in 60,000,000)
    4 5.587935438151892b-9 (1 in 179,000,000)
    2 9.313225746154785b-10 (1 in 1,000,000,000)
    1 0.0b0

This is for 2^32 random values per entry and a WinXP "memory" of four
entries.

------------------------------------------------------------------------

Derivation:

o The patch uses 6 random bytes, with 6 bits each, for
        32^6 = 1,073,741,824 possible combinations.  (Based on code
        in vfat_build_dummy_83_buffer() in the patch Tridge posted on
        June 27th.)

o There are a maximum of 32,767 entries in a VFAT directory.

o In the worst case, the user application will open each and
        every file in the directory.  WinXP seems to have a limited
        memory for recently opened files, and we assume that once this
        memory is full, opening a new file causes one of the recently
        opened files to be forgotten.  The size of its memory appears
        to be in the range of 3-4 based on Tridge's testing, so we
        will assume the worst case (4) and parameterize with l=4.

o As noted earlier, the probability the infamous Birthday Paradox
        is given by:

                P(n, m) = (n-1)! / ((n-m)! * n^(m-1))

        Here "n" is the number of possible birthdays (1,073,741,824 in
        this case) and "m" is the number of people (32,767 in this case).
        P(n, m) is the probability of -no- common birthday.  This is not
        the probability of no bluescreen, but we will use this result
        to calculate this probability while initially filling WinXP's
        memory.  I again use maxima, and again use the optimized form
        based on the binomial function:

                b(n,m):=binomial(n,m)*m!/n^m;

o See the attached .eps...

o The probability of no bluescreen while opening the first "l"
        files is given by b(n,l), just as before.

o Given no bluescreen while opening the first "l" files, the
        probability of no bluescreen while opening the "l+1"st file
        is the probability of missing the "l-1" files that remain
        after ejecting one of them to make room is "(n-l+1)/n".

        The cumulative probability of no bluescreen is thus:

                P(n,m,l) = b(n,l)*(n-l+1)/n

o We have the same situation when opening the "l+2"nd file,
        the probability of no bluescreen is again "(n-l+1)/n".

o This situation will repeat "m-l" times, so that we have:

                P(n,m,l) = b(n,l)*((n-l+1)/n)^(m-l)

        In maxima-speak:

                b(n,m):=binomial(n,m)*m!/n^m;
                nbs(n,m,l):=b(n,l)*((n-l+1)/n)^(m-l);

        The probability of bluescreening when faced with 32767 files
        in a directory, 32^6 possible random values, and the capacity
        to remember four files is then:

                1-nbs(32^6,32767,4);

        For floating-point results instead of a massive fraction:

                bfloat(1-nbs(32^6,32767,4));

        See below for the actual maxima output, typos and all.

------------------------------------------------------------------------

maxima

paulmck@paulmck-laptop:~$ maxima

Maxima 5.12.0 http://maxima.sourceforge.net
Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) b(n,m):=binomial(n,m)*m!/n^m;
                                    binomial(n, m) m!
(%o1)                    b(n, m) := -----------------
                                            m
                                           n
(%i2) nbs(n,m,l):=b(n,l)*((n-l+1)/n)^(m-l);
                                            n - l + 1 m - l
(%o2)              nbs(n, m, l) := b(n, l) (---------)
                                                n
(%i3) bfloat(1-nbs(32^6,32767,4));
(%o3)                         9.15401625433259b-5
(%i4) bfloat(1-nbs(32^6,2^14,4));
(%o4)                        4.576973184985319b-5
(%i5) bfloat(1-nbs(32^6,2^13,4));
(%o5)                        2.288233388567135b-5
(%i6) bfloat(1-nbs(32^6,2^12,4));
(%o6)                        1.143843845796893b-5
(%i7) bfloat(1-nbs(32^6,2^11,4));
(%o7)                        5.716441632059139b-6
(%i8) bfloat(1-nbs(32^6,2^10,4));
(%o8)                        2.855430941007629b-6
(%i9) bfloat(1-nbs(32^6,2^9,4));
(%o9)                        1.424922525947476b-6
(%i10) bfloat(1-nbs(32^6,2^8,4));
(%o10)                       7.096675510325187b-7
(%i11) bfloat(1-nbs(32^6,2^7,4));
(%o11)                       3.520398717286601b-7
(%i12) bfloat(1-nbs(32^6,2^6,4));
(%o12)                       1.732259841151157b-7
(%i13) bfloat(1-nbs(32^6,2^5,4));
(%o13)                       8.381902831793723b-8
(%i14) bfloat(1-nbs(32^6,2^4,4));
(%o14)                       3.911554742174612b-8
(%i15) bfloat(1-nbs(32^6,2^3,4));
(%o15)                       1.676380622425006b-8
(%i16) bfloat(1-nbs(32^6,2^2,4));
(%o16)                       5.587935438151892b-9
(%i17) bfloat(1-nbs(32^6,2^1,4));
(%o17)                      - 1.734723480823569b-18
(%i18) bfloat(1-b(32^6,2));
(%o18)                       9.313225746154785b-10
(%i19) bfloat(1-b(32^6,1));
(%o19)                               0.0b0

Hi Alan,

 > 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.

We have discussed implementation details on this list. We've shown the
code, and a FAQ on how the code works.

The situation is much more subtle with regard to what can be publicly
discussed than what you make out. Think of it like the media training
that many engineers get in companies these days. You need to learn
what words can and cannot be used. I think it is perfectly possible to
have public discussions of patents such as we are having right now.

I grant you that it is very unusual to do this, but I would like to
see that change.

 > > 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.

no, when the vendors are given a clearly non-infringing way of
implementation then I think they will go for it. The proof is that
they still ship Samba, which includes patent workarounds, and I'm sure
there are plenty of other free software packages which similarly have
patent workarounds and that are shipped with distros all the time.

 > 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

you are mixing up "validity" and "non-infringment". If my argument was
in any way based on a patent being "invalid" then you would be right,
because a court is required to start from the assumption that a patent
is valid. Trying to fight a patent based on invalidity is really
really hard.

The court is not required to start with the assumption that a piece of
code infringes a patent - quite the opposite in fact. If the defendent
can show a clear argument as to why it is not infringing then the
patent holder quickly loses.

Do you know of any example where a defendent had a really good
non-infringment argument and still lost a case?

 > 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 ?

'works' for all devices, except that any Linux users copying a file
with a long name to the device get an error. That is not my idea of
'works'.

My patch in May proposed that solution because of it's simplicity, not
because it was the best solution. It was the first solution I thought
of, and I'm sure others thought of it too, but it loses so much
functionality that it would be a very painful solution for Linux
vendors.

The dualnames patch achieves a much higher degree of functionality for
a much wider number of users. It isn't perfect, but I think it is much
better.

 > 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"

again, this is validity, not non-infringment. I am not advocating a
"you're patent is invalid" argument, as that is not certain enough. I
am advocating a "we don't implement that" approach.

 > 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

and what did TomTom do on these patents? They had to give in, because
they didn't have a workaround. What has that taught the patent holders
of the world?

I'd like to teach patent holders that if you assert a patent against a
free software implementation of any bit of technology that you will
have a huge group of engineers working on stomping all over your
patent, thus threatening the nice little revenue stream you have from
other proprietary licensees.

We need to be seen as the guys with the big club who even the bullies
don't mess with.

The great thing about this is that it works even better with patent
trolls. Their sole purpose in life is to derive revenue from their
patents. If we become known as the guys who threaten that income then
the trolls will give us a wide berth.

This is an advantage that only the free software community has. If a
proprietary vendor finds a patent workaround then they will keep it
secret, as they don't want the other proprietary vendors to be able to
avoid the license fee. That means the trolls lose just one victim if a
proprietary vendor finds a workaround. With the free software
community our open code means that the trolls will be risking their
entire revenue stream from the patent by attacking any vendor based on
free software. That puts us in a uniquely strong position in the
patent world.

 > - 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)

And if we make it so that copying files to a FAT filesystem return
-1/ENAMETOOLONG then what will that do to users? You really think
users will have sympathy with the situation then?

 > - if you delete stuff from base packages you hurt people in the rest of
 >   the world unneccessarily

that impacts only what the default should be, not whether the patch
should be in at all.

 > - patents are a tiny part of the process anyone shipping any software
 >   commercially on a scale worth lawsuits goes through reviewing.

so? For all the other parts of the process there are ways to manage
it. For patents, the solution of removing large amounts of
functionality is non-workable for many packages.

 > 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.

and how is your preffered 'return -1/ENAMETOOLONG' for valid long
names 'vfat'? A new filesystem name could be used, but I think that is
largely cosmetic. How many Linux users, other than developers,
actually type:

  mount -t vfat .....

I think nearly all users just rely on the auto-detection of the fs
type.

 > 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.

It is the 'some naming limits' bit which is the problem. As was
pointed out when I posted the patch that did this in May, those limits
impact a whole lot of normal use cases.

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