I'm releasing tools from my work that I developed for our operations.

We don't want to sell the tools - for the kind of money we could get for them in a market full of existing commercial options, it wouldn't be worth the trouble, let alone the sales and support overheads.

We could keep them closed in-house. There's nothing wrong with that and it's a viable option, but it means we give up the chance of sharing maintenance costs with others and benefiting from others' improvements to the tools.

Consequently, we've decided to open them up. This will permit competitors to use them - but most of our local competitors have already licensed expensive commercial equivalents they're committed to, so the only way they're likely to benefit is if we push pricing down across the industry, which isn't likely at this stage given that our tools are significantly less polished and more limited than the existing commercial offerings. It'd also permit new start-ups who wanted to compete with us to use them - but we're the dominant player in a mature and saturated local market with significant community loyalty. Startups have consistently failed despite having vast amounts of cash pumped into them by outfits who want to knock us out of the way and don't mind taking epic short-term losses to do it.

The upside of opening our tools up is that we're hoping to see participation from other companies and non-commercial publications, reducing the cost of ownership of our in-house tools, making them easier to maintain and less dependent on just one person in one company. That should help future-proof them for us if they're successful, and hopefully get us the use of contributed enhancements we wouldn't have developed ourselves.

IMO this is one area where OSS is really key in commercial use: when you need to build tools that help your business but aren't viable as a product.

All this is is a list of blacklisted IMEIs that's shared between most (not all) carriers. The phones are still perfectly functional when used in other countries with compatible UMTS/GSM frequencies, and on carriers that don't use the IMEI blacklist.

Some carriers do subscribe to the IMEI blacklist but take so long to update it that they might as well not. I'm looking at you, Vodafone.

Not only can stolen phones be sold overseas, but it's pretty trivial to rewrite the IMEI on many phones. This is a disincentive to casual theft, but not much more.

I *love* ISPs that block port 25 outbound... by default. It's a great spam control measure for Judy and Joe's unpatched Windows XP SP1 machine connected directly to the Internet via a USB DSL modem. Most ISPs, however, let you turn it off via a control panel offered for your service - if you know you want to and know enough to do so. Those that don't let you turn it off at all because they're trying to force you to pay them to unblock ports, they piss me off.

I relay all my oubound mail via a VPS at a reputable host - in my case, Linode, but many others would do. The VPS has a static IP allocated from space the VPS host has registered as used for hosting static customer services. Reverse DNS is configured to match the hostname it reports on EHLO and the hostname listed in the MX records.

That way I'm freed from all those annoying DSL/cable modem filter rules, and I get a secondary MX as part of the deal.

Out of interest: how do you find them? Scanning tools? manual inspection?

I don't run AV here, but I have AV software installed so I can use it for the odd system scan. I never turn anything up. I never see any evidence of virus activity, either, and I'm pretty used to spotting the signs thanks to experience fixing the home computers of users at work.

OTOH, it probably helps that my Windows installs have tended to last a year at the most before I reimage them for some reason or another (HDD failure/upgrade; OS upgrade; boredom; etc) so I'm rarely running a crufty old install.

Alas, right now I'm moving many services from RHEL to Windows 2008 Server.

Why? Group Policy, and Volume Shadow Copy Service.

I cannot overstate the importance of Group Policy in simplifying the management of a client network. Especially when combined with Windows Software Update Services, it's been wonderful. I've been a Linux guy since forever, but I'm really being swayed against my will toward the Windows server stuff for managing Windows clients.

As for the Volume Shadow Copy Service - it's all well and good to have 10-minutely Bacula incrementals thoughout the day, but nothing beats near-zero-cost snapshots that automatically age out when space is exhausted and that are very space efficient because they're done at the file system level. No, LVM cannot do this, it's block level and thus wastes a lot of space snapshotting changes to "free" space etc. Additionally, snapshots must be mounted, and old snapshots age out rather ungracefully. I've had a server fail to boot because of a broken LVM snapshot multiple times, and it's a major piss-off. It can't touch versioned files in NTFS. Maybe BTRFS will be there in 5 years.

Truly, though, it's Samba's quirks/limitations, and the lack of Group Policy, that's driven me to drop Linux for managing Windows clients. This isn't surprising, as Microsoft doesn't want to make it easy to manage Windows clients with anything other than Windows servers, and while the Samba folks are doing a heroic job there's only so much they can do.

