The Spectre of Math

August 31, 2010

directed acyclic graphs suck for a vcs

Filed under: Hacking,Technology — jlebl @ 7:28 pm

DVCS systems like git work on a directed acyclic graph (DAG) model where branching happens automatically with just about any commit. Traditional vcs (e.g. CVS) works generally as a tree where branching must be explicitly done.

Now the argument for DVCS is that you can commit without merging differences done by someone else. The axiom seems to be

Axiom of DVCS: Merging should be done as late as possible.

What’s wrong with that? Well nothing if you are happy for the computer to just blindly merge two very divergent code bases without worrying about interactions of those changes (you kept hacking on feature A which required that function foo works in a certain way, while person working on feature B changed how foo works because he didn’t see anybody use it yet because your use of it was in a branch that the second person of course didn’t look at because he was busy working on feature B). No that never ever happens because all developers always talk to each other about every little change and because every internal function/method/object is completely documented. Yeah.

With traditional VCS, merging is required when checking in. The axiom changes to:

Axiom of traditional VCS: merging should happen as early as possible when divergence is as small as possible.

When everyone continually has to keep up with all the other changes that other people are working on, possibility of screwing up is smaller. Merging other people’s changes into your tree can be far simpler if it was just someone’s morning worth of work with say 100 lines of code. You can actually look at that quickly to review what happened. Not to mention you will have to look at it if there are direct conflicts with your work. Furthermore, if the other person changed how function foo works, you will notice sooner rather than later so you can resolve the conflict before both of you go too far assuming function foo works in a certain way.

I know exactly why DVCS is more popular nowadays. Firstly it is new and new things are always better even if they are worse. Second, it is more complicated, and complicated things must always be better. But most importantly of all: DVCS has a lot more buzzwords. It is distributed, it uses directed acyclic graphs (finally you have a use for some of your CS classes). Lots of things that work are replaced continuously by complicated things that don’t.

Example: I would say the level of the desktop software (Windows, Linux, and Mac) has not improved substantially. It has changed yes. It does lots of graphical voodoo. It allows you to do things that nobody ever wants to do. But if you took a basic desktop from the year 2000 and you simply fixed it to work right, you’d have a much faster, much more productive environment. But fixing things is not as much fun as rewriting a desktop on OpenGL, making windows wiggle, and making a different funky widget set for each application.

San Diego wants to kill you (if you walk)

Filed under: Politics — jlebl @ 4:00 pm

San Diego, especially it seems north San Diego, is one of the worst places to be a pedestrian. Many places without sidewalks, crosswalks, very wide divided streets, etc…

But the worst part of all is the following. Someone had the bright idea that a crosswalk should exist on only 3 sides of an intersection instead of 4. Now, it is possible to go from any point to any point, but it can take very long. Sometimes you need to cross a busy street 3 times just to cross at one point (if you want to do it legally). I am not sure what is the advantage to the cars, but I assume the advantage is very minor. This means that you force a pedestrian to cross more crosswalks OR to jaywalk. That doesn’t seem like a way to improve safety, nor to reduce driving (you know to reduce carbon footprint, etc…) San Diego is apparently among the most dangerous places for a pedestrian. I think I know why. I think the city council hates pedestrians.

Not that the streets here are optimized for cars either. There are so many divided streets, no u-turn signs, etc… If you miss a turn in San Diego you might be likely to drive quite a lot longer (especially in rush hour). Or in some parts, just getting to a store that just happens to be on the other side of a divided street can be an operation involving several traffic lights and breaking a few rules.

damn git again

Filed under: Hacking,Linux — jlebl @ 5:42 am

Bitten again … so I now finally noticed that it seems that a ChangeLog file is now out of favour in the GNOME git. People just commit stuff (translations it seems) without anything. Plus when i do git pull, it just spits out a lot of jargon nonsense but doesn’t tell me the important things: Which files have changes. So I don’t actually notice what was changed. I have to go hunt down that information.


Even the git browser at is useless. I wish I had CVS back.

August 7, 2010

I’m the 18th most prolific GNOME contributor?

Filed under: Hacking,Linux — jlebl @ 4:40 am

I’ve looked through the GNOME Census: Apparently in the 6 or 7 years that I’ve not worked on GNOME, I still have not managed to get out of the top 20, at least based on number of commits. By a rough estimate based on time being employed by Eazel, I guess about 1/3 or 1/4 or so of my commits were as Eazel employee. Meaning that probably I account for 1/4 or 1/5 of all Eazel commits to GNOME (that sounds kind of freaky).

What’s even more freaky is that I single handedly committed about 70% as much as Canonical (which had a longer time).

Someone (can’t remember who, I’m reading these blogs while moving half way cross country) said something about that Canonical should have hired some people to just “hack on cool GNOME stuff.” Well, that was essentially my job description at Eazel. So if I managed, over the 3-4 years of really being active on GNOME to have 0.7% of “activity” on GNOME over its lifetime. Than if Canonical would have recruited me (though I was probably unrecruitable by that time) or someone like me, they could over the past 6 years have more than doubled their “contribution.” They would probably have a lot more say in the future direction of GNOME as well. A couple of dedicated engineers are not expensive in the overall scheme of things for a company.

Now number of commits is not the best way to count contribution. I think it’s probably hard to measure Canonical’s contribution to GNOME and it’s likely bigger than indicated by the number of commits.

Still … 18th still? They aren’t trying very hard these days. Must be that they’re all mucking around with git instead of coding!

Blog at