This C|Net article asks whether Netflix is killing DVDs "like Apple killed floppies".  And paints it as a good thing.

Well, first of all, it wasn't Apple that killed floppies.  Floppies stayed around long after Apple stopped including floppy drives.  The pretensions of the Mac faithful notwithstanding, Apple is far too much a niche player — especially in business — to have the power to singlehandedly kill the floppy disk.  What killed the floppy was the rapidly increasing size of data such as digital camera images etc (and the increasing penetration of new forms of digital data, notably MP3 music), rapidly dropping prices on optical media, and increasingly universal availability of write/rewrite capable optical drives combined with improving software integration that made it possible for just anyone to use them.  Apple dropping the 3.5" floppy drive from the blueberry iMac was, in the larger scheme of things, a complete non-event.  When your mother could drop a blank disc in the DVD burner and drag a video of the grandkids onto it from her camcorder, and have it just work ... THAT'S when the floppy disc's days became numbered.

But let's talk about his premise that Netflix is killing the DVD, and that it's a good thing.

Well, sure.  If Netflix isd able to kill the DVD, it'll be a great thing ... for Netflix.  And for the studios; it'll get them closer to their dream of you having to pay for your entertainment every time you watch or listen to it.  But for anyone else?

Oh, no, it won't be good for the rest of us.  Now, we can have our physical media.  We can buy the disc once, and watch it whenever we want. Even when our ISP is having technical problems, or there's an outage somewhere and the 'net is crawling.  We can buy it, rip it, and put it on a portable device to watch it or listen to it when we're away from a network connection.

But in an all-streaming world?

Oh, yes, Hollywood and Netflix would love that.  They'd get to charge you for every time you watch the movie.  Every time you listen to the song.  What, you want to watch that movie at your vacation cabin up in the mountains, but you have no broadband up there?  Too bad.  Want to listen to music while you work, but you work in a steel-framed building that jams your 4G connectivity, and your employer doesn't allow music streaming using company resources?  Tough. Want movies in the back seat to keep the kids quiet on the seven-hour drive to Grandma's place out in the country?  Sucks to be you.  Want to watch some niche art film from France that's never sold enough copies to make it worth Netflix's trouble to add it to their catalog?  Serves you right for watching that artsy-fartsy foreign crap. Shut up and stream Transformers 7 in 5D.

Choice.  Now that's good.  A choice of media.  A choice of how you access what you want to be entertained by.  Use the one that works for you.  Stream the movie you figure you'll only bother to watch once.  Buy a physical copy of the one you rewatch about twice a year, or the one the kids watch about twice a month.

But if streaming is all there is?

Come on.  We're talking about Hollywood.  If streaming is the only way you can watch movies any more, how long do you really think it'll be before it costs as much to stream the movie once as it costs to buy the disc now?

I've had it four full days now, and I have to say, it's pretty good. I'm not convinced yet it'll make as good a phone, in terms of voice clarity, as the RAZR2, because the open RAZR is ... well ... more phone-shaped.  I suspect the Droid, like most of not all modern smartphones, will be of limited use as an actual phone without a headset.

Well, that's why I had the foresight to buy a headset with it. An inexpensive, corded one, for now; I really don't use a cell phone very often.  Seriously, we're talking in the region of six hundred minutes or less per year here.  I expect I'll be using the headset whenever possible, and perhaps may eventually get a better headset than the minimalist wired earbuds-plus-inline-mic one I bought to start with.

The screen is nice; large, bright and sharp.  The physical keyboard is pretty good, considerably better than the keyboard on the HTC Merge, previously the holder of the Best Keyboard On A Phone title.  You can actually realistically type on it, and with a pretty low error rate.  (No "damn you, autocorrect".)  Battery life so far seems promising; it looks like I should be able to expect 2+ days from the stock 1450mAh battery, in normal use, and probably about three days from the [optional] 1930mAh extended battery.  Using it for navigation is harder on the battery; the Google navigation works great, but the GPS receiver is power-hungry. Of course, if using it for navigation, one can use the optional windshield mount and plug it into a 12V USB charger, which you'd probably want to do anyway because if using it for navigation without a human navigator/co-driver you'd (a) need it mounted, and (b) need to turn off screen timeout.  I did have to hard-powercycle the phone (power off, battery out for ten seconds) to get the GPS receiver online for the first time.

As for charging, when connected via USB, Gentoo Linux sees it without any hesitation as a 12GB USB-storage device (with about 1.75GB free) and it happily charges, unlike the Motorola RAZR2 it's replacing (which neither mounts as storage nor charges from a Linux box).  There are actually three charging options — direct USB connection, included wall-socket USB charger, or an optional inductive charging pad and back cover.  The inductive charging back will accommodate the extended battery.

