LVM snapshots also just aren't all that good.

They require you to pre-allocate space, so you have to guess how much copy-on-write difference will accumulate between the original and snapshot over the lifetime of the snapshot.

If the snapshot runs out of space, it *should* cleanly disable its self. Pity about the file system mounted from it that has no idea its backing block device just vanished. It gets messy, fast, when an LVM snapshot runs out of storage.

LVM snapshots are really inefficient, because they track all block changes, not just user-level file data and metadata. This massively bloats the snapshot, reducing how long it lives until it runs out of backing store and disables its self.

LVM snapshots don't share backing store. If you have three of them, snapshot t+3 has to store all the data snapshot t+2 and snapshot t+1 do, and so on. The differences between the real fs (t) and snapshot t+1 land up being stored three times in three separately allocated backing stores. You waste a HUGE amount of space this way, and it's hard to reliably predict how much you need so your snapshots often vanish out from under you are you're trying to use them.

LVM is useful, but for someone used to the Volume Snapshot Service (VSS) on Windows servers, to ZFS, or to any of the "enterprise-y" file systems often seen deployed with big SANs, it's just going to make them cry.

I think the "shut down the database" bit is what's wrong with dump.

"In particular, SQL databases are completely unsuitable for this kind of backup (this is why they have their own backup and transaction log handling procedures)"

While snapshots aren't ideal for SQL DBs, any real snapshot is equivalent to a point-in-time copy of the state of the file system. Restoring it and starting the database should seem to the database just like it's recovering after unexpected power failure or a process crash.

Any database that doesn't recover properly after a snapshot restore will also fail to recover properly after powerfail or a sudden hardware reset, because it's not ordering its writes properly.

Of course, proper snapshot implementations (ie not LVM) notify apps that a snapshot is about to happen so they can pause their work and enter a stable, easy to recover from state for the moment it takes to make the snapshot. So it's even easier on the database.

Now, I'll grant that for databases it's usually *better* to do incremental block-level copies, SQL-level dumps, etc using the databases own tools because doing so is usually much more _efficient_ than taking a snapshot then archiving it somewhere. But sometimes you just want the snapshot around as insurance before doing a major config change or upgrade, and for that they're just unbeatable.

While I don't much like Windows servers in general, I have a major case of VSS envy (Volume Snapshot Service, not Visual Source Safe - blech!), because it's worlds ahead of anything seen on any open *nix and has been for nearly ten years. Hell, my one and only Windows server maintains in incremental backup of its self on a remote iSCSI volume, including many point-in-time snapshots, that I can just unplug from the iSCSI storage host and boot if I need to for disaster recovery. It's impressive, and VSS is the core of what makes it possible.

What gets me about this is that "Something safe" here means "something safer for me at the expense of safety for others".

