[CrackMonkey] RMS on GNOME

[Rick Moen]

begin  Alex Feinberg quotation:

> Yes, standarts still suck. Let the user choose. Miguel was on crack when
> he said that UNIX like standarts, and that is Not A Good Thing. The less
> standarts the better. The only standard I recognize is C and POSIX. The
> rest should be up to the user.

When this came up on the SVLUG list, one of the more thoughtful posts
was by Karen Shaeffer:

---<snip>---

I couldn't agree more. The whole GNOME and KDE thingies are a disaster.

 ___________       _____________________       ________________
|    GUI   |      |   Either a pipe    |      | Commandline   |
|  Front   |<---->|   or a UNIX socket |<---->| core utility  |
|   End    |      |   or other IPC     |      |               |
|__________|      |____________________|      |_______________|

All NIX code should be crafted as such. Large application suites like
Star Office could be architected in this manner, if they would have
been thinking clearly. You should always have the capacity to take the
core and use it without any dependencies on the GUI.

GNOME should be designed to facilitate the creation and maintenance of
IPC channels between an arbitrary number of core utilities, and, of
course, controlled by the user. This architecture facilitates ease of
maintenance and is completely open to innovation.

[and, in a later post:]

The recent posts have been quite informative. But I just want to
highlight what I consider the most imperative consideration here: How
dependencies result in the macro accordion effect. This is of tremendous
importance as we move forward.

The legacy Windows development environment is rooted in dependencies.
This system emerged in a different time and sufficed. As circumstances
evolved, the legacy Windows system came to rely on these developer
dependencies as a trap for future acceptance. We all know this has lead
to a disgusting status quo--a subject I don't intend to get into.

But we now have real competition for the desktop. It would be tragic and
a tremendous mistake for GNOME to accept the failed architectural
premise of Windows: That un-fettered interdependencies are desireable.
The reality is quite to the contrary. When code re-use results in a
development environment that is incapable of rapid extension and
evolution--it becomes a clear liability rather than an advantage. That
may not have been true in the days when Windows was an unchallenged
desktop monopoly--but it is now.

The real *war* over the desktop is just beginning. It is the capacity to
adapt and evolve most quickly and to incorporate emerging hardware
related features that extend and enhance performance that will lead to a
sustainable and enduring desktop development framework. These
characteristics are not compatible with library dependencies that result
in the macro accordion effect.

It was mentioned how many developers will be migrating from GTK+ to
GNOME, and the GNOME folks need to accommodate this migration. Of course
this is true. But I think it is far more instructive to look at it from
the migration of emerging technological innovations--many of which
involve innovations in hardware. Avoiding the marco accordion effect is
imperative to facilitating rapid integration of these new technologies,
or, put another way, paving the road for migration of these technologies
from R&D development labs, to bleeding edge products, to incorporation
into the desktop environment. The desktop development environment most
suited to this reality will be the enduring one.

I hope the GNOME folks keep these issues in mind as they move forward.

---<snip>---

-- 
Cheers,                                Bad Unabomber!
Rick Moen                              Blowing people all to hell.
rick (at) linuxmafia.com               Do you take requests?
               --  Unabomber Haiku Contest, CyberLaw mailing list