Older blog entries for mjg59 (starting at number 184)

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.

Syndicated 2009-01-04 02:23:19 from Matthew Garrett

So. Burning down the house. Uniquely Welsh concept[1] or near-inevitable consequence of design failure? I present the following:


Innocent Christmas ornament or HARBINGER OF DOOM?

Note how the candle descends into the foliage. There's a good inch and a half of candle left there, embedded into a block. The foliage is, in fact, plastic. The block it's embedded into is some sort of hydrocarbon-based foam. It turns out that lighting one of these and leaving it for a while is a good way to trigger all kinds of excitement. Of the "Goodness me, there appears to be a large lump of petroleum byproduct burning quite vigorously in the hall" variety.

The software design moral: Everything is shit and will attempt to kill you when you're not looking

Now. Back to eating turkish delight and wondering what to do for New Year.

[1] Yes, yes, it's a cover. THAT'S THE JOKE.

Syndicated 2008-12-27 22:25:11 from Matthew Garrett

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

Syndicated 2008-12-26 02:37:52 from Matthew Garrett

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.

Syndicated 2008-12-14 09:11:35 from Matthew Garrett

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

Syndicated 2008-12-13 23:48:16 from Matthew Garrett

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.

Syndicated 2008-12-11 06:45:21 from Matthew Garrett

In other news

Travel plans:

7th December - 11th December - Boston. And Westford. Sob.
11th December - 15th December - New York
18th January - 25th January - Hobart (LCA)
25th January - 1st February - Melbourne, probably. But who really knows?
1st February - 4th February - San Francisco
6th February - 8th February - Brussels (FOSDEM)

And that's currently it. Anywhere else I should be? GUADEC's probably a given, but otherwise this is your opportunity to ensure that my bed lies cold and empty for large periods of the year.

Syndicated 2008-12-04 02:57:43 from Matthew Garrett

Advantage of Linux over Solaris

In response to this:

Idle power draw of Fedora 10: 100W
Idle power draw of Opensolaris 2008-11: 135W

Sure, there are other arguments. But with energy prices the way they are, choosing Solaris is choosing to spend significantly more money on your hosting. Remember to factor that into your TCO calculations.

(Testing done on a 4-way AMD with a Radeon X1900 graphics card, which is what I happen to have to hand. Out of the box configuration.)

Syndicated 2008-12-04 02:36:44 from Matthew Garrett

Thintel

ICH8 docs, section 5.13.5.1:

To eliminate the audible noise caused by aggressive voltage ramps when exiting C4 states at a regular, periodic frequency, the ICH8 supports a method to slow down the
voltage ramp at the processor VR for certain break events.


Sounds good. Section 9.8.1.6:

C4_TIMING_CNT: Bit 6 Slow-C4 Exit Enable —When 1, this bit enables the Slow-C4 Exit functionality.

Well, hey, we can quirk this on and make life better for everyone oh wait section 9.8.1.4:

Bit 0 C-STATE_CONFIG_LOCK: When set to 1, this bit locks down the C-State configuration parameters. The following configuration bits become read-only when this bit is set:
...
The entire C4 Timing Control Register (C4_TIMING_CNT)


Thanks, Intel. Thintel.

Syndicated 2008-12-02 03:28:00 from Matthew Garrett

175 older entries...

New Advogato Features

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!