Linked by Thom Holwerda on Wed 29th Aug 2012 22:52 UTC
Thread beginning with comment 533084
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Someone on another article mentioned that we need a stable kernel API for drivers, so that they can write them once, and know that they will run against future kernel versions for the lifespan of their product.
I would argue that the same needs to be done for applications.
I would argue that the same needs to be done for applications.
For the most part, that's already the case - for example, an app written to Gtk+ 2.0 back in 2002 will still probably compile and run on Gtk+ 2.24 today. It probably uses parts of that API which have long been deprecated, but it will still work. That's over ten years of stability.
For an actual API break, you have to go to Gtk+ 3.0, where they finally cleaned out all of those old deprecated functions. But even then, it's not a problem, because the 2.0 and 3.0 libraries have been designed to co-exist..
RE[2]: Comment by woegjiub
by lucas_maximus on Thu 30th Aug 2012 08:01
in reply to "RE: Comment by woegjiub"
For the most part, that's already the case - for example, an app written to Gtk+ 2.0 back in 2002 will still probably compile and run on Gtk+ 2.24 today. It probably uses parts of that API which have long been deprecated, but it will still work. That's over ten years of stability.
The work probably doesn't fill me with Enthusiasm
For an actual API break, you have to go to Gtk+ 3.0, where they finally cleaned out all of those old deprecated functions. But even then, it's not a problem, because the 2.0 and 3.0 libraries have been designed to co-exist..
Yes but GTK is one GUI library out of many that work on the platform.
The difference is with MacOSX/iOS, Windows and Android you have a standard set of APIs that you can expect to be there and expect to work in a certain way.l
This doesn't exist in Linux except for the basic userland.
Someone on another article mentioned that we need a stable kernel API for drivers, so that they can write them once, and know that they will run against future kernel versions for the lifespan of their product.
I agree with you on that. Maybe I should add that most users really don't care whether it is open source or not, they just want it to work.
A linux desktop works fine and doesn't need much maintenance, but you need someone that can help you out when an update screws something up. Most readers here will be able to do that, but the average user doesn't know what to do.
Someone on another article mentioned that we need a stable kernel API for drivers, so that they can write them once, and know that they will run against future kernel versions for the lifespan of their product.
For the 99,999'th time, bullshit, bullshit, bullshit.
I maintain a fairly large (in 100,000's of LOC) in-kernel project that covers everything from files to networking. This code works in Linux, BSD (when required) and used to work in Windows.
The amount of work required to maintain the project between different Linux kernel releases is negligible at best (usually less that 1h per kernel release).
*However*, I dropped the Windows support as undocumented changes between SP releases tended to break both the user-space part of the code and the kernel-space part of the code.
Care to prove me wrong?
- Gilboa
RE[2]: Comment by woegjiub
by lucas_maximus on Thu 30th Aug 2012 08:33
in reply to "RE: Comment by woegjiub"





Member since:
2008-11-25
Despite completely disagreeing with the Gnome3 direction, I find myself actually agreeing with Mr. de Icaza.
Someone on another article mentioned that we need a stable kernel API for drivers, so that they can write them once, and know that they will run against future kernel versions for the lifespan of their product.
I would argue that the same needs to be done for applications.
Unfortunately, there is never going to be a consensus on things like this, as we can see from the results of the attempt to make all distros use the same package format.
It is a shame that there can not be some sort of consensus reached between the linux foundation, red hat, novell, the debian project (which would bring canonical into line, presumably) and a choice other couple of partners like arch and their ilk.
Edited 2012-08-29 23:44 UTC