The Retrode is a brilliant little gadget: http://www.retrode.com/

It's basically an old-school console cartridge -> USB adaptor. It also supports old Megadrive / SNES gamepads and doesn't require host software (which is actually rather neat - it'll appear as a USB mass storage device with a cartridge image on it, plus presenting the controllers as either gamepads or keyboards). With further adapters you can plug in Mastersystem, Gameboy and N64 carts (plus two N64 controllers).

It's just a really nice piece of work. I use it to rip my cartridges, just like I rip CDs, then put them into whatever emulator I like. Avoids the legally dubious websites, etc. I can imagine there might be grey areas in some emulation stuff still (e.g. some emulators need a BIOS image, which someone has to have dumped from the console) but that's only for certain consoles - and at least you don't have to go on dodgy websites to download the games you already own.

I've heard tempting-sounding things about Debian kFreeBSD, actually - aside from anything else, BSD has a port of ZFS. So if you want something with a familiar userland (GNU utilies, Debian package management, loads of packages available) it does look quite appealing. I'm not sure how common it is to use ZFS under FreeBSD so far, though.

Also, there are Solaris distros out there, which is potentially another way to get the same effect. Nexenta started as one, though I remember them switching more to focus on server stuff since then...

I don't think I'm really adding much here but the discussion of the 8051's quirks struck a chord with me! The 8051 is a bit weird in place, although in fairness with a C compiler you can just mash on through that and not worry too much. If you actually have to look at the architecture, you can definitely see its age, though. But for 8-bit stuff, the AVR architecture (Atmel's microcontrollers) genuinely are relatively nice, despite being just an 8-bit CPU. They are RISC CPUs, so they actually have a fair number of registers and comparatively few weird quirks (that I could see).

The other big advantage in my particular line of experience is that as long as a CPU has lots of registers, gcc often supports it. Otherwise you end up having to use slightly less mainstream compilers - which is basically OK, they're still nice software. But they're not as comfortable to me as the standard GNU toolchain. Of course, I'm sure plenty of commercial embedded programmers aren't familiar with the GNU toolchain and so don't care about that.

I can speculate a bit with things that sound plausible to me given my knowledge of the system - but I might still be a bit off target... Still, maybe it helps a little.

Mir and Wayland both expect their clients to just render into a buffer, which clients might do with direct rendering, in which case the graphics hardware isn't really hidden from the client anyhow. AFAIK it's pretty normal practice that there's effectively in-application code (in the form of libraries that are linked to) that understands how to talk directly to the specific hardware (I think this already happens under Xorg). The protocol you talk to Wayland (and Mir, AFAIK) isn't really an abstraction over the hardware, just a way of providing buffers to be rendered (which might, have just been filled by the hardware using direct rendering).

In this case Xorg is a client of Mir, so it's a provider of buffers which it must render. The X11 client application might use direct rendering to draw its window, anyhow. But the Xserver might also want to access hardware operations directly to accelerate something it's drawing (I suppose)... So the X server needs some hardware-specific DDX, since Mir alone doesn't provide a mechanism to do all the things it wants.

As for why the Intel driver then needs to be modified... I also understand that Mir has all graphics buffers be allocated by the graphics server (i.e. Mir) itself. Presumably Xorg would normally do this allocation (?) In which case, the Intel DDX would need modifying to do the right thing under Mir. The only other reason for modifying the DDX that springs to mind is that perhaps the responsibilities of a "Mir Client" divide between Xorg and *its* client, so this could be necessary to incorporate support for the "Mir protocol" properly. That's just hand-waving on my part, though...

Bonus feature - whilst trying to find out stuff, I found a scary diagram of the Linux graphics stack but my brain is not up to parsing it at this time of day:
http://en.wikipedia.org/wiki/File:Linux_Graphics_Stack_2013.svg

I'm honestly not super clear myself! But the DDX is, as I understand it, the in-Xorg portion of the graphics driver. So I guess it's not unreasonable that that component needs to know it's not got complete control of the hardware, as opposed to the Xorg-only case where it would have. Presumably it needs to proxy some operations through Mir (or Wayland, for XWayland) that it'd normally just set directly.

A *bit* like running X under X using Xnest or Xephyr, though I'd imagine it's less extreme than that (since those, I'd guess, have to issue X-level drawing commands to their host X server, whereas to get graphics under Wayland/Mir they'd just render to a memory buffer like any Wayland/Mir client).

All slightly speculative since I'm not familiar with the in-depth technical details!

There used to be a village nearby (ish) to where I grew up, in which there were some peacocks that just roamed freely around the roads. If one of them felt like strolling in front of your car, you just had to put up with it. I remember seeing the peacock had gone to roost in the tree by the pub for the night, which at the time seemed a bit notable but - now you mention it - I didn't really know they could fly. I've never actually seen one take off before or since but apparently if they feel like it, they can get up there... Weird.

