"New" Xbox Experience

Microsoft pushed out a major software update to the Xbox 360 recently. The "New Xbox Experience" (NXE). Basically a new UI, but some added functionality too.

The main new piece of added functionality from my point of view is access to streamed Netflix movies. This would be sweet, except Microsoft expect you to not only have a Netflix subscription but also to have a paid Xbox Live subscription. Thanks, Ballmer, but no thanks. I bought a 360, and I'm already a Netflix subscriber, and I honestly don't see why I owe you anything. Especially since you won't even let me watch crap off youtube on the 360. As far as I can tell, you want me to find some other way to watch video. Fine by me.

The most noticeable change is the new UI. Neither I nor the missus like it. We both admit that it's mainly because we were familiar with the old UI, see no advantages to the new UI, and both wish we didn't have to relearn shit just because Microsoft arbitrarily moved stuff around. We'd already learned to cope with the old UI, and the transition cost seems pretty high for no discernible gain. Personally, I've given up and reverted to the subset of the old UI that's still available via the guide button.

If you've been streaming mp3s to your 360, you'll be disappointed to find that the NXE is every bit as shit as the old experience. There's no caching of the album/artist/song lists, and it's every bit as slow at building the menus, so if you've got a music collection large enough to be worth streaming, you'll still find yourself spending too much time staring at the "please wait" screen. (Which they did waste time updating, of course.)

Tracks within an album are still "helpfully" sorted into alphabetical order, and there still doesn't seem to be any way to get the proper order, so if you were planning on listening to classical music, or anything where one track leads into another, you're still screwed.

And there's still no on-screen keyboard for iTunes-like filtering. Yeah, I know an on-screen keyboard would suck, but it would suck a lot less hard than One Big List. Seriously, dudes, you can't navigate a multi-thousand item list. Not even if it is sorted alphabetically. Given that the best^wbiggest speakers in the house are connected to the 360, I would probably splash out on the little keypad if I thought I could use it to get a sensible interface. Hell, the damn remote, which I did buy, went from dildo proportions with the original Xbox to full-on police baton proportions with the 360. I use about 13 buttons (play, pause, eject, left/right/up/down, OK, info, a/b/x/y) of the 46 buttons on that thing. By my reckoning, those Redmond bastards could have fitted every letter of my alphabet on the remote and still had room to throw in a few accents to keep the French Canadians sweet.

(The 360's "visualizations", by the way, are an interesting contrast with Apple's iTunes ones. Microsoft has some nice variations on the usual themes, their "water-splashed inky line" one being my personal favorite until it starts spinning, but overall their intent seems much harsher. There's a distinct "bad trip" vibe to some of them. I especially hate the Melting Charred Lizard Corpse and the Spinning Klingon Blade Thing and the Big Staring Eye and I'm not even going to mention the Journey Up The Brown Canyon because it scares the poop out of me. What were they thinking? And where was the adult supervision they so desperately needed?)

