lkml.org 
[lkml]   [2000]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.

    [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/

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