Originally Posted by TobiSGD
Huh? If a proprietary driver does not support a specific kernel it doesn't matter if you run that kernel on Debian/Ubuntu/Fedora/Slackware/whatever, it is still not supported, no matter if you use DKMS or not or if a distro is more vanilla. In fact, distros where being vanilla is not that important, for example Arch, get new proprietary drivers usually faster running on new kernels, since they just patch the drivers (actually, not the drivers, but the shim, that part of the driver that interfaces between kernel-module and kernel, that part that DKMS compiles when you change kernels).
Why should I argue with that? What I don't understand is why you think that this is not possible with other distros. As a former Debian user I can assure you that that is absolutely no problem.
So, do you compile kernels from kernel.org for Debian or do you wait until Debian patches and releases them? Perhaps more importantly, whether you do or not, can you? I never said running the SAME kernel would produce change. The point is being able to move up to a new one immediately and not have to wait for maintainers to build you a package and put it in a repository you can use without jumping through hoops.
Originally Posted by TobiSGD
Use what you want, I don't care. Also, I have never said that I want to use DKMS or dependency resolving package managers, I don't know where you get that from. However, that doesn't hinder me from correcting factual errors or ask again if I think that there is a misconception. Thatr does not mean I have to like something, it just means that I prefer to be correct and fair to every project.
I also prefer solid. Debian with DKMS and dependency resolving is solid, so are Suse and Red Hat. Just because I prefer Slackware doesn't make these distros or the technologies they use somehow less solid.
Distros have made deep changes to accommodate their specific style of doing things and increasingly
become "Ivory Towers", isolated, and often with very little benefit and 25 ways to do the same thing and though diminished in severity, they still break - not exactly solid by comparison. For these and many other reasons Software devs don't give a damn about narcissistic distros and generally find them annoying. It seems to me it is exactly for this reason that the biggest trends to hit Linux in basically forever is the likes of systemd, CoreOS, Docker, Vagrant, Puppet and the like, because Devs are just sick of all the stupid diversity for the sake of being able to say "we're different". This puts maintainers in a holding pattern and I maintain that will only increase until and unless one of two things happen and that's
1) Return to Vanilla, or
2) Go to container based systems, like CoreOS
It should be obvious which of the two is going to happen on the large scale, and Linux as a whole, especially Package Managers, brought this on itself. It remains to be seen how well this will work out and at what cost. As it applies here, the increasing disconnect between Devs and Maintainers means Users "hang fire" - they wait, and often suffer. In making distros less reliant on compiling from source, a side effect is that they are no longer as good at it, or even actively hide or thwart it. This sometimes applies to .bin and .run installers as well.
It matters little what is theoretically possible. It matters what devs, maintainers and users find appealing and effective, and readily available.
Being fair doesn't imply just saying "They're all solid" and leaving it at that. If there are not distinct and important advantages to one distro over another, then why should they even exist, other than bundled software choices?