Hacker News new | past | comments | ask | show | jobs | submit login

The difference being that you can install or upgrade Windows on a system without buying a new laptop or requiring support from the vendor; the vendor doesn't lock down laptops to prevent upgrades and force people to buy a new device instead.



Which is mostly a problem that Google themselves architected into Android. By not building a sensible HAL in to android like requiring ACPI in the hardware for the first android phones (especially the moto droid which they worked on closely with Motorola), they condemned us all to vendors-specific kernels and bootloaders.

Google's inept 'management' of the android ecosystem has left us with openness for hardware vendors like Samsung but not end users. Their design of android deprives end users of regular security updates that iOS users enjoy but also deprives them of the right-to-modify that licenses like the GPL were intended to guarantee.

I don't know what everyone at Google intended, beyond 'let's beat Apple', but the way android turned out looks awfully evil to me.


On the Nexus 5X/6P and some other new phones, there's a separate /vendor partition for proprietary blobs that can be updated separately from your Android distro (which is at /system). Granted, the Nexus is Google-related and I'm not sure if that's the case on other devices…

By the way, the upstream Linux kernel supports the Nexus 5X! http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9...

And the bootloaders are based on fastboot pretty much everywhere I think? At least that was the case with the non-Google-related HTC phone I've had.


Samsung's Odin bootloaders are not based on fastboot (or at least I don't think they are). And whatever they are based on, the problem is that they can be locked, depriving end-users of their right-to-modify. And that Google went out of their way at every turn in Android's development to reimplement GPL components with permissive licenses (like Bionic) that would enable hardware vendors to engage in this sort of dickery.

Android is the emblem and sigil of Tivo-ization. And Google was the key enabler of this. I get that this was successful - after all, "Android overtakes Windows as the blah, blah," is very successful. And maybe if Google had behaved ethically Android wouldn't have been the success that it is. Just don't give me any of the "don't be evil" BS. When threatened, Google was every bit as evil as Microsoft was at the height of the browser wars.


Google was just realistic at the time. ARM boards do not have platform services at firmware level, nor plug and play buses like PCI. If Google required that in 2008, Android would have market share similar to Sailfish or FirefoxOS.

Have look at Redhat, how far got them requiring UEFI at server ARM boards. That's market, where the buyers have much more impact on the design than mobile.


Is that our problem or Google's? You can point fingers at 50 different companies in the ecosystem, or you can collectively point the finger at the root cause. By the topic of this article, they're no longer the underdog when it comes to dictating terms to device vendors, they're the biggest shop in town and there's no reason the vulns-frozen-for-life-of-device model should continue to be adhered to.


This represents such a fundamental misunderstanding of the power structures i almost don't know where to begin.

Suffice to say, if it was as easy as waving the magic wand you think it is, it would have happened already.

Instead, if you tried to wave it, handset makers would have walked and just done something else. Heck, some did!

Besides, why stop at Google? Why not blame the carriers for devices like this be on their networks?

By your logic, if Verizon told Samsung tomorrow said "you must update your phone monthly with security updates in order to stay connected to our network" it would have just happened!

Maybe instead of assuming a vast lack of caring or outright maliciousnss, you should consider that maybe it's not the trivial thing you are making it out to be, and that's the real reason it hasn't happened yet.


>Instead, if you tried to wave it, handset makers would have walked and just done something else. Heck, some did!

Yes some have and some more would have. And then it would have been up to these holdouts to come up with a viable OS. Good luck with that. Almost everybody who tried has failed.

There is no doubt in my mind that Google could force it successfully, but why would they? Everything is moving in their direction anyway and users don't seem fazed.


By the same logic: Why wouldn't they?

Surely Google is not intentionally refraining from solving the high fragmentation it is suffering from (which makes developing for Android harder, and keeps some people from receiving security updates)


>Why wouldn't they?

Because it causes friction, it's a distraction for management, and there is a danger that some of those rebel handset makers could have some success or get poached by Microsoft/Bing even if they fail at creating an alternative OS.

There is risk without much upside for Google compared to the gradual approach they are taking now.


Or it is within Googles power, but not within Googles interest to do so, so we in turn have power by getting outraged at Google, shouting from the rooftops and creating an incentive for them to apply more pressure to handset makers.

Walking away from Android is not currently a realistic option for most of them (recent Sony Sailfish news non-withstanding).


You are right, they are just being completely self interested and it would all just work out happily if only they would just beat people over the head repeatedly. That has worked out so great in the past for them and others, and would not result in Android being abandoned wholesale for something worse inside of two years.

