Linked by Thom Holwerda on Fri 27th Jul 2012 12:41 UTC
Gnome Honest question. Do you think the GNOME project is as healthy today as it was, say, 4 years ago? Benjamin Otte explains that no, it isn't. GNOME lacks developers, goals, mindshare and users. The situation as he describes it, is a lot more dire than I personally thought.
Thread beginning with comment 528519
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: gnome3 and unity.
by hhas on Fri 27th Jul 2012 15:53 UTC in reply to "gnome3 and unity."
hhas
Member since:
2006-11-28

But it’s a step in the wrong direction for open source desktops.


And what exactly should constitute an 'open source desktop'? I last used Gnome 2 six months ago, and it's barely changed from the days when it was still known as 'Mac OS 7.1' - i.e. 20 year-old GUI idioms, barely changed over all those years. (Still not as bad as its CLI, mind you, which is mired in 1970s-era design, or persistent storage, which is 1950s.)

The fundamental failing of all the mainstream Linux DEs - not just the GUI shells but the apps that run on them too - is that they all play to the competition's - i.e. MS and Apple - strengths when instead they ought to be playing to their own - i.e. *nix - strengths. Everyone involved in creating the first Linux desktops instantly forgot everything they ever knew about Unix Philosophy: keep everything small, simple, highly modular, endlessly composable, agile, adaptable. [1]

Instead, they built up these huge, grand palaces, fine testaments to their own mastery of sophistication and complexity, but insanely time-consuming and expensive to construct and maintain, and horribly bad at adapting to changing circumstances and requirements.

FWIW, the Linux GUI folks aren't the only ones to fall into this trap - web framework developers are also notorious for it, as is C++ where the answer to every question on how to improve it is invariably 'add another kitchen sink'.


The problem is this: the likes of Apple and Microsoft, who possess sufficient material resources that they can afford to get away with such a high-cost, high-maintenance strategy. Whereas OSS communities simply do not have the spending power to keep up with them; by the time they've constructed their own edifices, they can barely afford the existing upkeep, never mind the aggressive experimentation and evolution needed to keep it moving forward. Nor can they afford to throw away such a massive monolithic investment as that means starting over again from scratch. So they creak along year after year; okay, the lack of change may appeal to the strongly conservative nature of the majority of Linux nerds/geeks, but I would hope even they would eventually admit that such a strategy means they will forever be left trailing in the wake of the Big Two, with absolutely zero chance of ever jumping out ahead.

Let's call the above approach the 'Intel strategy'. Yes, x86 architecture sucks, but Intel are so incredibly wealthy that they are able to ameliorate its worst failings simply by throwing vast quantities of raw resources at it. What the Linux GUI folks need to adopt is an 'ARM strategy': don't even try to compete with Intel's approach to the problem; instead, develop a nimble, low-cost strategy that plays to your own unique strengths, redefining the problem itself where appropriate to better accommodate these goals, and do an end-run right around the competition.

I mean, consider just one problem: developing a word processor. Outsiders may not think it'd be such a hard problem (it's only one step up from a simple text editor, right?), but in fact just dealing with Middle East and Far East scripts alone is sufficient to put 20 years on even the strongest, smartest developer. LibreOffice copies Microsoft's approach: vast powerful monolith achieved through brute strength. Looks very impressive, but what a vast waste of an opportunity: completely inflexible structure, no feature reuse across other apps, requires a major commitment and loads of time and work to become a developer on it. Conventional commercial vendors can afford not to care about this - if anything, it's a valuable marketing tool, ensuring mass user lock-in. OSS folks though need to squeeze every single line of code, every single minute of developer and tester time, in order to extract every last possible ounce of value they can. Which is, of course, the sort of 'work smart, not hard' approach that Unix Philosophy is all about.


Now, you might think discussion of application architecture is irrelevant to the subject of DE development, but it's absolutely everything: DEs exist solely for the purpose of running applications, so the whole philosophy and construction of the DE inevitably dictate the philosophy and construction of all the applications that run on it.

Off the top of my head, the only Linux DE project whose philosophy is anywhere close is Etoile. Although the notion of a component-based desktop is not new. For instance, consider Apple's OpenDoc, which they abandoned at least partly because it did undermine the vendor-lock-in advantage of giant monolithic apps, ensuring that the main commercial app vendors (Adobe, MS) would never want to adopt it. With the technical issues ironed out I could see such an architecture being a terrific, natural fit for Linux DEs, precisely because it'd play so well to OSS strengths. Make it work, and all of a sudden Linux has a Unique Selling Point that the commercial DEs cannot directly compete on because it's against their interests to replicate it.

And that is what an OSS desktop should be.

...

That's all about where Linux should be heading though. Getting back to where it is today, especially with regard to Gnome 3?

IMO, wind up the entire Gnome project and close it down in orderly fashion. There are far too many poorly differentiated Linux DEs as it is - a period of consolidation in the immediate future would do them all a world of good, allowing more resources to be focused on fewer, more distinctive projects. If we're being brutally honest about it, all Linux really needs to cover all current bases are three production DEs: e.g. Unity as the everyman DE, KDE for the cool kids who love their endless bells and whistles, and Mint for the crusty old conservatives who like their desktops 1980s-style, thankyewverymuch.

All the folks left over by such a consolidation can then go spend some time getting individual GUI apps polished up a bit more (Dog knows most of them seriously need it). A few might even crack open their extremely dusty copies of the Art of Unix Programming, and think about how to apply all that forgotten wisdom to inventing a brand new OSS DE that follows Unix Philosophy through and through - one that doesn't simply continue the tradition of trailing way back in the wake of Windows and OSX/iOS, but instead completely outsmarts and performs an end-run right around them.


[1] http://www.faqs.org/docs/artu/ch01s06.html

Reply Parent Score: 14

RE[2]: gnome3 and unity.
by hhas on Fri 27th Jul 2012 16:44 in reply to "RE: gnome3 and unity."
hhas Member since:
2006-11-28

A few might even crack open their extremely dusty copies of the Art of Unix Programming


One addendum: whatever you do, don't read the 'Application Protocol Metaformats' section in Chapter 5. It is appallingly bad and should be avoided like the plague.

(I mention this as a meticulously designed high-level IPC system would form a cornerstone of a highly modular DE, so the absolute last thing it needs is to take that material as its guide. Amongst other atrocities, it talks about using HTTP as a transport layer and praises XML-RPC as being very much in the Unix spirit. Anyone who genuinely understands HTTP and REST concepts - i.e. maybe 1% of those who think they do - will tell you such abuse is the very antithesis of Unix good practice. And anyone who believes otherwise should have all their .ini files turned into binary XML format.)

Reply Parent Score: 3

RE[2]: gnome3 and unity.
by ple_mono on Fri 27th Jul 2012 18:52 in reply to "RE: gnome3 and unity."
ple_mono Member since:
2005-07-26

Good read! Thanks. I like your thinking.

Reply Parent Score: 2

If I could choose.
by Gone fishing on Sat 28th Jul 2012 09:35 in reply to "RE: gnome3 and unity."
Gone fishing Member since:
2006-02-22

Linux really needs to cover all current bases are three production DEs: e.g. Unity as the everyman DE, KDE for the cool kids who love their endless bells and whistles, and Mint for the crusty old conservatives who like their desktops 1980s-style, thankyewverymuch.


Probably - but I can't help feeling Cinnamon is wrong, all it is is Gnome Shell with a few extensions. Mint certainly have a handle on what a lot of users want, but if I could choose I'd have the Gnome Shell folk work with the Cinnamon folk to produce a default Gnome Shell that the more conservative users want and evolve it from there.

Perhaps Thom is right

Sadly, I'm afraid heels will be dug into the sand regarding GNOME 3, and we'll see a doubling-down on an environment people simply don't want, instead of trying to find out what users do want.

Shame

Reply Parent Score: 2

RE: If I could choose.
by _txf_ on Sat 28th Jul 2012 13:54 in reply to "If I could choose."
_txf_ Member since:
2008-03-17

Probably - but I can't help feeling Cinnamon is wrong, all it is is Gnome Shell with a few extensions. Mint certainly have a handle on what a lot of users want, but if I could choose I'd have the Gnome Shell folk work with the Cinnamon folk to produce a default Gnome Shell that the more conservative users want and evolve it from there.


Cinnamon wouldn't exist if it weren't for the actions of Gnome Shell people. I'd guess the Cinnamon people would much prefer to develop upstream, but I doubt the Gnome would welcome them..

Edited 2012-07-28 13:56 UTC

Reply Parent Score: 4

