Older blog entries for mjg59 (starting at number 161)

Russell writes about the iphone. I think he's missing a few things.

The open nature of the PC wasn't inherently what brought it greater success. The open nature of the PC meant that it could spawn an ecosystem of third party hardware vendors, sure. It also meant that it could be cheaply cloned by other manufacturers, ensuring competition that drove down the price of hardware. The net result? x86 is ubiquitous, sufficiently so that even Apple use a basically standard[1] x86 platform these days. Low prices and the wide availability of software that people wanted to run bought the PC the marketplace, with Microsoft being the real winners. Apple hardware remained more expensive for years, and the compelling MacOS software was mostly limited to areas like DTP. Nobody else had any incentive to buy a Mac.

Now, let's look at the phone market. Third party hardware vendors? No real distinction between the iphone and anything else. Sure, anything remotely clever has to plug into the dock port, but developing something to work with that also gets you into the ludicrously huge ipod market. Other phone accessories are either batteries, chargers or headphones. That's really not going to be what determines market success.

Competitive cheapness? When you have a multivendor OS like Android or Windows Mobile, you might expect there to be more opportunity to compete to undercut each other, offering equivalent platforms for less cost. But that's missing something. In the same way that the home computer market has basically consolidated towards PCs, the phone market has already consolidated. Your smartphone has an ARM in, probably along with an off the shelf GSM chip and some 3D core (generally something from Imagination, though in Android's case Qualcomm seem to have come up with their own core - I haven't been able to find out if it's derived from something else). There's no realistic way to make a phone with equivalent hardware functionality and quality to the iphone and sell it for significantly less money. And if you figure out how to, Apple get to take advantage of the same price reductions in their next generation hardware. And, being Apple, they'll probably find some compelling wonderful design feature that costs them nothing extra but makes you want it more anyway. So hardware competition probably isn't going to be what determines market success.

Which leaves two things - advertising and applications. Apple are good at marketing. This is unfortunate, because I'd really rather live in a world where everyone running MacOS was running Linux instead, but we seem to suck in comparison. The good news is that Microsoft also seem to, so maybe we'll have our act together some time between now and Apple crushing us to death. So, assuming current trends continue, Apple's marketing probably isn't going to kill the iphone. Which leaves one thing: applications.

The obvious argument against the iphone's success is that, as a closed software distribution platform, it's less attractive to developers. I don't think that's true. If we look at the console market, the gp2x was hardly a PSP killer. Or a DS killer. You could possibly argue it was a Gizmondo killer, but only if you ignore the Finnish mafia. Being an open platform doesn't immediately result in you killing closed platforms. You need developers, and you need applications. Otherwise nobody's going to buy your hardware, even if it costs $10 less than an iphone and has a few extra bits of plastic. What attracts developers? An attractive development environment and a revenue stream. Android has one real thing going for it here - it's not tied to Objective C, and so there's probably a larger number of potential developers. But let's be realistic. If you're a competent developer, you can move from C++ or Java to Objective C without too much effort. And if you're an incompetent developer, you're not going to be deciding the future of a platform.

Apple have made it easy for people to write applications that share the iphone's delightful[2] UI. There's almost active encouragement to write beautiful programs that integrate well. Sure, the platform limitations bite you in weird ways (like the no background running thing), but Apple have come up with hacks to smooth most of those over. The iphone is a wonderful device to develop for. Sufficiently delightful that there was a huge developer base even before Apple had released the SDK. What does that tell you? Developers actively want to write for the iphone. In fact, they wanted to even before there was a real revenue model. Mindshare means a lot.

What are we going to see in response from Android? To begin with, uglier applications. I'm sure that'll get better over time, but right now the Android UI just isn't as well put together[3]. It's functional, even attractive. But it's not beautiful. And lowering the bar to developer involvement means the potential for more My First Phone Application. Windows Mobile and Symbian have huge numbers of applications. They're mostly dreadful lashups of functionality you'd never want and a UI that's ugly enough to make you want to stab out your eyes, coupled with a nag screen asking for a $10 donation to carry on using it assuming it hasn't crashed before it got that far. To be fair, a lot of iphone stuff isn't much better. But proportionately? Right now the Apple stuff has it. I never want to see another listing of Symbian freeware.