If only they had thought of this. Oh, that's right, I forgot, it's not that this is much more nuanced and complex ecosystem interplay, it's that it's very black and white and they uniformly don't give a crap.


I mostly agree with you (Mencken's famous Quote about complex problems comes to mind), but I don't think we shouldn't assume no responsibility on Google's end either. This whole economy of "throw-away devices" without much more than a couple of very late patches seems to have been facilitated in ordes to boost Android's adoption - which arguably worked out for them.

Sadly this also leaves us with the current sorry state of affairs. I don't think much "could've" and "would've" would be helping there, but I would very much like to see a major economic force guaranteeing some common grounds for devices. Imagine what an "IBM clone era" of phones could mean - all it would take would be a common ground w.r.t booting and a couple of drivers.

Sometimes I'm really left wondering why we can't have such nice things...


If they cared one second about it, they would have changed the terms of access to the Google services.

The sad part is that the 2016 security report just came out and they brag how the whole security improved, without mentioning the elephant in the room.

Google IO is around the corner and I bet they will keep talking as if everyone could upgrade right away to Android O, with N now having barely 2%.


And that even google-sourced devices have a very short lifecycle for OS and security updates. Google seem to be running under the assumption any phone over 12 months old is reaching the end of its usable life.


Google has a engineering philosophy of constantly deprecating old stuff. They largely ignore backward compatibility and stop supporting stuff all the time. Their SOAP API for AdWords would break if it wasn't updated every 3 months and this is an API for paying Google money! They are trying to do this in the consumer space, but I don't think this is going to work for things like Nest where people don't want to have to upgrade their thermostat to the new model every year.


Nothing unique to Google. I have taken to consider it the Web-Dev/push-To-Prod mentality. This because on the web a change is a page reload away.

And this mentality is eating its way into all corners of IT as there is a generational changing of the guards. More and more Linus Torvalds (Linux) and Daniel Stenberg (cURL) staying with a project for decades are massive outliers rather than a norm.


Well, if you use your phone a lot you kind of have to buy a new phone regardless. Non-replaceable batteries should be illegal.


An ARM Chromebook that I bought more than 4 years ago still receives updates.


So does my 9 year old HP Elitebook running Win10 now. The problem is that vendors are allowed a say in the matter. If MS used the Android model I'm sure PCs wouldn't be update either.


Yes and no. While Google will backport security fixes, and change the Chrome related layer, the kernel version you are running is likely the very same one your Chromebook shipped with.

This is why they can claim that anything shipped from 2017 onwards will support Android apps, but maintain a list of potential devices from before that. Because said support need various container related features only found in newer kernels to work.

Effectively Google has further masked but not really fixed the issues that makes major updates to Android devices such a hassle.


Google did updated kernel on the Chromebook. It happened at least 3 times IIRC.


A Google device receives security updates for 36 months. Not sure where you pulled your 12 months from.


Ah I'm a little salty because although you get security updates for 3 years you only get feature updates for 18 months. Combine that with the fact the Google so poorly plan their product releases that supply is constrained for the first 6 months of the product lifecycle. So in practice someone who manages to buy a device when they're generally available has at best a year to get updates for their shiny new $500-$900 device. It was egregious when a new Nexus device was $500+, now it's outrageous.

The Pixel XL was released in October of 2017 which means updates stop one year away from today in April of 2019. Top of the line is $968 and you want top of the line for best memory performance. Why buy one of those phones and purchase sub par performance? It's a waste of money. So if I wanted one I'd pay $80/month for a device that's replaced in October of this year (Pixel 2 is supposedly an end-of-year release) and dropped from feature upgrades not too long after that.

Google need to fix their feature window by extending it to two years and fix their supply pipeline by ordering apple-like quantities of product. Otherwise they're not really competing with Apple.


Google has broken out GMS from android core so that they can do OTA updates w/o updating the OS itself. I do agree this needs to be better, however its also a non-trivial problem to solve.


How is signing a contract, with the respective legal consequences for breach of contract, a non-trivial problem to solve?


Because suing customers is sure to improve things! That's definitely the path to greater cooperation and goodness. Do you really believe any of these companies would sign that instead of going with whatever plan b is? If so, I guess n-gate is right.

But let's follow this silly thread anyway. On average, the lawsuit would take three to seven years to resolve.

Assume they win: great, they get some small amount of damages and everyone stops using Android. They can't and won't ever get the remedy of forcing security updates. It's not even something available.

Assume they lose: great, they get nothing and everyone stops using Android.

...

What did this solve again?


Let them stop selling phones with Android, create their own forks and lets see whose devices the public will bother to buy.


Everyone (who buys Google phones) can upgrade right away. It's not Google's fault that the other manufacturers refuse to update their products in a timely manner. The responsibility for these devices lies solely with the manufacturer.


Surely it is their fault, because Google is the very first to give the example of selling devices more expensive than desktop computers, above the minimum wage in many countries, with updates limited to 2 years (+1 for some fixes).

As for the other OEMs, there is this thing called contracts and legal obligations.

No updates, no access to Google services from invalid devices.

It is as easy as that, if Google actually cared about the consumers.


[flagged]


Isn't 36 months 2 + 1 years?

Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.

Google seems to have little interest in anything beyond the short horizon and that security tech debt is going to come due.


>Isn't 36 months 2 + 1 years?

He stated "+1 for some fixes" which is incorrect as it implies that you may not get all of the security fixes for that additional year and only "some" of them.

>Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.

I agree it is rather short and the sooner Android OEM's can move from an SoC supplier, like Qualcomm, that only provides BSP support for 2 years the better.


«He stated "+1 for some fixes" which is incorrect as it implies that you may not get all of the security fixes for that additional year and only "some" of them.»

Interesting.

The OP's statement was for "upgrades" not security fixes; I read it as 2 years upgrades and 1 for security fixes beyond feature upgrades. The choice of "some" was ambiguous, but "upgrades" is much less ambiguous to me than you seem to consider and not something I'd directly confuse with "security fixes" alone and something that the (+ 1) seemed to directly add "security feature" context to me, despite the ambiguous wording.

Though that still raises the question of if Google properly subsets general (feature) upgrades and security fixes across that 2 + 1 time period. The ambiguous word choice of "some" could be an editorial indication that the OP considers that Google is likely to release some fixes in more general upgrades that don't fall into that (+ 1) time period. As a non-Android user/follower, I have no knowledge in that area and no opinion to offer of my own if that may in fact be the case. I'm also not the OP so I can't express whether or not that was an editorial opinion.

Even if it was an editorial opinion that was expressed, I'm still not convinced it was "disingenuous on purpose", as it may very well be a sincere/candid opinion of the OP. I can only leave that for the OP to comment on.


The OP said "updates" not "upgrades". The use of the word "some" is not correct regardless of what context you try to paint it in.


I stand by my remark, as I don't have a way to confirm what security updates Google bothers to release at all to "outdated" devices.


Of course there's a way to confirm what security updates Google releases. You just have to go to the Android Security Bulletin site [1]. You know this, but it would conflict with your agenda of spreading Google/Android FUD because of your perpetual grievances with Google surrounding the Google/Oracle trial.

[1]https://source.android.com/security/bulletin/


Where does it state which devices got which patch level?

Just because a fix is available today doesn't mean an old Nexus will get it.

As for agenda, as a consumer and developer, I want a device where I am able to use the same Java libraries as on a regular Java and get updates as on any of my computers without having to pay more than a month salary for such time limited privilege.


It kind of is Google's fault. Most people associate any version of Android with Google. Manufactures that don't update their phones causes harm to both the manufacture's image and Google image.

Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.


> It kind of is Google's fault. Most people associate any version of Android with Google. Manufactures that don't update their phones causes harm to both the manufacture's image and Google image.

This makes no sense. "People associate X with Y" is not the same as "Y is responsible for X". If I associate Android with Linux, is Linus now culpable for Android's security problems?

> Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.

If we were living in a fantasy land where you could wave a wand and things would happen instantly, this would be the case, but mobile devices are not desktops and the challenges they face are entirely different. Google has already been moving logic as much as possible into apps like Google Play Services (updateable without OS changes_, and the fact that they haven't moved everything should make all but the most technically illiterate think "There may be technical challenges involved", instead of your "They're not making this easy" approach.


In an open marketplace, "People associate X with Y" is very much the same as "Y is responsible for X." This explains a lot of the legacy code in pre-Windows Vista Windows; if new versions of the OS broke someone's favorite app, they blame Windows, even if the reason the app broke is it didn't adhere to (or even actively tried to circumvent) published API (Adobe was notorious for trying to squeeze a few extra cycles of performance out of Photoshop, for example, by hand-rolling their own C++ data structure instances by building a binary-compatible pattern in memory instead of calling the documented constructor in the WinAPI).


> "People associate X with Y" is not the same as "Y is responsible for X".

I understand that, but many of the non-tech savvy people I know do not understand that Google is not responsible for most versions of Android that run on their phones.

> ...but mobile devices are not desktops and the challenges they face are entirely different.

I do not see how they are much different. To many people, their phone is just as important as their desktop/laptop. I do not see anything stopping updates to Android being invisible to the end use as most other updates. iOS is pretty good about updating in a way that is unobtrusive to the user and Windows 10 is getting closer.


But Android is not considered a Linux distro by most stretches. It's Android's fault.

It should have been called a "platform", and, since Google has the ability to say so, they should have told each hardware maker to come up with an OS name "on Android". Tizen on Android. NexusOS on Android. So on.

OR, they should have gone Apple and said "you will have this OS, Android, and it will look as such, and it will be patched as such".


> This makes no sense. "People associate X with Y" is not the same as "Y is responsible for X". If I associate Android with Linux, is Linus now culpable for Android's security problems?

This is ridiculous. Linus in Android is a component, not a whole system, and phone vendor own SW are way too accessory in the ecosystem and add so little value in it that they don't render Android a mere component in the same way: the base Android is the system, whereas drivers and 3rd party GUI or other minor stuff are what should be sufficiently decoupled so that Android can be updated without vendor consent.

Doing otherwise has proven to expose users at risk, and given its situation Google is responsible, not a swarn of phone vendors.

I might not be saying that if Android was really open, but then Android might not have that market share. Well, in the end, even that reinforce the argument that Google is responsible...


I dunno. Enthusiasts may track the versions coming out of Google HQ. But for most updating is a hassle rather than something they look forward to. This because it means downtime for their device, and if the update fails it may leave them with a bricked device (chance is small, but it is still in the back of their mind).

For most people a computer, a phone, or a tablet is an appliance.


iOS updates are something that seems like many people look forward too. If Android updates were as unobtrusive as updates to iOS (even Windows 10 is getting closer to unobtrusive updating), then there wouldn't be much of an issue there.

We are getting closer to the point where being secure and up to date is almost painless. That should be our goal in the tech industry.


They are more painless if you happen to have a Pixel. It downloads and installs the update on another partition, prompts for a reboot and comes up a minute later. The trade-off, of course, is space.


Try telling that to anyone owning a Nexus 5 (still a very viable phone) or older.


Yes and no. Google could rework Android such that it would be easier for companies to apply their own UX without doing deep code changes.

Also, they could isolate the Java VM layer further such that it could be updated independently of the Linux kernel and related userland.


This excuse completely ignores the fact that through the MADA contract, Google controls all of the manufacturers and defines whether or not they are allowed to sell Android phones, effectively. And that the OS is designed, by Google, to require the manufacturer to distribute the update, rather than, as with... pretty much all other OSes, the software developer being responsible for updating their own software.

Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.


Google does not control whether OEM's are allowed to sell Android phones. Does Google control the sale of all of those Chinese branded phones that don't ship with Google Play Services? Or how about the Blackphone or the Copperhead phone? The MADA simply states what is required if your phone wants to ship with Google Play Services and Apps.

>Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.

This sentence makes so sense. Google cannot update an OS that they did not create. The OEM rolled the OS so only they can update it. How exactly does Google update an OS from an OEM they don't even have the source for? It's the OEM's responsibility and if that OEM doesn't do their job in updating their OS then maybe it's time to start looking for an OEM that does do their job.


There's a confusion here between the Android's clone of the GNU libraries (to escape the GPL3 license) which is open source, plus the linux kernel, also open source; and the NOT open source Google Android OS which is much more than this, including a Java engine and a helluva lot of other parts including but not limited to the app store. China's Android-ish phones use the replacement library functions Google built and the Linux kernel. The Chinese could go all GPL3 and ignore any Google/Android contribution at all if they cared to - they don't because they too want to get away from the GPL3 license (with it's software and hardware patent grab and anti-tivoization clause that forbids locking down the phone, even for security purposes.)


1. Note my use of the word "effectively". Unless you're in China, where Google does not operate, there is no such thing as Android without Google Play Services. (Attempts to sell Android devices without Google Play outside of China have, for the most part[1], been dismal failures.) And Google has to give their written approval for the release of each and every device or software update of Android with Google Play Services.

2. Google created the OS. In fact, OEMs are forbidden from forking Android, and therefore, cannot "roll their own OS" from Android, without violating their agreement with Google. Yes, they sprinkle some of their own apps and drivers in, but this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.

I know for a fact you and I have had this discussion before.

[1]Someone will mention the Kindle. The Kindle does not compete with Google products, as it is perceived in the market as an e-reader more than a "tablet". And Google barely even does tablets anymore anyways.


> Google created the OS. In fact, OEMs are forbidden from forking Android, and therefore, cannot "roll their own OS" from Android, without violating their agreement with Google. Yes, they sprinkle some of their own apps and drivers in, but this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.

Forbidden from forking Android? Every OEM version of Android is a fork. What Google does not allow is for an OEM to distribute a version of Android that does not pass the Android Compatibility Test Suite.

>therefore, cannot "roll their own OS" from Android

Do you know how OEM's "roll their own OS"? They take the AOSP source code that Google drops and then they add all of their source code and then build and distribute their own version of Android that only they can update.

>Yes, they sprinkle some of their own apps and drivers

I'm not sure you really understand all of the changes OEM's make to Android if all you think they do is "sprinkle some of their own apps and drivers in"

>this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.

No it's not. Google does not build Android for the OEM's. They create their own version of Android and therefore are ultimately responsible for updating it. Once again, Google cannot update an OS they did not build.

>Google barely even does tablets anymore anyways.

Android is still the marketshare leader in tablets.


> They take the AOSP source code that Google drops and then they add all of their source code and then build and distribute their own version of Android that only they can update.

Yep that's a insanely huge design flaw, coherent with: "Google needs to be updating their own software independently of manufacturer-specific components."


So an OEM being allowed to build their own OS is a huge design flaw?

Is Debian also responsible for Ubuntu's security flaws?


It isn't "their own OS". It's Google's OS, which is explicitly and directly controlled by Google's contracts, which you continue to pretend do not exist. It is a single platform, and it is by no means an open source one. If it was, it wouldn't require the explicit approval of a single corporate entry to distribute it or any updates to it.


Yes, it actually is. An OEM builds their own OS from source. Google does not own their OS. Also, why are you claiming that I'm pretending that the MADA contract does not exist? If an OEM wants Google Play Services and Apps then they must agree to the terms in the MADA. It appears you have an problem separating the Android OS the OEM builds and the Google Apps and Services that are given to them.


As I recall, Google tried a laxer approach early in Android's history, and the quality results were pretty disastrous.

Why do we fault the company for taking steps to pull Android as a brand together?


I actually really loved the choice and freedom we used to have and Android, and thought it was a valuable trade off for platform unity. Now we have a very homogenous platform that is still horribly insecure... The worst of both worlds.

Google uses their agreements with OEMs to force them to bundle apps and including Google's branding, and protect their business, but refuses to use those agreements to ensure even basic security for their users.


I don't think I follow. In what sense is Android horribly insecure? More interestingly: in what sense is it horribly insecure that it wouldn't be if we lived in a world where Google didn't have the market agreements to, say, force security patches for pieces of the Android OS core that were broken?

Because we already lived in that world, and it was less secure than the one we live in now, to my memory. Security issue in one of the Android libraries that are now part of Play Services? Good luck; wait for your OEM to update your OS.


Let me ask a (potentially) very stupid question here: What prevents doing the same on phones?

What would make a phone hardware able to install anything that compiles to its CPU architecture the same way a PC can?


Paraphrase the question in the reverse and you get your answer: What makes this possible on Windows desktops?

Stable binary driver ABI. Hardware monoculture. Expensive driver certification program. Letting hardware vendors release binary drivers without releasing the corresponding sources. An opt-out automatic update mechanism.

(Disclaimer: I work at Google, but not on the Android team.)


Hardware monoculture? Surely you must be joking. There are only a few to several dozen current Android phone models being sold at a given time. There are thousands upon thousands of PC models being sold among major manufacturers. This doesnt even begin to account for home builds or customizations. There is a very slim chamce that anyone has the exact same hardware config as my PC, yet Windows still has to work on it. Sure, vast majority of Windows is x86/x64, but that doesn't mean it is a hardware monoculture.


If you break those PC models open what's really different? The hardware interfaces of PC has almost always been stable since the age of IBM PC clones. It might not be a monoculture in terms of all the RGB lightings you can put on your machine, but you definitely don't need to worry about different protocols. All the while Android phones can have the weirdest SoC's on the planet in them.


I admittedly have zero experience with configuring HW with ARM.

However, to say that HW interfaces on the PC have been stable since the age of IBM PC clones is a joke. In the DOS days, users manually had to manually set IO memory addresses and IRQ levels. Early Windows sat on top of DOS, so still had to do it there. Plug'n'Play didn't show up until Windows 95, and even then it was hit and miss. Some devices worked, others required manual configuration. RTM Win95 didn't support USB, either. That took the equivalent of a service pack (although, IIRC, they went by a different name back then. I want to say OSR1 added USB 1.1 support). Windows drivers didn't really get friendlier until the push to the NT kernel & it's HAL. Win2k had limited, but good support. WinXP got better. Vista was a step backwards. Win7, 8 and 10 have incrementally improved on Vista. Even on Windows 10, though, I have updates that "forget" a subset of my USB controllers. Windows doesn't know about drivers for my HOTAS. Most recent windows updates cause it to forget about my secondary monitor. Half the time after an update, my USB keyboard doesn't work (I have to login on my desktop using an on-screen keyboard to correct settings). I'm probably one of the only (or a small handful) of people that have a Geforce 690 & 1080 in the same system. Sure, PC might be better in that most peripherals go over USB. But, not all USB devices work with a generic driver, and Windows often doesn't include non-generic drivers for all but the most popular devices.


Let's ignore the historical legacy non-PNP ISA config nightmare, because they do not bring anything of value in this discussion.

The core system of PC is highly compatible with OSes in pretty much all directions. (Well now even if I don't ignore the non-PNP ISA configurations stuffs, it does not really change the situation: those were not for core system stuffs)

Then you have drivers for various bus controllers and peripheral, some of which are crucial for using your PC in practice, but as soon as the necessary driver exists, loaded by the kernel way after the core boot, and highly abstracted on all modern OSes (it only access the HW through functions abstracted by the OS)

For non-ancient PC, you even have with ACPI some abstracted functions, provided by the HW, and used at the runtime by the OS. It's to be considered as part of the core plateform, as if it was a pure HW interface, given what we are discussing about. The NT HAL, btw, is a vestigial of early NT years, and is of zero interest for the purpose of PC compatibility today (there is only one HAL that is in use on modern PCs, and IIRC switching the HAL was not even enough when multiple were in use IIRC, other MS binaries still needed to be recompiled -- so the NT HAL is merely an internal detail that bring no consequence in backward or fw compat as far as decoupling of binaries and their update of a partial subset in a system is concerned)

Now the situation for ARM SoC for Android is NOT the same. You just don't boot a generic ARM Linux kernel to driver your random ARM SoC of your random phone. Because even what could constitute an equivalent core system as what exists for PC, follows no standard.


You still need all of these things. An x64 Intel Processor manufactured in 2017 still boots into real mode at startup exactly like the original did 30 years ago. Complete with segmented mode without memory protection, multitasking, or code privilege levels, just as AT/AT compatible as the day it was born.


Thanks for reminding me of Plug'N'Pray. Some stuff worked but a lot didn't, likely the cheap rubbish hardware I bought with lame drivers. And trying to load a mouse driver for DOS and play a game that needed himem. Or trying the set the right IRQ to get the DOS game to believe you had an Adlib or SB16 compatible card....

The kids today don't know how easy things are with unified drivers for audio on Mac OS etc. I mean, even USB coming out was amazing instead of serial devices and guessing the COM port? Which LPT1?? And dial up etc etc so easy now.


My understanding is the interface between hardware and kernel is more vendor-specific on ARM than it is on the PC. So the PC has lots of hardware diversity but the way you talk to a given device is already somewhat abstracted from the perspective of the kernel.


A major thing you have on PCs that you do not have on ARM is bus query.

With PCI and later the OS can ask each device on the bus to ID itself and thus figure out if it is a known device type or not (and if not, ask the admin to install drivers).

On ARM You have things sitting off various buses that expect the kernel to know what they are and how to talk to them from the word go.

It has gotten better as now there exist something known as a device tree that can be read by the kernel at boot. But not every SoC provide support.


Intel started work on Moblin back in the day because Microsoft balked at bringing Windows to a x86 platform without PCI device enumeration.

Heck, if you crack open the ARM based Windows RT tablets you will find quite the odd duck of an ARM SoC inside. One more reminiscent of a x86 PC than what you find in your average Android device.


I think you're overstating the value of most of those things, because it's also possible on Linux desktops too. You can take a typical off-the-shelf x86 laptop, pop a disk in, and install Linux on it.

IMO the key point out of the things you mentioned is the hardware monoculture, because that definitely does help people get Linux running (and keep it running) on new hardware. I'm skeptical about most of the others.


Your example actually helps prove the point: the fact that Linux can use some of these advantages but not others lines up pretty neatly with the fact that it's generally harder to get Linux running on a given system than it is Windows. I say this as someone whose used Linux and thinks that practically everyone could benefit from giving Linux a try as their primary personal computer (with the always-major caveat that you have to be careful about hardware purchases and/or have someone knowledgeable set it up).


Windows runs on many CPU architectures. Android phones are packed with binary blobs.


Windows is one giant binary blob. Also, Android runs on many CPU architectures as well.


So it's Linux fault and Fuchsia is the solution, right? :)


What is this "fuck sea" you're talking about and how do I sail in it?


It's Google's best shot so far at provoking "Android is dead" rumours: http://www.androidpolice.com/2017/02/15/speculation-around-g...

But the reason I brought it up is that Fuchsia OS will have a stable driver ABI.


I don't really understand it either.

I get Windows security updates on every damn computer I buy. Yes, the computer is pre-loaded with bloat, but I still get updates like everyone else.

Meanwhile, on Android, I mostly get nothing. What is so fundamentally different between PC and phone? Why is it so hard on mobile phones?


Does your OEM create their version of Windows? No, they ship the binaries they receive from Microsoft. As long as Android OEM's are allowed to build their own version of Android this problem will always be in the hands of the OEM.


Well they sort of do, by adding pre-installed bloat.

But it's still Windows.

I just wonder why that is. Maybe Microsoft has stricter licensing?


There's a pretty huge difference between modifying the os and its desktop environment compared to just adding a few extra bloated apps and some wallpapers...


There's a big difference between an OEM merging their source code with Google's AOSP source code and then compiling it to build an OS than just adding crapware to a Windows installation. OEM's can't modify the Windows source code and can only distribute the OS given to them.


"What would make a phone hardware able to install anything that compiles to its CPU architecture the same way a PC can?"

The reason your question is "stupid" is because you think your phone is just one computer.

In fact, you can do just what you describe - and it wouldn't be that difficult - but it would only be for the application processor and you would end up with a nice PDA.

In order to make phone calls you would also need to control the other two, fully functional, general purpose computers inside of your phone: the baseband processor and the SIM card.

Currently, there is no way for you to control either of those in any meaningful way.[1]

There are deeply entrenched economic and technical forces standing in the way of controlling your own baseband processor and we are nowhere near to doing it.

[1] Osmocom on 2G phones is not meaningful, no matter how impressive and interesting it is.


hey thanks I think you hit the point very well here. But then how about tablets for example?


The short answer is that phone hardware is all over the place .. x86/64 has actually made generic kernels (including Windows) possible by having a slew of very similar machines. You can't expect the same thing from ARM systems yet - each system has to be specially targeted.


There are Windows versions that work on ARM: phone/mobile, and Win10 IoT.

They update just fine, sometimes even on the major versions. E.g. my phone initially had windows phone 8.1 and now it’s windows mobile 10. And despite the phone is 3 years old, I'm still regularly getting OS updates.

That’s why I don’t believe ARM hardware is responsible.


Not sure about ARM/Windows vs ARM/Android, but I do know that unlike the PC, Android ARM phones at least do not have things like a standardized BIOS, standardized peripheral bus enumeration, low-level firmware to hardware interface etc, or at least not to the same level..

This is why things like SBSA (https://en.wikipedia.org/wiki/Server_Base_System_Architectur...) were needed before ARM servers could even be talked about, and why things like Rasberry PI's are not directly compatible with BeagleBones, etc, at least for the low-level stuff..

Nothing to do with ARM itself; just lack of ARM standards.

This was similar in the early PC days and had similar headaches - compare the various CP/M machines with what became the 'standard' MS-DOS/IBM-PC 'platform'..


PCs do not have a standardized BIOS. BIOS configuration options vary widely, and often mean different things between different BIOS vendors. UEFI is standardized but sometimes difficult to adopt.


It is half-responsible, but MS did the necessary thing to achieve their capability to independently update the OS (and deliver it as binaries, instead of letting phone vendors built it from source, which MS do not want to distribute to anybody): they specified a common plateforme for ARM phones, that is, IIRC, basically ARM + ACPI.

Then they mandated secure boot with keys that cannot be controlled by the user, so that other systems can not leverage the platform on W10M hw :p . (That's in the spirit of what BG wanted for ACPI: something somehow incompatible with other OSes -- MS eventually managed to do this with a sidestep, but well, this did not really help their market share :P )


Pretty much. MS even balked at supporting mobile ATOM back in the day, because Intel had stripped out PCI support to reduce power requirements.

The The PocketPC and Windows Mobile situation was not much different from the Android situation today, i believe.


No, they're all similar enough. Only things forcing the upgrades are...

- Android breaks compat with old drivers every update - HW makers only ship (often vulnerable) binary blobs.


and you also have other things such as other pieces of hardware the the os needs to talk to. this might not be part of what "android is", in it's barebones, so you can't just hope to build an updated version of the os and that's it. a lot of vendors customise their android builds, which means that they need to be the ones pushing updates. i'm not siding with google, but that's the way it is. could they have done a better job in assuring continued security updates? yes, but they were far too focused on trying to spread android everywhere they could.


Qualcomm distributes firmware blobs. Once the blob is out of date you cannot use it on a newer version of Android.

(And device manufacturers do this too, but it's a ton easier to, say, fix flash with a shim than it is to fix networking.)


Pardon my ignorance, but... doesn't Android run on top of the firmware? You're saying newer versions of Android are breaking backward compatibility with older firmware?


As Android evolves, you need to update drivers to keep in step with new features (pretty much the same as with Windows - you need new drivers for newer Windows usually). But as opposed to Windows, Linux kernel doesn't really have a very stable driver API and the manufacturers love to patch and mess with the kernel itself to get their hardware working. As such, porting closed-source drivers to newer Android OSes is usually impossible without support from the manufacturers.

Qualcomm (by far the most popular hardware vendor for Android devices) doesn't care about supporting their released hardware.


Its a bit more complicated than that.

Quite often these days when a part is initialized, the driver uploads firmware as part of that.

If you look at most Linux distros they have a package of firmwares that various companies have allowed to be distributed with the kernel.

Meaning there is a small part of the Qualcomm blob that needs to interface with the kernel to upload the firmware.

And the interface changes as the kernel changes. This because Linux devs don't want the hassle of trying to debug a kernel panic only to find that it is happening inside a third party blob, and thus they can't fix it. Instead they want companies to either work with them to maintain drivers or hand them the information needed to maintain a open driver within the kernel source.


We can thank our lucky stars by design or accident of history the PC remains the only true open platform for end users.

Linux and its wide adoption, the ability of users to pick and choose hardware and software would simply not have been possible if Microsoft and Intel took the Google-ARM model to 'openness'.

Google and ARM pay lip sync to open source but users are locked tightly to their devices and OS. Users cannot even install updates let alone things like Linux which Android is based on.

The drivers work perfectly on Android yet users trying to install Linux on ARM socs cannot use these drivers? Open source developers struggle for years with ARM and Google with no results. How exactly did this come to pass without by design? There can always be myriad 'reasons' and excuses but the fact is ARM completely controls the hardware and Google completely controls the software and it's their design and decisions that drives net negative results for users and open source.


>The difference being that you can install or upgrade Windows on a system without buying a new laptop or requiring support from the vendor; the vendor doesn't lock down laptops to prevent upgrades and force people to buy a new device instead.

As a poweruser, I have installed new versions of Windows AND new versions of Android.

To the average user, neither is feasible.

To a technical user, both are possible.

I don't like this comparison. Many of us switch out AndroidOS's very frequently. It's actually not hard at all to install a custom recovery and load a different and custom version of android.

In fact, considering how defined the android ecosystem of alternative OS's is, and how undefined the Microsoft one is, one could easily suggest that Android is far less locked down.

After all, some Android replacements like Cyanogen/Lineage are far more developed and popular than Windows replacements.


I think there is a shocking difference here. Windows install is, for all compatible devices:

1. Insert install disc/USB. 2. Boot to install disc. 3. Spam the next button.

Installing new Android OS versions manually often involves custom third party unlock tools from sketchy download sites.


And yet, if you ask a non-technical user to install a new OS, it's entirely likely they'll refuse, be uncomfortable with the implications of what they're doing, and if you do force them to do it, will be frustrated with the result.

I worked in a Computer Repair shop for years through college and believe me, the average user has ZERO interest in installing or re-installing an OS. They will pay >$100 to have someone "spam next a few times" as you put it.

I would call that a distinction without a difference. End result is the same: non-technical users do not do it.


On the other hand, semi-technical users would probably do a windows reinstall if they knew they had a techie friend handy to call, but probably would not run an bootloader crack that has the potential to brick their phone, and instead would ask the same techie friend to do it for them.


The point is that many technical users do not install custom versions of Android, though. We all agree on non technical users, but changing Android version is still more complex, to the point that many people comfortable with upgrading a desktop will not mess with their phone


This is true. And I suspect, a major reason behind Microsoft's much-derided upgrade process for Windows 10.


There's a subset of handsets that have a locked bootloader, which means they cannot even flash the device themselves.


> The difference being that you can install or upgrade Windows on a system without buying a new laptop or requiring support from the vendor

You are looking at the past with rose-tinted glasses, or you got very lucky with drivers. New drivers were required for every new Windows version from Win 2000 to Windows 7,even for the display (or if you are unlucky, Ethernet). The only way to get those drivers was via support from the vendor. I distinctly recall trawling dodgy 4th party driver aggregation websites, downloading and burning them to CDs in internet cafes multiple times.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: