How long you get support for depends on how much you're willing to pay and what you actually want. Most companies don't want 'no upgrades ever', they want:

• Minimal UI changes that disrupt work
• No upgrades that break their in-house software
• Hardware that works
• No unpatched security holes
  • The first is a problem for companies like MS, because they justify selling you the new version largely based on the UI changes: that's what consumers see. It's not a problem for a company that is being paid for support, rather than a product, because the lack-of-change is a feature in what they're selling you.

    For a corporate desktop, you don't need all of a typical distribution's packages and there are lots of companies that will happily back-port security fixes to older versions of a few hundred packages, if you want them. And if all that you're doing when you upgrade is installing back-ported security fixes then the updates won't break in-house software unless they rely on unsafe behaviour.

    The final requirement, working hardware, can be addressed by either only buying hardware that's certified by whoever is doing your software support, or by paying them to write or back-port drivers to whatever kernel you're running.

    With a Microsoft solution, you get UI changes whenever Microsoft rolls out a new version. You get hardware that works, as long as you're on the latest version of the OS. You get big upgrade headaches for your in-house software whenever you move to a new OS version (or a new Office version if you've written a load of VBA). And you get security updates right up until they decide that they want to EOL the software that you're on. Sometimes, they'll let you pay vast amounts to be allowed to have one year of security updates past the EOL date. Often, it's a hard cut-off date.

You can only guarantee this with MS Office if you both have the same version of Office and you both have the same printer drivers installed, but MS marketing has been very good at convincing people to ignore this...

There are two reasons to object to DRM. One is ideological, the other is pragmatic. For most people, streaming DRM doesn't affect them because they run Windows or Android and it just works when they want it to. For BluRay, the DRM can still bite you even if you're using a fairly conventional setup, so there's a lot more objection. The same happens with Steam: lots of people are happy to accept its DRM because it happens to work fine for them today.

And most of that has negative value to the consumer. The worst offenders in the DVD world are Cheerful Scout, a company that is paid a lot of money to make detailed menus for DVDs that are visually impressive and completely unusable. I wish they'd put their logo on the outside of the box so I'd know not to buy them. I have never once put in a DVD with the goal of exploring the menu system. I put in a DVD because I want to watch the movie / TV show that is on it and I want to do this as quickly and easily as possible. Somehow, the studios don't get this and insist that what I really want to do is navigate a maze to get there. And then they wonder why people torrent...

I have a couple of DVDs designed by people who understand this. You put them in and they immediately start playing the movie. If you want to get at the menu, you hit the menu button. If you don't, you never need to know it's there.

The problem is that you get into diminishing returns. DVD is definitely better than VHS, but if the movie is engrossing then you rarely notice how crappy VHS looks on a smallish screen. Even SD iPlayer streams are watchable on a projector, although you do notice pixelation at times. The thing that killed VHS wasn't really the picture quality though, it was the convenience. DVDs are smaller to store, can be played on laptops and portable players as well as big TVs, don't need rewinding, don't get tangled in the machine, and so on. BD is less convenient. Most computers still don't have BD drives, they take ages to load, they're more effort if you want to rip them to play on a tablet, and so on. Their only advantage is the quality and, unlike DVD vs VHS, they're a step backwards in almost every other regard, which makes them less of an obvious upgrade.

MiniDisc would have been massively successful if they'd pushed the MD-Data format. Back when they started talking about it, a Zip drive cost about £100 and the disks cost about £10 each. Portable MD recorders cost under £100 and the discs were about £1.50. I wanted one as soon as they were announced, but I never saw one for sale and the people in my local Sony shop didn't even know what they were. In 1997, they increased the capacity to 650MB, making them the same capacity as a CD, but smaller than a floppy disk. I'm not sure how much the 650MB discs were, but a CD-RW cost about £10 then and a CD-R about £1.

I still don't understand how Sony had a format that was better than anything else on the market, existing economies of scale that would have made it possible to sell it for less than anything else on the market, and still failed.

