I guess this means we can officially stop hating on Microsoft for having such a lax attitude towards security, considering their last OS to suffer from that attitude was released 16 years ago, and it accounts for less than 3% of present day traffic according to statcounter.com
Meanwhile according to the same stats, Android sits around 37.9%, and I have to wonder just how many of those devices are still impacted by for example the 2015 libstagefright vulnerability. Given Google's guiltless ongoing "throw code over the wall" approach to security and passing the buck on to vendors who almost never ship firmware updates for old handsets, perhaps now is the time for us to begin holding Google to the same standard we applied to Microsoft a decade ago.
Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft. You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago
edit: If it weren't clear, the tragedy here is that instead of most devices being governed by a well-tested security process owned by a single responsible vendor, they're at the mercy of a plethora of downstream vendors who do nothing, with the ultimate upstream washing its hands and paying little more than immature lip service to the issue, never mind having anything that even remotely resembles a solid process.
As somebody who has been following Android for a while, this statement is incredibly unfair. The Android ecosystem is huge and remarkably safe. For those actually interested in the details, the Android security team releases annual security reviews, and the report for 2016 was just released: https://security.googleblog.com/2017/03/diverse-protections-...
The tldr: the number of devices with a harmful app is 0.05%, and for 1.5B devices extremely impressive. Basically, if you only install apps from Google Play and never enable unknown sources (the default and the vast majority of users) you are safe.
While the argument that most devices aren't running the latest security patch is certainly valid, it's important to note that there are many services running on device and in the cloud provided by Google which are doing most of the heavy lifting. If anything, the example of Stagefright actually shows the safety of Android - many many devices have never received any security patch to address Stagefright and yet most users aren't affected.
Citing Google's blog post for Android security is not very convincing. If Android is so secure, why are we seeing (often more frequently than) weekly headlines on Android security woes, often containing something like "millions of devices affected" (and often enough, no fix in sight)?
Also, quote from linked blog post:
> only 0.05 percent of devices that downloaded apps exclusively from Play contained a PHA.
1. What percentage of Android devices download apps exclusively from Play? They don't say. I, for one, have quite a few not so technical friends who sideload stuff. Also, pretty much all Android devices in Mainland China don't qualify for this criterion, and that's a huge number.
2. Given the track record of malware in Play Store, the number of devices containing a PHA is probably much larger than that of ones containing a known PHA.
> many many devices have never received any security patch to address Stagefright and yet most users aren't affected.
Not sure how you even know that. Not all exploits are visible.
In today's media environment is it strange scary-sounding headlines are published without deep analysis or actual evidence to back them up? But headlines saying devices are vulnerable is not evidence that the Android users are adversely impacted by PHA.
On the other hand, I referenced a report with actual numbers of devices impacted. Obviously you should be skeptical, but as you point out, if millions of devices affected is true, shouldn't we be seeing millions of instances of Android spam, remote roots, SMS fraud, botnets, etc.?
Yes, it is true that some users sideload, and threats to Android users vary a lot by country. There is only so much Google can reasonably do, and this is appropriate given Android is open source and has so many participants (device vendors, carriers, app stores, etc.). But it turns out with good integration with the developers, the distribution platform, and regular check ups, you can do a decent job at protecting your users.
You can also compare to other platforms and recall how devastating actual malware on Windows was, and how long Microsoft struggled (and still struggles) to protect their users. In Android, yes there are many vulnerabilities like Stagefright found, but in the end Android users are surprisingly safe.
> ... scary-sounding headlines are published without deep analysis or actual evidence to back them up...
Scary-sounding headlines, sure. But there usually is actual evidence.
> I referenced a report with actual numbers of devices impacted.
No, there is no "actual numbers of devices impacted". A number 1.4 billion is thrown out to impress; the pool of devices to which their analysis applies is much smaller, and of which only a percentage is given.
> if millions of devices affected is true, shouldn't we be seeing millions of instances of Android spam, remote roots, SMS fraud, botnets, etc.?
First, what you mentioned do exist. Maybe not in large numbers (not sure), but there's no guarantee they're not rising. Secondly, there are plenty of easier and more profitable channels for hackers these days. Please don't equate vulnerabilities not being exploited with being invulnerable.
> There is only so much Google can reasonably do.
Changing the subject? I was responding to "The Android ecosystem is huge and remarkably safe", and specifically how you quoted the blog post to back that up.
> ... in the end Android users are surprisingly safe.
Webcam users are surprisingly safe too. Not realizing their webcams are DDoS'ing some poor website right now, or their video feed is being streamed online.
> Scary-sounding headlines, sure. But there usually is actual evidence.
Actually, there usually isn't any evidence. Scary headlines sell, finding evidence is a hard work that most readers will not understand anyway. Guess what happens then.
>Citing Google's blog post for Android security is not very convincing.
So instead of believing metrics gathered from Google's SafetyNet telemetry from 1.4 billion devices you would rather believe scaremongering blog posts that have no concrete data to back up their claims?
>If Android is so secure, why are we seeing (often more frequently than) weekly headlines on Android security woes, often containing something like "millions of devices affected" (and often enough, no fix in sight)?
Do you really think it's that easy to exploit an Android phone? Once you have an exploit you must then chain it with other exploits to get around all of the Android security mitigation's in place. And then there's the fact that every OEM creates their own version of Android so not every exploit will work on every device or OS version - you can thank device and OS fragmentation for that one.
So this is why bugs like Stagefright never panned out to be the security armageddon that these click bait blog sites all wanted you to believe. Just because an exploit is discovered doesn't really mean it's being exploited in the wild.
Most Android issues arise due to either vendors which don't update the devices, or malicious vendors that actually pre-install malware (beware of phones ordered from aliexpress etc ...).
Android is open source, after all. Not much Google can do there.
Why wouldn't a device receive updates when the manufacturer abandons it? Most laptops from 2008 long abandoned by their manufacturers still run Windows 10.
If Microsoft can pull it off Google can do it too. No excuses.
stagefright is the last major Android vulnerability I'm aware of. Do you have sources for these? In my experience it's far less than weekly. Maybe yearly at most.
And where is your proof that Stagefright is actively being exploited? All you did was point to a scaremongering blog post with no data.
According to Adrian Ludwig, Android security director, not 1 Stagefright exploit has ever been seen in the wild according to the telemetry they receive from SafetyNet and the 1.4 billion devices it's installed on.
It's directly Google's fault that even the Play Store app isn't available. They make Google Play not easily installable. Their own help page says, after looking for the app:
"If the Google Play Store app still isn't showing up, contact your carrier or manufacturer for help. "
>Why doesn't Google allow it to be installed on all devices?
You can install it on devices (with varying difficulty depending on if you can unlock bootloader). It just doesn't come pre-installed on any device sold within China.
I think there is a difference between Google branded Android and AOSP (Android Open Source). Anybody (users or carriers or phone manufacturers) can build and install AOSP, and Google can't provide updates or force them to install Google play store. Also, AOSP being open source is easier to tinker with (install apps from unverified sources etc.).
When media reports security bugs for Android, it is hardly clear whether the bugs affect AOSP or the Google branded Android, and to what extend.
Why would you even count the lack of security for devices which are sideloading apps at all? I mean, there's a clear section in Android Settings called 'Security', and there's an option there to enable installing apps from Unknown Sources(set to OFF by default). When you try to enable that, it says this in clear words: "Your phone and personal data are more vulnerable to attack by apps from unknown sources. You agree that you are solely responsible for any damage to your phone or loss of data that may result from using these apps."
So if I give you a knife to cut fruits, and clearly tell you that you can also do juggling with it but it's not recommended and you should do it at your own risk, will you still blame me if you get hurt by knife juggling?
> 1. What percentage of Android devices download apps exclusively from Play? They don't say. I, for one, have quite a few not so technical friends who sideload stuff.
I also have an anecdote to share. The only app I've sideloaded and helped others sideload was the one I created myself. Out of 10 teenagers who are the most probably to tinker, 0 of them usually install apps from sources outside of the play store.
Wait a minute - users were requesting for years that Google change the permissions model of the Play Store from upfront to runtime permissions (like iOS does).
Google constantly shot that down and said how it works (agree to everything before downloading) was intentional and expected behaviour. They have finally changed that model now, but in my opinion this was pretty inexcusable and reckless.
I was unable to find the issue in the Android bug tracker now, but it's a pretty long thread.
Maybe "lazy" is the best word, but moving from Android's classic "grant permissions on install" to "prompt for permission" is a major change that they spent a long time working on (I think Android 4 already had a lot of the backend for this?).
It's not like it was secretly granting permissions to apps, and you could always choose to not install something that took too many permissions.
You could say they made the wrong choice, but we're a long way from "this binary can do everything on your files" model of Unices/Windows
Inexcusable may be strong - but I wish I could find the thread I was referring to.
Perhaps they were working on it for a long time, but they were actively defending their stance for years after many people were requesting this, and after many incidents of Play Store apps intentionally doing more than expected (uploading contact lists, tracking location, etc...).
As someone who has developed and published Android apps, it was super frustrating to spend half your app description justifying each and every permission used, and still getting negative reviews simply because you had to request some scary looking permission for the most mundane feature addition.
You mean the same report where they cleverly omit the actual situation about updates across Android devices, by only mentioning flagship devices sold in 2016?
If you're interested in the Android update situation, Adrian Ludwig just gave a talk at Next, the Google cloud conference about it (he even references the Wikileaks CIA breach): https://www.youtube.com/watch?v=Zm6ziX5pqt8
He talks about the task starting with only 5 OEMs to keep their flagships updated. And you start to see the insane complexity of running the update train: this meant 29 devices. Multiply by the 351 carrier partners, which goes to 5000+ builds and variants. That all need to be tested by all the parties. =/
The fact that the report doesn't even mention that there people like me that don't deserve updates, just because we aren't willing to pay over 500 € is what triggered me off.
The dasboard tracks versions in the wild, not the amount of users that were blessed with an update.
The report is presented in such a way, as if during 2016 the OEMs had a change of heart and now all provide updates.
Be careful what you wish for, my middle tier Motorola phone got an update a couple of weeks ago and has been crashing several times daily ever since. I'm not convinced their patching schedule is enough to make a real difference anyway.
It sounds Google like has an even bigger and more complicated mess to clean up than Microsoft! But they dug the hole themselves, it's going to take them longer to fix it, and they should have started on it years ago.
Bullshit. I've never had a kernel update in six plus years from my carrier. And while they are kind of a micky-mouse operation, they are the 5th leading mobile provider in the US...
P.S. don't get service from US Cellular if there are other options
You aren't going to get kernel updates, even if you get major Android version update.
It's kind of like with RHEL - the fixes are backported in the old kernel vesion and that's it. It has nothing to do with your operator, you can thank Qualcomm and other SoC manufacturers, that they are not willing to make platform support packages for newer kernels for a given chip.
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…
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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).
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.
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.
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 )
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.
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.
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.
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
> 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.
Just to play devil's advocate: Windows became the dominant platform when it had terrible security. Android became the dominant platform when it had terrible security. Maybe people don't care that much about security vs other features. At it's low point, Windows security was a lot worse than Android security. At one point, a fresh Windows XP machine plugged into the Internet would be compromised within a couple of minutes max.
I don't really understand this metric at all. I've heard it colloquially, but I highly doubt anyone was scanning IP address ranges so often that you could be passively attacked on the internet without any interaction by two minutes in. Even more so, people are often behind NAT, which acts as a good firewall on its own.
Maybe it's related to browsing habits? IE? I mean, you aren't going to get hit by a drive-by attack on any major websites -- even in the heyday of malicious advertisements.
So, what I'm really asking is: where did this metric come from, and why does it get spread so often?
> I've heard it colloquially, but I highly doubt anyone was scanning IP address ranges so often that you could be passively attacked on the internet without any interaction by two minutes in.
I witnessed this myself back in the day. I was probably about 14 at the time, had just freshly reinstalled a machine, installed AV (from a CD, hah.) and connected it to the internet for the first time via PPPoE DSL. Within minutes I had AV popups from having been hit by Blaster before I could even update Windows. In that day, few people had routers or WiFi, many, my family included just had a single machine connected to a modem directly and so had no NAT.
It was never individual attackers - it was worms running on other systems that had reached critical mass and were just hitting random IPs on the internet with the exploit in an attempt to infect more systems.
You're extremely unlikely to see something this bad with a modern OS - most of the time you're behind a NAT, provided by your router or your mobile provider which effectively blocks inbound connections. There's also exploit mitigations like NX and ASLR which are pretty much how the Stagefright bug didn't turn into a nice new MMS worm - it just sounded scary, but over a year later we've not seen any major attacks from it.
If you plug directly into the internet or DMZ your machine, you'll still see this type of stuff. I've heard it called "internet background radiation" - old worms out scanning for possible targets to this day.
It may sound crazy, but I did suffer from it myself. My Windows XP installation was guaranteed to be infected by the worm, because like you said, without any interaction (I didn't even open up the browser, to make sure I was not crazy), the Blaster worm was often sent from somewhere in the Internet during the installation procedure. Even if it wasn't, there was not enough time for me to run Windows Update before my computer being infected, because the infamous "your computer should restart now" message always displayed several minutes after the installation was done. So back in the days, I always made sure to turn off the DMZ before reinstalling Windows XP.
You could check how frequent the attacks were by yourself. I was using a custom firewall software, called ZoneAlarm, to see how many attacks I was receiving in a day. The log said literally every few minutes, the infectious Blaster worm packet was received. It was like how frequent your SSH server is attacked with random passwords - you can see this from the SSH server log too.
Dial up and early high speed internet both gave you a public IP address. The expectation you will have multiple internet devices is more recent behind a nat is more recent. And yes I dealt with an XP box that would get compromised before you could download the update.
There are others posting here but dropped in to also confirm that I firsthand witnessed this.
I had a single device and had to do a fresh install from factory settings. This meant I had about 30 mins before my 500kbps connection would grind to a crippling halt from all the accumulated malware.
This meant I had to incrementally procure protection, save it, then fresh install and repeat until I could access the Internet safely.
I worked at Microsoft as a contractor for a year during the Windows XP Service Pack 2 days. Blaster was so bad that even bringing up a new machine at Microsoft, you had to install patches from a CD that was passed around our team. If you installed Windows while connected to the corporate network, you would see errors start to happen a few seconds after the network interface came online.
I also had this happen 'live', one of the major problems as I recall was that Windows XP (and earlier) had the bad habit of enabling a ton of internet facing services by default, and these services contained lots of vulnerabilities so you didn't even have to manually 'go online' using a browser or some such in order to be infected.
Because it was real? It was infected computers scanning, not people. Once infected you joined the group scanning random ips and it grew like you would expect it to.
At the peak it got so bad that IPSs were blocking affected ports on all consumer connections just to save bandwidth.
People in this thread don't remember the NET SEND spam from Windows Messenger. (Which was a system service and had absolutely nothing to do with MSN Messenger)
You could basically do "NET SEND 12.34.56.78 my spam message" and it would appear on the screen of your victim.
Actually I liked that feature. We used to chat with each other using it when I was in school. It was definitely a right choice for Microsoft to disable the Messenger service, but I was a bit sad when it actually happened.
Seems to me that Android had better security from the outset than (consumer) Windows had. It was not until XP that most home computers even had a notion of multiple users in any real sense, thanks to the NT core.
And i don't think the problem is so much that people do not value security, but that they approach a computer like it is an appliance. Meaning that they do not internalize that it can do things without them being physically present and setting things in motion (i find it unnerving that Windows 10 can apparently bring a laptop out of shutdown to do updates in the middle of the night, thanks to programmable timers embedded in the BIOS/UEFI).
I really wish that a modern PC got more "blinkenlights" not less (i hate helping my mom with her laptop, as the damn thing do not even have a HDD activity light).
> i find it unnerving that Windows 10 can apparently bring a laptop out of shutdown to do updates in the middle of the night
Heh, I remember when Apple used that as a feature. Instead of updates, it downloaded your email and other things you'd want to have already available when you open your laptop.
What I don't like about macOS is that you cannot postpone the update, well not for more than a day. So next day the same popup, even if it's a non essential update to Pages or iTunes. Yes I can click them away, but that's not the point.
> Seems to me that Android had better security from the outset than (consumer) Windows had.
It does, but it's also operating in a much more hostile environment. At least windows had regular updates though, that's not the case for most android phones.
I think this is part of the problem. I see a lot of hate thrown at Windows 10 for the automatic shutdown to install updates - and some of that is due to bad design choices by MS - but many seem to hate the idea of updates being automatically installed at all. They say they'd prefer to be insecure rather than be inconvenienced.
I remember routinely wiping and reinstalling windows 98 and XP back when my folks were on dial-up. Browser security in those days was an almost unimaginable joke.
Android's fragmentation and shitty vendor blobs are nothing new. What's more disappointing is that Google, despite all its might, didn't do anything significantly different for its own phones. The cost of owning a google phone used to be ~$100 a year given the price of Nexus used to be around the ~$300 mark and a 3 year support cycle. With Pixel, that cost has become more than 2x for the same support cycle. If google with its current stake can't strong arm Qualcomm and other h/w vendors, I doubt if it'll ever happen. Microkernels may make it better, but that's just shifting the perception. What's really needed is more competition in the h/w space.
I don't see how microkernels have anything to do with all of that? Userspace drivers exists in all systems and arguably they are not more backward compatible or anything than kernel-space drivers, just the incompatibilities appears against other system-frameworks in other address spaces, instead of the (micro)-kernel. Ex: when windows switched to 64-bits, 32-bits userspace printer drivers where incompatible (it could and IMO it should have been done otherwise, but what happen is that they were broken!)
And more competition in the h/w space? Common, you already have an insane amount of competition for Android phones, and even some of the biggest multinational don't give a shit about maintaining SW for their product beyond a few months, even for security purposes. The only think we can do is prescription to every people we know: ex. tell all your non technical friends to never buy e.g. a Samsung phone.
It's ridiculous, because Android is the worse ecosystem for security purposes. If you want to be somehow protected, you can stick to iPhones, or, in a funny way, Windows 10 Mobile.
>And more competition in the h/w space? Common, you already have an insane amount of competition for Android phones
That competition is only on the surface. For SoC, GPU, baseband, radios etc., you are stuck with Qualcomm. Or maybe Samsung's exynos, which isn't necessarily better.
Not sure how exaggerated this is, but even then, those vendor can very well have the bad idea to don't give a shit about compat between one chip and its next version. Given where there go and the associated ecosystem, I suspect they do exactly that...
And then on PC too, you pretty much only have competition on the surface; then it's Intel and AMD. Given how modern CPU are SOC (and chipsets are now paired with CPUs, and with no 3rd party licence anymore), you have almost all of what matter in your system (for system compat) there...
The sad part is that these are issues with Android that Linux already solved.
Google uses Linux within Android but instead of allowing the underlying parts to be updated via package management-like functionality, the kernel level stuff is only distributable as images in one "big bang" go.
You could have a bug in a single binary at the kernel level, but instead of a tiny 1Kb diff patch you wait a year for a giant 1.2 GB vendor update that also contains a lot of other changes you have no interest in.
Part of the problem is that Linux has no driver API like Windows. The result is each vendor maintains their own fork of the Kernel with their crappy drivers shoehorned in. On the next Kernel version, they have to uplift all of their garbage to it.
The problem kind of exist but the comparison is mostly bullshit -- or at least was until recently. Windows regularly breaks driver compat, even more so on Windows phone.
Only with Windows 10 Mobile they engineered a strong way to upgrade the OS without needing vendor intervention too much (or at all?), it is a shame Windows Mobile market share as fallen so low and Windows Mobile is not even a priority of MS anymore :/
On Linux side, some (most?) phone vendors are most of the time not supposed to distribute the kernel and their binary-only driver the way they do it, because most of those distributions are likely GPL violations. The sad thing is some high profile organisations (Linux Fondation comes to mind) don't give a fuck about licence compliance, which is insane given the technical side NEEDS licence compliance in order for the end result to work well and not be dangerous for end-users for a large part of the ecosystem. (Worse, the Linux Fondation happily accept obvious GPL infringers at the highest levels.)
Anyway the kernel part is a small part in an Android distribution, and I'm not sure anything is available to handle the security update problem, or that somebody is even working on it... The technical update model MS has chosen is the way to go and Google is endangering us all by having such a huge market share and not wanting to take any responsibility that should come with it. (It's even worse given how Android has reached this market share levels, using practices that would make look past MS ones as respectful of competition!)
> Part of the problem is that Linux has no driver API like Windows. The result is each vendor maintains their own fork of the Kernel with their crappy drivers shoehorned in.
Linux has a driver API; the interfaces are not as stable as windows but they are there - the vendor shoehornning has more to do with closed hardware blobs, drivers not being developed in the open, and profits than a few struct member tweaks here and there shifting across android releases..
the handset manufacturers have no profit incentive to ensure that the phones are compatible for a longer term, and keeping the hardware drivers closed/behind version-specific blobs serves as convenient way to facilitate planned obsolescence
plenty of windows hardware doesn't get new drivers across OS release boundaries for the same reasons so slightly better API stability is not really a very good argument here on its own..
To the best of my understanding, Linux has the ability to add and remove drivers to the system. Android should have a package manager for these drivers to allow for updates in the same manor.
Well, if you have control over which patches you accept, you've created an exponential explosion in the testing state space. That may be even worse for security, never mind reliability.
Not sure about the linux distro being safe part. Linux desktop distros are also riddled with vulnerabilities that no one bothered to look. This is along with the bad design of the desktop in the first place as there're no isolation between apps and so forth.
Android on the other hand, has isolation mechanism built in as the central thesis of its apps system. Additionally, it also has some additional layers on top.
Unfortunately since nothing gets updated it maybe all moot, but I don't think somehow Linux distros are more secure.
Well, GNU/Linux distro are usually patched. Main ones for pretty much all known vulns. Tons of Android systems are not patched. I don't think any of those is secure against anybody motivated enough (and I'm not even thinking about a 3-letter agency, but any hacker competent enough!)
Arguably the security model of main desktop OSes is bad enough so that they are also easy to penetrate. That should not make us dismiss the problem of the way too many unmaintained Android systems!
The Dalvik system that runs on top does indeed put apps into their own named processes with restricted access etc, quite a good idea imho!
But the entire system as a whole doesn't get updates to lower parts. E.g. Updating your java app doesn't solve the problems in the underlying C libraries the system uses. We're at the mercy of vendors for that, if ever.
>You could have a bug in a single binary at the kernel level, but instead of a tiny 1Kb diff patch you wait a year for a giant 1.2 GB vendor update that also contains a lot of other changes you have no interest in.
Security patches are not 1+ GB in size - no where close to it. You're referring to OS updates that completely replace the old OS.
Google distributes patches each month to OEM's 1 month before they're released. Some OEM's merge them into their code base and create a patch while others don't really care.
"Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft. You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago"
Is Linus Torvalds criticized as strongly as this, when many of the hundreds of Linux distro maintainers fail to ship kernel security patches speedily? No? Google puts a lot of effort into securing Android and patching vulns quickly, but ultimately it is the fault of the MANUFACTURERS and OPERATORS for failing to update their commercial works derived from Android OS.
Not sure you consider this equivalent, but the Project Zero team has opened a number of issues against Android and phones that run android[0].
I'm wondering what blog posts on the Project Zero blog you consider to be "cheap muck"? There are a lot of posts on the Project Zero blog about Android as well.
The gist is that Google wanted to grow Android into something other than a niche player, and made a deal with the devils: hardware vendors. In effect, hardware vendors said they wanted to take a dump on their customers just like they always have, with bloatware baked in and planned obsolescence and Google said OK. And they don't control the hardware.
On the manufacturing side, a huge team is assembled with piles of money and resources to design and build a complete product out of hardware, firmware (blobs), and software, test it, document it, and then hand it off to marketing. That entire team is disbanded into a pool from which a whole new team will be created for a whole new product. Maybe less than a dozen people remain on a product team following release, and that's just to cover major bugs found once it's in the field. After about 6 months, it might be a team of two people. If it's a small market product, it might be a team of handful that cover multiple similar products.
Anyway, after 18-24 months there's essentially no one around from the manufacturer to support the product. It's not at all the same business model as say, Apple, where it's a giant team supporting a dozen handsets post-release, with coordinated roll outs for bug fixes.
If you want a newer OS on the Android phone, it's a do it yourself proposition. Lineage OS. Hopefully your phone has a relatively easy to unlock bootloader. And while Lineage OS will have a much newer kernel than the stock OS, the code to support, e.g. the NFC, may not be upstream because it's got some patent encumbered code, or maybe something new in the kernel breaks some driver and no one is around who knows enough about it to get it fixed. The exact sequence to put components into low power state, if not correct can cause battery life to suck. There are all sorts of ways this can not work out well, but at least it's an option.
What Google has done since Android 5 is emphasize library stability and security through Google Play updates. New features and bug fixes happen via Google Play itself being updated; it appears to be just an app update but it's actually what the bulk of 3rd party apps use. The low level stuff including the kernel isn't user space, and while your handset gets stuck for life, in effect, with an old kernel, Google are pushing out a chunk of bug and security fixes this way.
On Google devices starting with the Nexus 5X/6P, there's a separate /vendor partition for blobs, and Google publishes monthly updates for that. I'm not sure if other vendors do this…
If we are comparing 2017 android with 2001 Windows we also need to compare the exploits. During times of 2001 windows we saw things like worms that permanent destroyed hardware (or forced owners to replace them), worms that shutdown whole city networks, computers that got infected in less than a second when connecting to the Internet, and botnets that were bigger than the biggest super computers of the time. The harm were big and scary on a global scale, and specific malware were often calculated to cause billions in damages. On the "lower" end there were bank account hijackings and credit card theft.
What are the worst 2017 android malware doing to the world?
Taking over a machine thanks to autorun.inf, crashing machines with ping, unsecured shared folders, worms spreading everywhere, rendering fonts on kernel code, and a long list of other stupid defects... No. Android has never included this level of idiocy therefore it is not fair to hold it to the same standard.
Installing Windows was once the same as installing a rootkit in your computer. Android might have issues but never as bad as Windows. Windows holds all the incompetency records.
Then, "the operating system released 16 years ago" (Windows XP) is the 3rd most used operating system. It is still causing problems today.
> I guess this means we can officially stop hating on Microsoft for having such a lax attitude towards security, considering their last OS to suffer from that attitude was released 16 years ago
What? That is complete nonsense. Yes Windows security has improved over time but it's still pretty abysmal compared to macOS, iOS, Android and any mainstream Linux distro. Windows still defaults to your main user being an administrator with administrator privileges at all times.
Not to mention the fact that Windows now comes baked in with malware and not only defaults you into turning it on without giving you the option to turn it all off easily during setup, but the major patches that have come out since will re-enable a lot of Microsoft's tracking code and make you jump through hoops to disable it.
There clearly hasn't been any major deployment of this - especially at the scale of Blaster or Conficker.
It's "trivial" perhaps for a single device but every device is different and it'd require its own exploit code, exploit mitigation features cause it to be difficult to actually exploit too - making it quite problematic to deploy in practice.
Are we really so moronic that we need to wait for something to explode before we're ready to acknowledge the fire hazard that caused the explosion in the first place?
If it were so trivial it probably would have already happened. There's tons of cash to be made in SMS and MMS spam.
It's not trivial - there's a lot of devices and exploiting mitigation techniques to deal with, there's not even a reliable PoC that works on real-world devices with ASLR enabled.
These exploit mitigation techniques and differences in builds have basically saved it from becoming the disaster it sounds like at first glance.
I guess to answer your question, yes, yes we are that moronic. Not many people will care unless it's proven rapidly and readily exploitable.
You just stated that Stagefright was "trivially weaponizable". So why don't you answer their question and provide proof? Surely a "trivially weaponizable" exploit on over 1.4 billion devices would be a very attractive target to nefarious organizations and hackers.
It's been about 2 years since Stagefright was disclosed. Are we still waiting for it to explode? And if so, can you give a timeline for when this explosion will occur?
>Stagefright is trivially weaponizable as an MMS worm, in fact it may already have happened
No it's not. Where are all of the Stagefright exploits? This was supposed to be Android's security armageddon according to the scaremongering bloggers. And yet nothing happened. According to Google's telemetry of over 1.4 billion phones there has not been 1 case of a Stagefright exploit in the wild. So your assumption that Stagefright is "trivially weaponizable" is inconsistent with your knowledge of Android security and mitigations.
Yeah I recently learned from a Candadian friend that people in the US and Canada still text a lot? Outside of the US & Canada my estimate would be that 99% of people has switched to WeChat, Whatsapp and FB Messenger.
The only texts I ever recieve nowadays are automated (2FA etc...). Even though unlimited texts come with every SIM.
I am a rarity here in the U.K. as I still text, having got fed up of constantly switching IM apps. I mean, I remember when MSN Messenger was all the rage. Then Yahoo, ICQ, GTalk, Hangouts, various Jabber protocols, FaceAche, errr I mean FaceTime and Messenger, WhatsApp etc etc ad nauseum, Skype
SMS has remained the great constant throughout all these games. Turns out people don't get in touch if you don't use WhatsApp but shows how much they care eh!
If your GSM network is anything like Greece's (and I don't doubt it is, grey market devices from Spain sold here work without issue), Android automatically sets up the network settings for MMS and wireless networking. You don't have to do anything.
Is that really google's problem, though? Why do you think they have a responsibility to ensure their OEM clients update regularly? It doesn't reflect poorly on them; it reflects poorly on samsung, sony, etc etc, who fill their phones with crap ware and are slow with patches and upgrades.
>Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft.
Yes, because it's better to let hackers continue to exploit Windows than inform users and MS that their OS is at risk.
>You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago.
Security patches are given to OEM's 1 month before they are publicly released. Google patches their devices promptly. Unless I'm mistaken, I'm not aware of technology that allows Google to take an OEM's source code, apply patches, build it, sign it and then release it to all of the OEM's customers.
Sure, perhaps you could make a case for calling out the Android security team. GP didn't do that though, he called out Project Zero for not leaving Microsoft alone and instead fixing Android. I'm just saying, that isn't how things work.
On one hand, this is a truly incredible accomplishment for Google, and in so little time! On the other, it's sort of amazing this hadn't happened already - so, so many people in the developing world are entirely reliant on mobile, and mostly use low-end Android phones.
I use a Moto G4 and the experience is shockingly good for a device that costs less than a bar tab. It's no wonder that low-end Android's are winning, based on my experience with it. It's not the same caliber of phone as a new iPhone or a Pixel, but the difference is not worth $800.
And all of this is mostly open source, runs on Linux using Java, and can be developed on for free. This seems like a good timeline! (even if the API isn't that great)
Don't forget that the proprietary Google Play Services are required by more and more apps and that Google is doing everything it can to push these services to the largest number of devices by weaving some sort of web of interdependency.
I agree it isn't perfect, but services that phone home to google servers can't realistically be open source. Google is pushing them insofar as it is trying to make them better.
I think it's still a far cry from the state of affairs on iOS or MacOS, and the fact that you can fork it if you are willing to replicate those apis is still reassuring.
> I agree it isn't perfect, but services that phone home to google servers can't realistically be open source.
Yes, they can. Google makes a conscious choice not to make them open source. There's no fundamental law or anything saying that they can't.
I think the better question is: Why do those services need to phone home? There are plenty of apps that should work just fine without doing that, but don't.
Why does location services need to phone home? Or the App Store? Or push notifications? I think most of these are obvious. I am not aware of any non-obvious ones, but if so they are more likely for crash reporting or usage metrics than for advertising.
Obviously some of them need to phone home, I'm talking about the ones that don't need to. And, just because it can't phone home doesn't mean it should stop working altogether.
Yes, and you have to swallow the whole blob as soon as you need any single one of the services. Just want "cloud" messaging for your app? Force anyone who uses your app to install the whole blob. Want just assisted GPS? Too bad, you still force anyone who uses your app to install the whole blob.
If Google had made the services modular, it would probably be easier to replace them with homegrown ones, but they made it a blob because that gives them more power. There are efforts to replace this blob with other manufacturers' blobs (like the one Yandex is working on, or microG) but it looks like this is not easy and it's not going quickly.
We also probably get a typical reverse-engineering situation where Google's services will always be several steps ahead of anything anyone else can offer as a drop-in replacement, so the alternative looks less and less enticing to the average consumer and they'll probably go with the blob :(
but they made it a blob because that gives them more power
They made it a blob because they need the data to generate revenue. Googles services are free, if you let them have your data. I'm 100% certain that a paid alternative would not survive because people does not want to pay a reasonable fee for the services, when they can have it for free if they let Google save some, to the User, harmless data - they even get personalized content in return.
you can include just one component of the entire Play Service library (e.g. cloud messaging) in an Android Studio project with a line like this in build.gradle:
AOSP may be open, but on its own it is a skeleton of a OS.
Most of the magic in Android today is housed in Play Services, one of two things Google can push an update for (the other being the Play store app) without any dialog or concent from the device user.
That's kind of a demon of necessity though. Originally they did things more in the base OS but getting manufacturers to actually push updates was horrible. Now they can do bug, (minor) security and feature updates through a side channel that bypasses the carriers who don't want to update their older phones when people might go buy new ones instead.
Thing is though that is proprietary to Google, anyone wanting to use AOSP for their own has to clone the APIs.
This makes a lie of the whole notion that Android is open source. Yes, the skeleton is open, but the guts are proprietary. And the skeleton on its own is useless.
Look at the efforts that Amazon continues to invest in Fire, and CyanogenMod (the Company that Went Bankrupt as opposed to the jailbreak mod that still mostly exists) tried to invest in a Play Store/Play Services competitor, and Samsung is trying to invest in its efforts while also trying to be stealthy about it in its current Cold War with Google...
Android (AOSP) forks are numerous, yet competing with Play Store/Play Services seems expensive and onerous. Nontechnical consumers don't see Amazon's Fire as Android, just an Android-like system that runs many Android apps. Nontechnical consumers thought the same about CyanogenMod (the Company)'s efforts. Samsung's Cold War seems so desperate, from the outside, because they are trying to walk that fine line between remaining a consumer Android and yet still distance themselves from Google's control.
I'm curious how many of the Chinese forks label themselves as "Android" and if the Chinese have a different mental model of what "Android" means.
Without any first hand knowledge, I'd assume that the balance of things towards WeChat and away from Play Store/Play Services in China might mean that "Android" really does mean something different in Chinese markets? It's easier to sell an "Android" device if the benchmark is "runs WeChat" rather than "runs the apps I see advertised everywhere" (given the near ubiquity of Play Store emblems on American ads) and "runs the collection of apps I've bought over the last few years from the Play Store".
I am Chinese and I've been living in the U.S. for a couple of years, so I know both worlds. Everyone I know in China who use an Android has ton of apps on their phones. I'd say there are at the very least tens to hundreds of thousands of apps to choose from either in the various third party app stores or directly from first party websites, and it's very common for people to have multiple apps with similar functions, e.g., four or five web browsers.
I don't know where you learned about the misinformation that is "the balance of things towards WeChat and away from Play Store/Play Services in China", which is frankly quite ridiculous because WeChat is just a messenger app with a few added functionalities (social timeline, payment, etc.) — it's not comparable to an app store or a service SDK at all.
Thanks for some perspective. I'm sure my curious bias about WeChat stems from how often it dominates chat bot conversations (esp. here on HN) and how often chat bot conversations mention WeChat as if it were the largest Chinese app store/service SDK. Fresh perspectives help tamp some of that enthusiasm.
Back to my original curiosity, outside of my supposition you think is clearly wrong, do you have an impression that Chinese phones that have forked AOSP and don't have access to the Play Store/Play Services still count as "Android" in China? If so, can you give an indication why that might be different than in America where Play Store/Play Services are nearly synonymous with Android?
I imagine that's a purely business decision since Google owns the code and can open-source it if they wish. There's no reason that the code to talk to Google's servers needs to be closed source.
One reason is API change. For closed source solution they do not have to worry about API changes but open Android has to have much more elaborate API deprecation and change process.
This is incorrect for multiple reasons. The two big ones off the top of my head:
1. They could release source and provide no guarantee of supporting API backwards-compatibility, exactly as they do today, only with the source available publicly.
2. They already deal with API deprecation. Owning the client doesn't get it to every device instantly. Even logic pushed into Google Play Services requires a (sometimes lengthy) rollout and relies on customers to approve the install.
To be clear, the discussion isn't about whether Google should pull things out of AOSP and put them into Play Services. The discussion is about whether Google can open the source for those components. So long as Google owns the copyright, the answer is a clear yes.
Nothing about open source requires that they in any way stabilize their web-side APIs, the process they would follow could be the same as their binary releases, just with open source code released at the same time.
In theory that's true, but in practice, not so much. Even if they told people to not use those APIs, that they're not stable, people would still use them, based on the open source they saw. And then they would change, and people would be mad.
This is assuming that Google wants people to see and be able to use these APIs in the first place.
Well, for one they got manufacturers to adopt Google branding for Android phones, but then we're led to believe that getting them to update on time was hard. But from Google's POV, the only "necessity" here is that Google gets your data and tracks you.
So apparently "phone manufacturer must preload all Google applications" and "phone manufacturer must set Google as default search engine", and "Google network service must be preloaded" made it in the contract, but "phone manufacturer must update the phone" didn't. Those sneaky phone manufacturers !!
Maybe "fast updates" is a standard clause in the contracts and device manufacturers are simply doing a bad job and Google doesn't want to piss off all its partners by litigating this.
Oh, its not a mystery at all. Its just odd to come across people (in general, not you) who still think an advertising company would care all that much about their users (who are not their customers anyway). But yes, they're quite far from being the worst in this aspect.
They can care for selfish reasons. If android is completely riddled with bugs and is constantly compromised users will use a different phone system. Even outside security issues being able to roll out new features to people keep them from switching to iOS or Windows Phones.
Well I'm guilty of that same conception too. Why are the two at odds? Google wants to own the best platform for users out there. Engineers want to work on the best, app developers want to work on the best, and users want to use the best they can afford.
I'd say the majority of end users are not particularly knowledgeable about Google Play Services and the Store app to make an informed decision on whether to accept or not an update.
I think I agree... and that is a huge problem! The same can be said about Windows Update. Or any computing topic in particular! Which is an even bigger problem.
> one of two things Google can push an update for [...] without any dialog or concent
One of the two things Google _chooses_ to do this for. Nothing prevents them from doing the same thing for other pieces of software, except, perhaps, their own policy.
What I'm most excited for based on my time in Liberia, is when these mobile first citizens wring all the juice out of mobile devices and are able to adopts tablets and then computers. The things they'll be able to do since their grew up on these tiny devices will be incredible.
It's not so surprising when you consider that those people in developing worlds visit way fewer pages than someone on a broadband connection on a computer would - in part because it's still a smartphone with a small screen (especially the low-budget ones), it's slow, but mainly because data is expensive.
Agree entirely! However, Google still has a lot of work to do to put some sort of order in the lower end of Android devices like reducing fragmentation, offering a more unified experience for users and making sure that new devices are not shipped with obsolete hardware and software. Android One, for example, is a great initiative that desperately needs to go global.
I had recently been looking for a laptop to replace my wife's aging machine. She wanted something to hit all her social media stuff, save pictures and videos, basic office, and watch her tv and movie streams.
I had a barely-used lenovo that I had put xubuntu on that I wanted her to try first to gauge her size and performance requirements, but she wasn't ready for linux. I searched around a bit (knowing putting windows 10 back on there was not an ideal experience) and came across RemixOS, a version of android for PC.
That's when it clicked for me. She didn't need a traditional PC. What she really wanted was her phone in a bigger form factor (with usable keyboard). I was able to get all her apps on in a few minutes and she had a workable system with nearly no learning curve. I suspect this will be the case for more people as time goes on. I'm in favor of a competitor to windows, and I now think that is android, not linux.
It's called CloudReady and no it doesn't have Android support yet and I don't think it's planned. Though some have hacked it to run Android apps but it's super super buggy.
On that note, Android 7 and newer supports tiled apps. And if the OEM wants to, can even do floating apps (thinks windows).
Also, Samsung demoed their Galaxy S8 the other day. And one of the big tings was Dex, a dock that turned the phone into a desktop computer. Microsoft has in the last year or so been pitching a similar system called Continuum.
When I was a kid, I was frustrated for most of the adults can't use the computer so our society is very inefficient at daily life.
I was thinking, since our generation has affordable personal computers, when our generation become adults, the world will finally embrace the efficiency of computer where everything is computer-friendly and everyone can write code.
I was wrong.
The birth of so called "smartphone" made everyone dumb. The smartphone does not encourage its user to write code or text. They mostly consume the information provided by a handful of people who can use efficient input device, the keyboard.
My generation and the next generation were infected by the smartphone. Those hand-sized, touch-screen pathetic computer is the only computer most people ever use nowadays.
I refuse to own a smartphone. Since our society become so smartphone-friendly, not owning a smartphone makes me really inefficient at daily life. But I don't want to own a computer which tried so hard to prevent me to replace OS, modify the software, writing code and text.
A better comparison would be with a TV that doubles as your main communication tool and work instrument while it serves you addictive contents, ads, and spies on you.
There is no loss. Everything a smart phone can do, a laptop can do better. All a smart phone does is keep people bound to their online lives in an unhealthy way -- constantly beeping at you, notifying you of pointless shit, and spying on you. No thanks.
I don't own any phone, but if I did it would be a dumb phone with week-long battery life.
Writing code, outside of spaghetti BASIC and similar, is a full time job. It requires hours and hours of thinking and planning.
People already have full time jobs, sometimes two or more. The last thing they want is another, likely unpaid one, when they come home and sit down before the computer.
This is the biggest mistaken belief of the programming industry.
Where we're headed is multi-level architectures. At the bottom is what you think of as "all programming". It's low level code, with manual deployment, using a wide range of fairly arcane tools. You need to be a professional to do it.
What is slowly emerging, which you suggest is impossible, is a layer on top of that. It is written in highly constrained code. You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. But you are working within a sandbox that your professional software engineering colleague built for you.
Most of us software pros don't think about development this way. We think we're supposed to be releasing finished apps to end users. But 20 years from now, we'll think of our job as releasing libraries for "non-programmers" to use. DSLs that are foolproof, which end users will string together using simple function calls and literals and nothing else. Languages in which it's very difficult to express broken ideas.
There's no reason the marketing team can't write this file:
post("miami", "Bienvenido a Miami!")
image("miami", "http://static.flickr.com...")
paragraph("miami", "We've gotten more requests for a Miami location than the rest of our...")
Well, there is a reason. It's almost certain that the programmers down the hall, like you, don't believe that a marketing professional could handle the "hours of thinking and planning" required to write that code. But again, they are all mistaken. Any smart, computer-savvy person could write that code after a few minutes of instruction.
But first you'd have to build that API, and a realtime preview, that is editable from a nice simple web app. You could do the "hours of thinking and planning" so that your colleagues could write the high level business code.
That's where this is all going. There will be a lot of programmers that work inside a sandbox like that, a few hours a week. Most programmers will work like that. And there will be a smaller number of seasoned pros will maintain those sandboxes.
> This is the biggest mistaken belief of the programming industry.
Actually I think what you're saying is the biggest mistaken belief in the programming industry. The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch.
> You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine.
If it's Turing complete then someone can and certain would write spaghetti code. Every constrained environment that ever existed for lay people to use ends up in the hands of frustrated programmers.
> There's no reason the marketing team can't write this file.
There's no reason why they couldn't just drag and drop such logic and prefer to do it as well. Most people have trouble understanding how to work with Turing complete languages to accomplish advanced tasks. Programmers aren't purposely trying to make their environments difficult -- in fact making everything as easy as possible has been the goal since the beginning.
> You could do the "hours of thinking and planning" so that your colleagues could write the high level business code.
Honestly that High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer. It's a job in itself different from other jobs. It will never be a job for non-programmers and maybe not even junior programmers.
> The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch.
Yes, and it's working. All of those projects helped. A child will learn far more in their first year of programming today than I learned in my first year of BASIC. I think that trend is accelerating and we are very close to the hockey stick part of the accessibility graph. There are a LOT of people who have at least dabbled in programming today.
> If it's Turing complete then someone can and certain would write spaghetti code.
Sure. And yes, some poor schmo will have to deal with it.
But most of the code won't be spaghetti code. Most of the code changes will just be string edits. Marketing has a vested interest in not breaking their pipelines.
I honestly think a little instruction goes a long way here. It's not that people won't be learning coding best practices, it's that you won't need a year of training up front just to get started. I'm not talking about eliminating the learning curve, I'm talking about making it shallow and linear.
> There's no reason why they couldn't just drag and drop such logic
Visual logic programming has been a mixed bag. It does work well for some very constrained kinds of programs, like shader pipelines and audio programming. But generally research into visual programming has not gone well.
Text has one very important benefit over visual programming: it's linear. That's nice because much of code execution is linear. It's actually a tree, but it's definitely not Cartesian.
Drag and drop is also not very intuitive for most users. It's an invisible affordance. It requires dexterity. And it's also not very constrained... You can drag anything into anything.
Most programming will be text. I don't think it will be pure ASCII but it will be linear text.
> Programmers aren't purposely trying to make their environments difficult
Of course not. They are trying to make it just easy enough for a full time professional to figure out and no more.
> High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer
I think you're forgetting about some programmers. You know the kind... They just want something complicated to do. Like "rewrite the entire system using a custom memory store instead of SQL" and then they disappear into the wilderness for 4 weeks and come out with it finished.
Some requirements mean a lot of code to change. Some requirements require almost none.
What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles. Marketing, support, finance, they'll just do that coding themselves. At least they'll do the patch and submit it for review.
And the other stuff... Stuff that's more about code than business needs, that will still be the domain of the professional programmer.
Current programmers will have a choice. Do I want to stay in mostly code all day and solve thorny problems? Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming.
> Some requirements mean a lot of code to change. Some requirements require almost none.
My point is ultimately marketing/finance/administration people do not know, fundamentally, what is a lot of code and what isn't. That's knowledge for programmers. https://xkcd.com/1425/
> What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles.
There is no such thing as "obvious code changes".
> Marketing, support, finance, they'll just do that coding themselves.
Never happen.
> Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming.
My software team develops all the software for the marketing, finance, HR, and support departments. They are deeply involved in the design of their products (some departments more than others) but ultimately none of them can or want to program. Even basic SQL is beyond the skills of most them -- although we encourage anyone with interest to do their own queries.
You massively under-estimate the skill and experience involved in even the most basic programming tasks. Programming, version control, deployment, database design, systems design, etc. These people have their own professions with their own issues to deal with.
> There is no such thing as "obvious code changes".
What about "there's a letter missing in this heading"?
> Even basic SQL is beyond the skills of most them
I would put SQL in the category of "advanced programming". It's declarative programming, which is not easy for beginners, and you can literally do any operation at all from any place in the code. There's zero separation of concerns.
> You massively under-estimate the skill and experience involved in even the most basic programming tasks.
What's so hard about changing a letter in a string on Github? Anyone who can send a text message could do that. To me, that's the "most basic programming task".
What's impossible about:
Hi Fred,
Thanks for noticing that typo! You can fix it yourself... The code is here:
Just click "Fork" and then "Edit" and make the change. The system will send
me a notification and if nothing is broken I'll merge it, and it should be
live within the hour!
Best,
Erik
> ultimately none of them can or want to program.
OK, so that's a cultural barrier. If you want to really lure people in, it will require a little more than an email like the one I suggested. I think to get people to bite, you need a few things:
1) Web-based editing, with instant preview (no downloading anything, no commands to type)
2) No repos, just editing single files
3) Very high ratio of domain-specific language to implementation language. Most programmers don't bother separating out their domain language (customer, sale, analysis, etc) from their implementation language (page, element, server, etc) You can't have a sidebar with node_modules, src, view, etc, it distracts people.
All this really requires is writing an extra layer of domain code that wraps your implementation code. It's not necessary if your code is only ever read by professionals so most programmers don't bother doing it. It's extra work after all.
4) Use only functions, function calls, and literals. No loops, no classes, etc. That stuff can go in the implementation layer, but you can't expose it. This also means no SQL, no CSS, etc. One language, three language constructs.
5) Separation of shared code from sensitive code and data. If you can do something like:
import "users"
users.delete_all()
... you're screwed. People will never feel safe making changes in that environment. You need real separation of concerns where the code being edited is mechanically separated from everything but the few functions you want to expose to people. Think of each source file as a custom sandbox for just one non-programmer employee.
Get all five of those, and you have yourself a changed game. Building all of those things is a bit of work, but there's nothing fundamentally mysterious about how to do it. It's just work that most companies don't do because you can just wall off your code within your professional programming team instead.
Coding is only difficult because we have made it difficult. It should be possible for a user who is not overly familiar with programming to open up the source, find the part they want to change, change it, and rebuild the changed software. Instead, we have been making all our software as complicated to understand and edit as possible, and then only shipping binaries in order to hide the complexity.
The advice of my window manager, i3, regarding source installs is: don't. Disregarding that advice, and after fighting with my package manager to get the required libs, `make` made it extremely easy to build. From there, the edit I wanted to perform required changing the value of a constant from 3 to 0. Not hours and hours at all.
Making this feasible for everyday users is within reach. If the focus of the free software movement had been on making software that users can modify on a physical and practical level, rather than just a legal and technical level, we might see everyday users patching their software. That didn't happen, and it doesn't seem many people care about making it happen, and so the situation won't change.
I do have a smartphone but oddly he is mildly correct that they really aren't smart. You have to spend ages on them to do anything.
It is odd that computers are meant to work for us but we spend such a long time using them and working on them, in a huge perpetual cycle of production and consumption cantered around the computer itself, particularly in the software industry.
Ironically the smartphone brings proper computing to everyone's fingertips. Hell I use my iPhone as a SSH terminal, or even a hotspot for my laptop when programming away from wifi.
The Information Age would be a dud without constant access to said information from anywhere for anyone.
The smartphone has also made it super easy for the average person to enjoy the fruits of programmers labor via app stores. Overall it has been a positive for the world.
> tried so hard to prevent me to replace OS, modify the software, writing code and text
It's pretty easy to install a new OS on a typical Android phone. 1 million registered LineageOS installations already, many many millions of CyanogenMod installations before that.
Honestly the worry about "omg smartphones are turning everyone into consumers who don't create anything" is ridiculous. People write blog posts, edit photos and videos on smartphones a lot. A LOT.
> a handful of people who can use efficient input device, the keyboard
I really like my mechanical keyboard with blank keycaps, but I do type a lot on my phone's onscreen keyboard as well, and it is pretty efficient!
that is highly dependent on how close to "flagship" your brand and model of phone is.
For every S7 (or S8 these days) there will be 100s and 100s of cheap ones sold that nobody over at XDA or similar with ever grace with an alternative firmware.
Like me, I have a "MyPhone" and there appear to be no ROMs for it, nor do automated rooting apps do the trick. There's so much crapware on my phone such that the home screen has been taken over by advertisments that I can't close.
When I was younger there IBM, Apple, Be, and Microsoft were all working on these amazing new operating systems. Now the #1, #3, #4 most popular operating systems are all some variation on Unix. What happened? Why did no one except Microsoft come up with a new operating system worthy of mass adoption?
Well, Microsoft put OS/2 and BeOS out of business, and nearly did the same for Apple. While this was happening, FreeBSD and Linux emerged as excellent Unix variants, so when Apple and Google went to look for their own OSs to deploy, they leveraged what was already available.
If you're looking for alternatives, there is stuff being developed. Google's Fuscia is intriguing, and there are other non-Unix kernels from other organizations in the pipeline. IMHO, the difference this time around is that the web is the new compatibility target. If you design a new OS today and manage to get a full working web browser with javascript and Web Assembly, you'll be in good shape.
Lets not forget that Google bought Android, it didn't start as a in-house project. Rubin and crew had picked Linux as their base, and Java as their main dev environment, before being bought by Google.
Google was pretty much aware that GPL with Classpath exception was only for Java SE, not targeted at embedded deployments, but paying the license required for embedded deployments was too expensive apparently.
According to Gosling, Sun would have sued Google if they still had any money left on the bank, instead Jonathan decided to make the public support announcement, angering quite a few folks internally.
His blog posts are no longer live, but old references are quite easy to find.
Actually regarding OS/2, IBM had lots of blame as well.
They didn't managed the whole situation properly and trying to use OS/2 to get back into the game of selling their own PS2 architecture didn't help win the hearts of the buyers.
I would have had to pay almost 500 € extra, on today's money to get a PC capable of running OS/2 properly, instead of the one I got with Windows 3.1.
I had read that OS/2 Warp was considered a pretty good OS technically, though I don't remember the details now, as to what made it an improvement over Windows. I remember that PC Quest, an Indian PC magazine, gave out OS/2 Warp on a CD [1] in one issue.
[1] They often bundled a CD with lots of free software with their magazine issues, e.g. different distros of Linux, server software, utilities, etc. All free or trial software, usually. I remember they bundled the QNX OS once, and I installed it and tried it on my PC. It was very light and fast, had a GUI too - Photon, IIRC. They might even have bundled BeOS once. I think I tried installing that too, but it did not work on my PC.
OS/2 2.1 was a contemporary of Windows 3.0. Unlike Windows 3.x, it had preemptive multitasking and process memory isolation. It also had a nice-for-the-time GUI called Workplace Shell which was much nicer than Windows 3.x's Program Manager. It was very good at running DOS software, letting you make all of those config.sys/autoexec.bat tweaks on a per-program basis.
OS/2 3.0 (Warp) came out a couple of months before Windows 95. Compared to Windows 95, it was much more stable, but lacked compatibility for Win32 programs.
OS/2 was to go along with the PS/2. A update on the PC platform that was much more bespoke IBM compared to the largely assembled from off the shelf parts that was the PC/AT.
>OS/2 existed for quite a while before Warp came about.
>OS/2 was to go along with the PS/2. A update on the PC platform that was much more bespoke IBM compared to the largely assembled from off the shelf parts that was the PC/AT.
Yes, I was aware of those points, that Warp was a late or last version of OS/2 and that IBM tried to make the PC architecture closed with the PS/2 line - after it being originally open with the PC (which was what led to its success as a platform, due to the adoption and all the clones and extension cards and software for it). Had read about it. That doesn't change the fact that Warp had good reviews. Didn't try it out personally though.
But Apple and IBM (and some others) spent years and millions of dollars coming up with an alternative. And they ended up with FreeBSD and Linux. You could say the software development was badly managed in many cases, or the business case wasn't there because of the app-OS dependency. But I think the fact that everybody failed implies a failure to come up with something better. And therefore a lack of progress,.
The way I remember it, I would need to buy an expensive IBM with PS2 architecture to be able to use OS/2 properly, instead of the 386 I got with Windows, so lets not forget that IBM didn't managed the whole situation properly.
Me saving around 500€ on today's money, because I got to use my savings on a no name OEM PC running DR-DOS/Windows 3.1, instead buying an IBM PC with OS/2 2.0?
Because of the application barrier. It's a chicken and egg problem, nobody wants to use an OS without applications and not many want to develop for an OS that nobody uses. To get it started, a lot of resources and power (e.g. quasi-monopoly or tons of money) is needed, or you need to have some binary compatibility with another OS. The latter is difficult due patents and copyright, and because it will likely make applications slower than on other platforms.
Apple was able to do it, because they sell hardware, not software, but the transition from Classic OS to OSX was hard and rocky even for them and could have failed.
It's a pity, because neither Unix/Linux clones nor Windows are really good and technically sound desktop operating systems from a modern perspective, and it would be possible to develop something way better. As for mobile, I don't know, it's a different thing.
Apple was able to do it, but not without both a compatibility layer for direct binary compatibility (Classic) and a migration path to allow the same source code to be compiled for both OS 9 and OS X (Carbon).
Not to mention the heavy Java push they made for a while, which didn't end up becoming much in the long run but did provide one more way for developers to get their applications onto the platform. And developers like Omni that followed NEXT after their purchase by Apple.
But that implies that no one needs a different OS than Windows NT or Unix. People are constantly coming up with reasons to have new programming languages. Are there no reasons to justify a new OS?
Unix, in the sense that we talk about it today, is not an operating system, but a family of operating systems that is based on the original Unix. Linux is Unix in the same way that C is Algol. In the grand scheme of potential languages/operating systems they are very similar, and familiarity with one will transfer well. However, if you consider the ML family of languages (Haskell/Ocaml), or the Prolog family, you will see that Algol/C/Java/Rust are in some sense variations on the same language. In this sense, we have not seen the great variaty of new languages you are referring to.
In the case of OSes, it is beneficial to formalize these similarities into a single API. As long as the operating systems remain conceptually simmilar, there is no point in unnessasarily fragmenting the API. When there is need to deviate from the common Unix system, Unix-like operating systems have no problem doing so. But there is not strong enough reason to through out the massive amount of investment, both in software and human expertise, that has been built up on the common Unix base.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
>Algol/C/Java/Rust are in some sense variations on the same language
Actually, despite its syntax, Rust is more closely related to the ML family than the Algol family. The original Rust compiler was written in OCaml and it definitely shows in the algebraic data types, functional idioms, and immutability by default.
More to the point, maybe a new OS could gain meaningful adoption by seeming superficially like Unix while actually taking significant inspiration elsewhere.
There are plenty of research or toy OSs, but if they try to get really useable, they just implement a Unix compatibility layer and take drivers from BSD.
A lot of Windows NT was based on work Dave Cutler had done on VMS and RSX-11, so while I'm sure most of the code was new, the ideas are of a similar vintage to Unix.
Frankly it seems like nothing really new has come out of computing in decades. Basically all the container hoopla happening right now were in use on mainframes before Torvalds released the first Linux source code.
There's a very long list of inferior technologies that beat superior ones in popularity, or age.
QWERTY keyboards, Electronic forms, Combustion engines, Agribusiness refinements, Byte-oriented computers, Genetic technology (outside of GM crops), Building construction/insulation, Monorail and near-sonic trains, Pharmaceuticals, PlayStation, 8086, TDMA, USB, PHP, VHS...
The most common link between them is a low barrier to entry, which has multiple facets.
1. Intellectual Property
If you patent technology, it makes it hard or more expensive for others to license and/or implement it, which leads to a loss of market share unless you completely monopolize the market your product occupies. Any alternative technology which is both cheaper and more ubiquitous will dominate.
2. Cost
More advanced technology is, almost by default, more costly. It is costly for manufacturers to develop a new process to manufacture it, it is more costly for developers to learn to develop new products that use it, and it is more costly for consumers to buy it, both because of the lack of manufacturers and developers for it. It also will inevitably require one to learn a new way to use it.
3. Doesn't address a critical need
If there are two competing technologies, and both provide for the same need, the one that best addresses a need and costs less will win out. If one does not provide for a critical need, it will be left in the dust. Often that "need" is as simple as being faster or easier to operate, but it can also include specific functions.
--
The earlier you are able to introduce a technology, and as long as a newer technology does not beat you on platform support, cost, and critical features, you will remain on top.
Browsers are a good model for how this has changed hands over the years. The barrier for entry is smaller because you can make them for multiple OS platforms fairly easily, but sometimes one would have a monopoly. So to compete with the monopoly, one browser would remove a barrier to entry - cost - and develop new critical features. But then the other competitors could adopt the same changes and compete again.
Another example is Intel x86. Intel tried several times to end the x86 product line. But as the industry refined standards around it, it became too expensive and complicated to try and introduce a complete replacement. It was even forced to adopt features that competitors introduced.
UNIX (and C, since a lot of people lump them together) has stayed around so long because it has a low cost, low complexity, is ubiquitous, can adopt new features easily, and is highly compatible/portable. Even if you have a new critical feature, it can usually just adopt it.
In the end, kernel design has nothing directly to do with how it is adopted by users. Kernel design affects how software developers, and later manufacturers, will use it. And that affects what is left for users to adopt. Nobody really notices a kernel; what they notice is the ecosystem.
I realize that this has nothing to do with your larger point, but what technology do you consider to be superior to the original playstation? My understanding is that the PS1 was a significant technological leap.
3DO, Jaguar, PC-FX, Saturn, N64 were all superior technologies, and PlayStation absolutely trounced them in popularity for 10 years. Initially both the Genesis and SNES outsold all the 5th gen platforms, but eventually their perceived better quality and an increased availability of platform titles took hold.
N64 arguably yes, Saturn .. depends, but a bit of a mess. Jaguar and 3DO? No way, PSX was overwhelmingly better hardware than either of those. No idea about PC-FX though.
You're probably right there, they were released a year before PSX. PC-FX had no polygon processor and relied on prerendering, and had the same color support as PSX, and an older CPU. It was never released outside of Japan, though...
As the mobile computing ecosystem matures it's becoming clear that it will mirror the PC dominated computing ecosystem. You have the major player (Microsoft/Windows in PC, Google/Android in mobile) occupying about 85% to 90% of total market share [0] while Apple/Mac/iOS will do well in the high end market and control about 10% to 15% share. iOS today controls about 20% to 25% of global market share but Android growth rates far outpace iPhone growth as Apple's first mover advantage continues to be diluted with time and smartphone commodification.
There must be some fundamental dynamic at play which favors the 85%/15% market share duopoly.
This sort of matches Duverger's Law[0], which holds that given a particular set of constraints that sound a lot like the smart phone market, you will always end up with 2 players/political parties.
So I guess that means we will start to see a <1% libre alternative pop up? FirefoxOS tried. Ubuntu tried. Definitely interested to see who will occupy this slot in the distribution.
The hard part this time is all the closed source drivers. How did Linux solve that back in the 90s?
> The hard part this time is all the closed source drivers. How did Linux solve that back in the 90s?
It never did perfectly. It's about the same as it is on Android currently. All the basic stuff works but you need proprietary firmware for a few things like WiFi and cell radio. Some even have cell radio working.
If mostly-open is good enough though, flashing a stock AOSP build or LineageOS without GApps will get you there, you can install software from sources like F-Droid too.
I always hoped for a more 30%/30%/30%/10% distribution, with two big proprietary players, one FOSS one and a bunch of other more experimental or niche systems. Guess that hasn't happened so far. The only place in technology where I remember three big and roughly equally powerful players was the console market, but only for a while.
Would be interesting to find out details about these dynamics.
Developers seem to be willing to support two competitive platforms, but when there are three or more, they throw up their hands and support just the top one, or maybe the top two.
It depends on there being strong cross-platform development tools or not.
Back in the early days of the micro-computer, many games used a virtual machine of sorts. The game logic was implemented in VM bytecode and then the VM engine was the only thing that needed porting between systems.
This was to a greater or lesser degree aided by the limited hardware of the time, and that said computers were single task more often than not.
This intrigues me, as it clashes with everything I know about how classic game software was designed. Around what decade are we talking about? Can you name one or two examples of games that were designed like this?
Ah, alright. When you said "early days of microcomputers" I was rather thinking about the Atari 2600.
The VM approach was in absolute terms actually pretty unusual in the late 80s/early 90s, AFAIK. Perhaps counting only cross-platform games or adventure it was more common, though.
They're willing to if they can bundle it in something large enough to be—and otherwise more resource hungry than—a (sane) minimal graphical OS. Electron, say.
Google now has: The dominant operating system, the dominant web browser, the dominant search engine, and the dominant email service. They bundle all of these together and make them relatively independent, and there still isn't an antitrust suit in the US.
This is where all the money Google pours into government comes into play.
Interesting. Why do you assume it's money as opposed to, say, federal prosecutors having over a decade and a half of hindsight to conclude that the Microsoft antitrust suit was a giant fiasco that cost a great deal of money and time and, ultimately, never had the desired effect?
Actually, I think it all comes down to the fact that Google's "products" are all free.
I think the fact that a service is given away for free has been the loophole for Google and Facebook to create large and powerful all-encompassing monopolies on things which really shouldn't be monopolised.
When Chrome was launched, all you could see when using Google were Chrome ads, and with good reason - success by word of mouth alone can only come if your product is significantly better than the alternatives, which Chrome definitely was not (probably still isn't).
I do find some satisfaction in this, though, because another browser comes to mind. Firefox won its brief market dominance not through intrinsic quality (although it had some potential, and was surely better than IE), but through marketing campaigns, just like Chrome. Now the once-mighty are falling, and they ask themselves what went wrong. Well, when your product's only selling point are extensions (mainly developer extensions) and instead of focusing on performance, features and security you keep spouting "safer faster better" [1], there will come a time when someone with more marketing money to throw around will take your place, because your foundation isn't solid. Also, "good enough" works for most people, so if the IT person in their family set up Chrome for them, that's what they'll be using (just like they were using Firefox a decade ago).
On Android on most phones Chrome does not come preinstalled. Samsung, LGE, etc all ship their won browsers. Users must actively seek out chrome and install it themselves...
> Report: Linux overtakes Windows NT as the internet's most used operating system kernel.
Might be more of an interesting headline written this way.
GNU/Linux dominating Windows as a "most used" consumer OS has been a long-term push for the entire community. I would see this as achieving it, albeit in a form different than some would expect.
The point of the "Linux on the desktop" meme was that everybody would start using free, preferently GPL'd software for everything. Android is far away from that.
> The point of the "Linux on the desktop" meme was that everybody would start using free, preferently GPL'd software for everything. Android is far away from that.
I guess it depends how you look at it :) I would see it as "not using Windows" but your statement seems to be "not using any closed-source software".
It's an effort with variable goals and there are different opinions what is meant. If you ask rms he'd agree with you. :)
Yes, but without the associated userland it's a moot point. Just like nobody that simply wants to get from one place to another overly cares about their brand of socks.
I'd just like to point out that Microsoft win either way:
Says Forbes: Financially Microsoft is one of the biggest winners from the growth of Android as a platform, thanks to its wide range of patents. Samsung's royalty payment to Microsoft in 2013 was for over one billion dollars ($1,041,642,161 and fifty cents), roughly $3.41 per device.
Do you really think Samsung is paying them that much today? Samsung made a silly mistake by underestimating the growth of their phones. This all came to head when Samsung refused to keep paying Microsoft for their prior art ridden shake down patents a couple of years ago. There's a reason why some MS apps are now stubs on Galaxy phones that can now be downloaded.
I think those royalty payments are more of a silver lining to Microsoft's complete failure to capture any mobile market share. Google is still the "platform holder" and has the biggest advantage of Android's dominance.
Clear the 'Desktop/Laptop' filter and it gives share on all platform types. I think the difference in numbers may be due to this service is measuring only browsing activity.
It also removes 21% of traffic detected as bots, so that may also have an effect.
To all those pointing out that you can't get an up to date release of Android for your device: It's not all Google's fault, but it is increasingly becoming Google's fault because major SoC makers are keeping their Android Linux and drivers up to date.
Up to now, though, enough bits in OEM-specific drivers will go out of date to prevent Google controlling updates of all Android devices.
There is renewed urgency to solve this problem in general for Android Things. Having billions of unpatched things in the field for a decade or longer will be an even bigger disaster than phones that churn out of the installed base in 3 years. Google is building a field upgrade framework for IoT that should be applicable to handsets, too.
That MIGHT take enough OEM responsibility out of the picture to enable updatable Android phones.
I have a theory:
- Bots don't show up as Linux, they spoof Chrome, iOS, etc.
- Since this service filters out bot traffic, it is removing non-Linux traffic.
- Hence, Linux share is actually much higher than is generally reported.
I've got to think this is the rise of internet/consumer purchasing power in Asia. When I look at the analytics at the company I work for, Android accounts for 9% of total users visiting the site. We are a US-based web company with a predominantly English-speaking user base. Windows still rules, followed by Mac and iOS (interestingly iOS is catching up with Mac and is nearly even).
At a high level, Android seems to have more than doubled on our site in the past two years, which seems to be a reflection more of our overall site growth. Windows is still enormous.
All snap-shotty anecdotal stuff. If you're a global enterprise beyond US/UK/Australia, I'd think your numbers would be fascinating to look at.
Google can you please take control of your Android API, make it match iOS's slickness and UI, and be more controlling on getting your manufacturers to update their phones?
Can YOU PLEASE work on the perception the public has that Android is for cheap people? And the preferred upper class phone is iPhone?
For gods sake your iPhone apps are better than your android apps. Do you not see a problem here? Your developers and engineers think less of your platform.
There is a blatant stance on Silicon Valley as Android is second tier. Change this perception ASAP.
Also, Microsoft, with Windows Phone, tried to be much more domineering with the hardware vendors than Google. And those vendors told Microsoft to go pound salt. Google is letting the hardware vendors be true to their model which is to sell something snazzy, and then drop support after 12 months, with life support for another 6-12. That's what the device manufacturers want.
Depends how much one enjoys using an outdated dialect of the language and libraries, after Java 6, Android only gets support for Java 7 and 8 features cherry picked by the Android team, not 100% of them.
One reason why they backtracked on Jake and Jill was that they weren't being able to make all the annotation tooling and bytecode manipulation libraries work on the new toolchain.
Meanwhile according to the same stats, Android sits around 37.9%, and I have to wonder just how many of those devices are still impacted by for example the 2015 libstagefright vulnerability. Given Google's guiltless ongoing "throw code over the wall" approach to security and passing the buck on to vendors who almost never ship firmware updates for old handsets, perhaps now is the time for us to begin holding Google to the same standard we applied to Microsoft a decade ago.
Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft. You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago
edit: If it weren't clear, the tragedy here is that instead of most devices being governed by a well-tested security process owned by a single responsible vendor, they're at the mercy of a plethora of downstream vendors who do nothing, with the ultimate upstream washing its hands and paying little more than immature lip service to the issue, never mind having anything that even remotely resembles a solid process.