"Hey open source nerds, can you do all this hard work for free so we can sell it?" - says a trillion dollar corporation

Umm, and what's the problem? Companies have been 'selling' (or at least profiting off of) open source/free software for a couple decades. Do you just dislike Google in particular?

Google has contributed back a lot of engineering and code to the open source community, too. They aren't exactly freeloaders.

I see no problem with Google wanting to use the primary Linux kernel and not wanting to fork it. This seems like a good idea.

A stable driver ABI also seems, like a good idea, and seemed like a good idea 20 years ago, but the Linux devs seem to be institutionally opposed to this for no good reason. But, you know, screw users.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Because Windows was designed this way since NT began. Unix wasn't, and Linux inherited what Unix begat. Microsoft has a 30 year head start.

Edit: Apparently nobody remembers that *nix was all monolithic kernels until not too very long ago. S'ok.

Some flavors of *nix based OSs are still unbelievably picky about hardware even today...particularly BSD-based stuff.

Fascinating article as usual from Ars.This is the reason why Android has so few years of support, even on Google's own phones, as opposed to Apple.It's really hard to patch bugs discovered in five year old kernels, not to mention deal with all the partner companies.Apple, on the other hand, owns the whole stack from kernel, to OS, to chipset, to hardware manufacturer. (Not to mention only like 5 devices.)

Yep.

And all that goes back to what you want.

Apple is crazy restrictive and has very few choices when it comes to features. Basically what year and what size, MAYBE what size storage.

Android has an amazing number of features to pick from depending what you like...ranging from mixed options of expansion/accessories to ports and even different form-factors, some more modular than others, and the software is equally flexible depending what you want.

Supporting "this is the thing, you will like it" is a much easier objective than having a large variety of choices. But it's also one of the huge pluses depending on which you care about.

Personally, I still prefer having more say in which hardware features I want and what software options I use. It's why I have most of the time not been buying Samsung devices...other brands have provided more of the features that *I* care about. And it's why I have apps like Tasker, AutoVoice, AutoNotification, among others that help me tweak and customize the way things work and streamline what I want my device to be. periodically "security" breaks some of these and causes frustration...Apple never offered most of it in the first place.

Isn't there *also* a list of x86 drivers that *haven't* successfully been upstreamed, for things such as graphics and wireless networking which are, unfortunately, what Mobile is mostly about ?

For PC/server hardware it's a very short list.The only egregious case is the NVIDIA, thought they've mellowed up a bit.

AMD has moved to an upstreamed kernel driver which can work either with the open source user space or the closed source user space.And even before they were already contributing to the upstreamed open source driver and relying on it as they dropped support for older cards from the closed source driver.

The situation with wireless has been pretty good for years.Most common problem is that if you buy a laptop it may come with a fancy new wireless card whose driver isn't yet upstreamed and baked into your distro of choice. But it's been years since I actually faced that problemAnd if you search a bit you'll find plenty of hardware which will work out of the box.

Do note that, in general, the hardware is not the same thus nor are the drivers.Eg PCs have GPUs from intel, NVIDIA or AMD.No smartphone and virtually no tablet has that. Virtually all use ARM's Mali or Qualcomm's Adreno GPUs.

On mobile hardware you're pretty much screwed no matter how much you look.As noted in the article even if a smartphone manufacturer cares at least the smaller players don't have the weight to extract that from the SoC manufacturers.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

The reason Microsoft can is because IBM's original design of the PC included BIOS, which provided a consistent interface for the Operating System regardless of the underlying hardware.

Example, if one system used Real Time Clock(RTC) from Vendor A and another used a chip from Vendor B. The 2 systems would have slightly modified BIOS, in order to initialize/read/set the different RTC chips, but as long as they both provided the same API to the OS would still work without changes.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Because Microsoft is pragmatic. They aren't FOSS neckbeards with egos the size of planets who go around saying "if you want your drivers to work you have to make them open source (giving away thousands of manhours of paid work to competitors) and put them in the kernel tree". Instead, Microsoft have a stable interface driver that vendors can use, so of a drivers works on Vista, it works on Windows 10.

Needless to say, the FOSS plan of "open source drivers in the kernel tree" has backfired. Instead of the drivers becoming free, the whole kernel is proprietary.

I also don't know if I'd say that it's backfired. The only really big problem is Android, and the Android dev team's general approach to Linux has been so generally shit that it's questionable whether there's any way to accommodate them without some concessions to the quality of the kernel itself (which is something that Linus isn't going to do).

It's fair to point out that the article you link to to justify "stability, security, and maintenance concerns" kinda confirms some of the OP's suspicions concerning the political motivations of kernel developers. The article (which is very short), contains the following language:

Quote:

Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech).