I bought a BD-DL writer for my NAS when I built it 4 years ago. It was a bit under £50, so not much more than a DVD drive (well, a bit more than twice the price, but not much in absolute terms). I also bought a spindle of 10 blank disks. So far, I have not burned a single one. It's big enough to back up some things, but not the things I really want to back up, and splitting the backups across multiple disks is annoying.

Optical drives always seem to be introduced at a capacity that sounds great for backup, but by the time the media are affordable they're no longer enough.

How difficult is it to get the driver version and the hardware (honest question - it's been about 10 years since I did any OpenGL hacking, other than testing compiler stuff with OpenCL)? I was under the impression that there was a function that gave you the driver version string and that you had to enumerate the hardware devices before you could do anything (well, you could just say 'give me the default thing' but most games didn't because it often gave the wrong device). If this is the case, then it should be fairly simple to cache them. Driver updates will be a bit annoying, but hardware changes quite infrequently for most users (even if you're on a laptop with 2 GPUs, you're likely to only use one for gaming).

An IR doesn't buy you much. The time taken for clang to compile OpenCL C to SPIR is about 10% of the time required for LLVM to optimise and codegen the resulting SPIR into native code. The driving force behind SPIR comes from developers who don't want their shader source code embedded in their binary source.

Caching of compiled shaders is supported by the OpenCL spec, and I presume by GLSL as well (I've not looked, but they generally use more or less the same code paths). The application is responsible for asking the driver for the cacheable version and then loading it again later. The problem is that, on first load, the game is effectively doing ahead-of-time compilation of all of its shaders and, previously, these were all done in a single thread. The multithreading part is a bit odd, because most DRI GPU drivers use LLVM on the back end and LLVM has supported multithreaded compilation for a few years.

BSD UNIX was free software aside from 6 AT&T files before Linux was first released, and was completely free about 4 months later when AT&T lost the lawsuit against UCB.

KDE has always been portable. It even runs on Windows, but at the start it ran on Linux and *BSD. The developers at the start used whatever free OS they could find (some were using BSDs, most Linux). GNOME was created as a reaction to Qt not being open source and has increasingly become Linux-only in recent years, mostly as a result of Canonical and Red Hat's efforts. PC-BSD ships with KDE as the default for this reason.

The list of alternatives to Linux is quite long too (FreeBSD, NetBSD, OpenBSD, Minix, Illumos, HURD). Some of these would likely have seen some more development effort if Linux hadn't existed (HURD especially). Some of them can even work as a drop-in replacement for Linux in a lot of cases, as they implement the Linux system call ABI (and other, mostly proprietary, UNIX ABIs) for running non-native programs.

1991, when Linux was released, was indeed the dark days. The i386 port of BSD was delayed by legal uncertainty over the AT&T vs UCB lawsuit. When UCB resoundingly won, 386BSD was released and was a vastly more mature system than Linux. Today, Linux and FreeBSD aren't that different in terms of performance or support. Debian kFreeBSD works quite happily with a glibc ported to FreeBSD and runs most of the same applications as Debian Linux. Linux still lacks some things (kernel sound mixing, ZFS, DTrace, Capsicum, jails, and so on) that FreeBSD has had for a long time and there are things on the other side that Linux has that FreeBSD lacks, but by and large they're pretty comparable.

If we hadn't had Linux, we'd most likely be using a BSD derivative now. On the other hand, if Linux hadn't taken the momentum away from HURD, maybe some of the microkernel operating systems would have seen a lot more attention and we'd now not be in a world where you have 5-10MB of object code compiled from a language with no memory safety running in ring 0...

Why? He's got the name recognition, but he wasn't the first to develop an open source kernel. The UCB team had been doing that before and so had the FSF (although with less success). He was the first to release an open source UNIX kernel for i386, but only by a few months. I may be wrong, but I believe OpenBSD was first to use a public CVS repository, rather than exchanging diffs on a mailing list.

This award feels like pandering. He gets the award for being the figure who is well known for doing things that lots of other people were doing.