Yes, I tend to agree - in fact, that's basically one of the first things I thought, on seeing this article. It's easy to imagine that relatively few incidents like this will be required for Twitter to change its T&Cs so that individual customers can't buy ads like this (assuming it doesn't technically violate them already). This guy might have had enough money to get one ad griping about them but he's not as valuable a customer as the large companies who'll buy many ads and have an interest in not being criticised.

xpra is nice, although it'd be even nice to see an existing window manager / compositor provide support for remoting windows using the xpra protocol - I'm not aware of a reason this couldn't work, since the xpra server just works by being a compositor anyhow... This would give me the ability to grab arbitrary windows from my desktop and display them on other machines, whilst having them run at full speed locally - that would be a big improvement on remote X11, for my uses.

Also, I'd like to see Wayland support the same. In some ways, although I'm not worried about remoting being available on Wayland, I do wish there was a central place for common Wayland remoting implementations to live. AFAIK that doesn't exactly exist at the moment, other than de-facto in their demo code - and given various desktops are going to be implementing their own compositors, I don't know that they'll inherit these implementations conveniently... Hopefully I'm just lacking reassuring information and it'll all be OK.

I don't really agree with that in modern day Europe. The media companies don't toe the government line more than you'd expect in any country with a free press. There are often concerns about the closeness of ties between politicians and media but I think that's pretty common in Western countries. Moreover, in the UK the government itself makes a big deal of how important our relationship with the US is. Besides that, I'd argue that you're underestimating the reach of both the Internet and US culture generally. The Internet makes it easy to get access to a wide range of news sources, at least for those who are motivated to do it.

Probably more importantly, I'd guess that easily half the popular TV and most of the movies in Europe (and probably much of the world) comes from the US - there's a lot of information about US culture, self-image, even simple turns of phrase that continuously percolates into everyone's minds from this alone. People continually get (arguably idealised, since this is Hollywood) images of what the US stands for, what it's like to be American, etc. In terms of the vast entertainment industry, I'd argue that Europeans are routinely shown the same image of the US that Americans themselves receive.

Although I can imagine certain items being banned or screened more careful, I'd suspect that the lobbying of airports / airlines will protect the duty free shops from significant changes. Similarly, I've always suspected that the restrictions on liquids would have been lifted quickly if they were a financial pain (rather than a financial benefit) to the airports / airlines / shops.

Just my opinion, though, it's not like there's (as far as I'm aware!) particularly good insight available into how and what the interested parties communicate.

This is one of the reasons airport security has bugged me so much - I've been inconvenienced over trivial things that don't really matter to security, whilst equivalent or greater threats just go unmentioned. I once had a cone spanner confiscated. That's a very small, thin spanner, suitable for adjusting bicycle bearings - and very little else - I'd lost it at the bottom of my bag and hadn't realised it was there (though I had flown the outbound leg successfully without security picking up on it!).

It was against the rules to let "tools" through the checkpoint - but couple of weeks later on a much larger, more significant flight, I was able to get a heavier spanner for free on the front of a biking magazine in the duty free area. Derp.

Which makes sense because gasoline / petrol is more common than diesel. But as I understand it, diesel in a gasoline / petrol engine is less harmful than the reverse situation - so it's all a bit unfortunate!

A couple of mentions of the Model F already but I think it's worth a dedicated post! My understanding is that the Model M (a keyboard before whose build quality, longevity and tactility modern keyboards quake in fear) originated as the cheaper, mass-market version of the older Model F keyboard. I have both a Model M and a Model F; I do find the key feel of the latter to be even nicer. It's also even louder and heavier - and I don't have one of the really big 122 key terminal variants.

The Model M does actually use a membrane (a bit like a modern keyboard) to detect key presses but it puts a spring and a hammer / foot on top. The Model F uses a hammer / foot but senses its movement using capacitative sensing. In principle it seems like there is even less to wear out using this mechanism - not that the Model M typically has lifetime issues! I've also heard that this potentially gives the keyboard n-key rollover, which the Model M cannot achieve. I suppose you might need a custom controller to actually get the benefit, though.

It's worth trying a Model F if you get the chance; the only trouble is that at least some of them had a horrible, heavy space bar - that can be fixed by a spring modification. The other problem is that the layouts are varying degrees of crazy, since it appears people still weren't really sure what keys should be on a keyboard (or where). Still, it's the only keyboard you can successfully use to intimidate Model M users, when you're telling them to get off your lawn.

Unless things have changed, I think you can also ##program-name and get the TeXInfo page for it.

With file management, web browsing, KParts rendering PDFs, and the integrated man / TeXInfo viewers I practically never used to leave Konqueror.

If your plane is on fire and not a plane anymore then you are having a bad problem. You will not fly on Venus today.