luckydude · HackerTrans

luckydude

no profile record

Submissions

A developer’s guide to interviewing

medium.com

4 pointsby luckydude9 lat temu1 comments

Little is a statically typed, C-like scripting language

little-lang.org

18 pointsby luckydude10 lat temu6 comments

Google honors Steve

8 pointsby luckydude15 lat temu0 comments

comments

2 lata temudiscuss

Rick saying "I worked on BK" is the understatement of the century. He showed up and looked at my code, I had done things in a way that you could have walked the weave and extract any number of versions at the same time. He was really impressed with that. I split apart stuff that Rick had not seen before.

Then he proceeded to fix my code over and over again. I had a basic understanding of SCCS but Rick understood the details.

Rick knows more about SCM than any guy I know.

And he is right, SCCS is not well understood and BK even less so.

2 lata temudiscuss

I fished today, 3 halibut. Fish tacos for the win! If you cook halibut, be warned that you must take it off at 125 degrees, let it get above that and it turns to shoe leather.

2 lata temudiscuss

I don't like cheaters. If Tridge had done what he said he did, go him, I'm all for people being smart and figuring stuff out. But that is not what he did and it disgusts me that he pretends it is.

There is absolutely zero chance he figured out the pull protocol via telnet. I will happily pay $10,000 to anyone could do that with zero access to BK. Can't be done. If I'm wrong, I'll pay up. But I'll have a lot of questions that can't be answered.

So he cheated, he got Linus to run BK commands at his house and he snooped the network. He had no legal access to those bytes. Without those snoops, no chance he reverse engineered it.

As I have seen over and over, when the open source people want something, they will twist themselves in knots to justify getting it, legality be damned.

How about you be better than this and admit that open source is not without its skeletons?

2 lata temudiscuss

This is completely untrue. There is no way that you could make a BK clone by telneting to a BK and running commands. Those commands don't tell you the network protocol, they show you the results of that protocol but show zero insight into the protocol.

Tridge neglected to tell people that he was snooping the network while Linus was running BK commands when Linus was visiting in his house. THAT is how he did the clone.

The fact that you all believe Tridge is disappointing, you should be better than that.

The fact that Tridge lied is disappointing but I've learned that open source people are willing to ignore morals if it gets them what they want. I love open source, don't love the ethics. It's not just Tridge.

2 lata temudiscuss

My issues with Git

- No rename support, it guesses

- no weave. Without going into a lot of detail, suppose someone adds N bytes on a branch and then that branch is merged. The N bytes are copied into the merge node (yeah, I know, git looks for that and dedups it but that is a slow bandaid on the problem).

- annotations are wrong, if I added the N bytes on the branch and you merged it, it will (unless this is somehow fixed now) show you as the author of the N bytes in the merge node.

- only one graph for the whole repository. This causes multiple problems: A) the GCA is the repository GCA, it can be miles away from the file GCA if there was a graph per file like BitKeeper has. B) Debugging is upside down, you start at the changeset and drill down. In BitKeeper, because there is a graph per file, let's say I had an assert() pop. You run bk revtool on that file, find the assert and look around to see what has changed before that assert. Hover over a line, it will show you the commit comments to the file and then the changeset. You find the likely line, double click on it, now you are looking at the changeset. We were a tiny company, we never hit the claimed 25 people, and we supported tons of users. This form of debugging was a huge, HUGE, part of why we could support so many people. C) commit comments are per changeset, not per file. We had a graphic check in tool that walked you through the list of files, showed you the diffs for that file and asked you to comment. When you got the the ChangeSet file, now it is asking you for what Git asks for comments but the diffs are all the file names followed by what you just wrote. It made people sort of uplevel their commit comments. We had big customers that insisted the engineers use that tool rather a command line that checked in everything with the same comment.