But the most obnoxious new feature is their crappy avatars. They're more serious than the Wii's, and less creepy-zombie-pseudo-realistic than the PS3's, but they make no sense. Why do I need to create a bloody avatar when I'm about to play a game? A game where my appearance is chosen for me anyway? (And, no, I don't think Halo 3 would be improved if Master Chief were replaced by a little cartoon white guy in glasses and the nerdiest clothes available. I think this is a rip-off of functionality that made some sense on the Wii but makes no sense in its new home.)

While I found creating an avatar a pointless chore, the missus was quite keen. She likes that kind of thing in RPGs. The NXE was a disappointment to her, though, because the choices were so limited. None of the faces look anything like her. None of the clothing looks like anything she'd wear. It's bad enough if you're male and don't dress like some generic TV "cool teenager", but if you're female you might be surprised to find that there's neither a single skirt nor a single dress to choose from, and you don't have control over the clothing's coloring. If you like a design but don't like the colors, well, screw you. Oh, and if you're female, you might assume you get some control over your avatar's body type, but you don't. You get the body of an androgynous teenage boy, which you can make skinny or fat, tall or short, but that's it. If you were planning on any curves that wouldn't look out of place on an androgynous teenage boy, we regret to inform you that won't be possible.

Doubtless you'll be able to purchase all this crap at some point, which only reinforces my personal feeling of "you bastards!".

My original intention was to be a small white ball of healing light (and, thanks to Guilty Spark, I didn't consider this an unrealistic intention). Unfortunately, Microsoft seems to think that Xbox gamers (a) are humanoid – a not unreasonable assumption – and (b) wouldn't look out of place strolling the catwalk at Milan fashion week — which sounds like more of a stretch.

Why am I bothering to mention the NXE at all? Because I think it's interesting in relation to Chen's "The Old New Thing". This, I think, is a glimpse of what Microsoft would be like if their customers weren't corporations. This is what Microsoft is like when their customers will accept any necessary shit just to play their DVDs/games.

Those who wish Microsoft weren't so tied up with backwards compatibility might want to be more careful about what they wish for, in case it should ever come to pass.


tail -F

I've been a fan of Unix since I was a little kid with no access to Unix. I'd read books about Unix, borrowed from the "big city" library I'd sometimes get to visit as a treat.

I've used many Unixes since, mainly Linux these days, but I'm old enough to have grown up on commercial Unixes and Plan 9. And although for years now I've found it unbearably frustrating to be stuck on a system that uses some non-GNU variants of commands (Mac OS, mainly, but I sometimes run into undead Solaris zombies), I'll be honest: this GNU stuff is still new to me.

Unlike many of my peers, it wasn't all the fancy extra options that drew me to GNU userspace; it was the absence of fixed-sized buffers. Those old Bell Labs guys loved their fixed-size buffers, and it was a constant pain in my ass that accidentally pushed me into using Perl: I just couldn't trust pre-GNU awk(1) or sed(1) or whatever to cope with "long" lines. (And don't imagine they'd cope gracefully, either. I'm talking buffer overflows, because who could possibly have a line longer than, say, 512 characters?)

One side effect of my non-conversion is that I'm generally ignorant of GNU extensions.

POSIX tail(1) has a -f option ('f' for 'follow') that does its usual job of showing you the last few lines of the file, but then keeps running so it can show you all new content appended to the file. This, as you probably know, is really useful, especially for log files.

My problem is that I keep restarting a program that creates a new log file each time it runs, with the timestamp encoded in the filename. It helpfully creates a symbolic link to the most recent log file, but traditional tail -f opens a file descriptor and, to implement the -f part of its functionality, keeps calling fstat(2) to see if the file pointed to by the file descriptor has changed size, and if it has, it copies the new content to stdout. This, obviously, doesn't work in my case, because I care if the symbolic link changes too, and want to start following the new file.

I finally got sick of "interrupt, up-arrow, return" yesterday, and was about to write a simple script when I realized I should check GNU tail doesn't already have such functionality. And, of course, it does: tail -F. This re-opens the original path if the fstat(2) shows that the file is a different file (recognizable by an inode or device number change).

Why are both useful? Well, you want tail -f if your path might be renamed or unlinked but you still want to read it (remember that an unlinked file continues to exist as long as some process has an open file descriptor for it). And you want tail -F if your path might be renamed or unlinked or replaced by a different symbolic link and you want to switch to reading whatever file (if any) comes along to replace it.

Personally, I think I'm going to start retraining my fingers to use -F because I think that's my more usual use case. YMMV. And apologies to the youngsters who already knew all this, but I'm pretty sure I'm not the only dinosaur still wandering the earth.


Review: "The Old New Thing"

If you waste your time reading crap on the internet (as you clearly do), you've probably come across Raymond Chen's blog "The Old New Thing". You may also be aware that he wrote a book with the same title, and, for all I know, it's something all Windows programmers have read.

I, though, am "one of those condescending Unix computer users".

I've used Windows on and off since 1993, but I've only used Windows out of some kind of necessity. It always seemed to me to be badly designed and obscure and cluttered with legacy crap, and I might try to use that as an excuse for not liking Windows, if it weren't for the fact that you could say the same things about Unix. It may be that the real difference is just that I'm much better versed in the bad design and obscurity and clutter of Unix.

I don't actually believe that, but doesn't matter anyway: the fact is, Windows exists, and Windows is huge. One reason I've never been convinced by the argument that "Linux will win the desktop because it costs nothing, and people love not paying for stuff" is that you don't have to strike up too many conversations with strangers to find that the man on the street considers Windows (and MS Office and the like) to cost nothing either. Software either comes with the computer (and they get a new version when they get a new computer), or, if they're really keen, it comes from work or a friend.

People proudly tell me they copy Windows, which I've always found strange on many levels. But that in itself tells you something about Windows' ubiquity and how it's perceived.

Ignoring Windows is like ignoring religion. You may personally think it's a load of shite, but you can't deny its influence, and that influence alone makes it worthy of study.

Although I sometimes read posts on Chen's blog when they're linked to from places I read, and I was aware of the book's existence, I hadn't been curious enough to go out and buy "The Old New Thing", but I saw a copy on a shelf at work, borrowed it, and read it over this past weekend.

I loved it. It's full of random stuff from a perspective quite different from my own, but with an obvious shared heritage of double-frees and memory leaks and performance problems and so forth. There were whole chapters I basically skipped over (chapter 15, "How Window Messages Are Delivered and Retrieved", for example), but the range of the book is sufficiently diverse, and Windows' influence so far-reaching, that there's bound to be something of interest.

Topics range from memory allocation (and problems all the way from 16- through 32- to 64-bit), concurrency primitives, text rendering, debugging, reverse engineering, to why various Windows features/APIs are the way they are.

I liked the debugging tips slipped in here and there; the kinds of things you learn on the job rather than in class. "The poor man's way of identifying memory leaks", for example, talks about just letting a program leak away, and seeing what the heap's full of. And the fact that the caller whose allocation attempt causes your system's out of memory failure is probably responsible (despite your temptation to assume innocence unless proven guilty). And that the former can help you confirm or deny the latter. These are the kinds of things that aren't usually considered academic enough to be written down, but are still bloody useful.

Sure, you and I know that one, and probably most of the other debugging tips in the book (though there were also common Windows API mistakes, and thus fairly meaningless to me), but we also know people who still don't know this stuff, and we can probably still remember the time when we didn't know it either.

If, on the other hand, you're thinking "dude, get better tools", just wait: one of these days you'll be looking at a customer's production system, or looking at a postmortem, or a system too large or new or small to be able to afford better tools.

The Windows-specific stuff is sometimes a bit annoying, but it's only to be expected in a book like this, and it's not too hard to work out what's going on. For example, it seems like Windows uses the terms "brush" and "pen" for something like (but not exactly the same as) Java2D's Paint and Stroke respectively. It's easy enough to work out, and the (surprisingly few) sections that are obviously of no relevance outside Windows itself are easily skimmed over.

The book opens with a chapter of anecdotal examples of the kinds of lessons the Linux desktop still needs to learn. It's interesting at many points in the book, in fact, to contrast the three camps. Chen usually only talks about the Windows camp, for obvious reasons, and their position can seemingly be summarized as "we started this a long time ago, on really crappy hardware, and we know better now, and try to do new stuff in a way that shows we've learned some of these lessons, but our business is selling OS upgrades, and every incompatible change we make costs us a sale, so we go to ridiculous lengths to avoid ever breaking anything, even stuff that only ever worked by coincidence, or that deliberately went out of its way to fiddle with undocumented internals".

Mac OS is pretty much at the opposite end of the scale, with "we know that you can't make an omelet without breaking eggs, so eggs will be broken if we consider it to be in our greater good, and you get about one year of deprecation and the year after that, your code breaks; we're a hardware company, so we know people will buy the new release anyway, even if only because it comes 'free' with your next machine, but actually, they'll probably buy it anyway, because our main customers are individuals, not corporations, and they like shiny new stuff and don't have any DOS applications written in assembler in 1982 that they've long since lost the source to".

Linux? "Nothing really works very well yet, but it's free and Free, and you can fix it yourself, and it doesn't matter anyway because next week we're going to rip out all this half-working stuff and replace it with stuff that fixes a few things that currently don't work while at the same time breaking things that did work; it doesn't matter because we don't have customers, and our non-customers don't have any software they don't have the source to anyway".

Of course, you never hear these philosophies stated explicitly like that. Apple's too secretive, no-one can seriously claim to speak for "Linux", and I've no idea whether Chen is really representative of Microsoft, assuming it's any more possible to be representative (in the non-legal sense) of a company that large than it is to represent "the Linux community". But Chen has a clear voice, and it's an interesting perspective to me, especially presented through the course of a book, rather than in bits and pieces as I read occasional linked-to blog posts.

If you want just one contrast, try this, from "Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT" (someone spank the editor who changed == to = there!):

... This allowed people to write a single program that got the Windows 2000 look when running on Windows 2000 and got the classic look when running on older systems. (If you make people have to write two versions of their program, one that runs on all systems and one that runs only on the newer system and looks slightly cooler, they will usually not bother writing the second one.)

This, to me, was a revelation. By "people", he means, of course, "Windows programmers". But how interesting that, from my position outside the Windows camp, I actually did a double-take when reading his parenthetical comment. Surely, I thought, he means they won't bother writing the backwards-compatible version? Let the dead bury the dead, and all that? Isn't "looks slightly cooler" an important selling feature, even for Windows (the OS)?

Try to find a Mac application (that's still maintained) that still runs on 10.2, say, and you'll not have much luck. Try to run the latest version of a Linux app on Ubuntu 8.04 (the "long-term" release that some people will be stuck with until 2010-04) without resorting to building it yourself from source... and even then, you'll probably need to build the latest versions of umpteen different libraries it depends on.

I was well aware that Microsoft bend over backwards to keep stuff working (and I was disappointed that Chen doesn't actually go into much detail on the techniques they use, which was something I would have been particularly interested to read about), but I didn't realize the backwards-compatibility-above-all mindset extended to third-party developers too, or is at least perceived to do so.

Going back to some of the other topics, I was interested to hear both that Windows gets the old "pointer change without mouse movement" problem right, and how, and that it causes complaints (presumably from people who haven't suffered systems that get it wrong), and that no-one appreciates the effort much because the related "pointer change when a component scrolls under the mouse" problem needs to be solved per-application, and often isn't. I've always hated programming for systems that won't even let me get those details right, and it's interesting to hear a Windows programmer ("of all people!") saying how much he hates it when apps don't get those details right.

The weird part is that in the final chapter of the book he mentions several "funny stories" that are actually just annoying bugs in Microsoft software, but which he seems to see as cases of user error. It's almost like the last chapter is written by a different person, that depressing guy you always imagine works at Microsoft, cranking out shit code with a shit UI and with no interest in rising to the challenge of writing something that works well under all the awful constraints imposed on it, but who's just interested in getting all the relevant forms filled and boxes checked so he can move on to the next task he also doesn't care about.

Maybe Chen is that guy, at times, and his editor asked for an extra 20 pages Chen didn't want to write? Maybe we're all that guy at times, though most programmers I've known tend to be good at losing tasks in their to-do lists, because there's always more stuff to do than there is time to do it.

What else did I like? I liked the repeated mentions of the need for a holistic view of performance: that making one thing better at the expense of some other thing isn't necessarily a good idea. There are repeated reminders that it's bad to assume that your application is the most important application in the user's day, every day. (You'd hope this wouldn't even need mentioning, but everyone who's ever used software knows it does.)

Speaking of things that shouldn't need mentioning, I was amused to see an analog of something I first came across in a Studs Terkel interview with a Republican ex-governor of a state like Montana. This old Republican was criticizing modern politicians on both sides, complaining that they'd lost the insight of looking at any new legislation as if it had been brought up by the opposition for the opposition's own use. His point being that at some point, anything can and will be used against you. And if you don't like the look of it from the unfriendly end of the barrel, maybe you ought not be handing it out in the first place. Chen's version is more like "what could a virus writer do with this API?" or "if I was a user, how could a developer make a really annoying application with this API?".

One of Chen's code snippets had me mystified. I'll ignore the use of SIZE_T instead of size_t and assume I don't want to know, but there was a bit of C++ that contained this:

// Since this is just a quick test, we're going to be sloppy
using namespace std; // sloppy

The code contains three lines that would need an explicit "std::", none of which, with the "std::" added, would be as long as the "sloppy" comment. Bizarre. And a missed opportunity to show a handy trick I learned from Martin Dorey. Don't want to keep repeating std::cout (which were two of the three uses of "std::" in Chen's code)? Do this:

std::ostream& os(std::cout);
os << blah;

This is nice even in code that's "just a quick test", but it's better still when that "quick test" turns into production code, and you need to refactor so you can pass in an arbitrary stream. Your code is already referring to just "os" (the usual name for an ostream), so all you need to do is turn the local "os" into an extra argument. Job done.

Returning one last time to things I liked, there was an explanation of why NTFS keeps a Unicode case mapping table on disk, which is something I'd wondered about, but obviously never enough to ask. And the weird code I just mentioned was actually in a section titled after the only thing I knowingly quote from a Microsoft developer, Rico Mariani: "a cache with a bad policy is another name for a memory leak".

Would I buy this book? No. It's not a classic, or a reference work I can imagine I'd keep coming back to. But it was an enjoyable read, and an interesting insight into a parallel universe. Borrow.


Nice one, Adobe!

I find it interesting that, though I'm actually sincere, the title sounds like sarcasm.

I'm sure you've already heard because it was big news today: Adobe released an alpha 64-bit Flash player today, for Linux (amd64 only), and Solaris (amd64 and sparc). Here's my "added value": I was stupid enough to try it, and can tell you how I got on.

It works.

I'm watching some of the low-quality video crap that clogs up the intertubes in another window right now, even as I write this low-quality text crap which I'll bung into those very same tubes shortly.

I needed to "sudo apt-get autoremove gnash" before Adobe's player would work (the symptom being that I'd click on FlashBlock's icon, and the space reserved for the embedded Flash player would shrink to nothing), but that's fair enough. Thanks to the sheer number of non-functional Flash players I'd tried in earlier attempts, it was quite a hassle to find and remove them all, but that's not Adobe's fault.

I've never had Flash work on 64-bit Linux before. And not for want of trying. I know people who claim they have had working Flash on 64-bit Linux, but I know more who've had as little success as me, and even the "successful" ones will admit to unreliability.

Installation is as simple as a "tar zxf", a "mkdir ~/.mozilla/plugins", and a "mv" of the former file to the latter directory. If you're a Mac or Windows user, this might sound awful, and in a way it is, but the usual instructions for getting Flash working on 64-bit Linux (a) involve sacrifices of rare animals and (b) don't actually work. And you have to realize that if they'd tried anything more fancy, the users of some Linux distribution you've never even heard of would be complaining that there's no package suitable for their homebrew package manager.

As a sign of my gratitude, next time I'm strolling past their headquarters, and the missus goads me by saying "Adobe" out loud, I'll refrain from my usual response of "wankers that they are, cranking out shite".

Provided, that is, I don't encounter Acrobat Reader or any of their installers in the meantime...

Update: it's perhaps worth mentioning that, despite never having had trouble with Linux audio before, I now sometimes have to quit Firefox before RhythmBox can play music. Alternatively, if I use RhythmBox before Firefox, I get no audio in Flash movies.


Watching DVDs on an Xbox 360

So I finally got an HDTV, and games look awesome...
That's not a question.

Why do DVDs look shite?
Because they're still playing at 480p. Your TV probably tells you this when it switches mode. The DVD itself is recorded at a higher resolution than that, though.

Okay, so how do I fix it?
You need the 360 to "upscale" to 1080i. The 360 (if it's new enough to have an HDMI port on the back) contains the hardware to do this, but it won't do it via the component cables you're probably using.

But games are already at 1080i; why not DVDs?
Because Microsoft hate you, and want you to buy a custom Microsoft cable for USD50.

Do I have to buy Microsoft's USD50 cable?
No. All you really need is a standard HDMI cable (which shouldn't set you back more than USD5).

HDMI's selling point is that it does audio and video through a single cable, so that's all I need, right?
No. Not unless you want your audio through the TV's crappy speakers.

But my TV has a TOSlink (optical audio) out; can't I use that?
Not necessarily. Not on a Sony Bravia, for example. Audio that came in via HDMI won't come out via TOSlink, just via the TV's crappy speakers.

Why not?
Because Sony hate you too, because they know you're a dirty thief who probably half-inched the telly off them in the first place.

Don't forget that Sony are not only the leading consumer electronics company when it comes to proprietary connectors and formats, they're a recording company as well. Twice the evil!

So what do I do?
You need to use an HDMI cable from the 360's HDMI port to the TV for the video, and also run a TOSlink connection from the usual component cable in the back of your Xbox 360 to your surround sound system, like you were already doing.

That is: you need both the old cable and the new cable plugged into your 360 at the same time. You'll use the audio from the old setup and the video from the new setup.

Can I connect an HDMI cable and the component cable at the same time?
Electrically, yes. But Microsoft hate you, remember, so they put the HDMI port so close to the port for the component cable's proprietary connector that when the component cable's plugged in,it overlaps the HDMI port.

So what do I do?
1. You give Microsoft an extra USD50 for their stupid cable. This is probably the best solution.

2. Alternatively, if you like voiding warranties and begrudge those bastards in Washington USD50 that would be better spent on booze and lottery tickets, you take a screwdriver to your component cable, lever the big gray plastic case off, and plug the cable back in to the 360. Removing the plastic means you now have room to slip the HDMI cable in while the component cable is connected. You can find pictures on the web, but note that the plastic case has changed slightly so it's not quite as easy any more, but it's still pretty easy. The hardest part is that you'll have been holding on so tight you probably flipped the SD/HD switch on the side, and you'll want to flip that back.