If you're talking about something like Ubuntu, there's a tonne of work that goes into making sure it works with ..say.. a random three year old laptop with all the binary blobs in place.
Try getting something like wifi or Bluetooth working on some weird ARM dev board and suddenly there's no vanilla Linux unless you're willing to write device drivers.
But that work gets done and "users" of Ubuntu or Debian or Arch get to use it from the sources they trust (aka Ubuntu, Debian or Arch). I'm not claiming to have a full understanding of how every package or kernel module Debian or Arch or Fedora ships works. But I'm trusting Debian or Arch or Fedora for my packages. If it comes to light that debian or fedora maintainers had no idea that they shipped a malware in a release, then I'll seriously question going with that distribution in the future. And without sounding facetious, that has happened multiple times in past especially with debian. But the times it happened it was clear to me that it was merely a mistake rather than extreme incompetence or malice.
With Android, you have Google, which despite the general HN rhetoric I personally trust to not ship straight up malware. But when we're talking about Android that's not what we're talking about. We're often talking about binary ROM blobs from random XDA or RW users. Funny thing is 20 years ago, I'd have shouted about what's the difference between a random anon on XDA or WZBB providing a ROM blob. But now I know better.
Binary blobs are an unfortunate reality and no amount of trust in a company or entity can really solve this.
For the record, Debian and Arch doesn't work very well on non standard hardware. I use arch on my desktop but gave up on using it productively on a new HP laptop.
I understand your usage of the word, I'm just pointing out that if the mainstream ain't "standard" anymore... it kind of sets the standard in practice.
1. Originally you had to use the proprietary binary driver to get anything useful to happen with your card at all. Updating the kernel without updating this would more or less lead to having an expensive brick in your PC. Some Wi-Fi adapters fall into the "can't really be updated" category as well. A _LOT_ of ARM shit is like this.
2. nvidia-open came along (still beta for desktop cards at the moment) and it puts enough in the kernel that you can update the kernel without needing an updated binary driver for your card to function
3. nouveau/nvk have very recently started to come to a decently usable state (i.e. they have reclocking via GSP and somewhat usable graphics API coverage/efficiency) for an even more open driver stack which tracks system updates even better.
If your binary blobs fall into 1/2 then long term upgrades can be anywhere from impossible to unreliable. If they fall into 2/3 they can be anywhere from somewhat reliable to "will be working longer than any sane person would still be trying to update the kernel on that device". E.g. the AMD 7750 is 12 years old but can run OpenGL 4.6 and Vulkan via the latest AMDGPU driver in mainline mesa/kernel.
LTS distros solve this by using LTS kernels and security patching them rather than requiring "actual" underlying OS updates during the version lifecycle.
Android GKI/KMI addresses the issues related to this. GKI is relatively recent and OEMs don't offer 5+ years of Android updates because they haven't adopted it yet.
They wouldn't have to, that would be done for them, for free, if they got their code into the kernel...
Once you mainline it, making improvements, supporting new devices and features become 10x slower.
With a stable ABI, it would be better than everything. But we can't have it because of ideological reasons.
I think that at least open source community should move to "never break things" concept. So that you can write and test code once and never touch it anymore. Refactoring your code because kernel/library has changed its interface is just a waste of time which gives nothing in return, often time of unpaid volunteers who could do something useful instead.
This should apply to libraries, applications, programming languages, browser extensions. Take upgrading your Python 2 code to Python 3 as an example. You need to put a lot of efforts while gaining nothing. This is not how software should work. You should write a code once and it should work forever without any maintainance.
So if you open source your drivers and get them accepted into the kernel, then you don't need to rewrite/recompile them for each new kernel version. Just like AMD did with their drivers. And I think this is part a conscious decision that forces people to open source drivers.
But this is honestly just guesswork based on what I've read, would love to learn more!
[1] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-mo...
You don't, but someone does. In the note linked above they give an example of how the USB interface changed from synchronous to asynchronous, this must have required some refactoring in all drivers that used USB
no, they do it for you for free - you just have to make sure the quality is high enough to merge into mainline.
as a user, I hate apps that aren't in the repository. it takes effort to make sure it doesn't clobber something important just because the developer wanted to use the latest and most broken version of some library. thankfully nixos allows me to run whatever version of every dependency and then nuke the whole mess once I'm done with it.
That's not going to be fixed. This is a typical M-N problem. There are too many distros and it would require lot of work to port every app to every distro. Instead, there should be a "platform" (set of APIs) that app can work with and the same app would be able to work in any compatible distro.
Just the python's 3 string/binary distinction and explicit conversion squashed an entire category of bugs. Yes, it required to make explicit what was implicit before, but still, that's huge achievement in my book; saying that it is nothing is a very, very shortsighted.
And created an entire category of new ones.
That's how you can use a random 25 year old peripheral on multiple versions of Windows without anyone having to update a driver.
For windows you can usually download a binary from some 20 year old website and it'll work.
Avoiding that mess for some notion of beauty or purity only gets you so far.
depends; but may i suggest starting at kernel.org then look at 'linux from scratch'/gentoo then maybe slackware; surely not ubuntu
There's a reason all other kenels have adopted a stable driver API and ABI.
- Vanilla Linux it's propietary.
- GNU/Linux-Libre it's the proper libre one, rebased from GNU maintainers.
- There's no proper 'Vanilla distro' as LFS or Gentoo. Every one since 1993 has been an external bundle made from volunteers.
- The closest vanilla distro from the GNU project would be Guix as it works as a distro and a universal package manager to ship libre software.
hardware is either supported or not.
the "work" you mention on old wifi cards is to get a driver that was never contributed in any official way. hence unsupported.
Linux have more hardware support out of the box than anything, ever.
just educate yourself before purchasing.
This reminds me of certain countries that define literacy as the ability to sign ones name.
Linux driver support for a large fraction of hardware is incomplete at best.
no sympathy. you're also out of luck using old hardware in the first place because the manufacturer wants you to buy the new version. they will help you LESS than Linux devs. you're point is very unhelpful to the discussion, unless you got drivers updates from the manufacturer
The manufacturer probably doesn't exist any more. They wrote decent drivers and supported them for a number of years, that should be enough. Or maybe a dedicated fan wrote some OSS drivers at some point in the past. On both Windows and FreeBSD that's good enough; once a driver has been written, it largely stays working, so I can keep using my hardware. This really is a unique downside of Linux.
They accept only code which they will be able to maintain, yes. That excludes spaghetty or implementations of complex undocumented APIs that are useless without a binary blob. Nothing unreasonable about that.