Yeah, me too, then I came in here to see if I wasn't the only one!

I got one; I've generally heard it called a "BC wheel" or an "Impossible Wheel". Could never get the hang of riding the thing - with a normal unicycle (or even its cousin the Ultimate Wheel) you can put pressure on the pedals to stop the unicycle whizzing off and leaving you to fall to the ground. With a BC wheel you just have to balance incredibly well - it's hard. Some people (often younger people, I think) can pick up the balance quite quickly.

Some folks made an ace video of some properly skillful BC riding:
http://vimeo.com/7390720

I like seeing unicycles mentioned on Slashdot because balance sports generally seem to be enjoyed by tech-minded people. I suspect it's because they can require an intense but non-intellectual concentration - and possibly because they are non-competitive, unconventional and still easy to enjoy even when there's nobody else to join in.

That sounds like same Ballmer who laughed at the iPhone because of how expensive it was: http://www.youtube.com/watch?v=eywi0h_Y5_U

Same negative marketing smack talk. Also, enjoy the irony that expensive phones are apparently now good, and cheap is bad. (although, of course, cheap isn't the same thing as inexpensive - it really *is* good to be neither expensive nor cheap).

I think more systems these days have IOMMUs, which allow much better protection of DMA accesses by devices. So maybe they can properly address the DMA issue - once operating systems guys get round to it, anyhow.

Agreed that Python is similarly terse, that's one reason I like it. But static typing does eliminate a whole class of errors if done properly. The ML family and Haskell languages do have an amazing static type system, which provides guarantees that I don't have when I program in Python. It's more powerful than the type systems of other statically typed languages whilst being not verbose.

To a large extent, for some functions, when something got through the ML typechecker correctly I generally found most of the bugs were already gone.

The RPython language, which is used by PyPy, does do type inference and then static compilation. I'd quite like to see how good the type checking in that is, as a programming tool.

Part of the problem there is in the teaching of it though; my university taught Standard ML and almost went out of their way to avoid teaching us how to write anything in it that would be useful in the real world. There are some quite practical real-world software packages written in ML / OCaml / Haskell. Plus I find functional-style constructs incredibly useful to sprinkle in Python code I write.

Bizarrely, it's starting to feel like the old Flash Gordon / old cartoon style "rocket ships" are actually the future! I'm not sure I'll ever be able to see them as "retro" and less futuristic-looking than the shuttle, no matter how much more advanced and practical they actually are.

Well, that's the price some designs pay for power efficiency - various ARM implementations make this tradeoff too, which is admittedly a nicer architecture than Intel's stuff and offers good performance per watt. (http://stackoverflow.com/questions/4072183/which-arm-architectures-have-out-of-order-execution). Depends on the characteristics the design needs; for a workstation, in-order would generally be sub-par.

In fairness, for some of the dense, massively multithreaded stuff that SPARC has been targeting in the last few years, in order execution gives you some power and transistor budget savings. Compare the Intel Atom, which ditched the out-of-order capability of their other mainstream processors.

But I was surprised to learn that Sun hadn't previously done out-of-order SPARC, although apparently Fujitsu have.

I'm actually surprised by the reaction since I was under the impression that rights holders for Star Trek (and Star Wars also!) had generally had a policy (possibly even officially) of tolerating fan-made stuff and even fan reuses of their copyright materials within reason. I'd not have expected the tricorder app to be any worse than other stuff that's gone by - but others have mentioned that there are multiple rights holders on Star Trek stuff, so maybe some new people are involved now...

They're saying it's the end of the case but I think we should just hold the line for now...

A government which doesn't give bailouts probably has to be one which doesn't allow bailouts to become necessary - which, to me, implies some regulatory intervention that few people are really going to relish.

Python, at least, has the ability to pull off similar behaviour using its "with" statement. Whether the extra explicit blocks required to do this are good or bad probably depends on point of view, although it's probably rather forced on them by not being a original design feature.

There are some quite nice architectural features in there; whilst they might look like things that are toys for operating systems geeks they are also the kind of thing that makes a nice foundation for building cool stuff that might be more noticeable to the users!

As a multi-server microkernel OS the system is actually split up into a load of different components anyhow. HURD makes it practical (IIRC, assuming nothing's changed in this respect) for users to replace or augment those components - but only for their own programs. So, for instance, a user might develop a network filesystem whilst not requiring any special privileges. Or a user might build a virtual machine / container / chroot to work in, again without their requiring special privileges.

Naturally, this also implies that all the funky hacks involving userspace filesystems are possible - like FUSE on Linux. But that sort of operation is baked into the design and taken further.

The disadvantage of having multi-server microkernel OSes tends to be (reputedly) that they're slower. There are various sides to the argument about whether they *have* to be slower but HURD is, despite its age, not hugely heavily developed - so those problems are not going to have been fixed.

That sort of thing has been done with Linux in various ways - but with substantial disadvantages. Under L4 and Xen there were implementations of running device drivers (for block and network devices) in separate virtual machines from the one running the application. They were restartable and contained only soft state. I worked, in a small way, on the Xen implementation and it was quite enjoyable to sit around restarting the device driver and watching stuff come back. Of course, one advantage of doing things this way is that you can reuse existing drivers.

Another project that was of a similar vintage (around 2003/04) but came slightly earlier (I think) was called "Nooks" and had the advantage of looking more like conventional Linux driver model. You could reuse existing drivers here too but lots of wrappers were needed when interacting with the non-driver portions of the kernel. I was given to understand (admittedly by a Xen developer) that their approach wasn't necessarily very efficient because their kernel-driver switches were still quite expensive and probably fairly frequent.

Anyhow, it's sort of possible to make systems that are more robust to device driver problems with almost-current technology but for various reasons (some subset of needing a hypervisor, cumbersome to set up, memory hungry, performance problems) these mostly don't seem to have taken off yet.