The article contains a few other places where it is politely suggested that proprietary driver writers should FOAD. There may be valid security reasons, and having to maintain legacy interfaces is certainly a PITA. On the other hand, one could argue that the failure to standardize on simple things like what compiler is used to build the kernel in the first place (a lot of the stated objections to a stable ABI simply vanish if one commits to using GCC--which has had a stable C ABI for a very long time). Even if one were to allow for compile time kernel options (such as disabling SMP on single-core machines, a swiftly vanishing concerns as even the lowest-end CPUs are more likely to come with at least two cores, if not more), producing a stable ABI that is insensitive to such things isn't really hard.

It's fair to point out that the article you link to to justify "stability, security, and maintenance concerns" kinda confirms some of the OP's suspicions concerning the political motivations of kernel developers. The article (which is very short), contains the following language:

Quote:

Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech).

The article contains a few other places where it is politely suggested that proprietary driver writers should FOAD. There may be valid security reasons, and having to maintain legacy interfaces is certainly a PITA. On the other hand, one could argue that the failure to standardize on simple things like what compiler is used to build the kernel in the first place (a lot of the stated objections to a stable ABI simply vanish if one commits to using GCC--which has had a stable C ABI for a very long time). Even if one were to allow for compile time kernel options (such as disabling SMP on single-core machines, a swiftly vanishing concerns as even the lowest-end CPUs are more likely to come with at least two cores, if not more), producing a stable ABI that is insensitive to such things isn't really hard.

To have a stable ABI you need a lot more than just committing to use GCC.First and foremost you need to keep a stable API which is the major elephant in the room here.The Linux kernel developers don't want to be restricted in their ability to do major code reforms by the need to support out-of-tree drivers (independently of those being open source or not).And considering that the current kernel carries working drivers for hardware which has gray beard, there's more than politics to this.

Once you reject that requirement then the rest of the requirements for a stable ABI become pointless.But just for completeness sake you must also not change macros nor inline functions nor add elements to structs nor change alignment directives nor possibly more things I'm forgetting.

"Hey open source nerds, can you do all this hard work for free so we can sell it?" - says a trillion dollar corporation

That's not the vibe I was getting from this article. It sounds like Google is willing to do (and pay for) the work, but since Google ≠ Linus Torvalds, they need consensus to get what they eventually produce into, you know, the actual mainline kernel. Hence the talking things out with open source nerds.

This is my main takeaway here.

Wanting to change how things are done benefits them, certainly, but also lots of people down the line. They're working with the OSS community and doing their own work to provide a little direction. I have plenty of criticisms on the disparity between Google's open-source speaking, and some of the ways they actually handle licensing, but I don't see much wrong with this. An improved way of handling mainline kernels would seem to be a benefit for everyone, Google would just be another recipient of that, and will likely do a lot of work on their own behalf that is brought back to everyone.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Because Microsoft is pragmatic. They aren't FOSS neckbeards with egos the size of planets who go around saying "if you want your drivers to work you have to make them open source (giving away thousands of manhours of paid work to competitors) and put them in the kernel tree". Instead, Microsoft have a stable interface driver that vendors can use, so of a drivers works on Vista, it works on Windows 10.

Needless to say, the FOSS plan of "open source drivers in the kernel tree" has backfired. Instead of the drivers becoming free, the whole kernel is proprietary.

I also don't know if I'd say that it's backfired. The only really big problem is Android, and the Android dev team's general approach to Linux has been so generally shit that it's questionable whether there's any way to accommodate them without some concessions to the quality of the kernel itself (which is something that Linus isn't going to do).

It's fair to point out that the article you link to to justify "stability, security, and maintenance concerns" kinda confirms some of the OP's suspicions concerning the political motivations of kernel developers. The article (which is very short), contains the following language:

Quote:

Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech).

The article contains a few other places where it is politely suggested that proprietary driver writers should FOAD. There may be valid security reasons, and having to maintain legacy interfaces is certainly a PITA. On the other hand, one could argue that the failure to standardize on simple things like what compiler is used to build the kernel in the first place (a lot of the stated objections to a stable ABI simply vanish if one commits to using GCC--which has had a stable C ABI for a very long time). Even if one were to allow for compile time kernel options (such as disabling SMP on single-core machines, a swiftly vanishing concerns as even the lowest-end CPUs are more likely to come with at least two cores, if not more), producing a stable ABI that is insensitive to such things isn't really hard.

