Re: [Gnu-arch-users] Re: taglines vs explicit

[Tom Lord]

    > From: Davide Libenzi <address@hidden>

    > On Sun, 5 Oct 2003, Tom Lord wrote:

    > >     > From: Davide Libenzi <address@hidden>

    > >     > Come on Tom. I've never used BK but I did read a lot of its 
features (I
    > >     > don't think they advertise bogus things). It's a pretty nice SCM 
and the
    > >     > fact that its license sucks does not lower its technical value.

    > > No, the fact that it's just SCCS-on-steroids and cost _way_ _way_ too
    > > much to develop for what it does lowers its technical value.   The
    > > fact that a bunch of shell scripts, cranked out in about 90 days and
    > > converted to C in about 90 days, can compete with that crappy
    > > SCCS-on-steroids-blowhard-promoted-"solution" lowers its technical
    > > value.

    > I hope you're smart enough to not believe to numbers Larry shot about
    > developement costs. 

Well, given what I know about the architecture of BK, I suspect the
numbers are about right.   He made some really dumb low-level
decisions, and that translated into _way_ too much labor to deliver
the current product (and, looking forward, _way_ too much labor to
extend it with new features.).

It's a little hard to sum up the design space in a few sentences but
if you've been around it a bit, it's not too hard to spot the errors
at the root of BK.  (Shortest summary: "storage manager drives
design".)


    > Even if you have to understand that BK is not only the
    > core, but there're a bunch of GUI/integration tools to be accounted in the
    > check. 

Yeah, and we're like "third and inches" (c.f. american football) in
that area.


    > We are not talking about money here though, 

Maybe you aren't.

    > and if you take a step
    > aside you can't not recognize that BK did the right steps toward
    > distributed development. 

Nope.  LM took exactly one right step -- and that was working on
giving linus some semblance of revctl religion.   The details of bk
that pertain to that are not the central details of bk.

    > It's hard to believe that suddendly a huge number
    > of pretty smart engineers in lkml decided to go with BK. 

Why, exactly?   Do you think there was a systematic and careful
evaluation of the issues by these people?

-t