Linked by Thom Holwerda on Sun 20th Apr 2008 12:52 UTC, submitted by Michael Larabel
Thread beginning with comment 310636
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: What about everything that isn't linux?
by sorpigal on Mon 21st Apr 2008 16:18
in reply to "RE[4]: What about everything that isn't linux?"
If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.
At the moment there are no stable APIs being defined by linux. That's a central theme.
The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.
At the moment there are no stable APIs being defined by linux. That's a central theme.
The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.
Linux has a stated goal of no ABI or API stability. It's argued that such a restriction would shackle the kernel dev's hands, introducing artificial inflexibility. Whether or not that is true, it is true that Linux is not responsible for creating standards. If Linux devs and BSD devs wanted to get together and hash out a standard for something I'm sure they could do it, but nobody seems interested in doing that. Therein lies the real problem. We're a long way (in terms of time elapsed) from POSIX and I don't see new standards being developed by anyone, just new single-vendor APIs.
The exception here is the fine work at fd.o, but they don't really touch very low level stuff unless it's directly X-related.
RE[6]: What about everything that isn't linux?
by sbergman27 on Mon 21st Apr 2008 16:27
in reply to "RE[5]: What about everything that isn't linux?"
Linux has a stated goal of no ABI or API stability.
I know that you already know this. But I feel that it's best to always be careful to state that this policy refers only to the internal kernel api. Otherwise some people get the false impression that the kernel's user space api is unstable.
RE[5]: What about everything that isn't linux?
by SomeGuy on Wed 23rd Apr 2008 20:05
in reply to "RE[4]: What about everything that isn't linux?"
If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.
Hahahaha. In the bad old Xfree86 days, Xfree86 had a stable API. In fact, it was so stable that nobody had been able to implement significant improvements for over a decade. This is why the Nvidia people gave up on them and wrote their *own* 2d acceleration framework for their linux drivers, and they wrote their *own* kernel acceleration infrastructure for their linux drivers.
At the moment there are no stable APIs being defined by linux. That's a central theme.
The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.
The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.
Actually, no. The fact that Xfree86 was run by a**hats who had no clue of how to run a project, scared away all their developers, and did jack to actually improve the state of the art is the reason that this has lagged for over a decade.
The willingness of the Linux people to break their API and get things working is why they're able to do kernel modesetting at all -- kernel modesetting is yet another API and ABI break for the Xorg drivers that want to take advantage of it. It's a significant change to DRI.







Member since:
2006-08-04
If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.
At the moment there are no stable APIs being defined by linux. That's a central theme.
The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.