← Back to team overview

wintermute-psych team mailing list archive

Re: Appliance Computing and Brittleness.

 

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. If we do that, we _might_ be able to have Wintermute work 
with Fedora. 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.

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

> 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

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

Attachment: signature.asc
Description: This is a digitally signed message part.


Follow ups

References