The article I linked to is written by the guy who's effectively second in command on the kernel. I didn't link it to give my justifications (mine would literally just be "I need to be able to change this if there are issues"), I linked it to show what the official position is according to the people who actually maintain it.

And yes, it supports the literal argument that anything using the ABI has to either be open source or will receive zero support or attention, but... well, you don't call someone a "FOSS neckbeard" to make a point about maintenance.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

A lot of people replying to you bring up valid points, but they are missing the main point: ARM SoC's. They're not standardized like the x86 platform is. Try taking an ARM build of Windows and installing on an ARM based Chromebook. It won't work. Microsoft has the same issue.

At this point in the game, managing to have drivers not encumbered by 3rd-party IP, let alone open-source drivers, is a practical impossibility.

This often repeated but patently false.There's plenty of source code for Android drivers.The very fact that the kernel is licensed under GPL means that kernel mode drivers have to be be GPL'd or use a shim.Eg, https://www.nokia.com/phones/en_int/opensource

The problem is that the hardware manufacturers don't put in in the the effort of getting these drivers accepted into the mainline kernel.Thus the drivers quickly rot and become unusable with modern kernel. And 3rd parties lack either the manpower or the device knowledge to fix and mainline the drivers.

"Hey open source nerds, can you do all this hard work for free so we can sell it?" - says a trillion dollar corporation

That's not the vibe I was getting from this article. It sounds like Google is willing to do (and pay for) the work, but since Google ≠ Linus Torvalds, they need consensus to get what they eventually produce into, you know, the actual mainline kernel. Hence the talking things out with open source nerds.

Okay now you're just being too sensible for a proper web discussion on Android.

"Hey open source nerds, can you do all this hard work for free so we can sell it?" - says a trillion dollar corporation

That's not the vibe I was getting from this article. It sounds like Google is willing to do (and pay for) the work, but since Google ≠ Linus Torvalds, they need consensus to get what they eventually produce into, you know, the actual mainline kernel. Hence the talking things out with open source nerds.

This is my main takeaway here.

Wanting to change how things are done benefits them, certainly, but also lots of people down the line. They're working with the OSS community and doing their own work to provide a little direction. I have plenty of criticisms on the disparity between Google's open-source speaking, and some of the ways they actually handle licensing, but I don't see much wrong with this. An improved way of handling mainline kernels would seem to be a benefit for everyone, Google would just be another recipient of that, and will likely do a lot of work on their own behalf that is brought back to everyone.

Seems like a win/win to me.

It is on the face of it. In practice, previous attempts by Google to work with the community have involved Google doing plenty of work. The issue, at least as I've seen it explained by those in the community, is that they've often done that work on their own, rejected input from the community, and tried to force in changes structured in a way would only have benefited Android rather than in a more generic way that would support other OSes.

That leaves the kernel community on the hook to support stuff that's only useful for Google, and in some cases it means that they have to support several versions of the same stuff: one for Android, and one for everyone else. That's not exactly a win for the kernel community, and I'd imagine they won't be too interested in agreeing to even an LTS-stable ABI for the company unless it's willing to cut that out.

The problem is that the hardware manufacturers don't put in in the the effort of getting these drivers accepted into the mainline kernel.Thus the drivers quickly rot and become unusable with modern kernel. And 3rd parties lack either the manpower or the device knowledge to fix and mainline the drivers.

Yes, AMD and Intel are perfectly capable of pushing up drivers to mainline Linux.

It's fair to point out that the article you link to to justify "stability, security, and maintenance concerns" kinda confirms some of the OP's suspicions concerning the political motivations of kernel developers. The article (which is very short), contains the following language:

Quote:

Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech).

The article contains a few other places where it is politely suggested that proprietary driver writers should FOAD. There may be valid security reasons, and having to maintain legacy interfaces is certainly a PITA. On the other hand, one could argue that the failure to standardize on simple things like what compiler is used to build the kernel in the first place (a lot of the stated objections to a stable ABI simply vanish if one commits to using GCC--which has had a stable C ABI for a very long time). Even if one were to allow for compile time kernel options (such as disabling SMP on single-core machines, a swiftly vanishing concerns as even the lowest-end CPUs are more likely to come with at least two cores, if not more), producing a stable ABI that is insensitive to such things isn't really hard.

