[linux-elitists] Can we woo you first? [Was: How MS could woo me]

Jeff Waugh jdub@perkypants.org
Wed Dec 24 03:57:33 PST 2003

<quote who="Karsten M. Self">

> Particularly as I may (and do) run applications in a number of different
> security contexts.  The GNOME project appears to have largely forgotten
> to consider either:
>   - Remote X displays, e.g.: X terminals, or "dumb systems" used as
>     such.  Already, GNOME app performance on same is miserable.

Not really, it factors into what we do quite heavily, particularly with
companies like Sun involved, who have an active interest in remote display
technologies (not always X, but it is definitely important to them anyway).
What kind of performance is 'miserable'? Using the default 'Simple' theme,
I'm relatively comfortable using a complete GNOME desktop on 10mbit (my SS10
doesn't do 100mbit).

The upcoming GTK+ 2.4 release fixes some startup roundtrip inefficiencies
too, and there's more fixes like this in the pipeline (thanks to a great doc
from Jim and Keith).

>   - Selected apps displayed remotely whether through xhosts (on a
>     suitably secured and trusted local network) or (far preferable) SSH
>     X11 tunneling.  Just because I trust a remote application to display
>     locally doesn't mean I trust it to all local traffic and data.

Not sure what you're driving at here - local traffic and data associated
with the X display? You're stuck with that. Not sure what else you could

> > > Most cluepackets are generated as things happen in the user
> > > interface, such as you actively typing in an email address, or when
> > > one of your friends sends you an instant message. Lots of raw
> > > context. Dashboard tries to make sense of this by displaying
> WTF is "Dashbord"?

(As linked in the initial mail: http://www.nat.org/dashboard/)

> > Needs Google integration ;).
> More generalized:  needs plugin capabilities, including Web-based queries
> and results.  Google might die tomorrow, or worse:  be bought by
> Microsoft.

Current Dashboard, which is again a prototype, has a plugin system (as noted
in earlier mails too).

> > A big problem would be doing this would be performance. Most desktops
> > seem sluggish on older hardware, 
> I see Mr. Waugh's already failed to comprehend this point so:
> ...or handhelds.  Or wearables.  Or remotely accessed UML partitions on
> a master server.  Or highly contested mainframes.  Or (as previously
> discussed) remotely tunneled X applications, possibly over slow links.

Lots of very different performance concerns there. But they're *different*,
so you can't just whack them all in a paragraph and expect to solve the lot.
For PDAs/embedded, we have GTK+ and GPE. GNOME runs very nicely on big fat
servers and mainframes, because there's lots to share around. Yes, there are
X/display performance issues to be sorted out, but that will happen. We're
not slowing things down without good reason, or because we're stupid, or
because we want to annoy you.

> Mr. Waugh may feel that there's no need for anyone to run systems, say,
> less than 1/4 the speed of currently available new hardware.  Truth is
> that this is severely limiting not only in the special case situations
> mentioned, but for many SMBs, nonprofits, schools, and, frankly, income
> constrained households who can't shell out for new hardware every year
> or two.

Well, as I said earlier, you have choices. It doesn't make sense to run
GNOME on these kinds of machines, so... Use the machines as X terminals or
run XFCE or a simple window manager and some apps. Or run the apps on a
server, or... or... There are many options, and you can see them in use in
Brazil, Spain, Chile, etc., etc. The LTSP-based Telecentros cafes rock.

> My own personal experience is that current GNOME desktops on such systems
> are painfully slow, and will be ever more so over the 3-5 year additional
> life of this equipment.

I found recently that I wasn't enjoying running GNOME with only 256MB RAM at
work. That's a bummer, but we'll deal with it. You seem to be personally
offended by this, and I don't know why.

> Point is that MS Win98/NT4.0 and MS Offic97 play a lot better on hardware
> I'm contemplating migrating than _current_ releases of either GNOME or
> KDE, let alone the wet dream Mr. Waugh's spewed forth on this list.

[ So, I can't figure out why you're so combative, Karsten. Lay off a bit on
the formal addressing and unforgiving approach. This is incredibly rude and
ungrateful behaviour. ]

> Exchange is the ability to access data between applications.  If this is
> something designed specifically to work with GNOME apps, my own interest
> is going to be slight.  Tying it to work with mutt, w3m, and irssi-text
> might be of more use.  Especially if it's the sort of thing I can launch
> as a research tool.  Say:  dboard <foo> where <foo> is some identifier
> string (name, email address, GPG key, etc.).

Current Dashboard (*prototype*) has an incredibly simple interface and bits
of C you can plug into anything. There were patches for irssi and mutt at
one stage.

> > > So, we need to make standard user-oriented data accessible to
> > > everything in the desktop. 
> There are _so_ many reasons why this strikes me (and several other folks
> I've shared this with) as *highly* undesireable.
> Allowing systems to share on an on-demand basis, and making it the
> default, are very different things.

Uh, "providing a standard API for highly useful end-user data" like contacts
and calendaring. Hope that doesn't offend. It sure is bloody useful.

> Frankly if GNOME adopted a "feature" which made such a thing persistantly
> visible on the desktop, I'd run screaming from it faster than I already
> do.

Again, no one knows what the UI would look like. Dashboard is a prototype.

- Jeff

linux.conf.au 2004: Adelaide, Australia         http://lca2004.linux.org.au/
                "What inspired you to become a bus driver?"
                             "Linus Torvalds."

More information about the linux-elitists mailing list