- submodules turned Git into CVS. Maybe that's been redone but the last time I looked at it, you couldn't do sideways pulls if you had submodules. BK got this MUCH closer to correct, the repository produced identical results to a mono repository if all the modules were present (and identical less whatever isn't populated in the sparse case). All with exactly the same semantics, same functionality mono or many repos.

- Performance. Git gets really slow in large repositories, we put a ton of work into that in BitKeeper and we were orders of magnitude faster for things like annotate.

In summary, Git isn't really a version control system and Linus has admitted it to me years ago. A version control system needs to faithfully record everything that happened, no more or less. Git doesn't record renames, it passes content across branches by value, not by reference. To me, it feels like a giant step backwards.

Here's another thing. We made a bk fast-export and a bk fast-import that are compatible with Git. You can have a tree in BK, have it updated constantly, and no matter where in the history you run bk fast-export, you will get the same repository. Our fast-export is idempotent. Git can't do that, it doesn't send the rename info because it doesn't record that. That means we have to make it up when doing a bk fast-import which means Git -> BK is not idempotent.

I don't expect to convince anyone of anything at this point, someone nudged, I tried. I don't read hackernews any more so don't expect me to defend what I said, I really don't care at this point. I'm happier away from tech, I just go fish on the ocean and don't think about this stuff.

3 lata temudiscuss

It might not have happened if it wasn't for me and avb. I need to write that up but the short story is that FDDI was the path to 100mbit, I wanted 100Mbit ethernet, the sun hardware engineers thought I wanted to signal over copper the same way that 10mbit did.

I didn't care about that, I cared about what someone in this thread said, it's amazing that you can plug a 10Mbit hub in and have it work with 100mbit, Gbit, etc.

In my mind, it was all about the packet format, if they are the same then we get cheap switches. And that is what we have today, I saw this coming around 1990.

And for you guys hating on the 1500 bytes, the SGI memory interconnect taught me that bigger is not better. When you are doing cache misses remotely, big is not good. I'm doing a shit job explaining but there is some value in smaller.

If you guys want, I'll try and write it up.

5 lat temudiscuss

Tim was cool, he said add "The Perl logo is a trademark of O'Reilly Media and is used with permission" and we're good. Now I have to remember how to get into that VM :-)

5 lat temudiscuss

I think the most productive thing I could do is write up how the weave works. People don't seem to understand that, if they did, nobody would be talking about patches.

I'm sorry if I pissed off the other guy, but I'm retired, and I'm tired, and I have no interest in arguing with people who don't get it. But it's on me to provide the info that lets them get it. I'll do that and what people do with it is up to them.

5 lat temudiscuss

Pretty sure Tim doesn't care but I'll track him down and ask.

Edit: sent an email to him, we'll see.

5 lat temudiscuss

I've built two commercially successful systems, NSElite that was used to develop the Solaris kernel and was productized as Avocet/CodeManager/TeamWare (don't blame me, I didn't name it), and BitKeeper which was, at one point, in use on every continent other than the Arctic. If you are running on a 5 year old Intel CPU, that was developed using BitKeeper.

The comment that RCS scales for binaries couldn't be more wrong, RCS hates binaries with a passion.

The fact that you didn't address any of the points I raised says you either don't understand what a weave file format is, or, you do, you recognize it is a much better format but don't want to talk about that.

This part of this thread reminds of something Ron Minnich once said: "Don't worry about people stealing your ideas, you are going to have to cram them down their throats".

I'll drop it, we can revisit when I write up how weaves work. I don't think any objective person would argue that a patch based system is as good, let alone better.

5 lat temudiscuss

Who owns it? OReilly?

5 lat temudiscuss

I sort of agree with this. I'm not a lisp fan, I don't think lisp is bad, it's just not how my brain works so I struggle. But I understand lisp enough to agree with you and I think that is what John was trying to do.

5 lat temudiscuss

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.

5 lat temudiscuss

Little returns undef for OOB and for in bounds not set. Tcl returns "" for both.

The thing that GP was asking for, an OOB error, is not a thing in a language where there are no bounds.

5 lat temudiscuss

I think if you are asking this question either I have completely failed to explain why weaves are cool or you haven't read what I said about why weaves are cool.

Patch based systems are idiotic, that's RCS, that is decades old technology that we know sucks (I've had a cocktail, it's 5pm, so salt away).

Do you understand the difference between pass by reference and pass by value? You must, but in case you don't, you can pass by reference in sizeof(void *), 4-8 bytes. Pass by value and you are copying sizeof(whatever it is you are passing) onto the stack. Obviously, pass by reference is immensely faster.

But in SCM, it isn't just about speed (and space), it's about authorship. In a patch based systems, imagine that there is user A who is doing all the work on the trunk, there is user B who is doing all the work on a branch, and then there is user U who is merging the branch to the trunk. Lets say B added a bunch of work on the branch, it all automerged. U did the merge. In a patch based system, all of the B work is going to be copied (passed by value) to the trunk and the authorship of that work will change from B to U (since U did the merge).

Flip forward to a month from now, the code has paniced or asserted, whatever, B's code on the trunk took a crap. And people are running git blame to see who did that and who did it, U did. But U didn't, B did but U merged it and it was a copy so it looks like U did it.

That's just the SCM being dishonest because it has no choice, it is pass by value.

Weaves are pass by reference. If you merged in BitKeeper and it automerged, you run blame (we call it annotate but I should make blame be an alias if I haven't already, I'm the guy that came up with blame as that verb), you would only see A and B as the authors.

Weaves mean authorship is correct and that whole repack nonsense that Git does? Yeah, that goes away, you are passing every thing by reference so there is only one copy of the code no matter how many branches it has been merged from/to.

Anyone who is pushing a patch based system (and Git is one as well) just doesn't have a clue about how to do source management. Maybe something better than a weave will come along (and if it does, rbsmith will do it, that guy bug fixed my crappy weave implementation) but I think it will just be a better weave with new operators like MOVE (current weaves know INSERT and DELETE, that's it).

