Linked by Thom Holwerda on Thu 8th Nov 2012 20:54 UTC, submitted by Elv13
Gnome "Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. [...] I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your 'brand' is the best. Anytime I hear the word 'brand' being used in Linux, I know something valuable is being poisoned." I find the tone of this one a bit too harsh and overly negative at times, but his point still stands.
Thread beginning with comment 541622
To view parent comment, click here.
To read all comments associated with this story, please click here.
renox
Member since:
2005-07-06

You're kidding? You can summarize his post as finger pointing: the Linux desktop is a mess (true), but it's not my fault, it's because "the Linux kernel has no internal stable API", really??

He picked THE software in a Linux distribution which has a forward compatible ABI for userspace as the reason why desktops lack stability/compatibility?
I don't remember that when he worked on Gnome he was especially pushing for compatibility, but it must be Linus's fault also.

Reply Parent Score: 5

lucas_maximus Member since:
2009-08-18

Well you suck at reading comprehension.

He was talking about the attitude that is was okay to break APIs, is prevalent because of Linus. While people could argue about whether this is true or not it really doesn't matter whos fault it is.

Breaking APIs is the problem with no path to follow while transitioning. Which is what the blog post is about.

Edited 2012-11-09 14:19 UTC

Reply Parent Score: 0

renox Member since:
2005-07-06

Breaking APIs is the problem with no path to follow while transitioning. Which is what the blog post is about.


Yes, and one cannot help but notice that when he was leading a major Linux project he didn't do anything special about this point..

Reply Parent Score: 3

segedunum Member since:
2005-07-06

He was talking about the attitude that is was okay to break APIs, is prevalent because of Linus.

He totally misunderstood that, which is probably why he doesn't understand a lot of things. To blame his mistakes and that of others on the kernel just shows how little he understands.

Linus has no qualms about breaking APIs within the kernel, but what the kernel did not do was break compatibility with userspace applications - i.e. external interfaces. That's something Linux desktop components have done time and time again.

Edited 2012-11-09 20:25 UTC

Reply Parent Score: 3

silix Member since:
2006-03-01

He picked THE software in a Linux distribution which has a forward compatible ABI for userspace as the reason why desktops lack stability/compatibility?

you know that a kernel has one ABI facing userspace AND one facing drivers (or in general, modules), right?
and that OTOH userspace applications are all linked against the standard c library which actually implements syscalls - thus effectively decoupled from the kernel - but there's no decoupling layer between drivers and the kernel?
that on the userspace side, keeping the kernel ABI stable is actually unnecessary (as long as the library is updated accordingly when disrupting changes are made) and it's really enough to maintain compatibility at the library level - but it'd be necessary (and a sign of good sw design and development practice - ie compartmentization) on the kernel side (which ironically is the one ever changing)?

now, linux actually got it backwards in this regard (and also wrt desktop IPC...)...
and although users can adapt to the current situation for them to choose between using a certain kernel version OR supporting a certain piece of hw, and risk breakage/regressions (not that there arent any, see aspm..) updating the whole kernel, is a suboptimal situation

De Icaza may have been too far reaching in that sentence, but he wasnt completely wrong...

Reply Parent Score: 2