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

Karsten M. Self kmself@ix.netcom.com
Wed Dec 24 03:34:23 PST 2003

on Wed, Dec 24, 2003 at 12:56:34AM -0800, Aaron Lehmann (aaronl@vitelus.com) wrote:
> On Wed, Dec 24, 2003 at 04:42:41PM +1100, Jeff Waugh wrote:
> > Okay, so, throw a desktop-wide message bus into the mix (D-BUS,
> > which is being taken very seriously by freedesktop.org contributors
> > and the kernel community),
> I hope you weren't implying that it would have kernelside support,
> because that would be a bad idea.

Agreed, if there's any sort of high-level design going into it.  If
we're just talking interprocess communication, of which any of several
designs could be imposed, no problem.

> > and you get a stream of context that any application can listen and
> > contribute to. No more dashboard-specific cluepacket patches,
> > everyone's on the same bus.
> Sounds like a cool proposition but I think the security implications
> should be discussed. I know that X gives free access to the display to
> a lot of applications, but this is one of the things I dislike about
> X. I think any "desktop" being designed now has the potential to
> outlast X or at least its current security mechanism, thus it should
> preemptively allow for sandboxed applications without access to the
> metadata stream. Just a thought.

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.

  - 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.

> > 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"?

> > cut-down, relevant portions of the information - a photo of the
> > person contacting you, their latest emails sent to you, a few blog
> > headlines, a few contact details like their phone number and email
> > address, appointments with them in your calendar, etc.
> Needs Google integration ;).

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

> 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.

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.

Case in point:  the local school district currently runs systems of
Pentium-1 class or better, and has a warehouse of systems going back to
Apple ][.  This is a reasonably affluent northern California county.
Donated equipment is requested to be PII or better, 128 MiB RAM or
better.  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.

It shouldn't need pointing out, but there are classes of free software,
particularly desktop software, which painfully *don't* play well with
anything other than current higher-end hardware.  Desktop environments,
office suite software, and browsers are among the worse offenders.  This
*really* needs addressing.  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.

> > Most of these, in turn, are hyperlinks. So if your friend messages
> > you, "Oi, you didn't reply to my email!" there's a link to it
> > sitting in your dashboard right there, ready to go. ;-) But none of
> > this works well if you don't have searchable access to useful
> > information for dashboard to contextualise.
> Unfortunately, this kind of thing sounds like it could get much more
> annoying than Clippy very quickly. Every time your boss IM's you, you
> might have a picture of his ugly face pop up. 

Show some imagination, Aaron:  How about the boudoir shot of the
wife/hubby/SO showing up at work.  Or exGF in front of GF2?  Or worse:
SO's hitherto unknown paramour....

I'm sure spammers will figure a way to abuse this within about 15
seconds of release as well.

There are all sorts of ways automated data retrieval/display systems can
go wrong.

Mind:  a tool to rapidly research an individual would be somewhat neat.

The other complications that come into any system are:

  - Identity.
  - Change.
  - Exchange.

I'm drawing from my own experience with large- (and small-) scale
demographic data here.

Identity is simply the problem of determining that a data object has an
association with some entity foo (an individual, in this case).  You'd
need to tag every object associated with that entity uniquely.  And
while unique tags aren't hard to come up with (a sufficiently large
random, or any serial, value works), drawing associations between object
A and B, and entity foo, is the hard part.  You end up relying on
arbitrary tokens:  name, email address, or if you're lucky, something
solid like a GPG fingerprint.

Change is the problem of keeping information current.  To the extent
that Dashboard provides an aggregated index of content from some user,
it actually solves this problem.  However, for other information, there
remains the issue of keeping it up-to-date.  Otherwise, you're just
creating a large, poorly maintained data morass.

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.).

> I think that to turn this system into something worthwhile, you would
> need a very good metric for deciding what should be shown. The only
> way I can really imagine it not frustrating me is with artificial
> intelligence. A very good bayesian filter that learns from
> contextualized user choices might come close, but don't ask me how to
> do that efficiently.

ObIrony:  The MSFT paperclip *did* use Bayesian selectors, initially, to
set the pop-up occurance.  However, goes the legend, marketing types
felt that it wasn't showing up frequently enough and overrode the
Bayesian algorithms.  My own response is immediate, negative, and
violent.  When I'm parked on a legacy MS Windows system (thankfully rare
the past few years), my first task is to figure out how to neuter the
damned thing.

> > 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.

> > Having the source, relatively co-ordinated desktop projects, and so
> > on, can really make a huge difference for us. The ground work is
> > already done, we're already competitive: "... and then you win."
> On the first read I found the Dashboard idea quite attractive; now I'm
> not so sure. The big problem will be filtering results effectively.
> Besides, when I envision what the UI would look like, I always see the
> dialog in http://www.luc.edu/infotech/document/xp/images/xpdesk-search.gif
> in my mind for some reason (I think that's just my brain's way of
> telling me that this is going to be implemented as some big stylized
> multimedia extravaganza that's distracting rather than a tiny window
> with url's scrolling by).

My own pref:  an invokable tool, whether GUI or text-based, which could
be launched on demand, rather than by default.  I'm insanely jealous of
real estate, and highly annoyed by extraneous animation, decorations, or
displays.  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.


Karsten M. Self <kmself@ix.netcom.com>        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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031224/6c50e5ed/attachment.pgp 

More information about the linux-elitists mailing list