Devils are in the details [LWN.net]

Devils are in the details

Posted Mar 2, 2011 14:01 UTC (Wed) by renox (guest, #23785)
In reply to: Devils are in the details by drag
Parent article: An Early Look at GNOME 3.0 (Linux.com)

> It's really bad form for applications developers to be forced to hack around Linux being shitty.

Well it's called being pragmatic and wanting to have your application being available now, not several years in the future..
KDE developers do maintain a 'blacklist' list of features, but apparently there still wasn't enough testing (perhaps a lack of communication?) as I remember reading some complaints about HW-acceleration bugs..

>It's better just to fix Linux

Except that it's just wishful thinking:
1) some HW don't have open specifications!
2) Application developers may not own the problematic HW
3) plus fixing HW drivers (especially complex one such as 3D drivers) is a very different skill than developing applications.

>[cut] Choice is not a good thing when all the choices suck.

Welcome to the real world.

Devils are in the details

Posted Mar 2, 2011 16:21 UTC (Wed) by drag (guest, #31333) [Link]

> Except that it's just wishful thinking:

So is having a good experience with a desktop that is designed to both use XRender and OpenGL to do the same thing. :P

> 1) some HW don't have open specifications!

Yes. This sucks. But there is plenty that do, or at least are 'open enough' that they work out well. Nowadays we have enough hardware on the market made by Linux-friendly-enough companies that I think it's pretty reasonable to expect that if people want to run Linux with the "Full Desktop" experience that they can obtain the necessary hardware.

And like I mentioned before: On modern hardware there is no longer 2D. It's not simple like that anymore. Drivers capable of driving XRender are going to be capable of doing other stuff. It's a API that is designed for hardware that doesn't exist anymore, I suspect. I am sure that other people understand the details better.

What we really need is a DE environment that is willing to depend on fully functioning subset of a particular popular API. OpenGL is probably just fine in this regard. It should concentrate on just working with that set of assumptions. Not trying to support multiple APIs and forcing users to choose when they have neither the knowledge of the hardware or understanding of the environment necessary to make a proper choice.

Then we need a 'lite' fall back were there is no acceleration available at all. That all your expected to be using is just pure software rendering or bit blotted display or something like that. Even if it ends up slow because application developers learn to depend on a properly configured computer it is not terribly important. It just needs to work.

> 2) Application developers may not own the problematic HW

This is what quality assurance and test suites are there to deal with.

Live CDs, usb drive images, automated benchmarks. It's easy nowadays to setup previews and things that people can just download and run. No compiling necessary or deep understanding. Trace logs and scripts to help providing debug information to developers should be built into the evaluation environments and nice documentation on what developers want needs to be provided. Information on the experience of the tester can be uploaded automatically or be sent with a press of a button.

It's often very useful to have the folks that QA be completely different from the folks that develop. Programmers are often 'too close' to the software to be able to see how users will approach it and what issues they will find. This helps issues get identified quicker in many cases.