Eh? Both T-Mobile and AT&T (and Verizon, actually) offer no-contract service. Not one or two year. No year. Now you might finance a phone through them, and be on the hook for paying that, but that is not the same thing as being under a service contract.

Erm, LLVM was around for half a decade before Apple started contributing to it.

I would think the more apt analogy is that you sold me unlimited access to your fridge (bandwidth) but Netflix (content provider) is only restocking at a rate of one six-pack per week. IOW, Netflix is the one failing to have peerage agreements in place to honor their downstream sales commitments.

Very expensive items ... like an iPad. Even if, as you stipulate, the replacement rate is significantly higher, it can afford to be. Because again, half the cost. Less once you consider the cost of keyboard and case for the iPad.

But I frankly doubt the iPad will last that much more. The batter is probably higher grade in the Apple, but the battery in many Chrome books is user-replacement and long off-AC battery life is not going to be a pre-requisite for this use case. There may be a slightly higher breakage rate with a Chromebook (given hinges, keyboard, etc), but accidental damage is likely to be similar on both and repairs on the Apple side are going to be more expensive (since they are not easily user-serviceable). Loss and theft will be more expensive on the Apple side as well, since the unit cost is higher. And separate keyboards are probably more likely to be lost or damaged than a built-in one.

Less than half the price. When buying tens or hundreds of thousands of units, the savings add up.

And applications targeting the platform have the expectation of a keyboard and pointing device, unlike iOS apps.

There are limitations, but that does not mean it is unsuitable to all markets. And those limitations become less important as applications increasingly move to the web.

It was the G4 and a considerable level of creativity in Apple's marketing department. They were not considered a "supercomputer". They were briefly subject to an export ban to some markets because they breached a arbitrary limit that had already changed by the time they hit the market.

See, for example:

The extend of their superiority over the Intel and AMD processors of the time also need to be taken with a grain of salt. As with most Apple touted benchmarks, the fine print would reveal that the "up to twice as fast" claim referred to three specific Photoshop filters that were optimized for the Altivec operations in the G4. In other words, they exploited the fact that Intel made significant performance trade-offs with their implementation of SIMD instructions in that generation. In other benchmarks (like SPEC) the P3 spanked the G4.

Ah, you must be on the Red Hat AUS update channel, which (to my understanding) provides critical bugfixes and security updates, but not enhancements. In other words, you are running 6.4 + fixes, which isn't the same as 6.5.

RHEL 6.5 is just RHEL 6.4 with all the updates already applied. Applying the updates does not change the system-release file.

Yes, it does. The centos-release package gets updated with everything else.

That is the core API, not the standard library (csv, net/*, json, etc).

And again, that holds true for MRI Ruby, not every implementation. For example, in JRuby, this is:

/** rb_ary_push - specialized rb_ary_store
          *
          */
        public RubyArray append(IRubyObject item) {
                modify();
                int valuesLength = values.length - begin;
                if (realLength == valuesLength) {
                        if (realLength == Integer.MAX_VALUE) throw getRuntime().newArgumentError("index too big");

                        long newLength = valuesLength + (valuesLength >> 1);
                        if (newLength > Integer.MAX_VALUE) {
                                newLength = Integer.MAX_VALUE;
                        } else if (newLength

And in Rubinius:

def push(*args)
        Rubinius.check_frozen

        return self if args.empty?

        concat args
    end

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.