[lkml]   [2000]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] block device interfaces changes

    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.


    > 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
    on 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>
    having TXT record with URL and kernel version(s) in the body). Then all
    you need is (a) standard address (e.g. 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.023 / U:15.896 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site