I guess what felt weird to me was that he had to learn a lesson and then back - that he didn't do the "right" (or at least consistent with not destroying the Daleks either) thing straight off. But the Doctor who didn't destroy the Daleks was hundreds of years younger, maybe this one just needed that nudge in the right direction!

I'm probably overthinking it but it instantly bothered me that somehow we've gone from a Doctor who won't eradicate the Daleks to a Doctor who attempts to kill off Davros as a child - even if he did change his mind later, it seemed out-of-character that he had to go back and take a second shot at it. But I'm probably expecting consistency from something that was never that consistent - rather like Kirk, who's a good guy who occasionally threatens to lay waste to planets...

Also, bzr evolved IIRC from the whole GNU Arch / tla, which is much older again.

I think it's fair to say that git is the current winner in the DVCS race because it has the best network effects from mass adoption. I live in hope Mercurial will see a resurgence at some point!

Upstart, although sticking to it may now resemble NIH, does also predate SystemD and was used by other distros (Fedora adopted it before moving to SystemD when that became available).

Mir is the one I still find a bit mystifying. I'm sure it's nice technology, developed by smart people, I'm just surprised Canonical started on it so enthusiastically and so early.

Like how people weren't bothered by Y2K bugs? Let's not repeat that every century.

(I realise that still assumes there's enough memory for the applications to usefully run, which was at least part of your original point)

For the default Linux kernel settings, with anything approaching or exceeding 1GB of RAM you can actually get a benefit from more address space. The kernel only maps 1GB by default because of the restrictions of a 32-bit address space - and some of that 1GB is taken up by devices, rather than actual memory. The result is that the kernel has to create temporary mappings to access process memory. With a 64-bit system the kernel can keep it all mapped, all the time.

My comment applies to x86 specifically - other architectures will not necessarily have the same cost / benefit tradeoff. Also, there have been options for the kernel that allow it to map 2GB (with a reduced 2GB address space per process) or 4GB (which will be at a performance cost) - they're not often used but in a more appliance-like device (i.e. nobody is going to plop a load more memory in later and change the cost/benefit analysis) such as this they may also be a viable option.

The first Itaniums had x86 compat in hardware and were, I believe, disappointingly slow at executing x86 code. Obviously that's something that Intel could have improved if they applied themselves to the problem (and maybe they'd have made it faster if they hadn't been expecting / hoping / planning to replace x86 anyhow).

But given the different philosophies of the architectures, I think it's somewhat plausible that doing an x86 -> Itanium conversion in hardware is just a bit awkward and that software might genuinely give the flexibility to do a better job. Around the same time, Transmeta were selling their chips that exclusively exposed a software-emulated x86 layer for use in laptops. I remember wishing Intel would buy their tech and apply it to Itanium / x86 compatbility.

Apple seem to be pushing their mobile CPUs forward quite fast - they're also way ahead of the curve in adopting 64-bit ARM. I wonder if there's a longer term strategy to start migrating devices like the MacBook Air over to their A-series CPUs, instead of Intel. That could tie things together quite nicely for them.

Start at != fully loaded.

ISPs chose their flat-rate business model; Netflix didn't force it on them. If that business model no longer works, ISPs should switch to a different one.

Nah, Netflix used to use other CDNs. But then they got big enough that it was cheaper to build their own.

That's orthogonal to the issue that (in most people's opinion) no CDN should have to pay broadband ISPs.

Maltron keyboards are kind of crazy - they're still made using very low volume manufacturing techniques. The keyboard shells, AFAIK are vacuum formed and (unless things have changed recently) I think they do manual point-to-point wiring on the switches. But if you look at the sculpted shape of a Maltron, they don't lend themselves to conventional PCBs.

I'm typing on one now - I think it's quite an old one but it looks as though the design changes are mostly smallish refinements and updates to the controller / electronics. I got mine from an office clearer on eBay, otherwise they've very expensive and I probably wouldn't have got it.

I've also got a Kinesis, an ergo board which came later (and with a strikingly similar design). It feels a bit more like a slick, mass-manufactured product but I've known people insist that the Maltron is ergonomically better overall. I'm not so fussy, I'm just glad I got two cool keyboards for prices I felt I could afford!

There was work done on single address space operating systems but retaining multiple protection domains - the Nemesis research OS did this. It sounds mad at first but every process can still have separate pagetables, they just happen to all agree on the virtual addresses of shared libraries, shared memory areas, etc. This means you can still make the OS secure (though admittedly it would not be compatible with modern address space randomisation strategies).

Honestly, I can't quite remember what the main benefits actually were!

L1 caches are indexed using virtual addresses, so I suppose it may improve the extent to which shared lib code remains cached across process switches. I can't see that it would avoid TLB flushes as such because you'd still want to clear out mappings that the process you're switching too shouldn't have access to... Does mean that data structures in shared memory can contain pointers that actually work but that doesn't sound *that* important.

I'm sure there was some other, more compelling reason but on commodity hardware I can't remember what it would be. Hurm.

I'm used to just randomly hitting Ctrl+X then Ctrl+S in emacs when I pause and my fingers have nothing better to do. Semi-frequently, I do this in other applications without even realising I just did it, with various mildly weird results...

There are two different ways to do network display: the RDP way and the right way. With RDP you're sending the entire "screen" over the network, so all the windows have to be composited first. Thus RDP requires a fully featured compositor like Weston on the remote end.

The right way is to send each window over the network, which should require a lightweight compression proxy. No one appears to be working on this.