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.
Showers and UI design
Travelling rather a lot this year has left me spending plenty of time staring at showers[1]. There seem to be three broad categories of shower UI design. The first is the one that exposes the raw functionality of the underlying implementation:
(image by bean, reused under cc-by-nc 2.0)
Showers work by mixing hot and cold water and feeding them through a shower head. This implementation allows direct control of the hot and cold feeds. The user can obtain any combination of pressure and temperature that the supply contraints make possible, but at the cost of it being impossible to adjust single variables. Changing the pressure without changing the temperature is difficult. One of the most common alternatives I've seen this year is the following:
(image by anearthling, reused under cc-by-nc-sa 2.0)
Here, power and temperature are unified into a single control. The major problem with this design is that it's generally impossible to have any pressure setting other than full on. The benefit is that the temperature can be altered without any significant concern over the pressure. Simplification through limiting functionality. Finally, we have setups like:
(image by stevec77, reused under cc-by-nc 2.0)
Though not clearly shown, this interface separates temperature and pressure into independent functions. The number of UI elements is identical to the original "hot/cold" case, but the user is now able to set temperature and pressure independently without having to worry about the interaction between the two. This is obviously more effort to implement but improves usability, decreases complexity and doesn't clutter the interface.
So, if this is a solved problem, why do I keep coming across implementations that suck?
YES THIS IS A METAPHOR FOR SOFTWARE DESIGN
[1] Often in a certain degree of confusion, but that's not really the point here
Worrying realisations
The entire lifecycle of Ultrix from first to last release was on the order of 12 years.
I first ran Linux in 1995.
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!
