On Sun, 9 Jan 2000, Richard B. Johnson wrote:
> On Sun, 9 Jan 2000, Theodore Y. Ts'o wrote:
>
> > Richard B. Johnson wrote:
> > > For instance, there was a simple new change in the type of
> > > an object passed to poll and friends. This just cost me two
> > > weeks of unpaid work! Unpaid because I had to hide it. If
> > > anyone in Production Engineering had learned about this, the
> > > stuff would have been thrown out, the MicroCreeps would have
> > > settled in with "I told you so..", and at least three of us
> > > would have lost our jobs.
> >
> > You had the choice of not upgrading to the latest kernel, didn't you?
> >
> > If it was you who chose to upgrade to the latest kernel, why are you
> > complaining to us?
> >
> > If you told your management that Linux kernel interfaces never change
> > across versions, then you were sadly mistaken. However, the mistake is
> > on your end, I'm afraid.
> >
>
> No. According to our Legal Department, to satisfy the GPL requirement
> that we provide source to the end-user, they required that we supply a
> "current" distribution of Linux if the end-user requests it.
Oh. My. God. They are requiring you to do WHAT??? Do you mean that you
really ship 2.3.x to your customers? Arrggh. "Source" == "source of what
we are shipping". And not "anything that was written by other guys who
started from the same source". It's utter nonsense. _No_ license can
oblige you to include the modifications done by somebody else. Otherwise
you'ld have those drivers in the main tree, BTW - _that_ much should be
clear even for your LD.
[snip]
> The obvious solution, given these constraints, is that we just ignore
> all changes until shipping time, then attempt to compile with the latest
> distribution, fixing all the problems at once. However, we then end up
> shipping untested software which ends up being another problem. Checking
> to see if it "runs" isn't testing software in the cold cruel world of
> industry.
You do realize that stability of the system doesn't exceed that of the
weakest link, don't you? You _are_ shipping untested software if you are
shipping 2.3.whatever + your drivers. It's called unstable for a good
reason. Ouch... OK, what if Linus will put a
pre-patch-2.3.39-dont-even-think-of-using-it-anywhere-near-your-data-3.gz
on ftp.kernel.org tomorrow? Will your LD require you to ship _that_? No?
Is the notion of 'untested software' completely alien to them?
BTW, you could point them to Debian or RH - none of them ships the 2.3.x
in released versions _and_ it's not even the latest 2.2.x existing. Hell,
Debian 2.1 is shipped with 2.0 - switch to 2.2 is in potato (== Debian 2.2
to be). RH uses 2.2.12, AFAICS (with a lot of patches). And all of them
have darn good reasons to do so - stability being the first one. Is there
any chance to get your legal folks talking with RH lawyers? Or Caldera, or
Corel ones...
> So, presently, I have 13 drivers I have to keep "current". Yesterday
> they all got broken again. A week before, half of them were broken
> because somebody didn't like a variable name!
Which might mean that repository of pointers to 3rd-party drivers (along
with the contact info) might be Good Thing(tm).
I would suggest the following: keep this information in DNS (RBL-like
scheme; i.e. <driver_name>.<author_or_company_name>.drivers.linux.org
having TXT record with URL and kernel version(s) in the body). Then all
you need is (a) standard address (e.g. update@drivers.linux.org) aliased
to the script; (b) said script verifying (PGP, GPG, whatever) the source
of mail and updating the record. IOW, all it really takes is somebody with
nameserver, clue and decent connectivity. Any takers?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:15 EST