> Weird list of non-problems and not understanding how Linux works
I would like to add this attitude to the list.
I would like to add this attitude to the list.
> There's no concept of drivers in Linux ...
I'm not well versed in drivers, but this explanation makes it sound like hardware needs to target a specific linux driver to work as intended.
So instead of someone building their own driver against some api and including it with the product, they have to either design their hardware around linux (and maintain compatibility with windows/mac), or make a pull request for support and go through the normal development channels?
Is that really how that works? No wonder graphics + wifi cards have had so much trouble through the years...
> Your hardware generally either works or doesn't work. ... Linux-compatible hardware to purchase ...
I've never bought a device that didn't work with windows. Ever.
I understand what causes that, but for better for for worse, windows wins for usability here. And I'm not entirely convinced no one can come up with a system to smooth this out better.
> ... The distros keep your software working with newer versions of Gtk or Qt, and deal with licensing. It's not something that end users need to worry about.
Until something breaks and I do have to worry about it. Then it's explicitly my problem to solve, with only google on my side to help.
> Also the obsession with "screen tearing" ...
It doesn't bother me either, but "it doesn't bother me so it's a non-problem" is so unsympathetic to the typical user.
Is no one besides techie programmers supposed to being using linux? That's what it seems like most of the time.
When I asked for help for my sound (in linux its only 50% volume and sounds like its a cheap speaker inside of a tin can) I was blamed for:
- Using a laptop
- The brand of laptop
- The audio hardware of my laptop (its their fault, not the kernels "generic" driver)
Then was told to either carry around an external DAC + Speakers or buy a desktop with a "proper" audio card.
It was the first time in 6 years I'd installed Linux and it lasted less than a week.
This happens all the time.
"Oh, I had an issue and the community was so helpful, I got my issue resolved in a few days from going back and forth with nice people."
Some may disagree but I shouldn't have to enter communities of people to just get my computer to run. I want to put the flash drive in, wait an hour, and get onto what I actually wanted to do with a computer.
And it's sad, because I believe I share the same vision of people developing this software.
I want a world where every computer can have an OS that's free, completely open source, user friendly for every day computing, and empowers you to truly OWN the hunk of plastic in your hands.
It really seems linux is for no one but kernel hackers, software engineers, or to run on server hardware.
There is only one thing they don't blame.
No, it's not at all! Linux of course has the concept of drivers. In most cases the drivers are integrated into the Linux kernel codebase itself, and nowadays are in by far most cases contributed by the companies making the hardware (or contractors they pay to do so). In (much) rarer cases drivers are developed by the community. Overall this makes it quite a lot like for example Windows, where hardware vendors develop drivers and hand them off to Microsoft to distribute through Windows Update. Linux is roughly the same, with the drivers coming down through kernel (i.e. system) updates. A few drivers are maintained and distributed entirely separately by their vendors, but this is usually less convenient for the users in the end.
Within the kernel codebase, there are various frameworks catering toward device drivers of specific categories, so that a driver developer doesn't have to start from zero when implementing the driver for their device. Let's say a lot of storage drivers have to solve roughly the same problems, so of course it makes sense to share some code rather than reinvent wheels. This sort of code sharing is encouraged by the developer community, but not enforced.
For some categories of devices there are generic drivers, but those tend to reflect the existence of industry standards enabling their creation. For example USB Mass Storage and USB HID devices are standardized and don't need device-specific drivers (roughly speaking).
The bulk of the Linux kernel source code is drivers, and the bulk of those is contributed or paid for by hw companies.
In some cases kernel drivers also communicate with device-specific userspace components. For example when it comes to graphics drivers, in some cases only part of the driver resides in the kernel and some of the upper layers (e.g. the OpenGL API implementation) is organized through projects like Mesa, again with significant vendor participation.
> Is no one besides techie programmers supposed to being using linux? That's what it seems like most of the time.
There's plenty of Linux desktop devs that would take screen tearing to be a very serious problem :).
My assumptions are based on my own experience.
Under windows, if a device driver isn't tracked by microsoft, it's typically provided as an installer program from the company that made the product.
But I very rarely see that for linux, besides some passing recollections of nvidia or wifi card binary blobs.
Is there a reason for that? If I made some weird hardware that needed custom drivers, do I target the appropriate kernel APIs then get it submitted for the next kernel version?
And, to save you the breath, could you recommend any blog posts or articles that dig more into these things? I want to learn more.
Yep, there's a few reasons for that:
- Broadly speaking, the Linux kernel has a generic framework for "modules" that can be loaded and unloaded at runtime. Modules can do many things, including provide device drivers. It's possible to develop and build a module separately from the kernel, and within the code of the module make use of the aforementioned targeted driver frameworks.
- However, the Linux kernel intentionally does not provide a stable API or ABI for modules. And the driver frameworks are internal unstable API as well (unlike the kernel userspace API, which is never allowed to be broken). That does not mean it is impossible to develop and release a driver independently from the kernel - in practice, a fair amount of the API/ABI changes rarely - but it makes it much less practical and convenient than contributing the driver to the kernel source tree and developing it in lockstep.
- There's a wide range of (often heated) arguments around the issue of whether there should be a stable API and ABI for (driver) modules. For now the result of a debate spanning decades is I would say a loose agreement that getting hw vendors to contribute their drivers upstream has netted various benefits, such as the ability to maintain/update the driver when vendors cease to exist, get vendors to contribute to shared frameworks, make the drivers do things the vendor never planned for (e.g. expanding support to a new CPU architecture!), allow the kernel to develop faster (want to make a fundamental change somewhere? port all the driver users in one swoop and move things forward), etc.
- Overall this has lead to an ecosystem where this is now business as usual for I'd say the majority of hw vendors, who will make "contribute the driver to Linux before we release the hw" simply part of their dev and business routine.
- Some vendors still stubbornly refuse to (or have historical legal reasons they can't) contribute drivers however and have opted to try and maintain them separately. For those cases there exist some mitigating hacks. For example a little open source glue module that sits between the kernel and a proprietary binary-only driver, and distro frameworks that will recompile the glue module at boot time to fit an updated kernel (this gets around the ABI issue, but also some hairy legal license incompatibilities). Nobody loves these, but they exist and in some cases work OK where the vendor is very active in shouldering their maintenance burden.
A few decades in, I honestly find it hard to say which approach is better for which device. For example, you could say if the OS has a stable driver API/ABI, it means the vendor can cease to exist and their old driver release for my obscure hw will continue to work. This is true, but it also means you can never fix a bug in the driver, and the driver may no longer work with a major new version of the OS (say, Win 95 to Win XP, or Win XP to Vista) or in a computer with the same ports but a different CPU arch (say, x86 to ARM). In many ways the Linux kernel is the biggest actively maintained collection of "runs old obscure hardware" drivers around today, and there are plenty of gaps to "every hw works with Windows" that are filled by it.
Practical example: Recently I wanted to digitize some of my folks' old Hi8 family video tapes. My mother's boyfriend used to do this himself with an old EyeTV video capture stick they bought for their Mac circa OS X 10.3. Its drivers ceased to work around OS X 10.6 and EyeTV never provided support for their old product for newer versions of the OS, because they moved on to newer products. The fix? Capture from Linux using the same HW. Why does Linux have a driver for it? Because all these branded capture sticks map back to a just a few popular chips built into these products, and Linux has a well-maintained driver for the entire family, while the MacOS ones are vendor-specific.
And it runs deep: The entire mythical origin story of the free software movement began with a guy at MIT being upset about a bug in the driver for their expensive laser printer and the vendor refusing to release the source code and holding the device commercially hostage. This motivated the project that gave us modern open source licensing (GNU and the GPL, the latter used by Linux) and changed the entire software industry!
I had to wait a few months before Ubuntu moved to a kernel version with the support for my motherboard's network adapter.
I've been hit by this as well, when I bought an nVidia card in its launch month years ago and had to fiddle before the drivers became widely available. That said, nVidia is by far the most prominent example for swimming against the tide of the general rhythm of the Linux world and the other GPU vendors do a better job with open sourcing and early upstreaming.
My honest impression is that the developers of the software are often quite in tune with the needs and pains of the users, and the sort of "your problem is not a problem" responses lacking empathy you see are largely from other users. This isn't universally true, but I would say broadly. And even in cases where it isn't that one uncaring dev is often not representative of the project as a whole.
What I mean is - I think it's valid to call this a frequent failing of the broader Linux community, with users included. It bothers me as well. But the ones who do the most to make the software are often the ones who do care the most. And for them it's also quite a bad experience when generalizations go the other way.
Perhaps you have never perused the GNOME issue tracker then.