To have a stable ABI you need a lot more than just committing to use GCC.First and foremost you need to keep a stable API which is the major elephant in the room here.The Linux kernel developers don't want to be restricted in their ability to do major code reforms by the need to support out-of-tree drivers (independently of those being open source or not).And considering that the current kernel carries working drivers for hardware which has gray beard, there's more than politics to this.

Once you reject that requirement then the rest of the requirements for a stable ABI become pointless.But just for completeness sake you must also not change macros nor inline functions nor add elements to structs nor change alignment directives nor possibly more things I'm forgetting.

Major reforms can still be done, at major kernel revision upgrades. But, at least commit to a stable API/ABI for major release versions and their minor releases over the course of a few years.

I totally understand if I can't use the latest kernel on my phone from 6 years ago. But at least if the major release versions kept a stable api/abi, then my phone from six years ago might be able to upgrade to the latest of an older, LTS series of kernels that was maybe released a month ago.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Because Microsoft is pragmatic. They aren't FOSS neckbeards with egos the size of planets who go around saying "if you want your drivers to work you have to make them open source (giving away thousands of manhours of paid work to competitors) and put them in the kernel tree". Instead, Microsoft have a stable interface driver that vendors can use, so of a drivers works on Vista, it works on Windows 10.

Needless to say, the FOSS plan of "open source drivers in the kernel tree" has backfired. Instead of the drivers becoming free, the whole kernel is proprietary.

I also don't know if I'd say that it's backfired. The only really big problem is Android, and the Android dev team's general approach to Linux has been so generally shit that it's questionable whether there's any way to accommodate them without some concessions to the quality of the kernel itself (which is something that Linus isn't going to do).

GregKH has publicly called people who write proprietary drivers "leeches". Linus is busy dropping middle fingers to companies like Nvidia who don't want to share their drivers' sources with competitors (and considering how crap Intel drivers are, can you blame Nvidia for not wanting to share their homework in which they have poured millions of dollars to with Intel?). So, yeah, there is some "EVERYTHING SHOULD BE FOSS BECAUSE WE ARE THE BEST" sentiment in there.

In a FOSStopian world where companies develop drivers just to share with competitors via the kernel tree, then the kernel tree model would result in better stability, security, and maintainability, I agree. In our world, it results in a mess of forked, never-updated kernels.

I 'd say that the kernel tree strategy has backfired. The only really big problem is Android because Android is the only big commercial success for Linux in the home computing space. If market circumstance forced the Dells and Lenovos to offer Desktop Linux for real in their systems, targeted at Average Joes and not developers, you can bet Dells and Lenovos would ship their laptops with a proprietary kernel having proprietary Nvidia drivers welded to it so people will be able to use the 1070 Max-Q graphics card in the laptop they bought and in order to have Optimus work correctly. And of course the Dells and Lenovos would be in charge of updates, like they currently are on Android.

Major reforms can still be done, at major kernel revision upgrades. But, at least commit to a stable API/ABI for major release versions and their minor releases over the course of a few years.

I totally understand if I can't use the latest kernel on my phone from 6 years ago. But at least if the major release versions kept a stable api/abi, then my phone from six years ago might be able to upgrade to the latest of an older, LTS series of kernels that was maybe released a month ago.

You are basically describing how Linux distributions with long term support work. Eg, every major RHEL release has a stable ABI which it carries over it's 10 year life time.But this has consequences and you won't like them.

On one hand you can't bring big changes to the long term versions because they would break API/ABI. So you end up with a model where after the initial release your phone will get security updates but not major Android updates (because the new Android depends on a new feature which can't be backported to your long term version).

On the other hand for the things you will bring back to the long term version (eg, security fixes) at any given point in time you're spending resources porting things across the head and the 2-3 currently supported long term versions.

Just to be clear this is quite different from Windows.At every "major" release Windows changes it's driver ABI but keeping backward compatibility with previous driver ABIs for more than a decade worth of releases.The drawback here is the effort and the restrictions which come with keeping this backward compatibility.

"Hey open source nerds, can you do all this hard work for free so we can sell it?" - says a trillion dollar corporation

That's not the vibe I was getting from this article. It sounds like Google is willing to do (and pay for) the work, but since Google ≠ Linus Torvalds, they need consensus to get what they eventually produce into, you know, the actual mainline kernel. Hence the talking things out with open source nerds.

This is my main takeaway here.

