Comments for post Linux Kernel: just engineering without a vision?
Alex writes: Even single-company targeted *ndows has much more problems with the drivers and "stable" API than you can imagine. Some examples:
1. *rectX 9/10 has to bring more than 100 megabytes of compatibility DLLs by now, and the number will grow. A way to fight API/ABI changes, for sure. But there is no way to avoid them :)
2. "stable" API broken *rectSound3D support in *sta and upcoming *indows Seven bullcrap. And there was even no compatibility layer provided. The same as your case.
3. The same "stable" API broken plenty of application compatibility in the same bullcrap.
4. *ndows Installer is updated from 1.0 to 2.0 to 3.0 to 3.1 breaking many installers with each update.
5. Plugging in Creative webcam into XP SP2 or higher results in a stable blue screen crash. SP1 works ok. The "stable" API in action, yeah. Sometimes it is better to break API/ABI than to cope with probable bugs.
6. Try to run most of the XP drivers on *ista bullcrap. You'll be surprised with the ABI stability. And this is included *ista did not changed much in the kernel. Kernel second minor changes (i.e. 2.6.18 to 2.6.19) are bigger than that.
7. Try to run some XP sound drivers on 2003 kernel. You'll be surprised, too. And that's the same kernel.
8. Much much more can be mentioned.
"Stable" API/ABI is a dream or even a miracle. It can be keeped as long as the product has no reasons to get significantly better. When it has, API/ABI is changed.
liquidat writes: spceman: Yes, you're right, the Linux part of Mars rover was actually a bit different:
"On MER, Linux is being used for high-level science planning and for low-level command sequencing, visualization and simulation."
But that isn't the point here.
Drew Vogel writes: A better thing for the user (than even downloading a stable binary driver) is Debian's module-assistant that downloads, compiles, and inserts modules for you, relying on the already stable Depends system for handling API incompatibilities. Not only is it a single step but it also allows the drivers to get better over time.
spaceman writes: @liquidat
"What kind of vision would you like to have? Keep in mind that this is not a single company with a product with a specific target but a development project with literally hundreds of targets (server, embedded, desktop, mars rover, etc.)."
Mars rover does not use a linux kernel at all : watchdog subsystem is incompatible with a correct management of any kind of malfunction . In the 1997 a similar system completely fails , 'cause of a bug that caused the system to continuosily reboot. The new "sofware politics" of mars rovers is to use a microkernel structure that is able to make diagnostics against the misfunctional code or to isolate the entire subsystem , in the worst case.
Ev writes: If you are asking for stable kernel APIs, you are missing the point of Linux: it is free software. The source code for drivers of your camera, or for anything for that matter, should be available for everybody to see and change, therefore they are supposed to be updated in the same fluent and promptly manner as the kernel itself.
What you are asking for is a commercial software model except you conveniently are not willing to pay for it. You misinterpreted the meaning of "free".
davidonzo writes: 1 - Can I ask you where you bought it? I'm looking for a good webcam that works easly with my distro (ubuntu feisty).
2 - Linux is improved its desktop usability because desktop application work on this way.
I never see new linux kernel with "real" desktop oriented features.
Most of the job to make a real desktop oriented distribution is made by the singles distro team.
The linux kernel included in Ubuntu is never the same released by the OSDL.
The reason? Ask to Linus :)
But, maybe to release a single kernel for desktop and server machine make some decision not so easy to take.
3 - Translate your "mobile edition" (words "commenti" and "successivi").
4 - Thanks to switch this blog in english. Another way to improve it!
wageslave writes: Sometimes, you get what you pay for.
liquidat writes: Hm, I think you don't take into account why things are like that atm., and in which directions they are changing.
Of course, the development around the Video4Linux drivers is a mess and there was something really wrong in the development. The result is that it will take some time until all this smoothes out. Sad, but true.
However, in almost all other regions there was massive development in the opposite direction just recently:
* the WLAN subsystem has been massively reworked, resulting in a stable subsystem in contrast to six different subsystems.
* the MMC subsystem has been massively reworked to now support standards instead of just patching together the support for different devices
If you go some time back you find other, major and important developments: with D-BUS Linux finally gained a system wide IPC and HAL and udev improved the device handling and the possibility to react to different devices and different device quirks massively (she: when you think udev and HAL complicated anything there is something clearly wrong!)
Also, future developments are clearly outlined: the next major subsystem rework will be the one of the graphics subsystem. This is again not to break anything on purpose but to bring some sanity into the current solution which has many problems and blocks real performance on X.
Many of these changes are necessary out of historic reasons: now there is finally the money and time (=development power) to work on these subsystems in a clear an sane way instead of just patch-as-you-go.
Of course the switch should usually be like the WLAN switch (just delete old drivers if there are no regressions with the new ones in any way) and not like the V4L switch from 1 to 2.
Also, keep in mind that these switches of the happen also for another reason: performance improvements. Many of the old APIs have only limited scalability and performance, and new ones are necessary to really use the hardware.
Who wants to have a suboptimal solution?
About the question of a general vision: the vision is to let all hardware work in the best way. And to let the subsystem people do what they think is best. What kind of vision would you like to have? Keep in mind that this is not a single company with a product with a specific target but a development project with literally hundreds of targets (server, embedded, desktop, mars rover, etc.).
Also, about the stable API: this is already possible with quite little effort (userspace driver api) - but the question is if that is really necessary. If the subsystem development would have been made in a sane way it could have worked :/
Also, for a stable long term one-size-fits-it-all stable API you should keep in mind what the consequences would be like: http://lwn.net/Articles/162686/
So: I think the best way would be to address the subsystem people of Video4Linux and point out that something went horribly wrong. Just the fact that the new Flash 9 (released not too long ago) choose V4L1 instead of V4L2 already showed that there are some big misconceptions and problems in that area, and that the subsystem people did something horrible wrong there.
They should have at least talked to the users of the API (the application developers) so that V4L2 should have been supported at release date by all important apps. Also, the porting of the driver had too many problems apparently and that should have been smoothed out before the final release.
But that has not that much to do with a stable API but with coordination between developers and "users".
Paul writes: Don't forget about the tremendous work done by gspcaview/spcaview. Also its important to realize that driver development for these devices are done at a chip specific level, and not by the manufactures that assemble the final board arrangements which come in a far greater variety, requiring more overall testing. Still I think its wrong for management at these device manufacturing companies to limit the distribution of in-house code to run these devices. You have to believe that the developers that work on these devices have code in-house that runs on GNU/Linux, doing development on such systems out of convenience and just not releasing as gpl due to upper management. If thats the case the issue just needs greater awareness; I don't think a manager has a reason to even think of such a release concept.
David N. Welton writes: Remember to add hardware that doesn't work with Linux to the Linux Incompatibility List, here: http://www.leenooks.com
Thanks:-)
chuck writes: The term for a "binary API" is ABI, and the official policy of Linux is that there is no stable ABI, period.
That Linux can't manage to keep even the source-level API stable, or keep the ABI stable between patchlevel releases is a serious problem. OpenSolaris looks more tempting every day, and as more drivers are open-sourced, the value proposition of sticking with Linux is starting to diminish.
antirez writes: @she: basically it's exactly what I mean, the benevolent dictator is not working for subsystems of the kernel, and of course can't work at all for the "userspace madness", but at least the userspace complexity and inconsistency is handled by distributions and GUIs in some way... instead for the problems about the kernel there is almost no solution.
About your second point where you disagree, my idea is that of course it's not possible to go slow just to support legacy things, but:
a) probably some API was designed in a bad way if in order to make it better you need to totally break it and rewrite it from scratch.
b) many times, like for the V4L1 problem, it's possible to write a compatibility layer without too much efforts, why this isn't done at all? It's a shame. Also I don't think that changing the interface between kernel and modules is required in order for the kernel to work well. It should be like that for kernel 2.4 the interface must be taken stable, than 2.6 can change it and so on. It makes a lot of sense to bring a bit of API stability, there is always room to improve in the next release and if the API is well designed there is no reason at all to break things.
Thanks for commenting.
she writes: Although I dont agree totally, I understand and support your basic point.
We can take another example, the OSS vs ALSA madness that was here... my gripe with it all is that Linus does not provide a clear vision that goes out of his kernel. And obviously neither inside.
With that I mean, one way to FOLLOW. People can still strive away from this for whatever reason but at least you KNOW that this one way will work.
It also happened with the change to udev. udev complicated so much... now the same happens with PAM and HAL ... I think sometimes development just happens to make things more complicated.
Another example, I know how to configure kdm and gdm, but for me its just easier to do "rinit gnome" and this will start gnome via .xinitrc... or "rinit flux" and it will start fluxbox etc.. the total script is around 20 lines of code, and without args it will just startx...
simple and effective without the need for those fancy add-ons like kdm..
In actuality though, i want one thing to WORK, and work in a GOOD way. And this is where I disagree with you in this one aspect:
IF something will be BETTER, than I do NOT mind at all if legacy is thrown away.
(I'd just wish that people would throw away the ugly FHS, and that Linus would, instead of flaming gnome or whatever-i-dont-care, give a clear vision of how things SHOULD look. It would help a LOT, because after all, Linux as a whole is effective, but a TOTAL MESS)
home