7 ms·

Wow, just noticed this. I'm the guy who paid for Little, a bunch of other people did all the work. I'm surprised to see it getting some attention but happily

Wow, just noticed this. I'm the guy who paid for Little, a bunch of other people did all the work. I'm surprised to see it getting some attention but happily so. Little is what I'd like C to evolve towards, there is a lot of useful (to me) stuff in the language. I'll wander through the comments and reply where I can.

marktangotango 6y ago
I'm curious if you've written about the decisions around licensing that essentially killed the bitkeeper business by inspiring Linus to create git? What are your thoughts around that today?
- luckydude 6y ago
  Hind sight is 20-20. The BitKeeper business had a good run, we were around for 18 years. It made enough that I and my business guy are retired off of what we made. On the other hand, we didn't make enough for everyone to retire if they wanted to. We had a github like offering and it's pretty clear that we should have put a bunch of money into that and open sourced BitKeeper. All I can say is it is incredibly hard to make that choice when you have something that is paying the bills. I tried to get Sun to do it with the BSD based SunOS and they wouldn't. And even though I had that vision for Sun, when it was my livelihood, I couldn't see the path to doing so. Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it's a crappy design. It does what he wants, but what he wants is not what the world should want. It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits. Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.
  - brundolf 6y ago
    I hadn't heard of BitKeeper but it sounds interesting. Have you considered open-sourcing it now for people to look at, even though the business has faded?
    - luckydude 6y ago
      http://bitkeeper.org http://bitkeeper.org Been open source for years
    - momszack 6y ago
      This makes me feel old. The bitkeeper saga is why GitHub exists. The drama is archived in 2004-5 lkml.
      - brundolf 6y ago
        I was twelve :)
  - JNRowe 6y ago
    Now that all that isn't so raw, I'd love to know how you felt about the other contenders that were floating about at the time. Were any of them doing things you wanted to see in BK? I can't be the only one who'd be interested in your views on the general developments for such important tools of our trade. Have you written about it anywhere? I'll pre-order "Larry walks us from SCCS to the git monoculture".
    - luckydude 6y ago
      Actually I was part of an SCM conference put together by Facebook and Google recently. People are starting to think about what happens after Git. Unfortunately, even now, it seems that there is a lot catching up to BK still to be done. To be fair, we had kernel level programmers working on it, we don't think anyone will pick up our code, you pretty much have to be a top 1-2% programmer to work on it, it's all in very disciplined C, people don't seem to like that any more. So far as I know, BK is the only system that gets files right, we have a graph per file, everyone else has a single graph per repository. The problem with that is the repository GCA may be miles away from the file GCA; BK gets that 100% right, other systems guess at the GCA. Graph per file means each file has a unique identifier, like an inode in the kernel. So create/delete/renames are actually recorded instead of being guessed at. SCM systems shouldn't guess in my opinion (actually in anyone with a clue's opinion, would you like it if your bank guessed about your balance? Of course not, so why is guessing OK in an SCM? It's not). Graph per file means that bk blame is instant no matter how much history you have. BK is the only system that even attempts to get sub-modules (we call them components) right. Where by "right" I mean you can have a partially populated collection and you get identical semantics from the same commands whether it is a mono-repo or a collection of repos. Nobody else has anything close, Git sub-modules turn Gits workflow into CVS workflow (no sideways pulls). I tried my best to show what we did in BK at that conference, I have no idea if they will swipe any of it. It's not like BK is perfect, it didn't do everything, no named branches, a clone is a branch, which is a model that absolutely will not scale to what people are doing today (we can argue whether TB repos should exist, but they do). But for the problems BK did solve, it tended to solve them very well. Hell, just our regression tests are a treasure trove of things that can go wrong in the wild and we open sourced both the tests and the test harness.