Yes, a giant truck is undoubtedly safer for the occupants of the truck. Pity about people in small cars, motorcyclists, cyclists, pedestrians (they're terrible for collision safety with pedestrians) etc if the driver of said giant truck isn't utterly perfectly skilled and attentive.

It makes me really, really angry when I see some soccer mom driving one of those because they're "safer". What about other people's kids?

IIRC MPEG (or at least H.264) uses something vaguely similar to the NTSC space, so yes that'd be more CRT-aligned than LCD-aligned. Truthfully it doesn't matter much - it's the capabilities of the particular device that're key, and the technology only influences those capabilities it doesn't determine them. There are LCDs with much wider gamuts than most CRTs, and CRTs with much wider gamuts than most LCDs.

There are in fact no widely used generic colour spaces that're targeted at LCD displays. sRGB is designed around CRTs, and it shows.

I wouldn't think that this is as simple as reclaiming gamut lost by the move to LCD - not least because there wasn't necessarily any gamut lost in the first place. Moving to cheap, crappy LCD from high-end TV will cost you gamut area, but moving from cheap crappy TV to high-end LCD will most likely gain you gamut space.

In terms of color theory, nothing stops is potentially being real. If you expect to hook this up to some random source and get an improvement, though ... good luck. It's not going to happen. With an appropriate 10-bit or 12-bit wide-gamut source, though, it's certainly capable of better results.

The input may be 3-color (RGB), but if it's defined with a wide-gamut space like Adobe RGB, possibly with up to 16 bits of precision per colour channel, then it can represent a huge range of colours. It can do this by defining near-"perfect" primary colours and assuming perfect control over blending of those primaries.

A regular TV, though also an RGB device, has a very different gamut. That's largely because the primary colours the TV uses aren't as bright/saturated or as "perfect" as those in the Adobe RGB space, but it also can't blend its colours as well. Most likely it only uses 8 bits per colour channel, so it has a much more limited range of graduations, further forcing the colour space to be narrowed to avoid banding due to imprecision.

The regular TV must "scale" a wide-gamut input signal in a colour space like Adobe RGB to display it on its own more limited panel. It can do this by "chopping off" extreme colours, by scaling the whole lot evenly, or several other methods that're out of scope here. Point is, that they're both RGB devices, but they don't share the same colour space and must convert colours.

So, if the yellow pixel (another primary) expands the gamut of this new TV, then yes, even though it too only takes an RGB signal, it's in theory better, because it can convert a wide-gamut RGB input to its own RGBY space for display with better fidelity than a TV with the same RGB primaries but no Y channel colour achieve.

Another device might still be plain RGB, but for each of the red green and blue primaries it might have much better (closer to "perfectly red" etc) colour. This device might have an overall wider gamut (ie better range of colours) than the RGBY device, though it's likely that the RGBY device's gamut would still be capable of better yellows. (If you're struggling to figure out what I mean, google for "CIE diagram RGB CMYK" to get a feel for it).

Attaining better results through adding a channel and/or having better R,G,B primaries presumes properly colour-managed inputs to gain any benefit, though. In reality, video colour management is in a pathetic and dire state - inputs can be in any number of different colour spaces, there's no real device-to-device negotiation of colour spaces, and it's generally a mess. If you feed a "regular" narrow gamut source through to a TV that's expecting a wide gamut signal, you'll get a vile array of over-saturated over-bright disgusting colour, so this is important. Since this device would rely on wide-gamut RGB input to have any advantage, it'll need a 10-bit or 12-bit HDMI or DisplayPort input with a source that's capable of providing a wider gamut signal (say, BluRay) and is set up to actually do so rather than "scaling" the output video gamut to the expections of most devices.

The fact that most inputs only support 8 bits per channel (and thus aren't very useful for wide-gamut signals because they'll get banding/striping in smooth tones) really doesn't help.

Once you've taken a disk image of the original machine and have the image on a less fragile system, Linux will probably mount it with:

mount -t sysv -o loop /path/to/image /mnt/tmp

(possibly with any required -o offset= if it's a full-disk image not just an image of the partition/slice containing the file system).

Failing that, you can probably read it with SCO OpenServer 5.x if nothing else will handle it. SCO OpenServer still runs under current VMWare releases (though linux-kvm's SCSI HCI implementation is too incomplete so it crashes on kvm) and can be pointed at the disk image that way.

You can still find the old FreeSCO ISOs around on the mouldier corners of the 'net. I can't offer you any, since I only have fully licensed OpenServer 5.0.5 which I can't distribute. It's for a truly amazingly legacy Microsoft Xenix application from 1983!

SCO uses HPFS by default, but I think Xenix used something more elderly. SCO's mount(ADM) lists it only as fs type "XENIX".

True. However, health insurers in the US negotiate separate prices and discounts with providers. The sticker price of a device has little to do with the price a given health insurer pays. It's largely a negotiation ploy by the device manufacturer to push the health insurer's discounted rates up, and to let the insurer claim it gets their customers an "x%" discount on this class of item.

Don't have health insurance? Too bad, they don't really care about you, because you're not where the money is.

Add medical equipment regulatory and compliance costs into the mix, bump the price for a hefty bit of insurance against medical litigation, and you've got yourself one hell of a price tag. The relatively small size of the industry compared to, say, mobile phones doesn't help, nor does the fact that compliance requirements often prevent manufacturers from using off-the-shelf ASICs for common, simple tasks in their devices. A hearing aid DAC or ADC might be much the same as a DAC or ADC for some other purpose, but it's probably custom made for the industry if not the device because of regulatory requirements.

All that drives prices through the roof.

The Ur Quan Masters (was: Star Control 2) at http://sc2.sf.net/ is a masterpiece of a game, runs natively on Linux, and is free.

You can also run a lot of great games under DOSBox. You can get the X-COM series ( UFO Defense, Terror from the Deep, and Apocalypse ) from various online sources for something like $5 US, just make sure they're not DRM-wrapped. I also highly recommend Master of Orion II. All these run great under DOSBox on Linux and require no 3D video capabilties at all. They're all long-running single player strategies, which may not be your kind of thing.

I know - how about I market a new "TotalControl" phone brand that ships without any software, so the buyer can build a whole phone OS from scratch to their taste. Because, really, it's just lazy to expect existing functionality.

That'll be successful in the market, right? (Remember the topic / article?)

My point isn't that I can't write my own non-broken mail client with a new implementation of certificate handling - it's that it's absurd that I should have to replace such basic, core functionality of an existing "smart" phone OS.

In the same way, sure, I can install a file manager app. To do so I have to (a) know they're out there, which an average user may not; (b) evaluate the various offerings, (c) select one and (d) install it. It's a basic feature that really should be there from the start if they're going to call this thing a smartphone - even Symbian S60 has a file manager.

As for self-signed certs - it could be that self-signed certs are actually OK and it's just certs signed by a CA not in the pre-installed CA trust list that're a problem. I only tested a cert signed by a private CA. However, I've seen reports indicating self signed certs are an issue as well as the inability to install new CA certs:

• Issue 1077
• issue 1016
• issue 3237

As for doing the work yourself rather than relying on libraries - how much would you enjoy working with C++ without the STL? (OK, bad example, probably a lot - the STL is ghastly). Python without most of the shipping modules? Perl without CPAN? How would you like using a Linux desktop where 2/3 of the apps and libraries didn't exist and you had to hunt down alternative implementations of questionable quality and write what you needed yourself?

Sure, you can do all that. So can I. Do you want to? I don't know about you, but I want to get on with writing useful things, not basic OS and app functionality I want to just use so I can get on with the real work. I especially don't want to find out while trying to use a library to do my real, interesting work that it's been butchered and crippled.

I investigated Android 1.5 when looking at upgrading my phone recently, so I pulled down the SDK and fired up the emulator with an Android 1.5 instance. I was amazed at how limited it is - even more than the iPhone.

SSL/TLS support is painfully, cripplingly limited. You simply *can't* use mail providers that have self-signed certificates or (more likely) have certs signed by a company private CA. Android doesn't support importing CA certificates at all. Android also lacks any support, of any sort, for managing user X.509 certificates (via the common PKCS#12 transport format or otherwise) so if you need to access web or mail services that require you to authenticate with a client certificate, you're out of luck.

Even if your mail provider happens to use a cert signed by one of the pre-installed trusted CAs you'll discover you can't even delete messages or mark them as read using the IMAP client, so you're wasting your time anyway. Guess they want you to give up and use GMail.

The whole thing is built around Google services and things like decent IMAP support are a hopeless afterthought. File manager? Nope, not in any useful sense. Open local HTML documents, PDFs, etc? Not really ( there's a clumsy workaround for the browser that kinda works, but doesn't provide dir indexing so it's pretty useless ). Decent desktop sync? Nope (you're using Google's address book, right? Right?).

Google seems even less interested than Apple does in making it a flexible phone for general use. I'd say part of the reason it's not doing great is because it doesn't do very much, doesn't do it very well, and really has few attractions or distinguishing features over cheaper mid-to-low-end S60-based handsets let alone high-end S60 phones and the iPhone. The SDK and dev tools aren't awful, but can't touch the iPhone, and just don't give you enough platform access, so app development is somewhat more limited. Experienced java devs will spend most of their time swearing at the butchered and cut-down JRE and libraries, and wondering where basic things like platform certificate services are (answer: there aren't any! Too bad!).

Right now, Android seems to be competitive with Nokia's Series 40 and maybe the older Windows Mobile phones, the Sony Ericsson phones, and some of the custom ones like the LG Prada. Pretty but limited, or just limited. It's really just not a smartphone OS yet.

It'd be nice to just run the agent in a VM and isolate your real system that way, but it wouldn't work because they'll almost certainly be filtering by MAC address.

What you _CAN_ do is run the agent on the physical host with a minimal OS install, and then put everything else in a VM. Have the VM connect through the real host using NAT, so it has the same MAC address as the real host. The network won't know the difference.