The Droid3 comes with the usual Verizon V-cast applications and a bunch of preinstalled apps, many of which I don't give a crap about (like for instance some Mobile NFL thing). Unfortunately few of them are uninstallable.  I uninstalled the WGA golf game immediately (puh-leeze!), and would have ditched the Mobile NFL app as well if I could (I mean, me?  NFL?  Seriously?), but the only other preinstalled apps that appear to be uninstallable are the Youtube app and 'Nova', which has nothing to do with the PBS documentary series but instead appears to be a trial version of a Halo-alike FPS game.  (I uninstalled it too.  I have no desire to try to play anything remotely FPS-ish on a screen this tiny, particularly through a phone touchscreen interface.)  So far, I've installed a GasBuddy app and ColorNote, a notepad app with a reasonably well thought-out checklist feature.

The built-in cameras?  Not bad.  Here's a sample from the main (back) camera (quarter scale, click it for full size):

And here's the front camera, intended for videoconferencing, full size:

(Trust me, it's not the camera's fault.)

Things I'd change?  Well, I wish the corporate sync didn't force a screenlock password on me.  I prefer to choose for myself when I lock it, thank you.  And it'd be nice if there was a display timeout choice between two and ten minutes.  A five-minute option would be good.  Getting the back cover off is a bit of a pain in the ass, but you shouldn't need to do that often.

Oh, hey, I know what I forgot to talk about:  The voice recognition.  Specifically, voice-recognition navigation mode, which was the first thing I tried voice command on.  Untrained, it got "Nashua, New Hampshire" on the first try.  Later, we tried "Go home".  It got that in one try as well, but didn't know what to do with it.  Our street address, it fluffed on the first attempt, but got it perfectly when repeated slightly slower. No doubt it will do even better once I actually go through and train it.

Important PSA for Gentoo users:

If portage updates you to x11-base/xorg-server-1.10.2, YOU MUST MANUALLY RE-EMERGE ALL OF YOUR INSTALLED X11 DRIVERS.  Portage will not do it for you automatically because it does not know that the ABI has changed.  If you do not do this, X will fail to start.

Here's a one-liner to do the job:

