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.

Could be bundled as part of the application, updated via the normal mechanism, without requiring it to have a permission that allows it to send data remotely ('download' can mean an HTTP GET with a really long query).

Most of the time, I'm not typing a contact's name so this sounds like it would lead to a lot of false positives. I've never seen it suggest a name that isn't a common English name though, so it doesn't seem to actually need this.

If that is the case, it's bad design.

It doesn't seem to ever do that for me...

Since when does open source mean giving away my services? I get paid quite well to write open source software. My service is writing code, not copying code. I'm happy for people to copy the code for free, because copying it doesn't require any effort on my part. Having a body of open source code available expands my potential set of customers quite a lot, because a lot more companies can afford to pay for a single feature to be added to an open source codebase than can afford to pay for something to be written from scratch that has that feature.

Or are you seriously arguing that the model that makes the most economic sense is to write software for free but charge people for copying it?

I think the meme here is 'obvious troll is obvious'. Open source doesn't mean that the software is free, it means that copying the software is free. Writing it in the first place, fixing bugs, and adding features are all things that someone has to be paid to do (although sometimes people will do it simply in exchange for being able to use the resulting combined work, effectively doing it for free because it's something they need or want).

The problem in the case of OpenSSL is that everyone needs bug fixes and security auditing, but no one was making a coherent effort to sell such a service.

The Google Keyboard for Android sends what you're typing to Google servers 'to improve suggestions,' so I don't think that asking for your location a lot is the worst invasion of privacy of a mainstream on-screen keyboard app. The AOSP keyboard also requires a phenomenal list of permissions, including the ability to download files without notification, read contacts, modify or delete contents of USB storage and view accounts on the device. No idea why it needs all of these things - I wouldn't mind so much if it had access to all of my data for improving predictions if it didn't also have the ability to make network connections.

If you're putting your business in a building where power is sufficiently unreliable that it's worth the cost to have a UPS for every workstation, then you're probably doing something badly wrong. On a server, where downtime can cost serious money, it can be worth it. On a workstation, the extra cost for something that happens once every few years in a country that has vaguely modern infrastructure simply isn't worth it most of the time. The extra writes to the SSD from having to suspend to disk once every few years as a result of power failure are in the noise.

Satellite internet connections don't qualify as 'often' - they're a statistically insignificant amount of the userbase. Mobile connections are, but:

We're talking about browser in-memory caches here. A 100MB document will be saved to disk or opened by another application when it's downloaded. It won't sit in the browser's cache.

Not really, this policy predates hibernation by about three decades. It's so that swapping never needs to allocate new data structures when the machine is already in a memory-constrained state.

When Linux is using zram, it doesn't follow this policy (actually, Linux doesn't in general). It's impossible to do so sensibly if you're using compression, because you don't know exactly how much space is going to be needed until you start swapping. RAM compression generally works by the same mechanisms as the swap pager, but putting pages that compress well into wired RAM rather than on disk. You can also often compress swap, but that's an unrelated mechanism.

Generally, never. OS X does 'safe sleep', where it only bothers writing out the contents of RAM to disk when battery gets low, so my laptop never hibernates unless I leave it unplugged for a long time. My servers don't sleep, because if you've got a server that's so idle it would make sense for it to hibernate then it's better to just turn it off completely. My workstation doesn't hibernate, because the difference in power consumption between suspend to RAM and suspend to disk is so minimal that it's not worth the extra inconvenience.

Most post-mid-'90s operating systems use a unified buffer cache, so there's no difference between pages that are backed by swap and pages that are backed by other filesystem objects. Indeed, allocating swap when you allocate a page made this even easier, which is why this policy stayed around for so long: you could get away with just having a single pager that would send things back to disk without ever having to allocate on-disk storage for them or care about whether the underlying disk object was a swap file or a regular file.

POSIX doesn't. Windows has something like this, as does XNU. Mach had it originally, as it delegated swapping entirely to userspace pagers and allowed applications to control their own swapping policies. It's not really related to hibernation, but to memory pressure in general. It's often cheaper to recalculate data or refetch it from the network than swap it out and back in again, so it makes sense, for example, to have the web browser purge its caches when you get low on RAM, because it's likely almost as fast to re-fetch things from the network than get them from disk. On a mobile device, with no swap, it's better to let the applications reduce RAM footprint than to pick one to kill. This works best with languages that support GC, as they can use this event to trigger collection.