RE[2]: gnome3 and unity.
by dsmogor on Sat 28th Jul 2012 22:57 in reply to "RE: gnome3 and unity."
dsmogor Member since:
2005-09-01

Nice rant, but I can't agree with most of it.
Unix programming (and philosophy) have not attempted to produce anything significant on the GUI/productivity front. It's best in network services and HPC but the computing world have long moved forward from these basic concepts in the last 30 years.
Unix desktops are unusable by today standards.

You miss DEs that are not slavishly trailing Windows / Apple lead and look their own ways. There's plenty of them (e.g. GnuStep, E17), and they have their loyal following (that's as you admitted is enough to sustain them). But they are still the minority after years.

I second the OpenDoc argument. A huge missed opportunity by IBM, who could donate it do community 15 years ago, letting talented people like Miguel de Icaza to focus on writing functionality people actually care about.

About killing Gnome: as said not much would be saved by it as they don't have much contributions anyway. Besides you largely miss the political and philosophical factors. Gnome vs. KDE was always somehow US approach vs European approach fight. You can't assume the same people would easily switch sides and support the other one. Besides, you can't have Unity w/o Gnome anyway.


My comment to the situation, Linux users want a tweak-ability and choice but few on the realize that every choice increases support complexity and testing exponentially. There's simply not enough people in the community (and living in the planet earth for that matter) to test and polish all the combinations these people demand available.

Reply Parent Score: 3

RE[3]: gnome3 and unity.
by hhas on Sun 29th Jul 2012 01:00 in reply to "RE[2]: gnome3 and unity."
hhas Member since:
2006-11-28

Nice rant, but I can't agree with most of it.
Unix programming (and philosophy) have not attempted to produce anything significant on the GUI/productivity front.


Philosophies don't write code; developers write code. It's up to Linux developers to apply Unix philosophy in their designs, not the other way about. And where they fail to do so, they've no-one to blame for the resulting monolithic monsters but themselves.

I think part of the problem is that the early Unix designers were forced to employ humble parsimony by the extreme scarcity of hardware resources back in their day, but modern generations are spoiled by the massive glut of such resources in today's systems, allowing for the establishment of fat, grandiose designs that lack any hard checks against their own short-sightedness. They need to force themselves to be humble and parsimonious from day 1, so that by day 4000 they have not sunk beneath their own vast weight.

e.g. Me, I'm forced to employ such parsimony in my own work simply because I am not all that bright and my memory has all the capacity and reliability of a wobbly 16K RAM pack. So when I write a complex system, I put most of the effort into reducing or eliminating complexity as much as possible. Modern technology, highly reliant on high-level IPC and component-based construction to divide and minimise the solid core so it's as small and manageable as possible. e.g. When I needed to implement my own scripting language, I based it on the sort of simple Scheme interpreter they used to teach CS students to build in college; very high power-to-weight ratio as a result. Only the core data types are built in; all the actual functionality exists as plugins, even fundamentals like defining variables and performing flow control. And I'm just an art school drop-out and general bum, so the rest of you should have no excuses whatsoever.


It's best in network services and HPC but the computing world have long moved forward from these basic concepts in the last 30 years.


Pish and nonsense. Unix philosophy just doesn't favour Highly-Paid Enterprise Consultants who build their fortunes by creating their own problems to solve, and big-name proprietary OS and application vendors who benefit from the user lock-in business model, is all.

And even if we do limit ourselves to applying Unix philosophy to networks, what is a component-based framework such as OpenDoc if not a single-purpose network in itself?

I've been posting even longer rambles over in the hierarchical file system thread, most of which boil down to "So why exactly are we treating local (disk) data storage and remote (network) data storage as two utterly different things?" I frequently see very smart programmer types mentally slicing up service provision requirements according to technical implementation. Me, I approach the same challenge as a UI problem, and look at it in terms of overall usage patterns. They see the all the little differences: "disk vs network". I spot the broad commonality: "data storage". Which is actually the more crucial of the two? Ruthlessly consolidating overlapping ideas and squashing them down into their simplest common form is one of the core activities of Unix philosophy. So, for example, the Unix file system interface does double-duty as local storage and IPC mechanism. That's the sort of brilliant craftsmanship and creative efficiency that all OSS DE inventors should bring to their own work.


You miss DEs that are not slavishly trailing Windows / Apple lead and look their own ways. There's plenty of them (e.g. GnuStep, E17), and they have their loyal following (that's as you admitted is enough to sustain them). But they are still the minority after years.


