As I mentioned,
I recently had to change Atalib to track changes to the search result
page at WorldCat. The updated
version is now available: atalib.user.js
As mentioned before,
I want to improve the way I was serving source files. An obvious
improvement is to link together version control with distribution, and
the obvious alternative was cvs and CVSweb. Because
of recent changes, atalib, the greasemonkey
script for adding WorldCat search results to Amazon pages, was an ideal candidate
to try on the new arrangement.
Unfortunately, CVSweb is not well-suited to serving userscripts,
and/or greasemonkey does not play well with CVSWeb. See, CVSweb serves
up pages for URLs that end with the filename of the version controlled
file, but the resource addressed by the URL is not actually the file,
but a presentation of metadata for the file, version histories,
branches, that sort of thing.
As a more concrete example http://cvs.ninthorder.com/cvs/atalib.user.js
does not address the atalib userscript, itself, but the revision history
as seen below.
Here's where it starts to get rocky: greasemonkey believes that when
a URL that ends with user.js
is loaded, greasemonkey should
intercept it and try to install it as a greasemonkey script. While
greasemonkey is enabled, you can't even load the page that has the link
to the actual greasemonkey script.
Which brings me to the next issue: The link to the actual script
does not end in user.js
, it ends in a revision number,
so it will never be intercepted by greasemonkey to be installed.
I'm working on rules for mod_rewrite
that will allow a URL of the form .../atalib.user.js
to address a
revision via CVSweb. That part really isn't that hard. Unfortunately, if
you want to browse the CVS repository for a greasemonkey script, you're
going to have to disable greasemonkey while you do it.
UPDATE: Jeff suggests that no
one really wants to browse the revision history of my files. That might
be true, in which case all I need is to expose a cvs checkout to the
web. It's a thought I had last night, too, and it's worth further
consideration.
UPDATE: Further, Jeff wondered why I was using 20th century
technology for revision control. The answer was, I'm reasonably familiar
with cvs and CVSweb. He says I should be using git because he and Linus both like it. I
decided to scrap cvs for now and try bazaar for version control, because it
provides many of the same features as git, and the Canonical people at
PyCon 2007 gave me a
bazaar t-shirt. (Commit. Push. Merge.
)
The format of WorldCat search
results pages has changed, and it broke Atalib. I've fixed the bug, but
haven't worked out how to provide the updated source in my new,
improved blogotube information
architecture.
The corrected version should be available soon.
Experts, like security guru Bruce Schneier, are telling
us the
DRM systems included in Windows Vista is harmful to
users. It consumes system resources, causing slowdowns, and destabilizes
the system, causing, one assumes, crashes and hangs.
This software exists for one reason: to let someone else control what
you can and can't do with your own computer. To some extent all software
does this, but DRM software is unique in that it's purpose is to
reduce the functionality of the system.
Regardless of what you might think of the motivation for this, who do
you think ought to be able to control what is shown on your monitor, or
what sounds come from your speakers, or what data is moved from one disk
to another? Do you think they will get it right, and you'll never have a
problem, or wrong, and you'll find yourself unable to make a copy of
some file? What do you think the collateral damage will be? Does it
bother you that some corporations have decided you're untrustworthy?
If an automobile had a system installed that let the automaker
disable the steering by remote control, would you buy it?
Schneier suggests consumers not upgrade to Vista
.
Unfortunately, I find that an unlikely scenario, and offer as
evidence people paying more than $200/month for
unsatisfactory service, and writing comments on the newspaper website,
rather than making a meaningful change. Soon, all OEMs will be shipping
only machines with Vista installed, and in general we'll take it lying
down because the latest version of MSWord, won't run without it. Or new
displays won't. Or speakers won't.
We'll let Microsoft use us as pawns in a game to control the delivery
of content, forcing on us an OS which limits our control of our own
systems, and forcing their proprietary formats on the providers. (The
providers don't actually care that much about format, I suspect, as long
as you pay your $0.99 per track for your music, and can only access it
from one device. They'll deliver it in the format that will net them the
most ninety-nine centses.) Like a commodity, we'll be sold to the
entertainment industry. It's not because we're lazy or stupid; it's
just that many of us don't even realize we have a choice.
But we do. There are several concrete steps that would make those
that want to take control of our computers and networks from us sit up
and take notice.
Switch
browsers.
This is the easiest step to take, and aside from openness and keeping
your computer your own, there are good reasons to make
the change.
Break the reliance on MSOffice. Try something free, as in Freedom.
OpenOffice is full-featured, and has an open
file format so your documents aren't locked away by a software
vendor, forcing unwanted
upgrades on you. It provides compatibility to make the transition easier.
Finally, take back your system completely with a free operating system.
Ubuntu comes with both Firefox and OpenOffice ready to go, as well as
just about everything you might
want your computer to do. Photo editing? Chat? Media player? Simple
software updates? Community and professional support? It's all in
there.
Ubuntu's Live CD lets you try it all with no risk or commitment.
Update: Support free and open software by
joining the Free Software
Foundation. Support free networks and digital rights by joining Electronic Frontier
Foundation.
Don't take it lying down.
While tinkering around with the stylesheet for the pyblosxom implementation
of Internal Dialogue, I came across something curious.
-
My first crack at applying a background color (so I wasn't looking at
a blinding sea of white) was pretty simple.
body {
background: #cc9;
}
But it didn't quite look right, as you can see below.
-
So I tried fiddling with the margin...
body {
background: #cc9;
margin: 0px;
}
-
To try to get some idea what was going on, I set a border so I could
see the box.
body {
background: #cc9;
margin: 0px;
border: 1px solid black;
}
This bears further investigation, but it will have to wait until I
finish the switch.
Update
This turns out to be a difference in the way Firefox handles XHTML vs.
HTML. If I saved the document to a file with the .html extension, it looked
just fine, but if I named it .xhtml, I would see the weird, white border.
I moved the background-color directive out the the
body section and into the (newly created) html
section of the stylesheet, and it looks fine. The border disappears.
W3C may have something to say
about this issue, but it's hard to tell without a stardardese-to-english
translator.