At the moment, Apple wins at providing compelling applications. They may be a gatekeeper between the developer and the user, but right now that's not causing too many problems. Well. It wasn't. The recent fuss about Apple dropping applications because of perceived competition with their own software is an issue. If a developer is going to spend a significant amount of time and money on an application, they want a reasonable reassurance that they're going to be able to ship it. And, right now, Apple's not giving that. It remains to be seen whether this has long term consequences, but there's some danger of Apple alienating their developer base. If those developers move to another platform, and if they create compelling software, Apple might stand some real competition. At the moment? Apple has the hardware, the OS and the applications. They have the potential to take over broad swathes of the market. But they also have the opportunity to throw it away. And that's what's going to decide the success of the iphone - a closed platform is not inherently a problem, but it gives the vendor the option of removing one of their key advantages. If Apple get through this with their developer popularity intact, I don't see the open/closed distinction as having any real-world importance at all.

The relevance to Linux? We're not going to succeed by being philosophically better. We have to be better in the real world as well. Ignoring that in favour of our social benefits doesn't result in us winning.

[1] It's slightly more legacy free than a "genuine" PC - there's no i8042, and things like the gate A20 hack aren't implemented. But it'll boot DOS (given enough effort), so hell, it's a PC

[2] And yes, I genuinely do think that the iphone's UI is better than anything else on the market. There's no reason someone else, including us, couldn't have got there first. But we didn't, and now everyone gets to play catch up. Shit happens

[3] I have no idea where Apple gets its UI engineers from, but someone needs to find the source and start waving huge piles of money to pick them up first.

Syndicated 2008-09-25 02:48:51 from Matthew Garrett