Alas, Nokia kind of missed the boat with Maemo/MeeGo. They let Maemo idle for years on the no-cellular tablets that were interesting, but never really went anywhere. Then they tossed the N900 out the door - just as they decided to massively rework the OS, effectively EOLing the N900's OS before it was released. Unsurprisingly, app developer interest has been ... limited. *I* know you can upgrade an N900 to MeeGo (when it's properly ready, hopefully) but Nokia hasn't been too clear on this and it's unlikely app devs will want to target a platform where users have to reflash to a new OS to run their apps.

I love coding with Qt and have wanted it in phones for ages, so I was really excited to see Maemo move over - but the timing, amid a product launch, was horrifying.

MeeGo would've been great if it (instead of Maemo half-way through an API breaking transition to Qt) was released in finished form at about the time the N900 hit market. Now, by the time it sees real-world products, I think Android will be pretty much unstoppable, especially as it's now allowing native apps, the main advantage MeeGo had. I don't rate it's chances.

Personally I like MeeGo a lot more as a concept of how a phone OS works. It's my phone, not the carrier's / handset manufacturer's phone that I happened to pay for. Unfortunately, carriers (especially in the US) don't like that, and given the likely higher prices and limited app coverage of MeeGo, I don't see it going far.

Were I Intel and Nokia, I'd be thinking very hard about offering Dalvik and .apk support for apps without native code, at least for a subset of Android API features. Get some app coverage from the start, but encourage targeting of Qt by offering Qt Jambi from Java and offering better API access via the native interfaces. Be a better Android than Android.

It's pretty similar here in Australia. A distant friend of mine is, in fact, a convicted child sex criminal - because of photos of HIS CHILDREN taken WITH HIS WIFE THERE, in the BATH. A photo developer called the police, who seized his computers and media. They were unable to prosecute based on the original images, but the search turned up a collection of manga/hentai on a machine used by him and friends. Some of which "could be considered" to depict children, especially by a suitably encouraged jury. Bang, you're on the sex offender register and your life is fucked.

W.T.F.

Under Australian law, I could be considered a sex criminal if I accidentally include photos of partly clothed children in a wide-angle photo of a beach. Unsurprisingly, I'm now incredibly paranoid about taking photos - in fact, I flatly refuse to photograph anybody's children even with their permission or by their request. I'll let them do it, but only if I'm somewhere I can download the images, burn a CD to give to them, and destroy any copies I may have.

Sad, isn't it, that it's come to this. And all the fuss is further sexualizing children in people's minds, while doing NOTHING to even slow down the real perverts, who won't notice or care.

External access is - thankfully - locked down fairly tight. Otherwise I wouldn't mention it in any public forum, it'd be a big flashing "hack me, I'm stupid".

Users have IMAP and SMTP (both TLS, both requiring client certificates) and key-only sftp. That's it. There's no password-only auth for external access, it's all based on crypto.

Because users who "leave" the company tend to and doing patches of work for the company every now and then - and often do so remotely - I can't even assume that a user who's quit won't be working from home as a short-term casual six months down the track.

I find it's a remarkable incentive for keeping really good backups.

Personally, I've given up removing employee logins here. I rarely even lock them. We seem to have a revolving door, where employees leave and return all the time. Full timers leave, then return as casuals years later. Casuals leave, and years later re-appear as full time staff. The people responsible don't think this is in any way noteworthy, and don't give any warning when someone who's ostensibly left the company will be re-appearing. They just expect the user's login to still work. In that sort of environment, there's not much you can do exept sigh, sent a "not my problem" written warning to the boss, and forge ahead as best you can.

The pill ... because it's really, really, really cheap.

Anyway, I live in Australia so health insurance is much less of an issue - despite the government's best efforts. It'd probably go before broadband did, as broadband is way more important for holding a job.

Then I guess they're all rotten.

Dell: Numerous examples. I have one of them, the otherwise excellent XPS M1330 that has a defective nVidia 8400M GPU.

Apple: Numerous examples (including right now - iphone). The various iBook motherboard defects also come to mind.

nVidia: The afore-mentioned 8400M remained in production long after nVidia discovered the defect. They kept the defect secret for as long as possible, then when forced to admit it continued selling the faulty part without any warning for users and refused to talk about any arrangements they might've made with individual OEMs for RMA/warranty.

Acer: Frequently sells shoddy hardware and yells "la la la la" loudly when told about it. I have one of those, too, an Acer laptop with a fairly powerful GPU and a cooling subsystem for a basic one, so if you actually use it the GPU overheats and the machine crashes.

Hell, the list is basically endless. Everyone does it, because the consequences are small compared to the profits. Unless that changes, it'll keep on happening, too.

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.