Reply With QuoteOnly if you don't know how to use git and make. Which is a pretty sad excuse.Originally Posted by zoomblab
X.Org Developer
First off, this is about the most sensible post in this whole thread. You put your finger on the issue correctly with the last sentence.
That being said; the API does not need to be stable, it should evolve naturally. But it will automatically and naturally become more stable and future-proof if developers do spend more than 2 seconds thinking about their interfaces. Everything else comes from there, naturally, and almost painlessly (it is less painful than the current situation, that's for sure).
Everybody could win, if only the supposedly more clued people would spend some time using that bigger brain that they are supposed to have. Or put differently: by continuing to refuse to work like this, those refusing only prove that they are not deserving of the status that they like to claim for themselves.
Senior Member
Only if you don't know how to use git and make. Which is a pretty sad excuse.
X.Org Developer
Some backports for some distributions is rather limiting.
What we need is driver developer provided backwards compatibility (with some features disabled) for some distributions: ideally, compatible with debian stable. The likes of Redhat, Canonical and SuSE can then do the rest of the work for their older enterprise releases (for which they get paid). The job of supporting such older infrastructure will also be overseeable in such a constellation.
This way, every user can do one of the following to get drivers installed:
1) install packages built by distribution maintainers, who also have an easy task, so updates are plenty and frequent
2) build driver stacks from source for a reasonably current distribution
3) spend some time on getting the code compatible
4) buy support
5) update infrastructure
6) use a closed driver (for the sake of argument)
Depending on different user classes, you can then start guessing at the numbers.
Phoronix users:
1) 5% -> 50%
2) 10% -> 20%
3) 5% -> 2%
4) 5% -> 3%
5) 25% -> 5%
6) 50% -> 20%
Other hobby users:
1) 25% -> 60%
2) 5% -> 10%
3) 0% -> 0%
4) 10% -> 5%
5) 20% -> 5%
6) 40% -> 20%
Corporate users (admins doing the work):
1) 30% -> 75%
2) 20% -> 10%
3) 0% -> 5%
4) 20% -> 5% (little extra support needed for graphics drivers, but the support will be bought anyway for other issues)
5) 10% -> 0%
6) 20% -> 5% (most use intel hw anyway)
(would be nice to collect real figures though)
Guess what, those selling support will actually fare better:
* the user experience will vastly improve
* the market share will also improve (over time, we made a horrible impression so far)
* the manpower needed to provide graphics driver support will be reduced and can be rerouted to do more useful things
And, for graphics driver developers, there are the following advantages:
* vastly increased userbase for recent code: better testing!
* easier direct debugging: testing different versions of both driverstack and infrastructure is feasible
* easier user debugging
* less time spent dealing with bugs and support, more with development (but slightly more time will be needed there anyway)
* more pressure for closed vendors to open up
* bigger market share for free software
All that takes is the willingness to state: "Yes, we support up to debian stable", and to make that happen. When given the ability, users will then provide loads of testing, and will make sure that such support is not broken easily.
Senior Member
The link is broken. It does not link to the article.
Senior Member
No, it's not a sad excuse. It's an excellent excuse. Using a computer should be easy and intuitive. Like Mac OS and Windows.
Expecting users to deal with Git and make is ridiculous.
Senior Member
That's what distributions are for.
Senior Member
Only rolling release ones. The rest needs to wait half a year or more, which makes users sooo happy.
PCI Maintainer for Linux, X.Org developer, DRM developer, Mesa developer
No, this is our job, and we blew it for Sandy Bridge. We're supposed to do development well ahead of product release, and make sure distros include the necessary code to get things working (we have separate teams to do development and aid distros in backporting, though most of them can handle it by themselves these days).
I could give you all sorts of explanations as to why this is (Sandy Bridge is a big architectural change, we made some mistakes in defining our development milestones, and we didn't work hard enough to get our changes backported), but really there's no excuse. Fortunately we've learned from this and are giving ourselves more time and planning better for Sandy Bridge's successor, Ivy Bridge.
As for a stable ABI, yes it would definitely help situations like this and make lives easier for distros, device manufacturers, and probably users. But it would make life harder for developers, and as we all know, open source development is driven by developers, and we're a whiny and lazy bunch. (Yes, this is a flippant remark, don't take it too seriously since I omit much of the complexity behind the "life harder for developers" part that has big implications for users, distros, and device manufacturers; it's a complicated issue.)
Senior Member
Surely, it's possible to update Mesa, X, and the kernel in a non-rolling distro, as long as it provides the relevant packages.
Senior Member
If it does then it's not a non-rolling distro, no?
Posting Permissions