Wanting to change how things are done benefits them, certainly, but also lots of people down the line. They're working with the OSS community and doing their own work to provide a little direction. I have plenty of criticisms on the disparity between Google's open-source speaking, and some of the ways they actually handle licensing, but I don't see much wrong with this. An improved way of handling mainline kernels would seem to be a benefit for everyone, Google would just be another recipient of that, and will likely do a lot of work on their own behalf that is brought back to everyone.

Seems like a win/win to me.

It is on the face of it. In practice, previous attempts by Google to work with the community have involved Google doing plenty of work. The issue, at least as I've seen it explained by those in the community, is that they've often done that work on their own, rejected input from the community, and tried to force in changes structured in a way would only have benefited Android rather than in a more generic way that would support other OSes.

That leaves the kernel community on the hook to support stuff that's only useful for Google, and in some cases it means that they have to support several versions of the same stuff: one for Android, and one for everyone else. That's not exactly a win for the kernel community, and I'd imagine they won't be too interested in agreeing to even an LTS-stable ABI for the company unless it's willing to cut that out.

Hmm. Well, those people likely have a better idea of the specifics than I do, and that sounds unfortunate. I hope that if Google does push for and get this, that those fears are unfounded and Google puts a lot of work in as well.

I a FOSStopian world where companies develop drivers just to share with competitors via the kernel tree, then the kernel tree model would result in better stability, security, and maintainability. In our world, it results in a mess of proprietary kernels.

The only really big problem is Android because Android is the only big commercial success of Linux in the home computing space. If market circumstance forced the Dells and Lenovos to offer Desktop Linux for real in their systems, you can bet they would ship with a proprietary kernel with proprietary Nvidia drivers welded on it so people can use the 1070 Max-Q in the laptop they bought and have Optimus work correctly. And of course they would be in charge of updates.

Again, in the real world, the Linux driver model works fine for most hardware.The exception is pretty much

a) NVIDIA. Because NVIDIA doesn't give a f**k about people with Optimus laptops as they know their real paying Linux customers comes from people using workstations and servers.Because the entire problem with the NVIDIA proprietary driver is that is integrates poorly (or not at all) with major revisions and cleanups going on in Linux graphics stack.

b) Companies who don't want to spend a dime on supporting their hardware once you bough it (or often, once it's no longer being chose for new designs). Which also happens on Windows. Eg see the hardware which lost Windows updates ahead of time because of driver issues suck as Cloverfield.

At which point instead of complaining about Greg K-H maybe you should face reality: the entire problem here is that the "people" writing proprietary drivers don't give a f**k about your needs for a long term hardware support.So calling them leeches isn't out of order.

Because otherwise there are known proven solutions to all of these problems.AMD has mainlined the kernel part of the driver, supports the development of the open source user space but also provides closed source user space components.And there are no complaints from the kernel or X developers.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Because Microsoft is pragmatic. They aren't FOSS neckbeards with egos the size of planets who go around saying "if you want your drivers to work you have to make them open source (giving away thousands of manhours of paid work to competitors) and put them in the kernel tree". Instead, Microsoft have a stable interface driver that vendors can use, so of a drivers works on Vista, it works on Windows 10.

Needless to say, the FOSS plan of "open source drivers in the kernel tree" has backfired. Instead of the drivers becoming free, the whole kernel is proprietary.

