[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

Larry McVoy lm at mcvoy.com
Tue Sep 19 13:37:45 AEST 2017


On Mon, Sep 18, 2017 at 10:56:51PM -0400, Gregg Levine wrote:
> Hello!
> Larry, back when I was a serious Kernel Hacker, I actually obtained
> the appropriate release of Bitkeeper for grabbing the raw source code
> for the kernel that Linus wrote.
> 
> I found it much easier to use then what is in use now. Its few errors
> thrown in my direction were easier to understand then the many thrown
> at me by the current tool. 

yeah, git suffers from the Not Unix problem that Linux has.  There is a
lot of value in the Unix approach which is, in my opinion, fairly terse.
Do a little but do it right.  Don't go crazy with every option that
every well intentioned person wants, do the subset that is what people
truly want even if they don't realize it.

I know it doesn't matter at this point, git won, but BitKeeper is open
source under the very liberal Apache license (and if you don't like
that one for a good reason I can rerelease under a different license)
and there is a ton of useful stuff in there that has nothing to do with
source management.  Most of perl/lisp is in there, cross platform stuff
that includes windows is in there, some pretty amazing stdio work that I
wish Chris Torek would suck back into NetBSD is in there, and BK itself
is pretty sweet.  I routinely do

	git -C git-repo fast-export master | bk fast-import bk-repo

so I can look at the source with BK tools.  BK differs from git in many
ways, but to you Unix people, BK has the inode concept.  There is a
thing that is a file, it doesn't care where it lives, the pathname is
an attribute of the file, just like the changes are.  Git doesn't have a
file concept, no inode for you.  So no create/unlink/rename, Git doesn't
have those, BitKeeper does.  In practice that hurts, sometimes a lot,
in a big repo git blame is useless because it is so slow, bk's blame
runs in milliseconds.

And can we talk about merges?  Git has one graph for the entire
repository.  BitKeeper has a graph for each inode.  So when Git goes
to merge it's going to use the GCA for the repository for everything.
BitKeeper uses the GCA for the file which is always a better choice.
And BK uses a ton more info, go read the code, it's cool, way better
than diff3.

I weep when I look at Git.  It's just crap yet that is what the world
uses.  It's exactly what I predicted when I was arguing with the FSF,
if you want everything to be free then what you will get is substandard
stuff.	Not all the time but most of the time.

Part of the reason I love this list is it is full of people who were
careful, they cared about the code (look at the good taste thread) and
they cared about regressions, they cared that people could understand
what they did.	(And, for the record, I just love love love the stories
about the history, Mr Yacc has some great ones, Clem has great ones,
all you guys rock when you are talking about how you made something work.)

While I use Linux, I yearn for the days where you guys and the SunOS
guys were carefully, very carefully, creating a decent system that had
an architecture that you could see if you looked hard enough.  Unix
had that, I'm not sure Linux and friends does.

--lm

If you want the BK source it's at bitkeeper.org


More information about the TUHS mailing list