When I buy a laptop I install whatever is the latest version of Ubuntu on it and am done. When I buy an access point I install whatever is the latest version of OpenWrt on it and am done. I've tried to do the same thing with phones using LineageOS but it's hopeless. Devices are often half broken and are never guaranteed to continue being supported because of this kernel mess. It seems there's slow progress being made which is nice. I was hoping Android One phones would at least guarantee monthly security updates but it's still up to the manufacturer if that happens or not.
There's a compromise solution to achieve something equivalent. And I say so after having tried many possibilities.
Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP.
It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.
As far as I know those have the exact same issues with their kernels. The problem isn't the Android side of things, that's workable with Android One phones too. The problem is what is described in the article, the kernels at best get some patches but are never upgraded to new versions. Imagine if your Linux laptop was restricted to the specific kernel version the particular vendor had decided to ship initially.
> Imagine if your Linux laptop was restricted to the specific kernel version the particular vendor had decided to ship initially
In older times, kernel patches for exotic hardware often tied the user to a specific version - of course a very stale one... Let's not go there again !
The shoddy build quality, plus lack of microSD & heaphone jack means I will never buy a Pixel or other Google branded hardware.
My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects.
Meanwhile, both of my old Galaxy S4's is going strong, and ditto for all but one of my LGs (one had its charge controller start smoking, LG repaired it).
I have owned since launch day a Nexus 1, Nexus 4, 2x Nexus 6, 2x Nexus 7 and Pixel 2 XL and they are all currently still functional well past their warranty. (The Nexus 1 was replaced by Assurion for water damage with a refurbished device @1.5yrs but replacement is still running.) In fact my Nexus 4 is still in use every day as an APRS GPS receiver/data logger, and one of the Nexus 6s is now in use by a co-worker as a OBD2 data logger/HUD.
I've avoided Samsung devices (including Galaxy Nexus/Nexus S) because the girlfriend has had the last 4 Samsung devices fail or become completely usable right at the end of the warranty (+/- 2mo) running completely stock. For those that became completely unusable it was usually pitiful battery life, the others became too slow to function on stock roms that I suspect they failed due to internal storage wear. Not even custom roms could save them.
I keep my devices a long time, and frequently repurpose them after they are no longer my primary device. Non-Samsung "Pixus" problems are overblown, except Nexus 6 AMOLED burn-in which is annoying but didn't present itself until it was used daily as a HUD.
Seems like you missed the horrid bootlooping issues of the Nexus 5x, the bad battery firmware on the Nexus 6p, and the bootlooping and flakey charge controller on the OG Pixel.
Your choice in devices of the Nexus/Pixel series is very lucky, you avoided the defective models nearly entirely. I have no faith that I will be similarly lucky.
I won't buy anything but pure Google, Moto or lg phones anymore. If they start adding crappy software replacements I will switch. Samsung is a non starter there, hard coded button for bixby is idiotic. Also bixby is idiotic.
Same here. Galaxy Note II, still going strong. I bought a new battery for it a year ago, expecting the old one to go out soon, but I still get more than three days battery life from it.
Does Pixel work with upstream kernel? Does it use many blobs? Sony Xperia XA2 looks interesting, but not sure how usable it would be with upstream kernel and Mesa.
Pixel uses the same SoC as most other phones and thus has about same amount of blobs. The difference is that Google tends to update the OS faster and they're noticably more hardened in security sense.
Thanks to Treble, this shouldn't be a problem for phones launched with Pie. It should now be possible to build a single system partition then flash it to any Treble device.
Caveat applies though - the hardware layer won't update in this case (which includes the kernel version), so you'll have original (old, maybe buggy or insecure) drivers even though the platform is updated.
It's a huge improvement (a lot of bugs are in platform layer, including the media/stagefright stuff), but not yet perfect.
Android Inc should probably have gone with a micro kernel, instead of going for Linux' monolithic approach. Would have made things much easier to manage in regard to separation of concerns.
It could help, depending on one's goals - one of the most notorious issues (or features, depending on who you ask) with the Linux development process is ruthless interface refactoring which requires device drivers and board support packages to be in mainline or to become stale almost instantly.
A smaller surface area with a stable HAL would separate the proprietary / often bad board support code from the kernel itself and allow core changes to progress without requiring software-adverse hardware manufacturers to keep up.
Whether or not this is a good thing is certainly debatable, but I'm not convinced the Linux "get to mainline or get wrecked" approach has stood the test of time well.
That's a non-issue because a microkernel system call interface is stable. Drivers will simply continue to work in perpetuity. That seems like a huge help to me.
Why would you assume that? The set of required messages for drivers will increase over time, adding power saving commands, new hooks for higher level Android bits, and so on.
"Your WiFi only supports Android Kernel API 3.9. You need 7.0 to run this version of Google play".
The Linux kernel already has a stable user space ABI. If your hypothesis was valid, you would be able to upgrade the Android userspace on an old kernel with no problem. But you can't -- and that's with just one well specified ABI with a standardized, portable subset to worry about.
Anything not RAMIPS/MT76x8. If you want WiFi. I currently use a TL-MR3420 V5, which is 64/8 MB + MT7628 CPU, but WiFi is still broken. I'm gonna compile the latest revision of mt76 driver, today there was some talk on Github that it MAY fix SOME issues with SOME configs of WiFi routers... :/
I use mostly TP-Link stuff. The Archer C7 has been a good work horse lately. You will need something with more CPU power if you have Gigabit internet service. For everything else it seems more than capable.
You do nothing of the sort. You're buying a specific combination of hardware and software that may or may not get upgrades and security fixes over time, just like any Android phone. Apple just has a much better track record at doing that than any Android vendor.
On the other hand when I buy a laptop or an access point I just do minimal checking of supported hardware in case there's something that's very exotic and then I get to install whatever software I want for however long I want to keep the hardware in service. For the HN crowd this should be worrying. Mobile is the #1 hardware platform by unit volume and there's no way we can actually target these devices sensibly.
> You do nothing of the sort. You're buying a specific combination of hardware and software that may or may not get upgrades and security fixes over time
Bringing in strictly theoretical supposition which is directly at odds with what's historically been a very solid track record from Apple isn't doing your argument any favours. Unless I misunderstood you.
It's not strictly theoretical. The original comment clearly was calling out the Android and mobile ecosystem in comparison to other hardware devices. If I dig out my iPhone 3g, I'm not getting anything close to the latest iOS on it no matter what I try. I can pull out a laptop from the same time period and install quite a few of the top linux distros on it.
Any Apple device is a specific combination of hardware and software that Apple chooses when to stop supporting, and you have very little recourse. Apple has generally been better at providing support to older devices than Android (on average), but in the end the situation is fundamentally the same.
I've read my parent comment as a claim that we are all doomed because Apple might pull the plug one day -- which I dispute on the grounds that historically this hasn't been true. Also, iPhone 3g is ancient.
Outside of that I am in full agreement with you. The mobile ecosystem is basically a dystopia where we have zero recourse as you said.
Released 2008. If I get an x86 laptop from 2008, I can install a modern Ubuntu on it with approximately 0 effort. If anything, it'll usually be better than cutting-edge hardware because the drivers have already been developed and released in a stable Linux version. iOS still loses this comparison.
I’m not saying that you’re not making a valid point, but I would like to point out that you can still install the community-supported whited00r [1] on that 3G and still get some life out of it. Sure it’s probably breaking all sorts of copyright law to do so, and it’s not ideal, but the fact that almost no one on HN seems to know about it, and Apple has ignored it for years, underscores how little demand there is to keep 10 year old devices running.
Meanwhile I have a 5 year old 5S that I use while traveling which runs iOS 12.1 swimmingly, and keeping older devices running longer was a major topic discussed by Lisa Jackson at the last Apple keynote. I fully expect that this old phone will run iOS 13 as well, and I expect that current iOS devices will have increasingly longer usable lifespans than 5-6 years. There isn’t anything close in terms of manufacturer support on the Android side of things.
In terms of keeping phone hardware useful through an alternative OS, you may also want to keep an eye on PostmarketOS [2].
This. I managed to build recent Linux on a Pentium MMX Mobile (IIRC) laptop from 1998. A cell phone from 5 years ago can't handle a modern operating system, but a 1998 laptop can run Xorg just fine.
The funny thing is the SoC in these smartphones can totally run Linux & Darwin, but the driver support for the peripherals is shovelware. Vendors do the bare minimum to suppprt the hardware, and you get a mess.
Its frankly shocking that the Allwinner A10/A20/A64 (which can run Win10!) /H3/H5/H6 has nearly complete mainline kernel support, whereas nearly any of the smartphones made since 2008 can't boot mainline Linux and drive their cameras, screen, GPS, etc. Its a huge failing of the industry.
Allwinner can't run Win10 (hah, A33 can barely run Android :/ ) and has barely any mainline support on actual physical commercial devices (i.e. tablets, not SBCs)...
With regard to supporting tablets, most of the older Allwinner based tablets have feature parity between the mainline kernel and the vendor BSP kernel: https://linux-sunxi.org/Linux_mainlining_effort
A 2018 iPhone X is vastly more powerful than a 2008 iPhone 3G, whereas the performance improvement of laptops slowed dramatically after that point.
Take a copy of a standard 2008 version of Ubuntu desktop and try and install it on a 1998 laptop. I doubt it’d run at all, not without ditching the default desktop.
Um. I was actually going to concede the point, but look at your sibling comment. Apparently I'm not the craziest one in the room (believe me, I'm more surprised than you).
What't the point with software support if OS is unusable? I have iPhone 4S and it became unusuable when iOS 7 was released. I never wanted to upgrade, I wanted to downgrade which was impossible via official means. That's my main problem. If developers don't want to develop for old phones, that's their right. But they must not prevent me from installing old software.
The point isn't that Apple isn't good at doing updates. The very next sentence points out explicitly that they do that above and beyond everyone else in the space. The point is that you're locked in to a specific HW+SW ecosystem at the mercy of the vendor. If you like that ecosystem that may be great service to you, I'm pointing out that the #1 computing platform has only that choice and that's not the case in all the other major platforms so far. For the HN crowd that should be worrying.
The HN crowd, me included, are real humans with real needs and smartphone apps and convenience brings a real value to my life. For one, transparent syncing of photos, notes, basic spreadsheets and many others is a huge selling point of iCloud.
It's not about if I can buy a cheap FreeNAS rig -- an i5 CPU and 10-year old motherboard with 16-32GB of DDR2/DDR3 RAM -- and gradually add WD Gold hard drives to it. It's not about if I can use Syncthing and a command-line password manager. It's not about if I can use PostmarketOS or LineageOS and thus only buy Android-enabled devices (yay Linux freedom?).
I can do all that. But it requires more manual management. And I just don't have the time and energy for it.
It's strange to me to imply that the HN crowd are some sort of world-changers that never have financial struggles and live in beach houses a la Iron Man style with 3x independent gigabit fiber links and 500 sq.m. of home labs that rival Mythbusters' space -- and are constantly busy disrupting an area.
Truth is, even though in principle you are correct -- and even though I really would like to only use free [as in freedom and not a free beer] hardware and software -- the reality is that we all have jobs to do. And most of us actually love the people we live with and would want to spend a chunk of our free time with them. We all would love to get a normal amount of sleep and invest in the knowledge necessary to get proper nutrition because we're literally a hugely complex chemical compound and we better put the right chemicals inside of us...
...etc. etc to infinity., I can go on all day and night but I am pretty certain you got the point.
The HN crowd is certainly much more aware than many other crowds. Doesn't automatically imply they have the means to change a lot of things. Trust me, I'd like to live like Tony Stark and invent a ton of stuff that can change the world -- that includes his house and a lab -- but I am gradually coming to terms with the fact that I'll very likely stop at having 7-10 profitable consultancies and/or lifestyle businesses that will give me a peace of mind even after retirement.
Life is short and many of us don't want to work 24/7. More power to the people who can maintain a good living AND be inventors and disrupters. I have big respect for them.
You seem to be taking my point as prescribing what everyone should want. But that's not what I'm suggesting at all. I think well designed consumer software and hardware ecosystems that get out of the way are great. I don't want a world where there's no iPhone experience that has all that value in integration that you're describing. I'm not an OSX user but plenty of family members are and they seem to be well served by exactly that.
My point is that if the world's #1 computing platform only has that choice then we lose the ability to get some kinds of innovation driven by the few percent that care and have the time to tinker. And HN has a much larger proportion of the kinds of people that will want to do that innovation or at least value that it's possible. We wouldn't have gotten Linux if Linus couldn't develop on his hardware.
But maybe we've just been spoiled with mass-market general-purpose hardware up to now and this is the new normal. I shudder to think that but maybe it's true. At this point I don't think I'd much care for a smartphone if I didn't need it for work. And it's the stuff of nightmares for me particularly if that was also the case on the PC/laptop side of things.
Apologies if I misunderstood. No offense meant anywhere.
I agree that it's rather horrifying what we settled for these days. The world to me is a lot darker compared to my student years back in 1997 to 2001 when I played Quake3 for days on end, without sleep, with only WC and food breaks -- and when I was coding my heart and brains out on things I believed could shape the future world.
These are the times I'll dearly remember until the end of my life. And nowadays almost nobody seems to be wanting to make things better. It's saddening and extremely discouraging. I get it and I agree with your overall premise.
What I was mostly saying is that those of us who had wide-eyed naive optimism for the future and were there when the internet started gaining steam are now anywhere between 30 to 50 and we can only dream of the ages past when we could do the things you described without any other worries.
In the end, I am just pointing out that these past life phases are long gone and aren't likely coming back for the most of us. And I'll say it again: I have a big respect for those who still manage to truly innovate and disrupt.
> What I was mostly saying is that those of us who had wide-eyed naive optimism for the future and were there when the internet started gaining steam are now anywhere between 30 to 50 and we can only dream of the ages past when we could do the things you described without any other worries.
I agree and identify with this. The reason I point these things out here is that the kinds of people actually doing the leg work on these platforms are on the site. And in some cases if they did a few things differently (e.g., upstream the drivers much earlier in the SoC bringup) then maybe we could actually fix this. I'm not nearly as pessimistic about the situation as you :)
Oh, definitely! It's even worse because you don't even get a properly secured device, it's a horrible ecosystem right now. But because it actually runs an open-source kernel and the bootloaders can be unlocked in most cases there's a chance to fix it still. With Apple hardware, unlike in their laptops, you have no choice but to run their software.
>With Apple hardware, unlike in their laptops, you have no choice but to run their software.
Apple laptops are also in a pretty bad shape. Eventually, they may be usable as laptops for other (free) OSes with sufficient reverse engineering, but currently they can't. That they can be used at all is quite accidental due to things outside of Apple's control and other historical factors.
> I challenge you to name me one Android device that is officially supported for 4 or more years
This thread started with a comment about mobile phones in general being locked down to a specific kernel/os/software-combo, and that the upgrade paths is at the mercy of the vendor (unlike PCs).
Both Apple and Android phones are locked down. Who does it in the most convenient way is irellevant to the argument made.
Why does any criticism of Apple devices generally devolves into "but Android does it too", I expected better than fanboy-ism from the HN crowd.
The OP's comment was that any mobile devices these days, both Android and iOS are locked down black boxes. It wasn't specifically criticizing just Apple.
If you followed the dicussion you would see the big "both ecosystems are locked down and you are at the mercy of vendors" thread that goes on around here.
But it's easier to flag people as fanboys. <shrugs>
Since you are having trouble with getting what I said: I am saying that Apple in my eyes is the lesser evil of only two options. It's a very practical and time-saving decision to use Apple tech. But call it fanboyism if you like.
I am old enough to remember when buying a new laptop you would actually need to check if the wifi chip, the ACPI vs of the Mobo, the internal ethernet controller, the video card, hell even the sound card, had a linux-supported driver.
It was not always the case and for various reasons (mostly the much heavier integration constraints of different components) it is harder to make on a phone.
It may sound strange, but I think that redemption will come from efforts similar to the PiPhone [1] that allow to create devices from different manufacturers that were not specifically designed to work in a tightly integrated way.
Anecdotally, iOS 11 made my iPhone 6 run slower than iOS 10, but iOS 12 made it run faster than iOS 10. (This is in line with other reports and benchmarks you'll find if you go looking.) There's an awful lot of snark about iOS slowing down with each successive version, but I'm not at all convinced it's universally true. (Again, anecdotally, I'd say iOS 7 and 9–11 were guilty of that.)
At any rate, the big issue I tend to hear about Android phones getting updates is "my Android phone isn't getting updates." My iPhone 6 shipped in 2014, and iOS 12 actually ran on 2013's iPhone 5s. How many Android phones that shipped before 2016 are getting Android P? Are there Android phones that shipped in 2016 that aren't?
> Here's an awful lot of snark about iOS slowing down with each successive version, but I'm not at all convinced it's universally true. (Again, anecdotally, I'd say iOS 7 and 9–11 were guilty of that.)
It's not universally true. It's mostly true, with a couple of outliers (namely iOS 9 and iOS 11). Most of time, major iOS upgrades slow down older hardware.
I wouldn't necessarily have a problem with this, if not for the fact that iOS downgrades are literally impossible (outside a small window of time). Install an update and discover your phone is too slow? Either learn to live with it or buy a new phone.
> I wouldn't necessarily have a problem with this, if not for the fact that iOS downgrades are literally impossible (outside a small window of time). Install an update and discover your phone is too slow? Either learn to live with it or buy a new phone.
Or you could just restore from a backup, possible at any time.
Nope, you can't restore to an iOS version that isn't being actively signed by Apple's servers. Restoring a backup just puts back user data, it doesn't change your iOS version.
> You can downgrade (If you don’t have Shsh blobs saved) only until Apple is still signing the old software.
Saving SHSH blobs needs to be done in advance, while the iOS version you want to install is still being signed by Apple. With blobs, you used to be able to use a replay attack to force a restore. This doesn't work anymore due to the addition of NONCE, except in very limited and not particularly useful circumstances (you can move to an unsigned iOS version IF you're already Jailbroken AND if SEP is compatible).
If you know a way around this system, please do share. The Jailbreak community will love you for it. :)
Apple does everything in their power to make downgrading iOS impossible outside of a narrow window. I suspect this is also why we haven't seen any actual, definitive speed tests between different iOS versions. The discussion always devolves into "this feels slower" or "I remember my phone used to be like this," because no one can actually install an older version to test with.
I'm fairly sure I have seen speed tests between iOS 11 and 12 with actual numbers involved. Someone who has a single phone and upgrades it can't do it, no, but someone who runs, say, a testing lab, or iFixit, or any other place where it's possible to have two different iPhones of the same model running two different versions of iOS can do it pretty easily. Googling "ios 11 vs ios 12 speed" shows a plethora of links from people doing exactly that. I found the same for "ios 11 vs ios 10 speed"; I didn't keep repeating the experiment past that. :)
As to your original point, though -- yes. I'd certainly prefer it if Apple didn't make downgrading so difficult, even if it's just on general principle. I've rarely been tempted to downgrade, but iOS 11 could be pretty clunky on my iPhone 6 compared to its predecessor. (I think 11.4 finally smoothed all that out, but that came out literally a week before iOS 12 was announced!)
> There's an awful lot of snark about iOS slowing down with each successive version, but I'm not at all convinced it's universally true
Yes, it is, just not this time because of all the backlash Apple has received over the past few years over this issue. Let's see how iOS13 and 14 do, but my guess is they will be slower still.
People love to latch onto the outlier cases when an iPhone gets slower or half-broken after an update. For the last 5-6 years however, everyone I asked told me that their iPhone and iPad either gets a bit smoother or stays the same after a new iOS.
So please don't imply iOS updates brings iDevices "ever closer to unusably slow" because that's very non-factual.
> For the last 5-6 years however, everyone I asked told me that their iPhone and iPad either gets a bit smoother or stays the same after a new iOS.
Except those who Apple was "helping" "preserve battery life" by purposefully slowing the clock speeds on updates without telling them? I've often wondered how many people went out and actually purchased an entirely new phone due to this unannounced "help" vs slapping a (relatively cheap) new battery in it?
It's a basic electronics knowledge that there's a danger in physically damaging a chip if you continuously feed it less voltage than it needs.
What Apple did is to prefer to have people's devices run slower compared to breaking them.
What they did wrong was keeping quiet about it. I ain't ever disputing that, it was a really bad decision to hide it.
The reasoning to do it however has solid foundations in physical reality. Even I that I know nothing of electronics went out of my way to read about it and asked several electronical engineer acquaintances of mine and they all said Apple did the right thing by slowing down the devices.
Oh get off it. Either Apple didn't know they were ruining last gen phones, which means they're incompetent at best or they knew and chose to do it anyways which makes them actively malicious.
As a long time Android user and app developer I would rather use slow secure device that doesn't break rather than fast insecure one.
Every single Nexus device I have owned, and I have owned every model starting from Nexus S, went out with some sort of hardware failure in 2.5 years time. Either faulty chip, buttons or connectors.
Say what you want about Apple pricing and some bad decisions along the way, but their approach to security, hardware build quality and overall experience of using their device over longer periods of time is very good and certainly beats Android devices.
I wish there were good alternatives with open platform but there are none currently and I don't think there will be any in the next few years.
P.S. I switched to iPhone about a year ago and I don't really miss Android.
> It's all about tradeoffs, Android phones getting updates usually means the phone gets faster as opposed to ever closer to unusably slow.
You say this like it is unique to android, iOS 12 was basically the same. And I can say from friends experiences, its not always true for all android phones.
No, Android phones usually means not getting the updates in time, or at all. Speaking as someone who participated in 2008 Android Developer Challenge and had Android phones since, and until the last year.
This is happening because of Project Treble which creating a boundary between device drivers and the kernel.
Earlier, kernel versions (even android versions itself) were subject to integration of device drivers into the kernel source code... which took a long time and often resulted in forced obsolescence.
By separating out the driver interface using Treble, you can update the kernel and android versions from upstream without worrying about driver integration/updates.
This is happening, because Project Treble still requires OEMs to ship updates and in one year after its introduction, Oreo got a meager 10% when Android P was announced and OEMs were still shipping Nougat with updates to Oreo, which doesn't require Project Treble compliance in such cases.
Google is finally facing the issue that regular consumers aren't caring to update anymore, specially now that devices are quite usable for several years.
So if they want to bring new OS versions into the market they really have to force OEMs to do it.
Hence the new GSI concept, finally adding update clauses to the Play Store usage agreement, and now upstreaming kernel changes.
As soon as I read the title I started to wonder what (if anything) this means for Fuchsia. At first I thought “oh, they’re doubling down on Linux-powered Android and that in turn means they’ll be setting Fuchsia aside” to “ah, adding a HAL to the Linux kernel and reproducing it’s interfaces elsewhere is a great way to enable proprietary devices to switch OSes”. Does anybody more knowledgeable in the matter have other thoughts?
I'll believe that real progress has been made when google updates the major kernel version for a phone. No OEM (AFAIK) has ever done a kernel (major version) bump.
Honestly, it's extremely difficult to update the kernel since it's usually tied to the BSP the SoC vendor is providing.
Also, you gotta keep in mind the difficulties associated with the lazy 3rd parties providing drivers for a single kernel version, making updates almost impossible.
--
Disclosure : I work for an OEM as a system architect, and it's been one of my goals to try and get newer kernel versions running. (Suffice to say I failed so far)
Doing so will require a complete shift of responsibilities for parties involved. I myself witnessed many "brains being broken" scenes when somebody tries to explain why Linux kernel development being done for "free", to men with educational background in business.
In the end, you will never be successful doing so, be sure 99%. But whether they understood the bigger picture of things or not, technical needs need to supersede business needs, or that tech business will not work.
Is upstreaming hardware drivers to at least staging quality that much of an uphill task? Seems like this should be fixed at the source by having the initial development go straight into mainline. That's what seems to happen for PC hardware anyway.
That's exactly it. And even keeping to the preferred/qualified vendor list provided by the SoC vendor does not guarantee that the drivers will be in the mainline...
Android's use of the kernel really is fundamentally broken
It was either the original Moto G or the 2nd gen one that got a kernel version bump - from 3.4 to 3.10, I think. I remember being impressed at the time.
Newer Sony devices got a major version bump from 4.4 to 4.9 with their Pie releases:
I wonder if the major version update for Sony's 9.0/Pie was due to a Qualcomm BSP change, or if it was solely their initiative? I think the reason for typically not doing major kernel updates may be down to sticking with reference stuff from BSPs. (I don't think they're offering any big updates, not kernel or Android major versions, for their Mediatek stuff. I think that might be typical though.)
Kind of cool, anyway, to move from one LTS kernel release to the next. I wonder have any other OEMs made the same move?
The Galaxy S and Galaxy Nexus both got major version bumps. Old history at this point, but it does show that this can happen... (https://lwn.net/Articles/738225/)
The article actually addresses that - why would Google (or Samsung or anyone really) risk device issues by doing this kind of upgrade? What is there to gain on a running device except angry users due to breakages of already working functionality?
There's an upwards trend of people DISABLING updates because they tend to break tools they use in daily lives.
>What is there to gain on a running device except angry users due to breakages of already working functionality?
That's true, but regular distros are also faced with the same dilemma, and you see both cases. RH will patch a kernel to death ship of Theseus style for a decade, whereas Canonical offers newer stable kernel releases (although they also maintain the original kernel that the distro shipped with). Canonical leans more towards updating to a newer kernel version though.
>There's an upwards trend of people DISABLING updates because they tend to break tools they use in daily lives.
The general public is affected more by questionable updates higher up in the stack. I doubt if they interact directly with the kernel.
> The general public is affected more by questionable updates higher up in the stack. I doubt if they interact directly with the kernel.
Things like bluetooth, OpenGL drivers and Wifi drivers are usually the pain points which love to break (or more accurately: break in a different way) when upgrading them. This causes those endless "I've updated my iPhone/Android phone and now it doesn't work with my car anymore!" posts. It's usually preferrable to keep the things working as they are, since we humans accept that more easily.
All this vendor-provided code is why lesser-used hardware features like bluetooth low energy don't work on many tablets, even new ones. Good luck trying to get web-bluetooth running on Chrome, despite it supposedly being supported for Android 6.0 and later [1]. Samsung seems to have good support, but Lenovo and Vivo don't support it, despite saying they support Bluetooth 4 on recent devices.
> Devices will be expected to run this kernel; to make that happen, vendors will provide a set of kernel modules to add the necessary hardware support. Getting there will require the upstreaming of kernel symbol namespaces among other things.
Google should go one step further and require upstreaming hardware drivers.
Nice to see that progress is being made on upstreaming the Android patches. Hopefully this will make it easier for ex. postmarketOS to work using a vanilla kernel, or at least to update the version used.
While hacking on postmarketOS off and on for the last year, the #1 issue was always dealing with crappy old kernels from manufacturers with out of tree patches that would no longer apply to the current mainline.
Unfortunately this problem will still exist with the proposal in the article, manufacturers will still be allowed to ship out of tree code. Being able to boot a mainline kernel on your device is practically useless if the code necessary for display, input, audio, etc are out of tree and thrown over the wall by the manufacturer with no intention of keeping it up to date.
This is even an issue with Chromebooks from Google (e.g. Chromebook Pixel 2015). Sure, it "runs Linux", but how useful is that if you can't put any other distro on it? After a few years we finally got all of the Chromebook-specific patches pushed to mainline Linux, but Google doesn't seem to care about mainline at all.
Misread the title as "Bringing the Android kernel back to the mainframe". Since you can run mainframe emulators on Android, it only seems fair to run Android on mainframes. I wonder if the code is 36 bit clean?
I've always found this curious since Linux fans usually mention the high usage of Android as Linux usage. The people usually think of GNU/Linux when they think about using Linux but the truth is Android is far from that. Be it the lack of GNU utils, not using a mainline kernel or the myriad of blobs and proprietary stuff bolted on top.
It's not clear what you are curious about. You can run GNU/Linux with out of tree modules (e.g. proprietary nvidia graphics driver). That doesn't change the fact that you're running a (now probably tainted) Linux kernel.
I don't think anyone is thinking of a GNU/Linux desktop environment when they think "Android runs Linux!", they are quite literally thinking "Android uses the Linux kernel." They are not wrong.
Of course. I wasn't talking about the population of HN, I mean it in a broader sense, people who know GNU/Linux is a thing but don't know or care enough to realise the differences.
I'm curious about what is there to celebrate in some huge corp using some free software in a completely cornered use that gives little to no freedom to its users.
I'm sorry if my points are not clear. As it has been evidenced english is not my first language.
> I'm curious about what is there to celebrate in some huge corp using some free software in a completely cornered use that gives little to no freedom to its users.
Huge amount of money poured into development of said opensource software - including the patches in the article you're commenting on.
Major opensource projects are (and have for years) receiving most contributions from developers in Microsoft, Google, Intel, RedHat, Pivotal, and many others.
Ah, I see your point. I suppose there are folks who know GNU/Linux is a thing, but don't understand the distinction between "it uses a Linux kernel" and "it uses a Linux kernel and gnu-friendly environment." In which case they would wrongly equate Android == Linux == GNU/Linux.
> As it has been evidenced english is not my first language.
No problem, I'd say that your English seems great, better than some native English speakers I know. English is my first language and it's easy for me to be unclear :D
Unlike most other environments, though, it is very simple to create an Android application which embeds and launches a Linux userland, without any virtualization or syscall-ABI translation being required. See, for example, https://termux.com/
ChromeOS is also "Linux" in this sense, because of Crouton.
Agreed, the Linux kernel is nothing more than a board support package for Android. Android applications are not Linux applications. And Fuschia/Zircon are clearly efforts replace the kernel.
It would also be really nice if common distributions finally considered creating feature+architecture-based repositories, small improvements that you get by creating more specific binaries really sum up on mobile/low-powered devices. It does require more effort (and money for storage, compilation) though.
