Okay, I had to seriously burst out in laugh there. You do know Torvalds opinion on the GPL, and how he has ridiculed people trying to enforce the GPL on companies that fork Linux and publish proprietary forks?
And you do know that Torvalds considers the best option to find a compromise with the company, and slowly work on that?
> The vast majority of users similar to you will be running stable kernels.
And yet, where is Ubuntu 16.04 now?
> I do. Believe me, I do.
And yet, you don't seem to.
> If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
That kind of modularity is only possible if you actually have a modular system.
Do you know how annoying it is to debug a kernel crash when you're writing a device driver, because the kernel devs again changed some random API slightly around? And how much nicer it is to do this in userland? If you've ever written drivers, you know. And do you know how much nicer it is to separate a driver into modular pieces for the base functionality, and additional modules for addon functionality, such as the macro functionality of my keyboard?
Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work. Tanenbaum was right.
Monolithic kernels are broken by design.
Yet, the kernel dev team do not want this particular compromise. It would go against the design they prefer to work with.
> And yet, where is Ubuntu 16.04 now?
Why are we talking about Ubuntu 16.04? Oh, right, you are trying to run AMDGPU-pro, and that is the specific distro version that AMD chose to support. Are you mad at the Linux devs or mad at AMD?
> I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
> That kind of modularity is only possible if you actually have a modular system.
Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
> Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work.
That has not been my experience during the years I have spent using Linux. In fact, I have experienced better software, sooner, with fewer breakages (especially in NixOS), and the vast majority of my hardware works. The only hardware that doesn't work are sound cards or obscure wifi adapters that have only incompatible proprietary drivers (I actually ran out of those. All my wifi adapters currently work without effort.). So sound cards are the only issue I have left. That's it. I have a nice USB DAC anyway.
I'm running KDE Neon, which only exists as version based on Ubuntu 16.04
> Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
My goal is this:
(a) 100% free software in my life
(b) no compromise on cost, or functionality.
The DAL is the only possible way I can get that.
I want 100% of the functionality, at the cheapest price, with entirely free software.
That's why I've been spending 4 years of my life to build a hacky copy of every single cloud service or proprietary software I might rely on. And that's why I want the same for the drivers, it's why I've been writing hundredthousands (!) of lines of code by now to replace software, cloud services, and android driver modules.
The DAL with an open source, but out-of-tree driver, is the only way I'd ever get close to this. Any other option leads to more proprietary code in my life. Therefore, your actions are the same for me as the actions of Google: they attack my freedoms.
I do. Believe me, I do.
> developers that still don’t get the entire point of what I’ve been talking about
They do too. They acutely understand all of the advantages and drawbacks of a HAL, and how it would effect the project that they work on, and have chosen explicitly not to allow one. I'd like you to understand why, because these are intelligent people, many of them dedicating time and expertise for nothing in return but the satisfaction of the contribution itself.
It sounds like a great idea to have an abstract interface for these things. That's what a microkernel is all about. Microkernels are great, but Linux is a monolithic kernel. That is the core of its design. Linux isn't going to adapt its core design to be more compatible with proprietary software. In fact, Linux should do nothing to be more compatible with proprietary software, because that would simply perpetuate the problem.
A monolithic kernel does have some advantages.
* The kernel can change without breaking drivers, because drivers are part of the kernel
* There is no layer between drivers and the kernel, meaning no overhead, no translation, but raw communication.
These advantages are fundamentally broken by introducing abstraction layers. Extra abstraction also introduces more maintenance work.
If AMD really wants a microkernel, it can start focusing on its FreeBSD driver.
> None of this functionality has to be closed source.
That is entirely my point.
> If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
That is a compromise. A compromise that kernel devs are not willing to make. Linux is Free Software. Free as in Freedom. Free software users do not have to deal with the problems that are caused by proprietary software, of which there are many.
> How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
> The majority of users will be stuck on a several year old kernel.
The "majority of users" are running enterprise servers. That is the only reason to use a longterm kernel release. Users of a longterm kernel will not expect driver updates, in fact expecting the opposite. The vast majority of users similar to you will be running stable kernels.
> Stable kernel updates are released on as-needed basis, usually 2-3 a month. [1]
That is an entirely reasonable time-frame for updates. If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
[1](https://www.kernel.org/category/releases.html)