← Back to team overview

wintermute-psych team mailing list archive

Re: Appliance Computing and Brittleness.


On 5 September 2011 05:49, Jacky Alcine <jackyalcine@xxxxxxxxx> wrote:

> On Monday, 13 June, 2011 03:13:41 PM you wrote:
> > I forsee an issue on the horizon, and lo, it is brittleness.
> >
> > Any AI system is 'brittle'; it only works well within the confines of a
> > specific environment. Throw it something it was not designed to handle,
> > and it'll act oddly. The textbook case being that of giving a medical
> > diagnostic system the details of a broken car; for a leaking fuel tank,
> > it'll diagnose tuberculosis. You see?
> >
> > Wintermute's environment will encompass the user's digital life.
> > Websites, media, phones, laptops, netbooks, wired/wireless networks,
> > pictures, music, movies, documents, etc etc etc. It must be equipped to
> > handle all of these files. It must also be equipped to handle the
> > information about these files and be able to make sense of commands
> > related to these files and the rest of it's environment.
> Thus, the designing of a whole desktop environment, before even fully
> considering an OS, should be explored. I think we should seriously start
> designing and ruminating how the desktop environment should be before we
> head into the OS.

Whilst I've been bed-ridden, I've thought of nothing else.
I've been thinking; what is a good metaphor for explaining what it's like to
work with Wintermute? The answer is something akin to having someone else
use your computer whilst you give them instructions. You don't need the
buttons, panels, titlebars, indicators and menus then, do you? The other
person needs to worry about those.

But in this case, the other person is a computer, who does not need these
projected onto a screen; they can access them without having them projected.
The very concept of a GUI becomes rather lopsided; it's only goal, in this
metaphor, is to provide feedback to the instructor; not interactive
functions for the user.
Perhaps we can tie KDE's Plasma system with window management? Remove
everything not pertaining to visual feedback and slot in parts where
Wintermute would give feedback, and there we go.

Even the file-management system may well have to be changed (I just got to
that bit in the Parables, btw) to something Wintermute can deal with in a
way more akin to the user:
A document can, nowadays, be an odt file, a pdf file, a picture, an
audiobook...Wintermute needs to recognize them all as the same file; and the
standard file mangment metaphor does not do that; Dolphin with it's NEPOMUK
tagging function is halfway there...

As I said, substational modification...and everything has to go smoothly...

> If we do that, we _might_ be able to have Wintermute work
> with Fedora.

Fedora? Red Hat's testing ground? Known for bleeding edge tech which is
F/OSS only, and .rpm based? What's wrong with Ubuntu Base?

> It'd be Fedora with Wintermute, or Suse with Wintermute. Since
> Wintermute would be internally modular, how it works on each operating
> system would be equal. When we build our own distribution, however, the
> system, down to the file formatting would be optimized for Wintermute
> (ext4,
> Apt-based, Kwin, modded Dolphin, support for MP3s, etc).
> >
> > The only real, practical way to do that, is to follow a methodology
> > called 'Appliance Computing'. Right now, a computer holds a special
> > place in most folk's minds; it's a magic box which goes wrong sometimes
> > (in essence). Nevermind the numerous tools it has, nevermind the fact
> > that it is truly a tool of multiple uses. It is complicated, and
> > Wintermute must make sense of this complication in order to operate. It
> > must be fully integrated with a web browser. It must be kept aware of
> > downloads and uploads, it must be kept aware at all times.
> Hmm. (Of course) this sounds a bit tricky. We'd need to embed Wintermute
> into the program itself, but there's the danger of breaking platform
> capability when we do that (ie: losing critical updates from the original
> software). This is pretty complex of an idea.

Alternately; I like to think of it as 'Companion Computing' for the example
outlined above.
Applications would have to be completely integrated with the system in order
to work properly. By design, we can't allow the user to download any
application and let them think it'll work with Wintermute, everything will
have to be vetted by us and modified to suit. Hopefully we can work with
upstream to include this.

> > This will mean we will have to lock down certain aspects of the OS; a web
> > browser will have to be fully integrated into the system for Wintermute
> > to function; this means from a development standpoint, we must get rid
> > of the 'pick and choose' ability of programs. A full Wintermute system
> > could not have web-browser XYZ on it, for instance, unless we could
> > ensure we had good enough integration for it.
> We could just drop the idea of a web browser and use a web page viewer (ie:
> WebKitEngine) instead. Boom. No hassle, lol.

I'd like to, but there are certain functions many like; like an ad-blocker,
for instance.

> > To see the result of spreading our development so thinly,
> > you simply need to think in terms of quantity vs. quality.
> > We can either do a very good job, ensure the
> > user experience is stable, safe and fully intergrated, or we can spend
> > our time trying to make sure every program under the sun can be operated
> > by Wintermute.
> >
> > This does remove 'choice', I admit, but I see no other way to ensure
> > Wintermute can do the job.
> >
> > -Dante

I stick to my words; we can give the user choice, and make Wintermute crap
because we can't keep up with the workload, or limit choice until we can vet
and patch enough applications until choice is no longer threatened.

> --
> Jacky Alcine <http://www.jackyalcine.co.cc>