But how many of these DEs adhere to Unix philosophy throughout their construction? External appearance is irrelevant; it's the rules they set down on how each brick should be placed together that makes all the difference. And even that by itself is not enough. A DE that achieves Unix philosophy within itself but still only runs the same old monolithic slabs of apps that infect all the mainstream DEs has also failed to bring enlightenment to the OSS desktop as a whole. Remember, a DE's value resides in the apps it runs. If the apps are all rubbish, the DE's ultimately worthless.

It's the old 'work smart, not hard' mantra: OSS simply doesn't have the vast time and manpower resources that Adobe, Apple, MS, etc can use to brute-force hammer their own giant monolithic apps into being somewhat decent.


I second the OpenDoc argument. A huge missed opportunity by IBM, who could donate it do community 15 years ago, letting talented people like Miguel de Icaza to focus on writing functionality people actually care about.


Another anecdote: I have, for my many sins, just spent the last decade mastering Apple event IPC. (I'm perhaps one of a dozen folk in existence who truly grok it all the way down to its very bones. That's not a good reflection on me, mind; rather a poor reflection on everyone else.)

Amusingly enough, right after its birth in System 7, Apple shot the whole AE system in the kneecaps just so they could send a couple of its engineers to go get OpenDoc "ready to throw away" (as one internet wag memorably phrased it). Under pressure from their publishing users (back then still a key market), they tried reinvigorating all the AppleScript/Apple event stuff for OS X, but still didn't really understand what it was about and unsurprisingly made a bit of a muck of it, again. Few years later, they invented Automator as a less granular approach to desktop automation (Duplo blocks to AppleScript's Technics, not that there's anything wrong with that). Futzed that too.

A large part of the problem: you can't add componentization onto the side of an already monolithic app and expect to achieve wonders. You have to follow that philosophy from the ground up. And rather than build one giant does-everything app, build several small, simple ones that do one thing apiece and do it well, and ensure they can easily and effectively talk to one another. (My favourite target of hate here: email clients with built-in address book and calendaring facilities. Should be three separate applications every time.) And that's just with your classical application-centric desktop; if you go full-hog along the OpenDoc route (as a truly *nix desktop should), that pattern will be implicitly ubiquitous anyway.


My comment to the situation, Linux users want a tweak-ability and choice but few on the realize that every choice increases support complexity and testing exponentially. There's simply not enough people in the community (and living in the planet earth for that matter) to test and polish all the combinations these people demand available.


Two things:

1. Linux DEs need to learn when to say NO to the tweakaholics. (GNOME, to its credit, did try.) When they whinge (as they invariably do), hit them hard with the LART stick. Repeat for as long as they continue to understand the value of everything and the cost of nothing. Simultaneous to this, be aware that having really a good, logical, intuitive default design in the first place really helps to take any legitimacy out of their complaints, and that this may require some hard investment too.

2. Linux developers need to remember that any time they're seeing exponential growth in something, it's a damn clear sign they're using an O(N*N) [or worse] algorithm instead of an O(N) or O(N*log N) one. Redesign the algorithm, which in this case is their whole DE construction philosophy. The CLI developers don't have it anywhere near that bad, and it's not like their habits are particularly rigorous.

Reply Parent Score: 2

RE[2]: gnome3 and unity.
by zima on Fri 3rd Aug 2012 23:49 in reply to "RE: gnome3 and unity."
zima Member since:
2005-07-06

The fundamental failing of all the mainstream Linux DEs - not just the GUI shells but the apps that run on them too - is that they all play to the competition's - i.e. MS and Apple - strengths when instead they ought to be playing to their own - i.e. *nix - strengths. Everyone involved in creating the first Linux desktops instantly forgot everything they ever knew about Unix Philosophy: keep everything small, simple, highly modular, endlessly composable, agile, adaptable. [1]

LXDE can be probably considered quite mainstream by now, and is relatively "*nix philosophy" ...so far (so good)

Also, you mention word processors, and there is a whole collection of tools filling largely that role and in a "proper" philosophy: TeX and so on (also quite easy to use LyX) - problem is, people don't seem to want to use such too much, preferring the ~closed monolith model which allows them to manually tweak the layout (with usually much poorer results than a proper typesetting system would give)

Reply Parent Score: 2