I'm sitting on a plane. The screen in front of me is currently displaying X root weave. Xorg fo life, yo.
[ Home | Articles | Account | People | Projects | FAQ ] I'm sitting on a plane. The screen in front of me is currently displaying X root weave. Xorg fo life, yo.
One of the points I made in my presentation at LCA this year was that for power management to be effective, it needs to be something that works without anyone having to think about it. One aspect of that is ensuring that it doesn't get in the way of the user, since otherwise the user will eventually get irritated and turn it off. Part of my work at Red Hat is coming up with ways to not only offer power management functionality, but to make it sufficiently useful and inobtrusive that manual configuration is almost never required.
Screensavers are an interesting case. We have a good idea of whether most hardware is "doing something" or not, based on whether it's generating traffic or an application has it open. This is less true of screens - the resource making use of the display is the user, and it's entirely possible for the user to be reading or watching something[1] onscreen without us getting any feedback from them. It's common to see people noticing that their screensaver is activating and hitting the mouse or keyboard to stop it. What's the correct solution?
One solution is to have the user increase the screensaver timeout. This is a poor solution - it's one of those "Think about what you're going to be doing with the computer before starting to do it" ideas that I dislike a lot. Computers are there to serve the user, not the other way around. The other downside to this is that the timeout will be left at a large number and monitors will be turned on for significantly longer than necessary.
Another is to pay attention to what the user's doing. If they keep hitting the keyboard just as the screensaver's activating, it's because they want a larger timeout. It's not difficult to give them that. I spent a while today playing with various complex implementations, but I finally came down to a simple one:
Nnngh.
Intel have a magic communciation channel between the system firmware and the graphics hardware. It's based on a region of shared memory and judicious use of interrupts, and it's documented here.
Nvidia have a magic communication channel between the system firmware and the graphcis hardware. It's based on WMI and bonghits, and it's not documented.
Why, yes, I have spent half the day trying to work out how the NVIF method works.
I had a deeply fucked up dream last night. For some reason we'd paid huge quantities of money to obtain nothing of value and George W Bush had been president for 8 years. I clearly need to drink less.
Hey! My laptop's died again! Neat!
Dear HP,
How does "Next business day warranty" translate into it being somehow acceptable for you to be unable to source a replacement part until February, especially when I reported the problem at the end of December?
No love,
Matthew.
Analysis
While it's obvious that being a kernel developer is absolutely the best thing anyone in life could ever aspire to, I'm finding it increasingly difficult to justify not having just given up and gone off to be an analyst instead. Two stories stuck with me this week. The first claims that we can expect Android netbooks to be on sale within a year or so. The reasoning behind this? Android runs on x86 and has a MID profile. Oh, yeah, and it sounds like a cool idea. Sure, we need to ignore straightforward facts like, oh, I don't know, it being UNSPEAKABLY PAINFUL TO DO OS DEVELOPMENT ON ARM, and hence it being NO SURPRISE WHATSOEVER TO FIND THAT BUILDS AND RUNS ON COMPUTERS THAT ACTUALLY GO FAST AND SIT ON PEOPLE'S DESKS. Or that MID refers to the class of devices like Nokia's internet tablets or, well, any of these and not a netbook. And, leaving those, the evidence we have for this is that "It sounds like a cool idea".
It's easy to write an article on why something sounds like a good idea, and even easier to make it sound like a good business plan if you're not the one who's going to lose money on it. But yeah, maybe Google's going to push for Android on netbooks. It's going to be a kind of crowded place to be, what with Microsoft and Intel and Canonical and Xandros and half a dozen Chinese Linux distributions that you've never heard of and really hope never to again once you've seen their distributions, but it's possible. And so these guys might even be right. But the sum total of their insight here is that (a) Google have a product, and (b) Google might want to enlarge the market for that product. The rest is a collection of extraneous facts designed to make you think that they've actually done something more impressive than typing make, and frankly if that's enough to get you noticed then gentoo users the world over are missing out badly.
It's ok, though. There's worse. Google are making a secret OS, which by my count means that there's been eleventy billion people inside Google working on a fucking OS for the past TWENTY YEARS and this time we can tell not because people have, y'know, gone to Google and seen it, but because they're busy leaking information about their secret OS by removing the user agent string from a bunch of their web traffic.
Of course, as Clint points out in his article, Google's a web company and so would want to produce a web OS. The obvious way to develop this web OS would be to, uh, run it on top of Android, an OS currently entirely unsuited to desktop use due to little things like the lack of decently accelerated framebuffer drivers on any hardware you can currently obtain (rather than, say, any of the operating systems already deployed in Google, all of which share one striking feature - the ability to RUN A WEB BROWSER AT A DECENT SPEED). And even though basically everyone in Google seems to have an Android device, it'd be vital to prevent anyone from knowing that they used Android to browse the web, so scratch the user agent.
But that makes no sense. So what Clint's clearly getting at is that people using the Google web OS are browsing the web using the Google web OS, and so remove the user agent string to avoid leaking that information. That makes sense, up until you actually think about it. A web OS would run in a web browser. Why would you run a web browser in a web browser?
Google's not an OS company. They don't employ enough people to develop a full OS and releasing a Linux derivative themselves would just be a way of tarnishing their brand in a hideous manner. Any move into the home would have to be in the form of appliances with known hardware configurations, and seriously, what's the point? It's not a big enough market. If Google's going to push applications, it's going to do it through the browser. And if it's doing it through the browser, then right now it doesn't matter what the underlying OS is. There could be any number of reasons for the mystery of the missing user agent strings, but if it's because Google are trying to prevent people from working out that they're developing an entire software stack that they're going to push out onto arbitrary hardware then I have an Android netbook to sell you.
That'll be $50,000, please.
So. Burning down the house. Uniquely Welsh concept[1] or near-inevitable consequence of design failure? I present the following:
Christmas is a time to ignore such trifling details as nearly accidently burning the house down, and instead to focus on what's important in life - working out which hoops to jump through to make new hardware useful without installing less convenient operating systems. This year was more straightforward than some, and merely involved attempting to work out how to give people money in return for books that could then be read on my Sony reader thingy. Shockingly enough, the Sony Ebook Store requires a windows app, so not a good start. There's no shortage of sites that sell ebooks in a variety of formats without any platform dependent awkwardness, though - of course, most of them are inconveniently DRMed. And the only DRMed content the Sonys will read is either Sony's own or some encrypted PDFs[1].
Not to worry - the DRMed version of the Mobipocket format is based on a symmetric encryption algorithm from 1991, so finding a way around that isn't much of a problem[2]. The only real issue I had was generating the PID needed to buy one of the damn things in the first place. This 10 character string is generated when you install the Mobipocket reader software, but doing so would again involve Windows.
So here's a trivial C program that generates valid PIDs with working checksums. The PID on its own isn't a secret (given that you can get as many as you want by reinstalling the Windows software), so I can't see any awkward copyright law things going on. And, really, it's just a random string plus a checksum.
CRC code is from SSH, the checksum validation is a reimplementation of code from EBook::Tools::Mobipocket by Zed Pobre. My total creative input was generating a 7 character random string and sticking a dollar sign at the end. Go me.
[1] According to the blurb about the firmware update, though mine still seems to claim that it's not authorised to read DRMed content in the about screen. Possibly it needs keys generating, or something
[2] No, I'm not going to tell you how. The internet exists so you can work these things out without asking me
ngh.
Dear humanity,
When I provide shower-related metaphors about software design, it is because I am interested in software design. Not showers. Except to the extent that showers make me clean, which is beneficial from a functional aspect but still not the point.
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!