Linked by Thom Holwerda on Wed 29th Aug 2012 22:52 UTC
Linux Miguel de Icaza: "To sum up: (a) First dimension: things change too quickly, breaking both open source and proprietary software alike; (b) incompatibility across Linux distributions. This killed the ecosystem for third party developers trying to target Linux on the desktop. You would try once, do your best effort to support the 'top' distro or if you were feeling generous 'the top three' distros. Only to find out that your software no longer worked six months later. Supporting Linux on the desktop became a burden for independent developers." Mac OS X came along to scoop up the Linux defectors.
Thread beginning with comment 533084
To read all comments associated with this story, please click here.
Comment by woegjiub
by woegjiub on Wed 29th Aug 2012 23:43 UTC
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

Reply Score: 4

RE: Comment by woegjiub
by Delgarde on Thu 30th Aug 2012 03:09 in reply to "Comment by woegjiub"
Delgarde Member since:
2008-08-19

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.


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..

Reply Parent Score: 5

RE[2]: Comment by woegjiub
by lucas_maximus on Thu 30th Aug 2012 08:01 in reply to "RE: Comment by woegjiub"
lucas_maximus Member since:
2009-08-18

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.

Reply Parent Score: 2

RE: Comment by woegjiub
by spinnekopje on Thu 30th Aug 2012 04:58 in reply to "Comment by woegjiub"
spinnekopje Member since:
2008-11-29

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.

Reply Parent Score: 1

RE: Comment by woegjiub
by gilboa on Thu 30th Aug 2012 08:11 in reply to "Comment by woegjiub"
gilboa Member since:
2005-07-06

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

Reply Parent Score: 3

RE[2]: Comment by woegjiub
by lucas_maximus on Thu 30th Aug 2012 08:33 in reply to "RE: Comment by woegjiub"
lucas_maximus Member since:
2009-08-18

We are talking about Drivers not your pet projects ... unless you are talking about drivers your comments are not relevant.

Reply Parent Score: 1