Why did you write git in C? Because Linus told you to?
]]>You can pry off the key face gently as described here, just push away from you and up with a flat object. The face snaps into a cage mechanism consisting of three parts: a top plate and two wickets which anchor it to from the north and south respectively. Each wicket has a bar that wraps over the top plate, and two legs with pegs that secure it to the keyboard bevel. Viewed from the east or west sides, the wickets cross over each other, making an X. There is enough play in the cage's anchoring that you can squish the whole thing down flat. The only thing that impedes you is a little rubber spring glued to the keyboard bevel. This spring is primarily responsible for that distinctive Thinkpad key feel.
By squishing the cage flat, you can hook or unhook the wickets. To reassemble and replace a key, I found it easiest to build the cage first. Start by crossing the wickets--they are fitted to each other. While pressing the X sides of the cage in, you can slip in the face plate. Don't put on the key face yet. Attach the cage to the keyboard bevel by putting it in place and hooking in the south wicket's legs first. Getting the north wicket in is a bit of a stretch. Flatten the cage by pressing down on it until the north legs slip in. Now you can attach the key face by setting it on top of the cage and applying gentle downward force. You should hear it snap.
]]>Yet it's still crap. It's crap because cvsup doesn't need to exist. It updates the whole ports tree and even compensates for directories getting moved around. But you'd get that for free if FreeBSD would just migrate the ports tree to subversion. cvsup is just duct tape to make CVS kind of tree-versioned. Migrating to svn, however, won't happen anytime soon, because the kernel is in that same repository with the ports tree...and who wants to make the process of checking out the BSD kernel sources dependent on a trendy project like subversion? It's bad enough already that you need CVS to do that.
I hear you raising an additional objection: subversion working copies are a hog, both in space and time, so cvsup wins out on the performance axis. And I agree. SVK doesn't help you much here, as it contributes enough of its own flakiness to offset the working copy savings.
So what I'm really saying is, all of it sucks. I haven't seen something which doesn't suck yet. What the world needs now is a subversion minus the bullshit: a super-performant version control system that just presents itself through the filesystem for the most part. No not ClearCase...masochist. You'd still check out a working copy and make changes to that. But checkout would be a simple rsync operation against the repository-as-served-up-via-the-filesystem (FUSE?). The rsync could be local or tunneled over the network if the repository was hosted remotely. All you'd need is the ability access the full tree as a snapshot at every revision via e.g. /mnt/repository/$rev/.
Could you do this and still make it performant? A lot would depend on the filesystem module and the storage mechanism. Leaving kernel space to go talk to a database on a socket might result in heinous overhead. Just having a "real database" in your corner doesn't mean you win the fight either. At first I thought a "real database" was the solution to subversion's performance scalability problems, but the more I thought from scratch about a better schema, the more I started to understand. Supporting cheap tree copies and versioned trees at the same time is tough.
]]>(frame :number 2 :x 0 :y 0 :width 1024 :height 514 :screenw 1024 :screenh 768 :window 12582974 :last-access 126 :dedicated 0),(frame :number 0 :x 0 :y 514 :width 1024 :height 254 :screenw 1024 :screenh 768 :window 16777278 :last-access 0 :dedicated 0),
* A transactional, versioned filesystem that would be the backbone of a version control system.
(1) SVN has many serious architectural / performance flaws. Programming on SVN's swig-generated perl bindings over the last 6 months forced me to look them in the eye. They're ugly. I'll list them off in some subsequent post. The upshot is that SVN won't scale well to the enterprise level no matter how much snake oil CollabNet pours on it.
(2) SVK is having a bear of a time adapting SVN to the perhaps more powerful delta-based version control model. Other version control systems which are delta-based from the get-go (darcs, git, arch) are taking over.
(3) And finally, from a social standpoint, the project is dead in the water. This realization was finally hammered home for me after I attended an SVN user's meeting recently in New York. Corporate interest has ruined the project. It's opensource in name only at this point. Don't expect anything great out of SVN moving forward.
* A spam counterattack suite which is still in need of a clever name.
The one thing that came as a surprise--but maybe shouldn't have--is that now that I've started auto-reporting all this spam to the abuse addresses, I've been getting a lot more. Presumably, in many cases the spammers are in control of the abuse address as well, and are appending abuse reporters onto their next big recipient list!
Note that what I've written here doesn't overlap much with Spam Assassian, which is on the classification side. Rather it is complementary. From the Spam Assassin docs:
"SpamAssassin is not a program to delete spam, route spam and ham to separate mailboxes or folders, or send bounces when you receive spam. Those are mail routing functions, and SpamAssassin is not a mail router. SpamAssassin is a mail filter or classifier."
I'll release a beta of the spam counterattack suite soon. Let me know if you have any name suggestions.
* A wiki markup language that will take over the world. ;)
Imagine a sane back end that just uses the unix filesystem for organization. Imagine it's all available to you through a command line interpreter for the markup language.
Now imagine it's all quite simple in implementation and design. You don't believe me, do you? Wait and see.
This one I do have a name for, but I'm not telling you yet. ;)
* Some simple tools for working with dhcp packets.
The immediate application is getting onto poorly configured wireless networks that have used up all their dhcp lease space because the default lease time is way too long. You see this at coffee shops sometimes. The regulars are hanging onto all the dhcp releases, which expire once in a blue moon. So what do you do? You sniff packets until you see a DHCPREQUEST / DHCPOFFER, you wait for that bozo to leave, change your mac address to his, and then config yourself to match either manually or by re-sending the original DHCPREQUEST.
* An executable / object file format based on Bernstein's cdb, for the text segment at least.
Received: from fmmailgate09.web.de ([217.72.192.184])
by thegotonerd.com with esmtp
(envelope-from )
id 1GWjJZ-000GK2-8i
for [address omitted]; Sun, 08 Oct 2006 19:48:17 -0500
Reveived: from web.de
by fmmailgate09.web.de (Postfix) with SMTP id B33A81C9BA8;
Mon, 9 Oct 2006 03:11:24 +0200 (CEST)
Received: from [81.199.62.40] by freemailng2402.web.de with HTTP;
Mon, 09 Oct 2006 03:11:23 +0200
It was spam so I have no qualms about posting it here. "Reveived?" Am I to believe that there's some Postfix version floating around out there with that typo? Of course, if Mr. Venema were so good as to provide us with anoncvs I'd go find out right now, but the prospect of downloading 12 tarballs of the source and their accompanying 20 gzip patchfiles just to do a grep filled me with sadness. What has my life come to that I actually considered doing that for a split second?
Email as a technology is a rich source of entropy. Just try to write a "simple" (heh) IMF parser and you'll see what I mean. Now I get to go change a regex, and put in a wacky comment. Oh boy.
Incidentally I wrote a spam counterattack suite this weekend. It finally made it over the annoyance threshold for me I guess. While I'm still manually classifying it by moving it into a spam folder, now there's a queue system that lifts them out of the Maildir and actually does something with the spam. In fact it does a lot of stuff with the spam, including portscan the origin ip, determine country of origin, figure out the abuse address for the ip and actually mail a polite message there with the original message attached.
]]>There you have it, all the sort of behavior that arises in collaborative version control systems. Only wikipedia and wikis in general were imagined up as a totally new technical paradigm. They do introduce some amount of newness, but not a whole lot imho. The biggest thing is that contribution is so damn easy; you just need a browser. You don't even need a *gasp* text editor or a *gasp* version control system.
Umm, I think you do need these things. I think we've reached that point. But I also think that the original idea of low barriers to contribution is very much worth retaining. What we need is for someone to cook up a web interface to all of the important functionality in version control systems, in a way that doesn't totally suck of course. Throw in some simple editing interface and you're done--but always retain the version control system under the covers...expose that via the nice command line tools we expect of version control, and even expose it programmatically so other machines can directly interface to it, for mirroring, logging, presenting a particular logical view of the content, statistics, whatever.
Back to Sitataker's ideas on wikipedia. So individual people are free to run their own wikipedia and accept patches from other wikipedias. I think this is a great idea. He also talks about some wikipedias which are run by an expert, for instance a historian who has exceptional judgment when it comes to patches on WWII, and he basically acts as a branch which aggregates "good" patches on WWII. These patches are further merged to the main wikipedia site by dint of him being so famous / trusted and all.
I like almost everything here except the idea of a "main wikipedia site." I think for the wikipedia idea to be durable, that is going to have to go away. People hear "wikipedia" and the immediately think The Wikipedia which is the ultimate and final word on any subject amen. After all, it's all unbiased facts, right?
Yeah, good luck with that one. Even a collection of unbiased facts has bias; there is the selection of what unbiased facts to include, what facts to omit, the order they are presented in, and so on. There is no escaping the bias.
So admit wikipedia is biased. Admit that it will always be that way. Call it Jimbopedia or something. We call Linux "Linux" for a reason, we don't call it The Unix. It is A Unix variant ultimately controlled by the bias and personal tastes of one man, Linus Torvalds, and appropriately bears his name because of that.
You're free to fork your own Linux at any time and call it Bobix. But you've got a lot to prove if you want me to start using Bobix instead of Linux; chances are, you're not going to. Linus Torvalds is one of the best effing developers out there, and you're going to have your work cut out for you, Bob. People trust Linus. He's proved himself to them. Nevertheless forks occur and take people with them, like DragonflyBSD, for instance. These guys have really good ideas on how to do thread IPC solely via message passing, which simplifies a lot of concurrency issues. But the FreeBSD maintainers didn't quite agree, so they forked and did their own thing. Perfectly ok.
So to summarize, in the end you have a bunch of decentralized wikipedias merging selectively with each other, and the market determines whose best. The structure of trust will emerge, both between wikipedias, and between wikipedias and the vast public.
Let it emerge. Don't force it.
]]>$ plopdb add pics/billy-taking-a-bath.jpg $ echo billy-taking-a-bath.jpg | join - /usr/share/plop/db/master 361709f6fb0a1ccd7fbc94ffcf773fcf billy-taking-a-bath.jpg 1159847154 $ echo "http://nakedbillydotcom/plop.cgi?key=361709f6fb0a1ccd7fbc94ffcf773fcf" | \ mail -s "naked pictures of our little darling" grandma@grandmas.isp
plop-1.0-beta-1.tar.gz
plop-1.0-beta-1.tar.bz2
browse the source
"Integers 2^63 and larger are reserved for future extensions. Under many cosmological theories, the integers under 2^63 are adequate to cover the entire expected lifetime of the universe; in this case no extensions will be necessary."
Phew.
]]>Whatever syntax I end up with, I want to avoid doing something isomorphic to this. I'd like to have a generic way to say "here's some substructure," and I don't want to worry about forgetting to close the substructure. Maybe indent level (or :set ts=2 in my case) is the way to do this. This, coupled with the ability to source in other files, allows one to define arbitrarily structured composite pages ala Wikimedia's "Main article" subsections. It's like the dual space of hypertext: rather than linking out to other pages, you can also flatten them into one big page, efficiently via some cgi / caching mechanism if need be. Over time it could acquire a sort of fractal structure as the page itself descends into tendrils of detail.
I think this will help me resist the urge to impose taxonomy on the content via some external system like categories. Things are not really hierarchical; only anal retentive human brains are hierarchical. This is why OOP is not so useful in the end...your data is usually more useful as a loosely related graph of stuff than as a rigidly defined hierarchy. Boy I'm starting to sound too Web 2.0 for my own taste here...oh yes and tagging, I absolutely need tagging! and a karma system! and proprietary magical algorithms to run on the graph of stuff that make random "fun" connections between things!
]]>