Ruby 1.8, which was superseded in 2009 and completely discontinued in 2013.

The majority of the standard library is written in Ruby. The handful of extensions typically have native Java versions under JRuby (and I believe in Ruby under Rubinus).

It may not be "wrong", but it is significantly incomplete. The language has multiple first class implementations, in multiple languages. But the broader point was not the implementation language (which I point out is C in several examples) but other languages in the same class are not interpreters in the classic sense. They are almost universally virtual machines, either from the beginning (like python) or at some point in their evolution (like Ruby, TCL, PHP, etc).

- Perl 5 and earlier: An interpreter written in C.

Not exactly. The interpreter compiles the source files into a bytecode and executes it on a stack-based virtual machine: ahref=http://perlbin.sourceforge.net/perlcompiler/perl.internals.pdfrel=url2html-14852http://perlbin.sourceforge.net...>

- Python: An interpreter written in C.

A virtual machine in C: http://www.troeger.eu/files/teaching/pythonvm08.pdf

- Ruby: An interpreter written in C.

A virtual machine in C: http://en.wikipedia.org/wiki/YARV

Or in C++: http://rubini.us/

Or against the JVM (which is written in C++): http://jruby.org/

- Lua: An interpreter written in C.

A virtual machine in C: http://www.lua.org/doc/jucs05.pdf

- Tcl: An interpreter written in C.

A virtual machine in C: https://www.tcl.tk/community/tcl2002/archive/Tcl2002papers/kenny-bytecode/paperKBK.html

- PHP: An interpreter written in C.

Hey, you got one. However the they are currently revising the language to make it compatible with adding a JIT later: http://www.computerworld.com/s/article/9248637/PHP_keepers_plot_radical_revision_of_the_language

And Facebook has their own C++ VM: http://hhvm.com/

- UNIX shells: Interpreters written in C.

Different problem space.

Dalvik is its own VM and bytecode specification.

I'll sort of second this. JRuby. Full access to the Java ecosystem, but better aligned with the goal of rapid development.

The beauty part is that you can do your prototyping in a convenient, highly expressive language using the same frameworks you plan on using in production.

systemd is irrelevant here. RHEL6 has always had a committed lifecycle, ending on November 30, 2023.

Red Hat does the same thing. They provide ABI compatibility for major components (e.g. libc) two major releases back. For example, an application released against RHEL5 (first released in 2007) will continue to be supported until RHEL7 falls out of support in 2027.

Likewise, AIX does the same as Red Hat. Any given release of AIX is supported well past the release date of its successor. So even though AIX 7 became available in 2010, AIX 6 is still supported and AIX 5.3 was supported until 2012.

Ultimately ABI compatibility is a secondary concern for large scale and long running deployments. The question isn't whether an application will still work after an upgrade; it's why you should upgrade a working system in the first place.

s/the problem/the point/

More to the point, the problem is that x86 is not compatible with ARM. And it's pretty much just a problem for Intel. So not really a problem at all.

In other words, it's not only on the internet, but it's been vouched for by anonymous sources. It clearly must be true.

Seriously? Grow the f!@# up.

I never said a finger was like a pointer. That does not mean you cannot design an interface that can accommodate both effectively.

With a convertible device like this you _are_ directly holding the device when using it as a tablet, and when you are using it like a laptop you have a keyboard and a touchpad, so reliance on the touchscreen aspect is diminished. I think you overstate the challenge there, though. I have absolutely no problem using the touchscreen on my tablet when it is on a dock or even stood in its case.

Either way, it's pointless to argue over matters of aesthetics. If your opinion of their design decisions turns out to be more common, it will do nothing for their bottom line and they will either change course or lose marketshare.

*shrug* That strikes me as a fairly unimaginative assumption, but it isn't really worth arguing.

For half the price you're probably going to get something with a plastic screen, half the resolution and twice the weight. This is a competitor to relatively high end ultrabooks, not laptops.

I'm not the market for this either. I'm a cheap son of a bitch and I haven't used Windows in years. On the other hand, I can see the appeal of the form factor and of having a single device, especially for people who already have a large phone for opportunistic use.

I tend to stick to keyboard navigation, myself. That does not mean I cannot see value in other interface paradigms, nor will I outright reject that touchscreen interaction is not valuable even when a keyboard and mouse are available.

Adding additional options does not require removing existing ones. You can add touch scrolling and it doesn't remove scrolling with the scroll wheel on your mouse, or dragging the scroll bar, or multi-touch swipe on your touchpad, or using pgup/pgdn on your keyboard.

It has been obvious for a while that Microsoft is operating on a convergence strategy. In other words an interface that can accommodate multiple input paradigms. Whether their approach will ultimately be successful remains to be seen, but they are clearly much further along than the competition. Apple, as you pointed out, has only make token concessions toward unity between their two environments, and Google went backwards, bifurcating into Android and ChromeOS as related but separate ecosystems.

I actually think it is a smart strategy, though I haven't used Windows extensively since NT. As touchscreens become ubiquitous, the options for replacing discrete controls with gestures will only increase. Scrollbars too small? Who cares, you just swipe to scroll?

There is also room for innovation in presentation of controls. Even on the desktop there has been a trend de-cluttering interfaces and presenting only commonly used controls. By decreasing density, target areas can be made that much larger for common functions. Secondary functions could be packed more densely and employ existing schemes for precision selection.with touch screens, like using long-press to highlight and expand a selection in densely packed controls, allowing you to fine tune before release.