I also don't know if I'd say that it's backfired. The only really big problem is Android, and the Android dev team's general approach to Linux has been so generally shit that it's questionable whether there's any way to accommodate them without some concessions to the quality of the kernel itself (which is something that Linus isn't going to do).

GregKH has publicly called people who write proprietary drivers "leeches". Linus is busy dropping middle fingers to companies like Nvidia who don't want to share their drivers' sources with competitors (and considering how crap Intel drivers are, can you blame Nvidia for not wanting to share their homework in which they have poured millions of dollars to with Intel?). So, yeah, there is some "EVERYTHING SHOULD BE FOSS BECAUSE WE ARE THE BEST" sentiment in there.

I'm not saying that the sentiment isn't there. I'm saying that the sentiment isn't the reason why they've refused to provide a stable ABI. As for Linus giving NVIDIA the finger, IIRC that was less just a matter of the company failing to support FOSS and more to do with the company being generally horrible to work with. That's the explanation Linus gave, at least, and I'm inclined to believe it given that he's not exactly forgiving towards more FOSS-friendly companies that similarly dick him around. See also: Linus suggesting that they move to ARM because of the bullshit Intel pulled with the kernel after Meltdown.

Quote:

In a FOSStopian world where companies develop drivers just to share with competitors via the kernel tree, then the kernel tree model would result in better stability, security, and maintainability, I agree. In our world, it results in a mess of proprietary kernels.

I 'd say that the kernel tree strategy has backfired. The only really big problem is Android because Android is the only big commercial success of Linux in the home computing space. If market circumstance forced the Dells and Lenovos to offer Desktop Linux for real in their systems, targeted at Average Joes and not developers, you can bet Dells and Lenovos would ship their laptops with a proprietary kernel having proprietary Nvidia drivers welded to it so people will be able to use the 1070 Max-Q graphics card in the laptop they bought and in order to have Optimus work correctly. And of course the Dells and Lenovos they would be in charge of updates, like they are on Android.

A few things to mention here.

First, "the only big commercial success of Linux in the home computing space" has a pretty significant condition attached to it. Home computing is a segment of a much, much larger market, and the fact that you have to qualify this down to just that market segment in order to make your argument massively weakens it. Linux's approach isn't nearly as much of a barrier in other markets, so it's pretty blatantly clear that the model they use isn't unworkable in general.

Second, you're objectively wrong in your "Dells and Lenovos" example. Both companies (and other OEMs) have sold computers that come with Linux pre-installed (usually Ubuntu for home users), both companies (and other OEMs) provide support for users with Linux, and as far as I know neither of them uses a proprietary kernel.

Finally, Android is the big problem both because it's popular and because Google has effectively encouraged this approach. They have more than enough leverage at this point to change their approach and the approach of hardware vendors that rely on them. They've already used that leverage in order to prevent Android-based competitors from getting a foothold, so it's hard to imagine that they aren't able or willing to use it generally. They just don't want to use it for this. Maybe they're right not to - I honestly don't know - but the fact that they could makes it pretty clear that this isn't some necessarily unavoidable aspect of Linux's approach.

Major reforms can still be done, at major kernel revision upgrades. But, at least commit to a stable API/ABI for major release versions and their minor releases over the course of a few years.

I totally understand if I can't use the latest kernel on my phone from 6 years ago. But at least if the major release versions kept a stable api/abi, then my phone from six years ago might be able to upgrade to the latest of an older, LTS series of kernels that was maybe released a month ago.

You are basically describing how Linux distributions with long term support work. Eg, every major RHEL release has a stable ABI which it carries over it's 10 year life time.But this has consequences and you won't like them.

On one hand you can't bring big changes to the long term versions because they would break API/ABI. So you end up with a model where after the initial release your phone will get security updates but not major Android updates (because the new Android depends on a new feature which can't be backported to your long term version).

On the other hand for the things you will bring back to the long term version (eg, security fixes) at any given point in time you're spending resources porting things across the head and the 2-3 currently supported long term versions.

Just to be clear this is quite different from Windows.At every "major" release Windows changes it's driver ABI but keeping backward compatibility with previous driver ABIs for more than a decade worth of releases.The drawback here is the effort and the restrictions which come with keeping this backward compatibility.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

Major reforms can still be done, at major kernel revision upgrades. But, at least commit to a stable API/ABI for major release versions and their minor releases over the course of a few years.

I totally understand if I can't use the latest kernel on my phone from 6 years ago. But at least if the major release versions kept a stable api/abi, then my phone from six years ago might be able to upgrade to the latest of an older, LTS series of kernels that was maybe released a month ago.

You are basically describing how Linux distributions with long term support work. Eg, every major RHEL release has a stable ABI which it carries over it's 10 year life time.But this has consequences and you won't like them.

On one hand you can't bring big changes to the long term versions because they would break API/ABI. So you end up with a model where after the initial release your phone will get security updates but not major Android updates (because the new Android depends on a new feature which can't be backported to your long term version).

On the other hand for the things you will bring back to the long term version (eg, security fixes) at any given point in time you're spending resources porting things across the head and the 2-3 currently supported long term versions.

Just to be clear this is quite different from Windows.At every "major" release Windows changes it's driver ABI but keeping backward compatibility with previous driver ABIs for more than a decade worth of releases.The drawback here is the effort and the restrictions which come with keeping this backward compatibility.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

I think a stable ABI for LTS would help with this to a point, but AFAIK Google already provides a stable ABI for their Android kernels. Devices still end up wildly out of date even with Google's releases, because... well, vendors have little to no incentive to update this stuff, and refusing to do so makes newer phones more appealing. Having a stable ABI in mainline would still make it easier to get features from mainline to Android, but that doesn't necessarily translate to that Android code making it into existing devices.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

