Short answer: yes.

If you don't want "the legacy", compile it out of the kernel, but don't remove it, for crying out loud! Some people still use that, and for good reasons.

64-bit arithmetic can be easily implemented on 8-bit devices. The problem will be upgrading the software on them, although it seems like it's doable in 25 years, even if that means going to some harder to reach place such as the North Pole.

Of course, that's a much bigger problem if you don't have the original sources and/or if you work with legacy technologies (think: COBOL) that are more difficult to maintain these days due to the lack of people that are competent in those areas. But that just means that the demand for such solutions will rise and someone will come with one or more ways to tackle it.

Mod parent up. It's called the Principle of least privilege, which Unix systems implement using mechanisms like sudo. Having root access on Android systems breaks this to some extent.

In fact games involve massively parallel tasks at the data level. It's why dedicated hardware for graphics use architectures with tens or hundreds of cores. IMHO games would benefit a lot from multiple lower-frequency CPU even for non-graphics tasks (think: simulating a unit in a some real-time strategy game using a thread).

No. (IBM) PC is a computing platform, while x86 is a processor architecture. Better if we don't confuse those two.

It should be noted though that Romania wasn't part of the USSR before 1990, as weren't Hungary, Czechoslovakia, eastern Germany etc.

Not necessarily. If the code you run results in usage of extra hardware, the cost of using that might result in a less efficient behaviour power-wise. What I'm saying is yes, Hurry Up and Get Idle is a good principle in theory, but it doesn't always work in practice because different instructions incur different power/time costs.

So the problem might be a tad trickier, there's other measures to be taken into account, such as how that affects lock contention, caches and so on. I personally can't make any statements until I see actual power usage results and comparisons.

Yep, and here's something even funnier (this time on purpose): http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD475.html

I mean I'm not saying people always make good decisions.

Not really. Mechanisms are patentable, algorithms aren't.

In this case slide to unlock is a mechanism with a clear description and such, while range checking is (as far as I can see) something too abstract to become a patent.

That wouldn't make sense. I mean what marketing person would use "Linux machine" and "graphics" in the same sentence?

Ok, so imagine you want to teach computer architectures. Which aren't quite electrical engineering but they aren't theoretical computer science either. Which department would you assign that to?

I'd also add that any good computer architect should be skilled in both hardware and software-related issues, in electronics, electrical engineering as well as some discrete math. I don't see how you can put all those together outside of a CS department.

Actually things aren't that simple. I find the field of Game Theory to provide pretty good measures for such things as social and individual welfare. And from what I managed to understand, a non-centralized system (that is, where everyone is mainly interested in their own well-being) doesn't necessarily lead to a non-optimal social welfare. Reversely, a centralized system (where some entity makes decisions to try and satisfy everyone) doesn't guarantee optimal social welfare.

So while some social measures might be good (protecting children and disabled people for example), most of them can actually prove to have a bad effect on the society as a whole. And even though communism is pretty much the mother of all bad socially-oriented decisions, the idea of bad socialism has the chance to apply to any society, including the ones that are democratic in nature.

Actually a lot of the functionality of Renault cars has been designed and built by Romanian engineers for quite some time now. I'm not saying that's necessarily state of the art, but it surely invalidates your statement.

That sounds simple but it isn't. While you could theoretically do this from a virtual machine, the difference between visualising” it and testing it on real hardware is significant especially when it comes to device drivers, which are known to be the most common source of bugs in kernels.

Plus verifying a kernel or a compiler is a pretty hard problem, it's a miracle if you manage to do it in decent time, let alone manage to visualise it in any way.

I don't know if I got the "hypertext literature" bit too well, but I think blogs are literature as much as books. So I don't believe that only because the format is different, "hypertext literature" is in itself dead.