High on my list of Things That Annoy Me When I Hack is sourcefiles that contain huge blobs of license text at the top. That is valuable territory which should be occupied by a header comment explaining the code, not a boatload of boilerplate that I’ve seen hundreds of times before.
Hackers have a lot of superstitious ideas about IP law and one is that these blobs are necessary for the license to be binding. They are not: incorporation by reference is a familiar concept to lawyers and courts, it suffices to unambiguously name the license you want to apply rather than quoting it in full.
This is what I do in my code. But to make the practice really comfortable for lawyers we need a registry of standardized license identifiers and an unambiguous way of specifying that we intend to include by reference.
Comes now the Software Package Data Exchange to solve this problem once and for all. It’s a great idea, I endorse it, and I will be using it in all my software projects from now on.
The following is a comment I just filed on FCC Docket 15-170, “Amendment of Parts 0, 1, 2, 15, and 18 of the Commission’s Rules et al.”
Thirty years ago I had a small hand in the design of the Internet. Since then I’ve become a senior member of the informal collegium that maintains key pieces of it. You rely on my code every time you use a browser or a smartphone or an ATM. If you ever ride in a driverless car, the nav system will critically depend on code I wrote, and Google Maps already does. Today I’m deeply involved in fixing Internet time service.
I write to endorse the filings by Dave Taht and Bruce Perens (I gave Dave Taht a bit of editorial help). I’m submitting an independent comment because while I agree with the general thrust of their recommendations I think they may not go far enough.
Who are the programmers who are famous for doing programmer things?
I’m wondering about this because my wife Cathy asked me a simple question last night, and I realized I didn’t have an answer to it. “Are you” she asked “the most famous programmer in the world?”
I think it’s weird that I have to write this post in 2015, but earlier today I had to explain to someone with the technical skills to submit a good patch that he was doing the process wrong in some basic and extremely annoying ways.
Googling revealed that most explanations of patch etiquette are rather project-specific in their advice. So I’m going to explain the basics of patch submission that apply to just about any open-source project, with a focus on how to do it right when you aren’t a regular committer (that is, it’s what’s often called a drive-by patch). Here we go…
Earlier today I was in an email exchange with a Tier 1 tech support guy at a hardware vendor who makes multiport serial boards. I had had a question in as to whether a particular board supported the Linux TIOCMIWAIT ioctl. Tier 1 guy referred the question to an engineer in their Linux development group, and Tier 1’s reply to me happened to include his email chain with the engineer.
The engineer wrote to Tier 1 “Is that Eric Raymond ‘ESR’? He’s a big deal in open-source circles.” This made me smile, because when I get made that way it usually means the engineer’s going to work rather harder to make me happy than he would for some random. This is helpful to get my work done!
But there is a duty which is the flip side of that privilege, and that’s what I’m here to write about today. Because if you are reading this at all, your odds of becoming a geek-cred certification authority someday are higher than average, and if that happens, it’s better if you consciously understand what you ought to be doing.
I think Terry Pratchett’s death finally hit home for me today. I’ve been kind of numb about it before now, but today I learned abut this proposal for GNU Terry Pratchett. And as I was commenting about it on G+ I found myself crying.
Here’s a very slightly improved version of what I said on G+. I don’t think I knew Terry well enough to give him the tribute he really deserved, so this will have to do.
An incredibly shrinking Firefox faces endangered species status, says Computerworld, and reports their user market share at 10% and dropping. It doesn’t look good for the Mozilla Foundation – especially not with so much of their funding coming from Google which of course has its own browser to push.
I wish I could feel sadder about this. I was there at the beginning, of course – the day Netscape open-sourced the code that would become Mozilla and later Firefox was the shot heard ’round the world of the open source revolution, and the event that threw The Cathedral and the Bazaar into the limelight. It should be a tragedy – personally, for me – that the project is circling the drain.
Instead, all I can think is “They brought the fate they deserved on themselves.” Because principles matter – and in 2014 the Mozilla Foundation abandoned and betrayed one of the core covenants of open source.
I just read Okay, Feminism, It’s Time We Had a Talk About Empathy. and When Nerds Collide.
I’m caught between admiration for Meredith Patterson’s writing ability and what she’s trying to do, and a feeling that the attempt is fundamentally doomed.
I’ve just had an insight I find a bit disturbing. Though perhaps I shouldn’t.
Occasionally I visit Scott Alexander’s excellent and thoughtful blog, Slate Star Codex. Today’s entry reminded me of Laurence Iannaccone’s research on Sacrifice and Stigma, which argues that onerous religious requirements are effective ways of building in-group trust because they are commitment signals that are difficult to fake.
It occurred to me to wonder: do hackers do this? And…I think we do.
How To Learn Hacking: Version 1.2, with a new section on being original. Incorporates more feedback from here and G++
For those of you who wondered why this didn’t just become a major section in How To Become A Hacker, it’s because I think it might become long enough to make that document too bulky to read at one sitting.
Finally. After ten months of work, it’s done. Emacs is fully converted to git. You can clone from git://git.sv.gnu.org/emacs.git and if you have commit rights you can push to it and the changes will stick. The bzr repo is still up but only as an archive.
Lately I’ve been wrestling with various members of an ancient and venerable open-source development group which I am not going to name, though people who regularly follow my adventures will probably guess which one it is by the time I’m done venting.
Why it so freaking hard to drag some people into the 21st century? Sigh…
I’m almost 56, an age at which a lot of younger people expect me to issue semi-regular salvos of get-off-my-lawn ranting at them. But no – I find, that, especially in technical contexts, I am far more likely to become impatient with my age peers.
A lot of them really have become grouchy, hidebound old farts. And, alas, it not infrequently falls to me to be the person who barges in and points out that practices well-adapted for 1995 (or, in the particular case I’m thinking of, 1985) are … not good things to hold on to decades later.
Why me? Because the kids have little or no cred with a lot of my age peers. If anyone’s going to get them to change, it has to be someone who is their peer in their own perception. Even so, I spend a lot more time than seems just or right fighting inertia.
Young people can be forgiven for lacking a clue. They’re young. Young means little experience, which often leads to unsound judgment. It’s more difficult for me to forgive people who have been around the track often enough that they should have a clue, but are so attached to The Way It’s Always Been Done that they can’t see what is in front of their freaking noses.
This landed in my mailbox yesterday. I reproduce it verbatim except for the sender’s name.
> Dear authors of the RFC 3092,
> I am writing this email on behalf of your Request For Comment “Etymology of
> ‘Foo’.” We are currently learning about the internet organizations that set
> the standards of the internet and our teacher tasked us with finding an RFC
> that was humorous. Me and my two friends have found the “Etymology of
> ‘Foo'” and have found it to be almost as ridiculous as the RFC about
> infinite monkeys; however, we then became quite curious as to why you wrote
> this. Obviously, it is wrote for humor as not everything in life can be
> serious, but did your manager task you to write this? Are you a part of an
> organization in charge of writing humorous RFC’s? Are you getting paid to
> write those? If so, where do you work, and how may we apply? Any comments
> on these inquiries would be greatly appreciated and thank you in advance.
> XXXXXXXXXXXXXX, confused Networking student
I felt as though this seriously demanded a ha-ha-only-serious answer – and next thing you know I was channeling Master Po from the old Kung Fu TV series. Reply follows…
When I have to explain how real hackers differ from various ignorant media stereotypes about us, I’ve found that one of the easiest differences to explain is transparency vs. anonymity. Non-techies readily grasp the difference between showing pride in your work by attaching your real name to it versus hiding behind a concealing handle. They get what this implies about the surrounding subcultures – honesty vs. furtiveness, accountability vs. shadiness.
One of my regular commenters is in the small minority of hackers who regularly uses a concealing handle. Because he pushed back against my assertion that this is unusual, counter-normative behavior, I set a bit that I should keep an eye out for evidence that would support a frequency estimate. And I’ve found some.
There’s a documentary, The Hedgehog and the Hare, being made about the prosecution of Andrew Auernheimer (aka “the weev”). The filmmaker wants to interview me for background and context on the hacker culture. The following is a lightly edited version of the backgrounder I sent him so he could better prepare for the interview.
The responses to my previous post, on the myth of the fall, brought out a lot of half-forgotten lore about pre-open-source cultures of software sharing.
Some of these remain historically interesting, but hackers talking about them display the same tendency to back-project present-day conditions I was talking about in that post. As an example, one of my regular commenters inferred (correctly, I think) the existence of a software-sharing community around ESPOL on the B5000 in the mid-1960s, but then described it as “proto-open-source”
I think that’s an easy but very misleading description to land on. In the rest of this post I will explain why, and propose terminology that I think makes a more useful set of distinctions. This isn’t just a historical inquiry, but relevant to some large issues of the present and future.
I was a historian before I was an activist, and I’ve been reminded recently that a lot of younger hackers have a simplified and somewhat mythologized view of how our culture evolved, one which tends to back-project today’s conditions onto the past.
In particular, many of us never knew – or are in the process of forgetting – how dependent we used to be on proprietary software. I think by failing to remember that past we are risking that we will misunderstand the present and mispredict the future, so I’m going to do what I can to set the record straight.
I did something unusual today. I pulled the plug on one of my own projects.
In Solving the CVS-lifting problem and Announcing cvs-fast-export I described how I accidentally ended up maintaining two different CVS-to-something-else exporters.
I finally got enough round tuits to put together two-thirds of the head-to-head comparison I’ve been meaning to do – that is, compare the import-stream output of cvs-fast-export to that of cvsps to see how they rate against each other. I wrote both git-stream output stages, so this was really a comparison of the analysis engines.
I wasn’t surprised which program did a better job; I’ve read and modified both pieces of code, after all. Keith Packard’s analysis engine, in cvs-fast-export, is noticeably more elegant and craftsmanlike than the equivalent in cvsps. (Well, duh. Yeah, that Keith Packard, the co-architect of X.)
What did surprise me was the magnitude of the quality difference once I could actually compare them head-to-head. Bletch. Turns out it’s not a case of a good job versus mildly flaky, but of good job versus suckage.
The comparison, and what I discovered when I tried to patch cvsps to behave less badly, was so damning that I did something I don’t remember ever having felt the need to do before. I shot one of my own projects through the head.
Last night, in an IRC conversation with one of my regulars, we were discussing a project we’re both users of and I’m thinking about contributing to, and I found myself saying of the project lead “And he’s German. You know what that means?” In fact, my regular understood instantly, and this deflected us into a discussion of how national culture visibly affects hackers’ collaborative styles. We found that our observations matched quite closely.
Presented for your amusement: Three stereotypical hackers from three different countries, described relative to the American baseline.