Comment Re:Sudden? (Score 2) 268
Was parent modded down due to lack of citation? Maybe they were referring to this?
http://www.prb.org/Publication...
Was parent modded down due to lack of citation? Maybe they were referring to this?
http://www.prb.org/Publication...
You are generally safe with Nexus devices, since you have the best chance of upgrading to the latest OS.
A device with an unlocked bootloader is also more likely to be more future-proof. I have a newer version of KitKat running on my Galaxy Tab 2 7.0 (4.4.4) than on my considerably newer Moto X (4.4). The tablet's running Cyanogenmod...have no idea if Samsung ever got around to spinning a KitKat build for it, and don't particularly care at this point as the only thing that doesn't work under Cyanogenmod is the IR blaster. My phone, OTOH? Motorola has pushed newer versions (maybe even Lollipop now), but the bootloader is locked and you can't even root newer firmware versions (rooting 4.4.4 requires an unlocked bootloader first).
That new phone that Asus introduced earlier this week sounds interesting, and there's already an unlock for it. The only downside is the ginormous, almost tablet-sized screen. The Moto X is barely larger than the iPhone 4 it replaced, but it seems hardly anybody wants to build a full-powered phone that'll still fit in your pocket anymore.
the lost revenue by the studio, which currently stands at $10AU ($7.90US) based on iTunes pricing.
The studio should only be entitled to recover the wholesale price, which is presumably somewhere around half of the retail price.
You're off by a decade... 31 years.
He must be using one of those newfangled Pentium processors.
But it does require extra fuel. I'd have expected that fuel to be more than the weight of a parachute system, though perhaps not: it would be lowering a mostly-empty tin can.
I imagine that it's a bonus to be able to have that kind of precision on your rocket engines: if you can get them down, then it may provide advantages in going up. Certainly it's nice that you've proven that kind of control.
Losing data goes with the territory if you're going to use RAID 0.
In particular, RAID 0 combines disks with no redundancy. It's JUST about capacity and speed, striping the data across several drives on several controllers, so it comes at you faster when you read it and gets shoved out faster when you write it. RAID 0 doesn't even have a parity disk to allow you to recover from failure of one drive or loss of one sector.
That means the failure rate is WORSE than that of an individual disk. If any of the combined disks fails, the total array fails.
(Of course it's still worse if a software bug injects additional failures. B-b But don't assume, because "there's a RAID 0 corruption bug", that there is ANY problem with the similarly-named, but utterly distinct, higher-level RAID configurations which are directed toward reliability, rather than ONLY raw speed and capacity.)
Simple with a BSD license you can check the code yourself, build the code, and then deploy the code using a signed encoded DFU file with a custom boot loader.
I disagree that it is because java is easy to read. Java is easy to write. A good programer can write an app in Java and have it work really well. A bad programer can write an app in java it will work.
With C++ a good programer can write an app and it will work but you really have to watch for a lot of gotchas. A bad programer can not write a program that works in C++ because it will leak memory, stomp on memory, and have issues with pointers.
Java is better at stopping the little brain farts from blowing up in your face.
C++ is a lot more fun to write in IMHO.
It is easier with something simpler, not something smaller. When you start doing extreme optimization for size, as in this case, you are going to do it at the expense of many things, checks being one of them. If you want to have good security, particularly for something that can be hit with completely arbitrary and hostile input like something on the network, you want to do good data checking and sanitization. Well guess what? That takes code, takes memory, takes cycles. You start stripping everything down to basics, stuff like that may go away.
What's more, with really tiny code sizes, particularly for complex items like an OS, what you are often doing is using assembly, or at best C, which means that you'd better be really careful, but there is a lot of room to fuck up. You mess up one pointer and you can have a major vulnerability. Now you go and use a managed language or the like and the size goes up drastically... but of course that management framework can deal with a lot of issues.
And also other tradeoffs. It is fashionable for some geeks to cry about the amount of disk space that stuff takes, but it always seems devoid of context and consideration, as though you could have the exact same performance/setup in a tiny amount of space if only programmers "tried harder" or something. However you do some research, and it turns out to all be tradeoffs, and often times the tradeoff to use more system resources is a good one. Never mind just capabilities/features, but there can be reasons to have abstractions, managed environments, and so on.
If the aborigine drafted an IQ test, all of Western civilization would presumably flunk it. -- Stanley Garn