Older blog entries for apenwarr (starting at number 108)


pphaneuf mentioned a team at Microsoft that switched from Visual Sourcesafe to Subversion as if this said something bad about VSS.

Well, it does, but it only says good things about the judgement of Microsoft's developers in general. In fact, the smartest teams at Microsoft have never used VSS at all. Last I heard, many projects were using a modified version of Perforce. At the time my spies last reported, several teams didn't even use Visual Studio, preferring vi and make instead. But that was a few years ago now.

So there's your gossip for today.

Bi-directional QoS

Guspaz asks why routers only do one-way QoS (that is, in the upload direction).

The simple answer is that while yes, you can fiddle with TCP sliding windows to adjust the receive rate, it's very complicated to do so accurately. The way to make TCP slow down is literally to drop packets, not just to delay them; delay is a latency thing, not a bandwidth thing, and a server noticing a high latency should put *more* packets in flight at once, not less. But you'd have to drop outgoing ACKs, not incoming packets, to reduce the bandwidth, and that's just complicated.

Incidentally, Linux's QoS stuff can do it, but it has a fatal complexity: you have to tell it what your link bandwidth is, and most users just don't know. mag will remember how annoying it is to calculate that correctly. (BTW: no, we still don't.)

Conversely, outgoing QoS (as it's normally defined) is easy. You just take all the packets currently sitting in the queue, and sort them in priority order. Got a new packet and the queue is full? Throw out the lowest-priority one. No real "bandwidth management" is needed, the algorithms are trivial, and it doesn't matter what your actual bandwidth count is.

Social Commentary

"Look, you can dress a monkey in a suit, but he'll still be a --"

"Oh, hey, handsome! Nice suit!"


The cubicle I selected for my self in our Toronto office has a big tree growing out of it. It's the only one that does. If you look up over the cubicle walls as you're walking through the office, it looks like a weird oasis of green in a sea of... well, cubicles.

I can't take any credit at all for this. I didn't choose the cubicle because it had a plant. In fact, it was was so piled with random junk before I moved in that I didn't actually discover the tree until after I had removed the random junk.

Still, I like my tree.

25 Feb 2006 (updated 26 Feb 2006 at 16:32 UTC) »
Non-strategic insanity

Tonight I rediscovered that doing crazy things for stupid reasons is still just as much fun as it always was. It feels like I haven't done that for a long time.

My new job title has me doing plenty of crazy things for good reasons, which is a start. But it's just not the same.

Related Discovery

If you check in after 7am, some hotels only charge you half price!

KFC in the Bronx

They... give you mashed potatoes by default instead of fries. And the largest combo has only two pieces of chicken instead of three or four. And the cole slaw... it's the creamy kind, NOT RADIOACTIVE GREEN! It's almost sort of kind of healthy! (Okay, "healthy" is probably the wrong word, but it defines a unit vector in the direction I'm talking about.)

And, being the Bronx, they serve it all to you using a bulletproof plexiglass double-interlocking shelf system. Every place has its charms.

Useless Trivia

I am the top, but by no means only, Google match for "radioactive cole slaw".


I now hold a job position with responsibilities that, in the history of my company, have always guaranteed total and highly visible failure within three months or less.

I intend to take at least 3.5 months.

More Compromises

I've written before about the importance of finding non-compromise solutions to problems. Well, here are a few more trick questions to ponder.

Who can you trust?

You will probably find that your answer to this question puts you in one of the following two groups. (You might be surprised to find that the other group really does exist, completely disagrees with your group, and is just as popular as yours.)

  1. Trust must be earned. You won't trust someone to do something correctly until they've demonstrated their ability to do it. Once they've earned your trust, you'll usually trust them automatically to do that job in the future. But that doesn't mean you automatically trust them to do a different job, and so on.

  2. Trust is transitive. If a person is in a position of authority, you trust them implicitly. If a person is trusted by a person with authority over you, then you trust that person as well. For example, someone who works for a manager that your own manager trusts would be trusted by you automatically, so you really don't have to worry about whether they'll do a good job or not; that's really someone else's problem to worry about, and you can safely assume they're handling it.

The second solution is short-term efficient. The first solution is long-term resilient.

I think I see the non-compromise solution to this one. Do you?

Brilliance vs. Repeatability

Another question that has come up recently has been the question of repeatable processes versus the flash of brilliance.

In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.)

Software, however, just makes a mess of things.

You could summarize the mess as the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes.

Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments. (You might say the same about science in general, but most scientific research nowadays, outside of universities at least, is more about the repeatable processes than the brilliance.)

The really great stuff that we love about computing requires brilliance. The guy who figured out how to do the iPod user interface, or the person who realized that data structures could have functions encapsulated in them, or the person who invented the superposition operator in perl: those people are the ones who really make all our lives better, even as the rest of us try to repeatably write working programs in perl.

Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition.

I don't know the non-compromise answer to this one, but I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.

But what on earth would you do with that much output?

3 Feb 2006 (updated 3 Feb 2006 at 08:20 UTC) »
Company Policy, Revisited

Now these guys have the right idea.

And more on design

The same guys have some really interesting writing on various design concepts, including non-software UI design. (That's just one article; browse around to find others.)

UPDATE: Oh man, this stuff is addictive. The Intel "Yes" compaign in Russia and "To be quite candid, it was the first time I was sitting in a car with the Settings menu."

1 Feb 2006 (updated 3 Feb 2006 at 03:37 UTC) »
It Takes Two to Fail

It struck me today how management success is kind of an OR operation. So many things in life are AND: if you do this and this properly, then it works! But if you miss that one step, then boom!

But management is different. On the one hand, if you're a good manager and you align things just the right way, you can take a reasonably good group of people and make them massively successful. (Example: most big companies.) But on the other hand, even if you suck like crazy at management, if the people you manage are really great, they can succeed despite the way you've kind of set them up to fail. And of course, there's every point in between those two extremes.

But what's interesting is that because of this effect, when you do manage to fail (or your project is late, or buggy, or whatever), then there's always someone to blame it on: the person doing the work. Because obviously the person doing the work didn't rise to the challenge, blah blah, and look, it sucks!

I think a proper manager's job is to reduce the challenge, so nobody will fail to rise to it. But maybe not eliminate the challenge entirely, or else it's too boring.

UPDATE: I didn't like the old title. Sorry.

99 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!