On Sun, Jan 20, 2008 at 11:35:31PM +0200, Alexey Eremenko wrote:
Hi Greg KH,
What specific problems with "backward-compatibility" do you see on Linux today? Where are you having problems that you see needs to be solved. Specifics please.
I'm happy that one of the best is listening :)
OK: my own experience: I took tuxracer.RPM from Mandrake Linux 9.2 to Mandrake Linux 10.1 (one year difference) and it crashed on start. Unfortunately, I haven't done any stracing/debugging to get more facts, because it was a looong time ago.
tuxracer is an open source program, it is ment to be rebuilt on a new system and it can rely on a system providing some specific libraries. This has _nothing_ to do with how a "commercial" application is distributed and ment to be run and installed.
But then again, if some commercial company release app XYZ based on Qt1, it is very unlikely to run on modern Linux systems.
No, it probably will work just fine, _if_ they know how to handle their packaging and dependant libraries. Note that this is _not_ a new thing, nor unique to Linux, same thing happens for Windows and other operating systems.
Kernel Module/Driver ABI insanity:
<snip> Go read Documenatation/stable_abi_nonsense.txt in the Linux kernel tree for _why_ the Linux kernel abi is constantly under flux and changing. If you have questions after reading that, please let me know.
Not to speak about kernel modules (drivers), which break with every nano-upgrade of one-line of Linux code.
That is why all kernel drivers should be in the main kernel source tree so that no user will ever experience this. Note, if you know of drivers that are outside of the main kernel tree that you rely on, please let me know. I have a list that I am currently working on getting merged to solve this issue.
While drivers ABI isn't very stable on Windows too, you have still very high chances, that a binary driver written for Windows 2000 kernel will run on Windows XP/2003 kernels, unmodified.
Hah, you gotta be kidding. Just read the Windows driver mailing list for a few days to see how wrong this is :)
Those LKMs are used quite frequently inside "normal" applications by-the-way. VirtualBox, Nero ImageDrive, and Incentives Pro USB-over-IP are such examples. BTW: LSB doesn't have specs for LKMs too.
All of those modules you mention are closed source, right? If not, there is nothing keeping them from getting added to the main kernel tree and solving this issue. If so, then they are violating the copyright of the Linux kernel developers and are ripe for a lawsuit (note, a number of them are currently pending, so don't think that the kernel developers don't care about this...) And no, there will never be a LSB for kernel modules, see the above referenced file for details why.
I know, that those problems are nearly impossible to fix, but easing them will already help me a lot. For example, if LKM were compatible for all Linux kernel's first three numbers. That is: LKM compiled for Linux 2.6.18.0 should work on all Linux 2.6.18.x series, not break between 2.6.18.0-1 to-> 2.6.18.0-2 versions, that are downloaded via online-updates. This will be huge step forward, as it will ensure drivers compatibility at least within one specific distro.
Again, impossible, please see the above referenced file for why you do not ever want this. thanks, greg k-h -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org