[linux-elitists] Can we woo you first? [Was: How MS could woo me]
Karsten M. Self
Wed Dec 24 05:50:47 PST 2003
on Wed, Dec 24, 2003 at 10:57:33PM +1100, Jeff Waugh (email@example.com) wrote:
> <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'?
Application only. No GNOME desktop here.
Galeon tab management, Galeon 1.2.5, specifically. Upwards of 10-20
seconds to open, move, or close tabs.
Nick Moffitt's also groused about remote display sluggishness generally,
though I'm not sure what applications he's specifically referring to.
He might have specifics to add.
> 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).
Good to hear.
> > - 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
Local == LAN traffic at 100 MBps hubbed.
Tunneled == LAN or remote traffic, at speeds varying from LAN to modem.
With additional latency imposed by ssh encryption and/or compression
(latter disabled for LAN traffic).
> > > > 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/)
Saw that, actually, in context with prior post.
More a general rant that people shouldn't assume that software currently
in nascent vapor stage and with less than six months' life is generally
known. I've found entire O'Reilly books that make this error. One
advertised itself as "The only book on <foo> you'll need". Given I
couldn't figure out (from title, contents, index, intro, or first
chapter) what <foo> was, I assumed that the set of books I needed on foo
was, in fact, empty.
> > > 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.
The point I'm making, and possibly one that's a carry-over from the days
of E as default window manager, is that performance of GNU/Linux GUIs
has frequently been very poor, particularly in the cutting-edge stuff
(older desktops/apps often _do_ perform well, witness twm or icewm). As
my legacy MS Windows comments indicate, I've a grudging admiration for
the amount of GUI performance Microsoft managed to squeeze out of
386/486s. Though X11 displays of the same era were reasonably
lightweight as well. And compared to contemporary displays, decorations
and capabilities were highly limited.
> > 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, non-profits, 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.
LTSP isn't running X remotely....
> > 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.
I run WindowMaker with 512.
It's, in general, the assumption that your program is all I'm running on
my system, and/or there's only one user on the system, and/or that the
user is local, and/or that the system is a PC. Some systems do need
highly customized apps (e.g.: handhelds with limited display and
distinctive inputs). Others don't -- they're just slow and memory
limited (old, slow, school computers). At the same time, it's the
locations where resource limitations are most likely to benefit from the
integration of GNOME.
While hardware pricing and Moore's law tends to win in the long run, in
the short, and in edge cases, there's a lot of flagrant extravagance.
That said, I've been looking at XFCE the past few days, it might be a
good alternate. Mostly looking at pulling in all the right pieces, as
it doesn't have menus by default.
> > 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
That's the line out of Microsoft.
My point stands. Depending on the scriptability of this, and the
trustedness of scripts run, there are any number of possible exploits,
ranging from desktop hijacking to data extraction. These _aren't_
> [ 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. ]
Odd you should mention.
You earned it the last time. If you want to un-earn the response,
you'll have to behave yourself for a while, take counsel, and generally
behave like something _other_ than the arrogant snot you were in
October. Just letting you know you left an impression.
Karsten M. Self <firstname.lastname@example.org> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Backgrounder on the Caldera/SCO vs. IBM and Linux dispute.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031224/91ae862c/attachment.pgp
More information about the linux-elitists