Not being from Oakland, Meth has a relatively small impact on my life. Until I get a cold, at which point I get to curse the lack of effective drugs. What's surprising is how phenylephrine does have a noticable effect. What's even more surprising is that it has this effect about thirty seconds after I've swallowed the capsules, indicating fairly strongly that it hasn't actually hit my bloodstream in any sensible way at that point (though I've had astonishing difficulty in finding figures on how long the plastic capsules take to dissolve in the stomach). So, even though I know it's got no measurable effect beyond that of a placebo, the placebo effect still works. Damn you, psychology.

Syndicated 2008-09-08 00:08:00 from Matthew Garrett

HELLO I'M ON THE TRAIN

and, by the looks of it, may be for some time:

Yes, the track is underwater. Sigh.

Syndicated 2008-09-06 15:58:45 from Matthew Garrett

Power management and graphics

It's the X Development Summit in Edinburgh this week, so I've been hanging out with the graphics crowd. There hasn't been a huge amount of work done in the field of power management in graphics so far - Intel have framebuffer compression and there's the lvds reclocking patch I wrote (I've cleaned this up somewhat since then, but it probably wants some refactoring to avoid increasing CPU usage based on its use of damage for update notifications). That still leaves us with some fun things to look at, though.

The most obvious issue is the gpu clock. Intel's chipset implements clock gating, where unused sections of chip automatically unclock themselves. This is pleasingly transparent to the OS, and we get power savings without any complexity we have to care about. However, there's no way to control the core clock of the GPU - it's part of the northbridge and fiddling with the clocking of that would be likely to upset things. Nvidia and Radeon hardware is more interesting in this respect, since we can control the gpu clock independently of anything else. The problem is trying to do so in a reasonable way.

In an ideal universe, we can change these clock frequencies quickly and without any visual artifacts. That way it's possible to leave it in the lowest state and clock it up as load develops. There's a couple of problems with this - non ideal hardware, and the software in the first place. Jerome's been testing a little on Radeon and discovered that changing the memory clock through Atom results in visual corruption. It's conceivable that this is due to some memory transaction cycles getting corrupted as the clock gets changed. If we could ensure that the reclock happens during the vertical blank interval, that's something that could potentially be avoided (of course, then we have the entertainment of working out when the vertical blank interval actually is when you have a dual head output...). The other problem is that 3D software tends to consume as many resources as are available. Games will produce as many frames per second as possible. Demand-based clocking will simply ramp the gpu to full speed in that situation, which isn't necessarily what you want in the battery case (as the number of frames per second goes up, so does the cpu usage - even more power draw) but is probably pretty reasonable in the powered case.

Handwavy testing suggests that this can save a pretty significant amount of power, so it's something that I'm planning on working on. Further optimisations include things like making sure that we're not running any PLLs that aren't being used at the time (oscillators chew power), not powering up output ports when you're not outputting to them and enabling any hardware-level features that we're currently ignoring. And, ideally, doing all of this without causing the machine to hang on a regular basis.

Syndicated 2008-09-05 14:46:13 from Matthew Garrett

Jesus fuck, Dell, why do you have a WMI event interface that seems to do nothing but pass back things that look awfully like keyboard scancodes? I mean, E045? Come on, now.

Driver forthcoming for those who really want the little battery button on their Precision M6300s to work.

Syndicated 2008-08-27 01:24:47 from Matthew Garrett

What amuses me about complaints about censorship is that they often seem to be associated with, uhm, censorship. Compare and contrast:



Bored now.

Syndicated 2008-08-14 18:38:30 from Matthew Garrett

Things I have learned in the past 24 hours

  • Websites that claim you'll never be able to get them taken down are quite easy to get taken down
  • Legal threats are an excellent way of obtaining information
  • The IP address used to subscribe me (and several others) to a vast number of mailing lists was 68.57.223.4. Which seems to belong to Ryan Farmer. "Fucking hero", my arse.

Syndicated 2008-08-14 11:47:16 from Matthew Garrett

Testing 2.6.27-rc2 with the current released (not development) BIOS on the Foxconn G33M reveals the following:

  • There are no ACPI errors on boot, other than the (irrelevant) OEMB table (there are in previous kernels, stuff's clearly been fixed in .26 or so. Can't really be bothered digging through to find out what)
  • The system fails to reboot if it has been suspended and resumed. The fix is three lines long, one of which is a comment and one of which is blank.
  • The system is otherwise perfectly stable.
Summary: Almost all problems caused by bugs in Linux, one problem caused by BIOS vendors interpreting the ACPI specification differently to the Linux implementation and trivially worked around. No sabotage.

Thanks very much to Carl at Foxconn for being able to get me information about what was causing the reboot issue - I spent significantly longer putting the system together than I did fixing it.

Syndicated 2008-08-06 18:13:03 from Matthew Garrett

Coincidentally, I had the opportunity to poke at a machine that actually does deliberately treat Linux differently in its ACPI tables today. Jeremy was poking at an Acer Aspire One before installing Fedora on it, and Dave noticed that it printing a bootup message indicating that the firmware was testing for _OSI("Linux"). A bit of poking later, and we have the following:

            If (_OSI ("Linux"))
            {
                Store (0x03E8, OSYS)
                Store (0x0A, \_SB.PCI0.LPC.S4TM)
                Store (0x43, \_SB.PCI0.EXP2.PXS2.LSMP)
                Store (One, \_SB.PCI0.EXP2.LL0S)
                Store (One, \_SB.PCI0.EXP2.LLL1)
            }
            Else
            {
                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                    Store (0x06, \_SB.PCI0.LPC.S4TM)
                    Store (Zero, \_SB.PCI0.EXP2.PXS2.LSMP)
                    Store (Zero, \_SB.PCI0.EXP2.LL0S)
                    Store (Zero, \_SB.PCI0.EXP2.LLL1)
                }
Other OSes get the same values as Linux, other than the OSYS field. Now, what do these writes do? They're all to PCI config space, so since the machine in question is a 945/ICH7 machine we have publically available docs. A bit of digging later and it shows that the firmware is disabling PCIE active state link control and programming more conservative timings for entry into the C4 processor idle power saving state. In other words, certain bits of power management functionality are compromised if it detects that it's running anything other than Vista. Weirdly, it also flags the HPET as present but invisible on Linux, but I suspect that's an oversight rather than anything deliberate.

Why would they do this? I've no idea. I suspect it's something to do with the degree of platform validation performed rather than a subtle attempt to degrade Linux's battery life on the hardware (frankly, we do a good enough job of that ourselves right now), but this is exactly the kind of reason we removed _OSI("Linux") support from the kernel. Vendors will do stupid things with it.

Syndicated 2008-08-01 18:47:15 from Matthew Garrett

152 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!