Android putting graphics drivers outside the kernel and not under the GPL has created enough of a disaster. I don't look forward to the day when everyone is running a kernel that doesn't force SoC manufactures to share even the most basic drivers.
Some companies just flagrantly violate the GPL, and little ever comes of it.
Others ship minimal shims in the kernel, and put the proprietary bits in userland code or some such. This seems to be more common, where vendors will technically release their kernel fork, but the code will be obfuscated or just generally useless without the proprietary blob that goes with it.
I'd much rather the kernel just have a stable ABI so these kernels could at least be freely updated instead of being stuck with the hacked together fork with its proprietary shims.
Sometimes I wonder if Linus could go back and do it over, if he would license Linux under the BSD license instead of GPL. He's never seemed like a particular stickler for free software ideology, and has welcomed connections between Linux and industry. I don't know that it bothers him that much to see Linux used in proprietary software.
Not trying to start a flame war over licenses here, just speculating. And maybe this could be easily refuted by a link to one of his email rants, who knows.
So I very much doubt he would license it under BSD or similar.
Having said that, he has also stated that he is glad he stuck to GPLv2, as he is not a proponent of the TIVO clause, IIRC his words were something to the effect of 'I just want the code contributed back to the kernel'.
However, he sees things like adding it as being a pretty significant change to the GPL, and does not like the fundamentally changing the deal. If GPL v3 consisted only of wording clarifications to ensure it worked properly in more regions and perhaps to allow apache license compatibility, he would presumably have had no objections, but of course, would be unlikely to have been able to relicense the kernel, given the kernel's numerous contributors and lack of "or later version" clause.
https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/copyleft-compliance/enforcement-st... https://sfconservancy.org/copyleft-compliance/firmware-liber... https://sfconservancy.org/news/2020/oct/01/new-copyleft-stra...
On x86, you can just grab a Windows or Linux .iso and it will enumerate all hardware via PnP and install the appropriate drivers. This is something that is sorely missing in the Arm world. Instead you get semi-closed BSPs, source code thrown over the wall, and you have to write your own device-tree files and often kernel code to get something to run. SSBA is a start but only targeting the server market.
It absolutely is a problem. There is plenty of not-that-old hardware that will only work on previous versions of windows.
There's also _mountains_ of _terrible_ binary drivers that cause serious stability concerns.
The very same hardware somehow works perfectly fine on Linux. No kernel panics (not a single one in 12+ years of running it on Realtek crap), no intermittent connectivity problems, no weird GPU bugs, nothing of the sort.
What I mean is: I can go to the store and buy a random thing, and I can just assume there will be a driver at all and my PC will find it.
I work for a company which manufactures industrial PCs with touch interfaces, and one thing we noticed with our X86 line is that we can just stop caring about drivers. Although everything down to the touch panel and the mainboard is custom, you can just throw a windows OR a Linux (Ubuntu) iso at it and it will work 99%. This is not about Windows vs. Linux, but about PnP vs. no PnP.
(Still not reason enough for me to go back to Windows tho)
Yes it is. Let alone the inability to study the source code and other goodness of open source, there are old drivers that are not maintained anymore and that can't run on newer versions of Windows, where hardware that is not maintained anymore by the manufacturer still works on Linux because the open source driver can still be adapted to run on newer versions.
Proprietary drivers are a problem wherever they exist.
Closed source drivers are a nightmare for users.
This is all just to say, I don't think "GPL drivers" and "PnP generic images" are as separate as you're suggesting.
We entered the new millennium with the concept that most computers could use most extension hardware with (relatively) little effort, and you could upgrade your computer's basic operating system at will; even change it to another one entirely.
I'd love to update my still-decent Android phones that have long since stopped receiving security updates, but I can't. This is objectively inferior, a massive regression from general computing.
> I'd love to update my still-decent Android phones that have long since stopped receiving security updates, but I can't. This is objectively inferior, a massive regression from general computing.
this is one of the smelliest BS i've read on hn in the last year or two. phones before android were not upgradable AT ALL. if you were lucky, you could put a bigger memory card, and that was it.
nowadays you can access most of the sources of the os for your average android smartphone, you can rebuild the os and reflash it yourself. doing such thigs was a basically just wet dream in early 2000s.
Sure, some carriers restricted updates - but that's still a problem Android faces.
They weren't general computing devices. They were for making phone calls, sending SMS messages, and tracking contacts. The security risk profile did not include access to social media accounts and/or online banking.
For many folks, and a growing many folks, their phones are now their primary computing devices. For many folks, their primary computing devices no longer receive security updates.
> you can rebuild the os and reflash it yourself.
Tell me how I do that if I cannot root the phone.
What you need is a bootloader that is not locked so you can boot a different OS instead.
In my experience most major Android vendors do support bootloader unlocking.
Apparently I dreamed of doing Series 30, Series 40, Symbian and Windows CE updates.
If you show me such a device, I would instantly ditch my iphone, pretty much the only reason I have one is the great hardware and the lack of google supervision. I even bought a pinephone, but it needs a lot of work (and a new hardware iteration) before it can become truly usable.
And who enabled that? Not everyone wants to admit it, but it was IBM together with Microsoft which made this possible. This openness was thanks to a proprietary vendor wanting to make one operating system that ran on a wide variety of hardware.
The chaos of the embedded world is Linux's doing.
Which is the funny thing, given how much closed source drivers have hurt android as far as I can tell.