They can prioritize all they want, but no one wants to pay for the carrier certification of thee modified SDRs, particularly when using a T-Zone on a Snapdragon chip in order to run the baseband, and the FCC demands that the SDR be certified as a unit (software + hardware). That's a carrier certifiiation per carrier, per country, per device, per version update.

Also no carrier using a contract lock-in revenue model is going to provide an update that doesn't lock you into a new contract, and a version update won't do that unless there's a charge for the update, based on FAS (Federal Accounting Standard) rules, since without an exchange of consideration, there is no contract. This is why Apple charged for the WiFi software update on iPods, and non-cellular network iPads, but didn't charge for cellular connected iPads and iPhones. It had to do with realization of revenue over time, versus a one time sale, and adding features to the device via software.

You should also be aware that the image that's shipped by the OEM is often not even buildable by Google engineers; apart from the fact that the devices used during development are generally signature neutered, and it's impossible to cryptographically sign the image for the given device without it either being neutered like that, or signing code that they device manufacturer generally does not share due to it containing a signing key they don't want out there... they entirety of the board file is generally not committed back to the Google maintained Android source tree. Nor is it maintained going forward so that it's up to date, nor is the remainder of the OS productization standardized across all the OEMs. They are trying to differentiate their products, after all, and my Samsung device looking and feeling exactly like a non-Samsung device is not in Samsung's interest: it makes them into a commodity, which is a quick race to the bottom on margin.

Google has significant dictatorial powers when it comes to Chromebooks, which are not available to the Android folks, even if they had the ability to code sign, and could dictate a code cut, the Android in the tree is pretty raw, and never productized.

Finally, Android lacks a uniform app ecosystem; this is a more or less direct consequence of having allowed third party stores, without a strong compatibility for the apps across all devices.

Seriously, one of the smartest things that Apple did was keep the baseband processor separate from the application processor so that there was no telecom recertification required, unless they were explicitly hacking the baseband for some reason (e.g. the carrier lock they did by re-doing the SIM/IMEI handshake when doing a hand-off between cell towers in order to intentionally break SuperSIMs and similar techniques for hardware carrier unlocks).

Without the app ecosystem and the continuity of app and other content going forward on Android -- which it doesn't -- I don't see a means of enforcing carrier lock-in to support that economic model, particularly if you started supporting software updates.

Actually, it does.

The Android partner model is to snapshot the tree, and then the OEM productizes the snapshot, adding hardware driver support, their own apps and UI changes, and then they do a deal with the carrier for badging and more apps -- like pointing by default to the OEM or carrier's app store, in order to monetize the device further.

This model exists to avoid disclosing information between OEMs and different carriers, since Google does not do the actual productization.

Because of this, pretty much every Android device, other than the ones which were Google-badged as "buy them from Samsung, resell them under the Google name", is a one-off with a one-off version of the OS. In order to update the OS, it'd be necessary to (effectively) re-do the port of the OS to the device for each new version.

On top of that, there's really not a lot of incentive for the carrier to have the versions of the OS an Android phone is running changing on them, since each new one requires recertification, and, depending on the degree of changes made to things like the baseband and changes in electronic noise due to changes in the software, FCC recertification, or whatever the local equivalent happens to be in your home country.

It's like building a whole new phone, except you're not getting paid for it, and theres no upsell to get you back under contract for the next 18 months.

In other words, it's a lose for everyone involved, due to the way the Android/OEM/Carrier relationship is structured, and there's no product continuity upsell like you have with the various iPhone models.

You were lucky. Our schools two Commodore PETs had only cassette decks.

My first impression was, "WTF?! Why would anyone want to do that?" Keep in mind that not only am I typing this on a Chromebook, I basically live on this thing. For what I use it for, it works well. With a web based IDE and an SSH client, you can accomplish almost anything. Entertainment is not a pleasant situation but that's what we have gaming PCs for, right?

ChromeOS does actually have some nice features. It's nice to have updates that only take fifteen seconds, including a full reboot. The battery life is great, and it's really cool to be able to sit down at a brand-new Chromebook, type your google username and password in, and have all of your bookmarks, apps, and files available within 30 seconds. The thing is, I really don't think you're going to be able to get those same features with any other combination of hardware and software. As you point out, the boot speeds are likely not going to be any faster, and I would be surprised to learn that the non-Google versions of ChromeOS had the same, ah, vendor lock-in.

I'm very ambivalent about ChromeOS. It looks nice, it's very secure, it has a number of good features, and I feel like it is particularly good for schools. I've been able to make my Chromebook do what I want, and having a pair of them was really great for wandering around Central America for a year or so doing freelance web development. They're cheap enough to be more-or-less disposable. On the other hand, it's very much not a replacement for a real operating system. The good thing is that it sounds like the OP doesn't need a real operating system. The bad thing is that he probably isn't going to get what he likes about ChromeOS out of this either, no matter what he does. A stripped-down distro is probably the better option.

As an aside, I also share your sentiments with regards to the swapping issue. I've had a bunch of netbooks in addition to this Chromebook, and I've had real Linux running on this machine via both crouton and a direct install. With ChromeOS, I can only have 30-40 tabs open before it starts killing tabs to free up memory, and fewer than that if the pages are resource-heavy like gmail, disqus threads, or videos. In my experience ChromeOS has far more memory issues than other distos on the same or worse hardware. However, I will say that ChromeOS's failure mode of killing pages early and often works very well to prevent the machine from ever becoming unresponsive due to memory/swap issues. It's kinda hard to pick between those two problems, to be honest.

Iain M. Banks had the notion of a 'mind state abstract', where you'd send a copy of (part of) your mind and then either discard it or reintegrate. It would either be downloaded into a drone or biological construct, or just used in VR. It made a lot more sense to me than the transporter, as long as you solve the reintegration problem. Especially on a dangerous mission, I'd prefer to send a copy down and then merge their memories into mine if they survived...

So Is Mac OS X.

I converted time_t to 64 bits on 64 bit systems (which include the most recent iPhones) as part of the changes for 64 bit binary support on the G5 when I wrote the 64 bit binary loader support into exec/fork/spawn, and again as part of UNIX Conformance. It's basically been fixed since Tiger.

Apparently I've not had enough coffee yet (or have spent too long staring at MIPS CPU traces to spot the error) and thought that you said the exact opposite of what you said.

More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.

The issue is only when you pass standard library objects across a library boundary between two libraries compiled for different standard library implementations. It's perfectly safe to pass C and Objective-C values between libraries that use libc++ and libstdc++ internally.

Daz Loader is good, but it does not support UEFI installations, because of the GPT partition format.

What comes to OEM installations, with some trickery there is also a possibility to feed the BIOS SLIC key to Windows Software Licensing Management Tool. This allows to install without an OEM-specific installation media, and it's also legal as you're using the legitimate key from the sticker.

Obviously... if it's AI, and it has some real world utility, then we rename it so that it's not AI any more. Then we complain loudly that "AI has never produced anything useful".