11–20 of 20 posts
Simply don't buy Nvidia. Apart from that there shouldn't be a lot of hardware requiring blobs on the desktop.
I use a Ubuntu desktop daily as a development workstation and have for a decade at least. Never really had a problem, though it slows down Virtual Box installation once or twice a year. shrugs
Maintaining the drivers together with the rest of the system allows subsystem maintainers to make broad improvements to the functioning of drivers, and encourages vendors to upstream them as free software. If you want a stable kernel driver ABI, then you're going to have to maintain your own wrapper which will retain all of the anachronisms that have been excised from the upstream kernel. You are perfectly at liberty…
Of course everyone has the liberty to write a wrapper, but that is just silly.
If Windows can have a stable ABI, why can't Linux have it too? Why would it need to "reduce the quality of running kernels"?
Maintaining the drivers together with the rest of the system allows subsystem maintainers to make broad improvements to the functioning of drivers, and encourages vendors to upstream them as free software. If you want a stable kernel driver ABI, then you're going to have to maintain your own wrapper which will retain all of the anachronisms that have been excised from the upstream kernel. You are perfectly at liberty…
But if vendors does not want to upstream them as free software, then we have a problem and an issue with the non stable ABI solution. The end user does not care if the driver is free software, they just want their machines to work. I guess this is an issue for Google too, for their Linux fork Android. Of course everyone has the liberty to write a wrapper, but that is just silly. If Windows can have a stable ABI, why…
You're saying this as though the end user experience is separate from improvements to the performance and semantics of the driver ABI.
Also, on Android all of the (kernel space) drivers are free software; it's just that they're so crappy usually that they can not be upstreamed. They don't hook into much of the infrastructure in the kernel on account of ignorance, so they could easily push updated kernel module binaries, ABI compatibility does not affect that problem.
Android's kernel is not a fork of Linux, it's a LTS tree with some configuration changes, and a couple of modules (most of which have been upstreamed by now).
> If Windows can have a stable ABI, why can't Linux have it too? Why would it need to "reduce the quality of running kernels"?
Windows doesn't have a stable driver ABI, they break driver ABIs pretty drastically every once in a while. Longhorn (later yielding Windows Vista) was the last straw, they couldn't build a good quality operating system with the same driver ABI.
Furthermore, drivers from Vista often do not work with 7, 8, or especially 10. You can get the exact same sort of stable driver ABI by distributing for a specific distribution release or long term kernel tree.
Maintaining the drivers together with the rest of the system allows subsystem maintainers to make broad improvements to the functioning of drivers, and encourages vendors to upstream them as free software. If you want a stable kernel driver ABI, then you're going to have to maintain your own wrapper which will retain all of the anachronisms that have been excised from the upstream kernel. You are perfectly at liberty…
But if vendors does not want to upstream them as free software, then we have a problem and an issue with the non stable ABI solution. The end user does not care if the driver is free software, they just want their machines to work. I guess this is an issue for Google too, for their Linux fork Android. Of course everyone has the liberty to write a wrapper, but that is just silly. If Windows can have a stable ABI, why…
Upstreaming the code also means quality control. Linus and his subsystem maintainers by far do not merge everything people throw at them. Users also gain out of the box support for their Hardware if the driver is in the kernel. Also a lot of people using and developing Linux or the surroundings care about (at least some aspects of) free Software.
> Why would it need to "reduce the quality of running kernels"?
Because possibly (mostly, HW manufacturers in general are not exactly known for the quality of their software) low quality code becomes part of the kernel, Linux is a monolith.
> If Windows can have a stable ABI, why can't Linux have it too?
I think not providing a stable API/ABI is a major reason why Linux is able to move so fast. If you have to make sure your change does not break this 5+ year old driver you can't do major architectural changes that easily. The kernel developers would then need write the equivalent of such a "silly" wrapper.
> I guess this is an issue for Google too, for their Linux fork Android.
Google apparently likes doing this, e.g. they also maintain a fork of openssl to make some minor changes for their needs.
Earlier quoted context omitted.
Because the kernel developers aren't interested in assuming the maintenance burden of maintaining (possibly many incompatible and versioned) interfaces purely for the benefit of users who maintain out of tree drivers.
I'm surprised driver interfaces are still changing so frequently. Ten years ago perhaps, but they're not largely sorted today twenty five years+ after Linux debut?
Earlier quoted context omitted.
But if vendors does not want to upstream them as free software, then we have a problem and an issue with the non stable ABI solution. The end user does not care if the driver is free software, they just want their machines to work. I guess this is an issue for Google too, for their Linux fork Android. Of course everyone has the liberty to write a wrapper, but that is just silly. If Windows can have a stable ABI, why…
> The end user does not care if the driver is free software, they just want their machines to work. Upstreaming the code also means quality control. Linus and his subsystem maintainers by far do not merge everything people throw at them. Users also gain out of the box support for their Hardware if the driver is in the kernel. Also a lot of people using and developing Linux or the surroundings care about (at least som…
As http://lkml.iu.edu/hypermail/linux/kernel/1604.0/03993.html states, you can get binary stability for in the order of five years from the likes of Red Hat and SuSe. I don't know where you can get binary stability for decades, but it wouldn't surprise me if some military applications guaranteed that. Since there's nothing stopping suppliers from selling it, there apparently isn't that much demand for it.
Stable API or not, every time there is a new NVIDIA driver, my Win10 boxes work and my Fedora/Ubuntu ones break. I doubt Microsoft is asking NVIDIA to keep their driver inside Microsoft repositories.
Use a distro that ships the Nvidia driver in its repos or a repository that builds for your distro's kernel specifically.
Maintaining the drivers together with the rest of the system allows subsystem maintainers to make broad improvements to the functioning of drivers, and encourages vendors to upstream them as free software. If you want a stable kernel driver ABI, then you're going to have to maintain your own wrapper which will retain all of the anachronisms that have been excised from the upstream kernel. You are perfectly at liberty…
But if vendors does not want to upstream them as free software, then we have a problem and an issue with the non stable ABI solution. The end user does not care if the driver is free software, they just want their machines to work. I guess this is an issue for Google too, for their Linux fork Android. Of course everyone has the liberty to write a wrapper, but that is just silly. If Windows can have a stable ABI, why…
Probably not a good example to use Google for this. Google has shown time and time again that they are culturally incapable of developing open source software if any other stakeholders have the power to say "No" to Google. And that's just for the projects developed in open, most of their "open source" is dropping code dumps for legal or strategic reasons rather than collaboration.
I'm not trying to make that sound like a complaint. They have the weight to throw around to enable their uncompromising and secretive approach to opensource. Them's just the breaks.
Earlier quoted context omitted.
I'm surprised driver interfaces are still changing so frequently. Ten years ago perhaps, but they're not largely sorted today twenty five years+ after Linux debut?
There have been general architecture changes. Look at DRM as a better way to do rendering versus the old Unix way, for example.