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.
Re:Perl 6ers just can't get shit done.
on
Perl Is Undead
·
· Score: 1
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
Re:Perl 6ers just can't get shit done.
on
Perl Is Undead
·
· Score: 1
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).
Re:Perl 6ers just can't get shit done.
on
Perl Is Undead
·
· Score: 2
- Perl 5 and earlier: An interpreter written in C.
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.
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.
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.
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.
You're missing the point - "still essentially be a PC", "full power laptop which can have the keyboard removed" and "runs Office" are the selling points here. Just because you are not the target market for a product does not mean there is no market.
Slashdot Mirror
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:
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.
You're missing the point - "still essentially be a PC", "full power laptop which can have the keyboard removed" and "runs Office" are the selling points here. Just because you are not the target market for a product does not mean there is no market.
How many people are doing 24 hours of straight computing without access to an outlet?