evan_tech

Criticisms or calls for respect of Richard Stallman seem to miss the real importance of the man. People focus on gcc or emacs or the GNU stack, which have certainly been great works; or his more recent GNU/Linux posturing or interviews, which seem to me desperate and nearly pathetic; but these lose the greater context.

I once read the argument that Chomsky -- whether you agree or disagree with his ideas -- serves a useful purpose in delimiting a boundary of the debate. By being "radical", he allows for others to have positions that are more moderate versions of his without themselves getting pegged as radicals. Stallman served the analogous role for free software at a time when it was just not done (the GNU announcement was 1983; Wikipedia says the first nearly free BSD came out in 1991, and the Debian Manifesto was 1993). It'd be excessive to attribute Mozilla or the Free Culture movement just one person but he definitely planted the seed.

In part due to Stallman's influence, today we're not limited to arguing over the relatively minor difference of which megacorp (Microsoft? Apple? mine?) we'd like to license our computers from, but rather whether in a non-zero-sum game like software there are actually moral arguments to be had about sharing beyond simply applying capitalism.

Do I believe in or use the GPL? No, not anymore. But I do believe in free software, and still have a healthy respect for what came before.

I'd like to draw your attention to bradfitz and Brett's pubsubhubbub, a protocol for distributing real-time updates.

It feels very bradfitzy to me: it is simple, decentralized, seems obvious in retrospect, and pays careful attention to an incremental migration path from existing technology (here, people who provide static feeds with the expectation of clients polling).

The slides are brief and to the point. Give 'em a glance.

Suddenly, developing a browser for my marginal operating system seems more important, huh?

(No, I can't answer any questions, except to note this future is different than the one I imagined.)

I finally cornered Dan -- the guy who ran sweetcode -- at a party and told him that I and many others mourn its passing. He seemed surprised.

He told me spent literally hours a day collecting the tidbits that made sweetcode what it was. Since the purpose was to bring things to you that weren't well-known, the normal avenues (hearing from a friend, seeing on a news site) weren't useful. He had to give it up once he got a real job.

We proceeded to discuss why current news aggregation approaches fail (what I'm interested in is good things I haven't heard about before, regardless of the date, while news uses "happened recently" as an heuristic for that), whether a platonic ideal of good exists for the sort of information sweetcode presented, and, y'know, Kaa's law and I got sad about sweetcode all over again.

git.chromium.org is a git-svn mirror of the canonical SVN repository. It works like this: the SVN server pushes out, with svnsync, a mirror to another machine. That machine then has a cron job that runs git-svn against the local svnsync'd repo. (Part of this design was so this mirror machine doesn't have any access to the writable repo.)

By the way, there's info on our wiki about how to set up git-svn such that you can fetch with a fast git fetch from the mirror while still using the slow SVN server when it's time to commit.

This has been working fine for quite a while but I noticed that occasionally (rarely) it was getting the proper commit data but the author wrong.

$ echo $(git rev-list --author=chrome-bot origin | wc -l) $(git rev-list origin | wc -l)
86 14624
Half a percent of commits.

I asked around and the best guess is this surprising gotcha: SVN commits aren't atomic. :(
The author metadata is a separate property of a commit and so it's possible for my mirror to grab a commit before the author data has synced over.

What's the fix? svnsync puts a lock in the repo before syncing. Right now I check the lock. To be correct I'd need to grab the svnsync lock myself while I'm doing my copy. Another option is to rewind and try again whenever I see a bad commit get mirrored, but git-svn doesn't really like having history rewound without clobbering its metadata and I can't let it just rebuild its metadata from the commit history for complicated reasons outside the scope of this post.

In summary, now I have this git repo that has the wrong authors in some commits. Fixing it would require rebuilding history from the earliest instance of the problem, invalidating everyone else's copies. I haven't done it since I'm not convinced it's too important. Now that I look at the logs, it seems to have gotten much worse recently...

I am pathetically behind on email -- I see I've failed to ack patches to at least four of my projects, and I noticed another has been forked (a good thing! though I should probably just give them ownership).

I suspect the fundamental problem is it's more fun to start something than finish it. If you have been trying to get a hold of me, please re-ping me if I don't respond in a day or two.

Dear Linux hackers,

Chrome tends to push minor updates (often security) pretty frequently. We'd like to operate as a good member of the Linux ecosystem and just offer an apt/yum/etc. archive, but it seems unlikely to me that people will accept pulling a new 20mb binary package every few days.

One idea I've idly had is that we could provide deltas, ideally ones that would reconstruct the normal packages you'd get if you went through the slow path. For example, it could look at which package version you currently have installed, then combine the diff with the files you currently have installed to regenerate the files that would be in the newer package, and then construct the package from there and hand that off to dpkg/rpm. I've heard about such tools existing but my Googling is failing me. Do you have any links? Do you have any friends I could ask?

(For comparison, Firefox uses its own autoupdate system on Linux if you haven't installed it via a distributor, which is actually pretty reasonable when you consider the above. But this also requires that the running binary have write access over its own files, which more or less means it needs to be installed in your home directory. This is one of the reasons (aside from the fact Microsoft also recommends it) that Chrome on Windows installs into the Windows equivalent of your home directory.)

CVE-2009-0521 was actually me: I was poking around trying to make Flash not crash on Linux Chromium and noticed something wasn't quite right. I had just thought it odd; Tavis, the reporter, recognized it as a security problem.

(I really don't intend to post this much security-related stuff. I believe it's just coincidental that I've had a lot lately.)

Upgraded to Ubuntu Jaunty.

• X hung with garbage on the screen after rebooting. Booted into "restore mode" (I forget the exact name), it gave me a text-based dialog where I could say X was broken. Picking that made it spew --help output to the console and redisplay the dialog, but the fix held.
• Have new notifications display.
• Volume buttons no longer work. (I'm on an X60.)
• Turning my wireless on via the hardware switch again makes it auto-find wireless access points. This worked a few releases ago, then broke more recently, and now it's back to fixed.
• Turning compositing on in X made everything very slow. (Despite this being an Intel chipset? Maybe related to above recovery problems?)
• Suspend worked for me once or twice but it hasn't come back from suspend twice now so I guess it still doesn't work. It hasn't worked for so long that waiting another year to see if the next release helps is familiar territory.
• I still can't figure out how to tell gnome what window manager I want. It's changed so many times over the years that none of the four methods I could find online worked.

I appreciate that releasing software this big is hard, and some of that is hardware issues, that part of the Linux social contract is that it's up to me to roll up my shirt sleeves and fix some of this stuff, etc. So I'll summarize by just saying that for me personally, the upgrade was a waste of time.

I'm considering doing a fresh reinstall in the hopes that I have cruft in /etc/acpi or whatever to help with the suspend thing. I was pretty excited the first time it came back from suspend.

(PS: We set up a Fedora 11 box at work for testing Chromium against different compiler/libraries/etc. They use ext4 by default and managed to get a nonbootably corrupt disk within a few days. I'd suggest avoiding ext4 for now -- it's been fine since we reinstalled with ext3.)