1) This model would see your device released with an older Android (from the time the SoC was developed) and never updated beyond major bugs because the kernel cannot support more recent Android.

2) This model doesn't guarantee you updates. Because it's still the SoC maker who needs to backport the updates to your device's kernel (unless they had been nice enough to upstream it to Google at which point Google could do it). And in general the SoC maker doesn't bother to do either.

In the end even a bunch of volunteers (Lineage OS) achieve better results than the smartphone manufacturers.This has little to do with development models and all to do with perceived value.

Major reforms can still be done, at major kernel revision upgrades. But, at least commit to a stable API/ABI for major release versions and their minor releases over the course of a few years.

I totally understand if I can't use the latest kernel on my phone from 6 years ago. But at least if the major release versions kept a stable api/abi, then my phone from six years ago might be able to upgrade to the latest of an older, LTS series of kernels that was maybe released a month ago.

You are basically describing how Linux distributions with long term support work. Eg, every major RHEL release has a stable ABI which it carries over it's 10 year life time.But this has consequences and you won't like them.https://www.cnn.com/2019/11/19/us/baby- ... index.html

On one hand you can't bring big changes to the long term versions because they would break API/ABI. So you end up with a model where after the initial release your phone will get security updates but not major Android updates (because the new Android depends on a new feature which can't be backported to your long term version).

On the other hand for the things you will bring back to the long term version (eg, security fixes) at any given point in time you're spending resources porting things across the head and the 2-3 currently supported long term versions.

Just to be clear this is quite different from Windows.At every "major" release Windows changes it's driver ABI but keeping backward compatibility with previous driver ABIs for more than a decade worth of releases.The drawback here is the effort and the restrictions which come with keeping this backward compatibility.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

I think a stable ABI for LTS would help with this to a point, but AFAIK Google already provides a stable ABI for their Android kernels. Devices still end up wildly out of date even with Google's releases, because... well, vendors have little to no incentive to update this stuff, and refusing to do so makes newer phones more appealing. Having a stable ABI in mainline would still make it easier to get features from mainline to Android, but that doesn't necessarily translate to that Android code making it into existing devices.

A big part of this is that the "kernel proper" frequently needs to be customized. Referring to "kernel proper" in a monolithic kernel architecture SLIGHTLY begs the question, but there are some functions that are core to a microkernel that require off-chip resources to do. Even if one assumes that control of the radio, anything to do with power management, anything to do with persistent storage, as well as the entire human interface can all be treated as "services", there's still core things like scheduling, memory management, low-level bus and chipset configuration, that are dependent on the specific hardware and cannot be treated as a stock this-works-on-all-ARM-devices blob.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

1) This model would see your device released with an older Android (from the time the SoC was developed) and never updated beyond major bugs because the kernel cannot support more recent Android.

2) This model doesn't guarantee you updates. Because it's still the SoC maker who needs to backport the updates to your device's kernel

If the device drivers are separate kernel modules loaded by the kernel, the conceivably, I could download a new kernel that is NOT DEVICE SPECIFIC. I just download the new kernel, and it loads the existing driver modules at bootup.

The whole point of this article and discussion is about making kernel updates come from upstream, and get rid of device makers from being a middle man that prevents me from ever getting updates.

In this model, my phone would check for kernel updates either from a google/android repo, or maybe kernel.org (or a mirror).

Driver updates, if available, would still have to come from the device vendor.

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Something something x86 not fucking ARM....

Windows NT originally ran on several architectures. It eventually standardized on x86 and amd64, but the ability to build a HAL for something else is still there. Windows NT *has* been offered on ARM - Windows Phone 8 & 10, RT, something more recent that's been discussed around here from time to time. It's not offered at retail right this instant, of course.

Sure it's nothing to sneeze at, but it's also stagnant in the case of servers - sure there might be more and more servers (web or otherwise), but it's basically a role that could be filled by any OS - Linux is just the cheap solution, which is great but hardly a glowing endorsement or something that will light the way into the future.

You say that being a "cheap solution" is a bad thing.

I quite specifically (as seen above) said it was a good (great) thing, but a very narrow and somewhat stagnant niche. I do not know where you read "bad" in that sentence