Sorry if I'm being a dick, not looking for sympathy but I've got health problems, my feet hurt like crazy and I get kind of terse at the end of the day. If you truly want to understand more, and this goes for all of hacker news, I'm happy to get on a zoom call and talk this stuff through. And it is blindingly obvious I need to write up the SCCS weave and I will do so, you guys have inspired this 58 year old, burned out, can't code to save his life, dude to at least try and pass on some knowledge. I would love to be working with some young person who has some juice and pass on what I know. I don't know everything about SCM but I know a lot. I'm done, it's time for someone else to carry things forward, I'll help if you want. The world deserves a better answer than what we have now.

5 lat temudiscuss

I wrote most of my first source management system (NSElite, mentioned elsewhere in this thread) in perl4. I was learning perl at the time and my first and second efforts were awful. Perl really lets you get sloppy and create unmaintainable code.

My 3rd rewrite was very stylized and, I felt, maintainable. Which proved to be true as I had to fix bugs in it.

I did weird stuff like using $whatever as the index into the @whatever array.

But I digress. On the <>, Little has argv so you can do

int main(string argv[]) { int i; string buf; FILE f;

    if (defined(argv[1]) && streq(argv[1], "-") && !defined(argv[2])) {
        while (buf = <STDIN>) bputs(buf);
    } else {
        for (i = 1; defined(argv[i]); i++) {
            if (defined(f = fopen(argv[i], "r")) {
                while (buf = <f>) puts(buf);
                fclose(f);
            } else {
                 fprintf(stderr, "unable to open '%s'\n", argv[i]);
            }
        }
    }
    return (0);

}

but why would you want to when all of that is

int main(string argv[]) { string buf;

    while (buf = <>) puts(buf);
    return (0);

}

I mean, come on, that's cat(1) in 8 lines of code.

edit: I need to learn hacker markup. My code looks like crap.

5 lat temudiscuss

You are kind of making my point. In tcl, they'd just give you "", but you can't tell the difference between "past the end of the array" or an element where you said

set foo[i] = ""

In Little you can tell, we'll return undef (your clear "error" though in these languages it is a supported feature, not an error). So we support the auto expanding array but give you that extra bit of info that you are past the end.

5 lat temudiscuss

You seem bound and determined to not hear that tcl auto expands arrays as needed. There are no bounds. So there is no error to catch.

We just thought it would be clever to return undef if you were out of bounds, which tcl code would see as "" which is what you'd get in tcl. But Little code could actually tell you are past the end.

In my mind, which many have argued isn't the best, it's a reasonable design.

You keep trying to push backwards to a design point where arrays are fixed in size at declaration and that is not how tcl (or Little) works.

5 lat temudiscuss

Richard is awesome. He also did sqlite. As for Fossil, I'm a fan of his UI and code, but haven't looked in detail at the design. I'm pretty sure it is patch based with everything stored in sqlite. It's an OK way of doing things but not if you understand a weave.

But no disrespect intended towards Richard, I've met him plenty of times and enjoyed it each time. Great guy.

5 lat temudiscuss

I don't see the array access as any different than a null pointer dereference, in both cases you are asking for something that isn't there.

In Tcl, stuff just gets auto expanded on assignment and returns "" (I think) on dereference. We chose to return undef. I'm not sure what the problem is.