- luckydude 6y ago
  BTW, Linus switched to Git 2005. BitKeeper didn't give up and turn to open source until 2016. So we had a 10 year run after Git showed up where people still paid us. It was good run, not many software companies get an 18 year run. I'm fine with it, would have liked to do more for my people. Though, when we were shutting things down and I was bumming that I had not gotten retirement money for all of my people, one of them said something like "Dude, are you kidding me? My best friend barely knows his kids, he is out the door by 7am to fight Houston traffic and not home until close to 7pm. My commute is from my bedroom to my office down the hall. I've got to help my wife with the kids, I see the kids all day every day, my life is infinitely better than my friend's life and you gave that to me. You're fine." I'm a wimp, I teared up a bit, that was the nicest thing he ever said to me. It's not just about money.
rdpintqogeogsaa 6y ago
I just wanted to say thank you for believing in the SCCS weave when making BitKeeper. It is an incredibly elegant design (though I've failed to properly implement it myself yet).
- luckydude 6y ago
  The SCCS weave was our secret sauce. Tichy did the world a huge disservice in his PhD about RCS (like that was worth a PhD, come on) where he bad mouthed SCCS's weave (without understanding it, or maybe he was spreading misinformation on purpose, he implied that SCCS was forward deltas where RCS is backwards deltas, see below for what that means). When we were still in business, each new SCM that came out, we'd hold our breath until we looked at it and said "No weave!" For those who don't know, the SCCS weave is how your data is stored. Most people are used to something like RCS which is patch based. For the RCS trunk, the head is stored as plain text, the previous delta is a reverse patch against the head, lather, rinse, repeat. Branches are forward deltas, so if you want to get something on a branch, you start with the head, apply reverse deltas until you get to the branch point and then forward deltas until you get to the branch tip. Ask Dave Miller how much he loved working on a branch of gcc, spoiler, he hated it. With good reason. SCCS has a weave that is not aware of branches at all, it only knows about deltas. So you can get 1.1 in exactly the same amount of time as it takes to get head, it is one read through all the data. bk annotate (git blame) is astonishingly fast. And merges are by reference, no data is copied across a merge. Try that in a patch based system. How many of you have been burned because you merged in a branch full of code that someone else wrote, and on the trunk all the new data from the branch looks like you wrote it, so you get blamed when there is a bug in that code? That's because your brain dead system copied code from the branch to the trunk (Git does this as well, that's what the repack code is trying to "fix", it is deduping the copies). Weaves are the schnizzle, any SCM system that doesn't use them today is so 1980.
  - froh 6y ago
    How does dcfs weave compare or relate to what pijul.org is doing? Some recent discussion of pijul on HN: https://news.ycombinator.com/item?id=24592568 https://news.ycombinator.com/item?id=24592568
amacbride 6y ago
Avocet (CodeManager) ruined me for other source control systems for years and years — I still look back on it fondly.
- luckydude 6y ago
  That was me as well, though I wrote it in perl4 and C. My version was called NSElite. The Solaris kernel was developed under NSElite, some stuff is here: http://mcvoy.com/lm/nselite http://mcvoy.com/lm/nselite 2000.txt documents the first 2000 resyncs (think bk pull) of the kernel. Avocet was what you got when you took all my perl code and handed it to the tools group and they rewrote it in C++ (which they later admitted was a horrible idea). The only thing of mine that they kept was smoosh.c and that was because not a single one of them had the chops to write that code (yeah, there was no love lost between me and the tools group). BitKeeper is what Avocet could have been if Sun had not stopped me from doing any more work on NSElite (I was 1 guy who was coding circles around 8 tools people and they didn't like it). Shrug. C++ was just wrong, perl4 was just way faster to code in, and when I needed performance I coded in C. It's not my fault they picked the wrong way to go about things. (That, BTW, was the first time I ever personally saw that you really can have one guy who can do the work of 8, almost, but not quite a 10x programmer :-)
luckydude 6y ago
I just realized I didn't give credit to all the people who worked on Little. So here goes. Tim Daly did the first pass. Oscar Bonilla stepped up, I still remember him saying to Tim "we need an AST" and Tim said I can do this. We needed an AST, Oscar was right about that and a lot of other things. Rob Netzer, my roommate from college and former Brown tenured prof, he did the most heavy lifting in the Little compiler. Damon Courtney was our GUI guy, he had huge influence in Little. Jeff Hobbs from the tcl community helped as well. I have pictures of that group of people. Jeff helped a lot, he wanted this, I could say why but I don't want to speak for him. Little is what I'd like C to be but those guys made it happen. I'm amazed that Little got some traction, happy that it did for a moment, those guys deserve all the credit, I was a whiny dude wanted a more C like thing and they gave it to me.

marktangotango 6y ago

I'm curious if you've written about the decisions around licensing that essentially killed the bitkeeper business by inspiring Linus to create git? What are your thoughts around that today?

luckydude 6y ago
Hind sight is 20-20. The BitKeeper business had a good run, we were around for 18 years. It made enough that I and my business guy are retired off of what we made. On the other hand, we didn't make enough for everyone to retire if they wanted to. We had a github like offering and it's pretty clear that we should have put a bunch of money into that and open sourced BitKeeper. All I can say is it is incredibly hard to make that choice when you have something that is paying the bills. I tried to get Sun to do it with the BSD based SunOS and they wouldn't. And even though I had that vision for Sun, when it was my livelihood, I couldn't see the path to doing so. Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it's a crappy design. It does what he wants, but what he wants is not what the world should want. It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits. Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.
- brundolf 6y ago
  I hadn't heard of BitKeeper but it sounds interesting. Have you considered open-sourcing it now for people to look at, even though the business has faded?
  - luckydude 6y ago
    http://bitkeeper.org http://bitkeeper.org Been open source for years
  - momszack 6y ago
    This makes me feel old. The bitkeeper saga is why GitHub exists. The drama is archived in 2004-5 lkml.
    - brundolf 6y ago
      I was twelve :)
- JNRowe 6y ago
  Now that all that isn't so raw, I'd love to know how you felt about the other contenders that were floating about at the time. Were any of them doing things you wanted to see in BK? I can't be the only one who'd be interested in your views on the general developments for such important tools of our trade. Have you written about it anywhere? I'll pre-order "Larry walks us from SCCS to the git monoculture".
  - luckydude 6y ago
    Actually I was part of an SCM conference put together by Facebook and Google recently. People are starting to think about what happens after Git. Unfortunately, even now, it seems that there is a lot catching up to BK still to be done. To be fair, we had kernel level programmers working on it, we don't think anyone will pick up our code, you pretty much have to be a top 1-2% programmer to work on it, it's all in very disciplined C, people don't seem to like that any more. So far as I know, BK is the only system that gets files right, we have a graph per file, everyone else has a single graph per repository. The problem with that is the repository GCA may be miles away from the file GCA; BK gets that 100% right, other systems guess at the GCA. Graph per file means each file has a unique identifier, like an inode in the kernel. So create/delete/renames are actually recorded instead of being guessed at. SCM systems shouldn't guess in my opinion (actually in anyone with a clue's opinion, would you like it if your bank guessed about your balance? Of course not, so why is guessing OK in an SCM? It's not). Graph per file means that bk blame is instant no matter how much history you have. BK is the only system that even attempts to get sub-modules (we call them components) right. Where by "right" I mean you can have a partially populated collection and you get identical semantics from the same commands whether it is a mono-repo or a collection of repos. Nobody else has anything close, Git sub-modules turn Gits workflow into CVS workflow (no sideways pulls). I tried my best to show what we did in BK at that conference, I have no idea if they will swipe any of it. It's not like BK is perfect, it didn't do everything, no named branches, a clone is a branch, which is a model that absolutely will not scale to what people are doing today (we can argue whether TB repos should exist, but they do). But for the problems BK did solve, it tended to solve them very well. Hell, just our regression tests are a treasure trove of things that can go wrong in the wild and we open sourced both the tests and the test harness.
luckydude 6y ago
BTW, Linus switched to Git 2005. BitKeeper didn't give up and turn to open source until 2016. So we had a 10 year run after Git showed up where people still paid us. It was good run, not many software companies get an 18 year run. I'm fine with it, would have liked to do more for my people. Though, when we were shutting things down and I was bumming that I had not gotten retirement money for all of my people, one of them said something like "Dude, are you kidding me? My best friend barely knows his kids, he is out the door by 7am to fight Houston traffic and not home until close to 7pm. My commute is from my bedroom to my office down the hall. I've got to help my wife with the kids, I see the kids all day every day, my life is infinitely better than my friend's life and you gave that to me. You're fine." I'm a wimp, I teared up a bit, that was the nicest thing he ever said to me. It's not just about money.

rdpintqogeogsaa 6y ago

I just wanted to say thank you for believing in the SCCS weave when making BitKeeper. It is an incredibly elegant design (though I've failed to properly implement it myself yet).

luckydude 6y ago
The SCCS weave was our secret sauce. Tichy did the world a huge disservice in his PhD about RCS (like that was worth a PhD, come on) where he bad mouthed SCCS's weave (without understanding it, or maybe he was spreading misinformation on purpose, he implied that SCCS was forward deltas where RCS is backwards deltas, see below for what that means). When we were still in business, each new SCM that came out, we'd hold our breath until we looked at it and said "No weave!" For those who don't know, the SCCS weave is how your data is stored. Most people are used to something like RCS which is patch based. For the RCS trunk, the head is stored as plain text, the previous delta is a reverse patch against the head, lather, rinse, repeat. Branches are forward deltas, so if you want to get something on a branch, you start with the head, apply reverse deltas until you get to the branch point and then forward deltas until you get to the branch tip. Ask Dave Miller how much he loved working on a branch of gcc, spoiler, he hated it. With good reason. SCCS has a weave that is not aware of branches at all, it only knows about deltas. So you can get 1.1 in exactly the same amount of time as it takes to get head, it is one read through all the data. bk annotate (git blame) is astonishingly fast. And merges are by reference, no data is copied across a merge. Try that in a patch based system. How many of you have been burned because you merged in a branch full of code that someone else wrote, and on the trunk all the new data from the branch looks like you wrote it, so you get blamed when there is a bug in that code? That's because your brain dead system copied code from the branch to the trunk (Git does this as well, that's what the repack code is trying to "fix", it is deduping the copies). Weaves are the schnizzle, any SCM system that doesn't use them today is so 1980.
- froh 6y ago
  How does dcfs weave compare or relate to what pijul.org is doing? Some recent discussion of pijul on HN: https://news.ycombinator.com/item?id=24592568 https://news.ycombinator.com/item?id=24592568

amacbride 6y ago

Avocet (CodeManager) ruined me for other source control systems for years and years — I still look back on it fondly.

luckydude 6y ago
That was me as well, though I wrote it in perl4 and C. My version was called NSElite. The Solaris kernel was developed under NSElite, some stuff is here: http://mcvoy.com/lm/nselite http://mcvoy.com/lm/nselite 2000.txt documents the first 2000 resyncs (think bk pull) of the kernel. Avocet was what you got when you took all my perl code and handed it to the tools group and they rewrote it in C++ (which they later admitted was a horrible idea). The only thing of mine that they kept was smoosh.c and that was because not a single one of them had the chops to write that code (yeah, there was no love lost between me and the tools group). BitKeeper is what Avocet could have been if Sun had not stopped me from doing any more work on NSElite (I was 1 guy who was coding circles around 8 tools people and they didn't like it). Shrug. C++ was just wrong, perl4 was just way faster to code in, and when I needed performance I coded in C. It's not my fault they picked the wrong way to go about things. (That, BTW, was the first time I ever personally saw that you really can have one guy who can do the work of 8, almost, but not quite a 10x programmer :-)

luckydude 6y ago

I just realized I didn't give credit to all the people who worked on Little. So here goes. Tim Daly did the first pass. Oscar Bonilla stepped up, I still remember him saying to Tim "we need an AST" and Tim said I can do this. We needed an AST, Oscar was right about that and a lot of other things. Rob Netzer, my roommate from college and former Brown tenured prof, he did the most heavy lifting in the Little compiler. Damon Courtney was our GUI guy, he had huge influence in Little. Jeff Hobbs from the tcl community helped as well. I have pictures of that group of people. Jeff helped a lot, he wanted this, I could say why but I don't want to speak for him. Little is what I'd like C to be but those guys made it happen. I'm amazed that Little got some traction, happy that it did for a moment, those guys deserve all the credit, I was a whiny dude wanted a more C like thing and they gave it to me.