I think that it's a good thing that the data center is becoming more and more OS-agnostic, and if you have specific requirements for a specific system you can just spin up a VM instance. Indeed, there's a lot of research going on in improving the performance of hypervisors and such, so the suggestion that this is an entirely solved problem isn't correct... but I think it's a good thing that racks full of cheap PCs clustered together has rather completely blown big iron designs out of the water. It's a HELL of a lot easier to build a cluster of N stock computers hooked together by a pair of Cisco routers (redundancy in the network) than it is to try and build a single box with N cpus, N main memories, N disk arrays, N power supplies, and so forth, designed so that if N/2 (or whatever) of these subcomponents fail, the box itself does not.

For decades, the server industry was trying to solve the wrong problem.

Of course, it's a good thing. And if all Linux wants is to be the base OS under virtualization and containers in server-land then all is great. And I truly mean that - there is nothing wrong with knowing what purpose you want to fulfill and focus 100% on that.

You sound a bit like someone who wants OS design to be "sexy", and are despairing because the data center is anything but these days; mature marketplaces seldom are.

I'm not sure what a "sexy" OS design would be, but no - I don't particularly. I just want Linux (I know I'm anthropomorphizing here to encompass the wider Linux eco-system maintaining the code here and the LKML in particular) to figure out what it wants to be.

If it wants to be the best possible base OS for virtualization and containers - go for it, but focus on that then, and give up the fantasy of Linux on the desktop ever happening beyond hobbyists and perhaps the admins of said servers. I would think that'd also free up a lot of resources both in maintenance and debate if it happened.

But if it wants to be a modern consumer usable OS - whether on the desktop or mobile - then it needs to get its act together and move into the 21st century. Fuchsia seems a clear indication that Google is losing patience with the way Linux is run.

I would be *ecstatic* if essentially every Android phone could *at the very least* get security and maybe minor performance fixes because Linux and Android followed the model you suggest I wouldn't like, above.

Most Android phones get *maybe* 2 major OS updates (including kernel) in the first 2 years of their lives, and then are never updated again, leaving millions of users exposed to security vulnerabilities that are known and NEVER patched.

Of course, that's not just in the kernel - that's also in things like OpenSSL, the wifi service, and so forth.

I just want to see phones have at least 5 years of security fixes. That would be incredible.

1) This model would see your device released with an older Android (from the time the SoC was developed) and never updated beyond major bugs because the kernel cannot support more recent Android.

2) This model doesn't guarantee you updates. Because it's still the SoC maker who needs to backport the updates to your device's kernel (unless they had been nice enough to upstream it to Google at which point Google could do it). And in general the SoC maker doesn't bother to do either.

Yes it would because in this model there would be a stable ABI that did not change with each update so I could update the kernel at any point and the driver blobs would still work.

Sure bugs could be outside the kernel in the drivers - but that's not what we are talking about here.

If the device drivers are separate kernel modules loaded by the kernel, the conceivably, I could download a new kernel that is NOT DEVICE SPECIFIC. I just download the new kernel, and it loads the existing driver modules at bootup.

The whole point of this article and discussion is about making kernel updates come from upstream, and get rid of device makers from being a middle man that prevents me from ever getting updates.

In this model, my phone would check for kernel updates either from a google/android repo, or maybe kernel.org (or a mirror).

Driver updates, if available, would still have to come from the device vendor.

In theory Google could do that tomorrow.

Whenever Google releases a new major Android version they base it on a finite list of kernel versions (ideally one).And Google takes onto themselves the effort of backporting bug fixes into those kernels.Google could (without much effort) ensure that those updates don't break the ABI and Google could then just ship updated kernels that could load existing modules.

The reason Google does not do that because Google does not know how much the SoC maker mucked around with the kernel source code, how ABI compliant are the drivers or if they're even using one of the Google reference kernel versions.

It doesn't matter whether you have a stable ABI or not.You can't engineer your way of the lack of interest from the SoC makers.

<edit>Reality check: Your concern is support for old hardware.On PC/servers despite the lack of a stable API/ABI Linux has better support for old hardware than Windows.Thus the Linux development model is better for old hardware support. Thus the problem with Android and old hardware is not the Linux development model but the lack of interest of the hardware makers.</edit>

Every time I read a plumbing article about Android it seems like a mess. I just don't get how Microsoft can install on so many pieces of hardware (sometimes on decade old hardware), and Google can't achieve what Microsoft did...

Something something x86 not fucking ARM....

Windows NT originally ran on several architectures. It eventually standardized on x86 and amd64, but the ability to build a HAL for something else is still there. Windows NT *has* been offered on ARM - Windows Phone 8 & 10, RT, something more recent that's been discussed around here from time to time. It's not offered at retail right this instant, of course.