emerge -1 $(eix -I x11-drivers/* | grep x11-drivers | awk '{print $2}')

(For clarification, there's nothing new about major version bumps in X.org changing the ABI.  On most previous cases, though, such as when 1.7 and 1.9 came out, the postmerge notes on the ebuild either noted that the ABI had changed and all drivers needed to be rebuilt, or pointed to the postmerge notes on the main X.org site, which told you the same thing.  This time, however, this advisory was omitted for some reason. So, if you don't happen to remember that the version you're updating from is NOT a 1.10.x subversion, you can find yourself with an X that won't start.)

We've all heard lots of examples of security breaches, most recently Sony's entire PSN gaming network getting totally 0wn3d and virtually every bit of user credential data stolen including credit card data.  Some companies handle it well.  Some handle it poorly.  Sony actually reacted relatively well this time, shutting down PSN until they'd cleaned and re-secured it, publicly owning up to the breach, and notifying all their customers.  After the Hannafords data breach a couple of years ago, RBS Citizens Bank pre-emptively replaced all customer debit cards that had been used at a Hannafords store, just in case they might have been compromised.  (This not only protected customers, it made sound business sense too; it's cheaper to preemptively replace a bunch of cards that would have been replaced in the next year or two anyway, than to clean up fraudulent transactions later and possibly eat losses of anywhere from hundreds to thousands of dollars per card.)

Other companies haven't handled it so well.  I'm not naming any names, but there have been companies which it has transpired have suffered massive customer data breaches and simply didn't bother to tell anyone until they were outed, and other companies that only notified their customers of breaches in states where the law forced them to do so.

Here's an example of doing it right.  Lastpass.com is an online password-keeper service.  On Tuesday morning, they noticed a network traffic anomaly during routine (for them) analysis of network traffic logs.  They couldn't be certain what it was; but they couldn't be 100% certain that it wasn't evidence of a breach.

So they played safe, and handled it as though it was.

In this case, we couldn't find that root cause.  After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server).  Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed.

A lot of their customers are complaining about being forced to change their master passwords.  But this is the right way to handle a possible security breach.  If you cannot rule out a breach, you study the evidence you have, you figure out the worst probable case consistent with the available evidence — and then you handle it as though that worst case happened.  Because in the long run, it's MUCH safer, and much less expensive, to assume you were breached and later find out that you were not, than to assume you were not breached ... and later find out that, actually, yes, you were.

My gods, Telstra could teach even Verizon an entire trunkload of tricks when it comes to crippling phones.  I recently bought an unlocked Motorola RAZR2 V9, and, yes, sure, it's unlocked, it works with a T-Mobile SIM card, but holy Hastur in a merrywidow, even the damn PHONE MAIN MENU is locked out.  'Setup' allows you to do one thing:  enable or disable the Bluetooth indicator.  Not Bluetooth, mind you — just the indicator.

What in the name of all good bits does Telstra expect their customers to use their phones as?  Clubs?

Anyway, right now I'm in the process of trying to reflash the phone with new, generic Motorola firmware. Also, shaking my head at the sheer stupidity inherent in Motorola's software update tool, which will only update the firmware of a phone that is still within its original warranty.  Planned obsolescence...?

Coming soon to a fiber near you?  Interesting reading.

Specifically, for yet another "clever" Apple technology with unintended consequences.

You see, ever since getting my new machine up, I've been noticing a really excessive amount of clock drift relative to my internal stratum-3 network timeserver.  Like, six seconds per day of clock drift.  This is really bad considering I'm running ntp.  The old babylon5 had some clock drift, but never this bad.

Today, I finally found the problem.  And the problem is that mDNS is shooting me in the foot.

mDNS is Apple's multicast DNS technology, and certain Linux packages — CUPS, for one, also created at Apple — are really rather difficult to persuade not to use it.  But when you install it on linux, it never gets properly configured.  The file /etc/nss-mdns.conf — which should contain a list of domains for which mdns SHOULD resolve IP addresses — is not created, and the package doesn't tell you that you should.  What's more, there's no documentation installed on doing so.

Now, this shouldn't be a problem.  You see, here's what should, if mdns were reasonably designed, happen when, say, ntpdate tries to synchronize to a timeserver:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, no domains for me to resolve, nothing for me to do here", and passes the request to DNS.
4. DNS looks up the address, passes it back to ntpdate, and ntpdate makes the connection to the correct server.

But, Apple being Apple, this is what REALLY happens:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, there's no list of domains for me to resolve, but you didn't explicitly tell me NOT to resolve anything, so here, LET ME GIVE YOU SOME RANDOM IP ADDRESS THAT I PULLED OUT OF SOMEONE ELSE'S ASS BASED ON MY OWN HIDDEN COMPILED-IN DEFAULTS.  It's not even REMOTELY in your network, but what the heck, what you don't know won't hurt you, right?"
4. "Gee, ntpd is running, but my clock's still wrong.  How can that happen...?"

Apple has from time to time come up with some very good ideas.  The aforementioned CUPS, for example, works very well.  My opinion of Apple would, however, be rather less jaundiced did it not so frequently appear that when designing or implementing a technology, Apple looks at what the rest of the world is doing, then deliberately does something incompatible.¹

I disabled mdns in /etc/nsswitch.conf, restarted ntp, and SHAZAM!  Magically, just like that, my machines' clocks are perfectly synchronized.

[1]  Possibly the classic example of all time² is Apple's proprietary Appletalk network protocol, in which network address assignment is basically accomplished by jabbering.  In every OTHER network protocol that I'm aware of on the face of the planet, jabbering is considered to be a severe networking failure.  This is why, whenever an Appletalk network exceeded a certain rather small number of nodes, nodes would start just randomly dropping in and out of view on the network.  There was nothing you could do about it.  You couldn't fix it.  Apple eventually sort of fixed it, by creating Appletalk Phase II, which divided networks up into zones, and an Appletalk device could only talk to other devices in the same zone that it was in.  This didn't fix the problem, but it sort of alleviated it.  Somewhat.

[2]  Though a close runner-up is the Apple one-global-system-menubar metaphor, which was bad enough on single-monitor Macs, but really broke hard when Macs started being able to handle multiple monitors.  A list of everything that's wrong with the single-system-menubar metaphor would be a post of its own.  Yet twenty years on, MacOS users are STILL stuck with it.³  Apple insisted that This Was The Best Way To Do It, because they had called in Efficiency Experts.  What I've always wanted to know is, did the "efficiency experts" know anything whatsoever about using computers in the real world?

[3]  The saddest part is, they don't care, because The Steve Has Decreed That It Is Good.

Sergei Shevchenko decodes a multilayered, multi-version matryoshka trojan hidden in a Flash video.

When this master exploit encounters one of these twelve combinations [of platform and Windows version number], it will unpack the string by interpreting it as a hex-encoded byte sequence, and then reload this code as a Flash file via loader.loadBytes().  I don't believe it:  A Flash file which is decoded dynamically and then loaded proceeds to load another dynamically created Flash file from a repertoire of twelve strings.  But it's true.  When I copy the first string into my hex editor, I can clearly detect the structure of a, this time uncompressed, Flash file.

That's what I call professional!  The various versions of the Flash environment differ to such a degree that exploits which rely on specific addresses only cause the Player to crash, which doesn't serve the attackers.  Therefore, they either have to write very generic shell code – which is quite difficult, or they arm themselves with an arsenal of very specific exploits and then choose the one that fits the respective Flash Player.  Quite obviously, our little criminal has chosen the easier way and is carrying a whole arsenal of weapons.

[...]

And that malware authors now use the obfuscation strategies already known from conventional Win32 malware in virtual environments such as Flash is bad news for the anti-virus vendors.  Because it ultimately means that AV vendors will from now on also need to emulate the run-time environments of JavaScript, the .NET framework and Adobe Action Script to reliably detect malware.

This is a very clever exploit.  And I seem to find myself saying that altogether too frequently of late.

The first generation of malware was one-off exploits, frequentyly fairly simple, put together usually by single individuals who launched them themselves for the notoriety, for extortion, or just to see what they could wreck.  The second generation was the polymorphic virus development toolkits that let basically any black-hat wanna-be build a virus with a handy point-and-drool interface, and fast-spreading blitz worms like Code Red.  And the third generation...

Well, the third is sophisticated, professionally-crafted attacks like this, like Stuxnet, like Conficker.

The world has changed.  Again.  And not for the better.

OK, so the Conficker worm was smart and scary (though it ultimately appeared to fizzle; there is still speculation that it was a proof-of-concept).  It looks like Stuxnet might be scarier, in its own way.

Stuxnet makes use of two compromised digital certificates and four known zero-day Windows vulnerabilities; selectively uses a fifth vulnerability (the same one exploited by Conficker) on its target systems, where they're likely to be unpatched; it can infect a system running any version of Windows from a USB stick, upon insertion, with no additional user action required whatsoever; it limits the number of systems it infects, to try to avoid attracting attention; it specifically looks for SCADA systems to take over; and it knows how to reprogram SCADA systems.  The term "cyber missile" is being used to describe it.  It appears to be incredibly specifically targeted; it "fingerprints" systems that it infects in order to identify its target, looking for specific code in specific locations on specific programmable logic controllers, but there are no clear indications whether it has found its target yet.  It leaves systems that have the wrong "fingerprint" alone and doesn't interfere with them.  There is apparently speculation that (a) it's too sophisticated to be an "amateur" effort, (b) that it's possibly targeted at Iran's Bushehr nuclear reactor, and (c) that it may have already done its work — as Bushehr did not come online in August as it was supposed to, which Iran has explained away as "hot weather".  (Hot weather preventing a facility in Iran from coming online?  That sounds a bit like a ship not being launched on schedule because the ocean was wet.)

Links: Computerworld, Christian Science Monitor, a second CSM article, NetworkWorld, and Knowledge Brings Fear (blog; the author thinks it is targeted at Iran's uranium-enrichment centrifuges rather than at Bushehr itself, and cites Wikileaks and the BBC for supporting evidence).

(via bruce_schneier_feed)

Sometime about 0440 Sunday morning, my main server, babylon4, went down hard and fast.  I still haven't been able to reconstruct a single thing about what actually happened, but it left the machine down, with the boot archive corrupt and the boot blocks completely gone.  The last thing logged before it went down — about half an hour before — was Apache2 logged some probably-acne-ridden git trying in vain to probe for phpMyAdmin holes.  (It's not installed.  Neither is PHP.)  Just to add a weird touch, whatever happened apparently sent a break over the serial console line to epsilon3 and halted it too.

I didn't discover this until I got up on Sunday.  I fairly quickly discovered that all of the ZFS filesystems and their data were completely intact; the system just couldn't be booted.  I spent essentially all of Sunday trying various different ways to repair the boot blocks and boot archive, not one of them successful.  I managed once to boot it by hand using the grub on a Solaris 10 install DVD and the failsafe miniroot from my Solaris installation, but that wasn't any help because ZFS on-disk had been patched to a newer version than originally installed and the ZFS patch didn't patch the ZFS drivers in the miniroot.

Well, I never got around to live-upgrading the machine to Solaris 10 u8 10/09, anyway.  So on Sunday I backed up the user-data filesystems in the root ZFS pool over to the main array pool using ZFS snapshots, blew away the root pool, and reinstalled 10/09 from scratch, then on Monday morning set about reinstalling third-party packages and reconfiguring the Solaris ones the way I wanted them.  I had a few minor fights with smf, the Solaris Service Management Facility, but after it saw reason and agreed to do things my way, I had most of it all set up and running again Monday night, and finished setting up the last group of services today.  Thanks to the ZFS snapshot gambit, I didn't lose a single file or configuration setting.

Of course, being a prudent sort, right now I have a fresh set of full backups running.