wintermute-psych team mailing list archive

[SII <dante.ashton@xxxxxxxxxx>]

On 13 September 2011 11:22, Jacky Alcine <jackyalcine@xxxxxxxxx> wrote:

> This is an email I woke up to and read with joy.
>

Sarcasm, much? :P


>
>
> On Sep 11, 2011, at 8:56 PM, SII <dante.ashton@xxxxxxxxxx> wrote:
>
>
>
> On 5 September 2011 05:37, Jacky Alcine < <jackyalcine@xxxxxxxxx>
> jackyalcine@xxxxxxxxx> wrote:
>
>> On Tuesday, 10 May, 2011 05:12:58 PM you wrote:
>> > Hello Jacky
>> >
>> > Two things;
>> >
>> > First, remember how we were looking into encrypted files a while ago? I
>> > found a program in Ubuntu called the GNU Privacy Assistant. It'll let us
>> > encrypt and decrypt files, so if there is anything we need to protect
>> > whilst sending to each other, it'd be handy...
>>
>> Yup, but KDE has KGpg and my keys show up in it. Dolphin supports the
>> decryption and encryption via a service, pretty nifty.
>>
>
> Oooh, the context menu, you mean? Last time I checked, KGpg was being
> obselted and replaced with Kleopatra, which...isn't quite ready for
> prime-time yet (one of KDE's downfalls is pushing out new tech before it's
> ready)
>
>
> So it won't be available until KDE 4.7? Shucks.
>

Oh, it's avaible now. It just won't be 'stable' until KDE 5.2, probably :P
KDE's developmental style is "make something with as many features as
possible, then take (literally) years to stablize those features, if ever."

Right now, Kleopatra can import keys, but looses them and, in the case of a
few key methods, corrupts them.



>
>
>
>>
>> >
>> > Secondly; I had an idea for another function of Wintermute; I call them
>> > 'sub-minds'; smaller, lighter, and less resource hogging then
>> Wintermute.
>> > It's like a mini-me Wintermute could construct and equip for a number of
>> > purposes;
>>
>> Now, when I think of a sub-mind, in terms of implementation, I think of
>> the
>> BackTrack OS. Yes, that network penetration system. It's because the
>> system's not designed to be installed anywhere. That's one plus, except
>> that we'd like sub-minds to be able to physically carry information back
>> to
>> Wintermute, no? Also, the system has a pre-configured purpose, to
>> accomplish
>> Z by doing A, B, C and D.
>>
>
> I think of it as a way to get Wintermute into places the system, as a
> whole, cannot go.
>
>
> Okay. Now this is something I was personally afraid from a development
> point of view. If this is the case, I have to be on the team's P&Q to make
> sure the code can be compiled and run anywhere. Grr, meeting ABI is like
> obeying traffic laws when crossing the street.
>
>
>
>>
>> We'd need to create some sort of interfacing capability for Wintermute so
>> it can detect whether or not if it created this sub-mind (easily done with
>> a list of the drive UUIDs). It could further link foreign sub-minds to
>> other Wintermutes that it knows. Case examples:
>>
>> 1) "The inserted sub-mind is from the Wintermute Developers team, an
>> trusted source. This sub-mind provides critical system upgrades, including
>> security, semantic and linguistics updates to Wintermute."
>>
>
> Ooh! Good idea! Not everyone has a constant internet connection...
>
>
> Thanks :D I'll add this into the specification for Subminds.
>
>
>
>>
>> 2) "The inserted sub-mind is from your friend, Karen, who wishes to import
>> modifications to my appearance. Do you want to see a video she attached?
>> It's about 2 and a half minutes long."
>>
>
> Maybe overkill here; I'm thinking Subminds operate as a sort
> of miniature Wintermute; not as a package delivery mechanism. Although, this
> does make me think that a sub-mind, on a memory stick, designed to encrypt,
> contain and decrypt confidential data (and wipe it if
> decryption parameters are not met; remember we could throw in biometrics
> here.) could be very useful if physical transportation was the only way...
>
>
>
> Well, the submind could do whatever the original crafted wanted it to do.
> Even better, I think it'd be possible to use natural language as the
> scripting for the submind and literally compile it into binary code, but
> that's a future concept.
>
>
>> 3) "The inserted sub-mind is from an unknown source. It's requesting
>> permission to transfer all of your information to a remote source. Grant
>> authorization to this device?"
>>
>
> Again, maybe overkill; perhaps think of it like this way; Wintermute is a
> country, the sub-minds can act as it's diplomats, construction workers, etc.
> Or, another metaphor; Wintermute is an octopus (shudder) and the sub-minds
> are it's tentecles (double-shudder: I have a rabid fear of octopi and
> squid!)
>
>
> Hmm, okay then. At the same time, this could be how new connections are
> formed between Wintermutes, but meh okay.
>
>
>> Device authorization could be a whole another aspect of Wintermute's means
>> of communication. If we consider sub-minds as members of an AngelNet, then
>> the trust system could be exploited there to provide even more security
>> and
>> configuration for sub-mind devices. Sub-minds, of course, could be even
>> mounted from ISOs (since ISOs can be mounted as a CD/DVD) and such a
>> set-up
>> could be for ... God knows what?
>>
>
> If I know; does that make me God? Sub-minds could be classed as
> second-class citizens of the AngelNet; perhaps you might have a sub-mind
> monitoring a remote backup device. Again, through the AngelNet, a sub-mind
> could provide control of a non-Wintermute machine to a Wintermute one; or as
> a low-resource relay program.
>
> Very interesting. I was considering the ontology contain the partial
> definition of  the AngelNet's hierarchy but now it's inevitable. With a
> class structure, things get interesting.
>
>
> As for ISO's...some subminds, like the encryption example mentioned above;
> can be used in this manner. Installation of a full Wintermute instance would
> also be sub-mind based.
>
> So a submind would manage thr installation of Wintermute? Okay,
> interesting.
>
>
>
>>
>> One thing about the sub-mind system; it'd have to run off a set of pre-
>> configured commands.
>
>
> In terms of command and control; AIML would be suitable here (my god, I've
> actually found a use for that damn language!)
>
> Oh, oh. So AIML works both ways? Lol that went over my head, but yes, this
> seems like a probable use.
>
>
>
>> What better to manage such a process than daemons. A
>> daemon instance of Wintermute would only provide the raw minimum of
>> Wintermute's abilities (this of which is currently linguistics parsing,
>> ontology parsing and (if network capable) AngelNet connectivity).
>> Currently, this pulls in about this many dependencies:
>>  Depends: libboost-program-options1.42.0
>>  Depends: libboost-python1.42.0
>>  Depends: libboost-signals1.42.0
>>  Depends: libboost-system1.42.0
>>  Depends: libc6
>>  Depends: libgcc1
>>  Depends: libncurses5
>>  Depends: libpython2.7
>>  Depends: libqt4-dbus
>>  Depends: libqt4-network
>>  Depends: libqt4-xml
>>  Depends: libqtcore4
>>  Depends: libqtgui4
>>  Depends: libsoprano4
>>  Depends: libstdc++6
>>  Depends: libwntrdata
>>  Depends: libwntrling
>>  Depends: libwntrntwk
>>
>> The total size of the packages come up to at least 45 MB (and that's just
>> guessing), so the minimal sub-mind system would be around 50 MB to 70 MB
>> just for introducing itself.
>
>
> If we had basic sub-minds, like the installation sub-mind, written with
> AIML, that would drop to the amount of simple .txt we gave it.
> The trouble there, though, is that isn't very technologically
> ground-breaking. Hmm. Well, altering it so Wintermute could alter it would
> provide some challenge...
>
>
> The size shown above is more or less constant, those are like the program's
> needed parts. I wonder if there's a useful AIML engine..
>
> We could have a introductory sub-mind on first
>> install that could be easily deleted for users to learn how to get
>> accustomed to Wintermute.
>>
>
> Or that role could be performed by the installation submind.
>
>>
>> >
>> > First off; think of a diagnostic submind; a smaller version of itself,
>> > designed to go in via USB keys into a system to diagnose and (hopefully)
>> > repair the system, somewhat automagically. With limited speech
>> > recognition and nothing in the way of an ontology,
>>
>> The above list doesn't even include speech synthesis and recognition
>> sizes,
>> that would have it skyrocket with 200 MB+, still under 400 MB, but it's
>> pretty chunky.
>
>
> I'd like to point out that would be: very small for a system, we'd be
> looking at a gigabyte or so for good speech recognition per language/accent;
> unless there is some insanely clever compression mechanism I haven't heard
> of? (Which, I admit, is quite probable; I'm only a demi-god, after all :P)
>
> Hmm, it's still early to tell but the size alone may be 750 Mb before
> compression.
>
>
>
>> One thing about Wintermute, the ontology it contains, I'm
>> predicting would be about 8 - 15 MB at minimum with all of the knowledge
>> it
>> needs to present itself
>
>
> Bit optimistic?
>
> Not too much, the ontology is written in text and I don't see Wintermute's
> defining ontology getting bigger than COSMO, which has over 170,000 lines of
> text. The most I really expect is around 21, 22 MB.
>
>
>
>> , like a fresh install. Speech recognition would be
>> optimal and of the same quality of a desktop install, unless we really
>> would need to bring down the size. We should have Wintermute spawn sub-
>> minds that use the same voice as its parent, just to make this more
>> naturally efficient.
>
>
> Now your thinking with robo-psychology! I've been thinking about this
> point; we discussed, earlier, that Wintemute would be the same; giving the
> impression it was one entity. We definitely need a way
> to distinguish sub-minds from full instances, but I'm not sure voice is the
> way for that.
>
>
> Voice is a defining feature, though.
>
> A level of proficiency should be shown to the user (from
>> weak to strong) in terms of its speech abilities before production, as to
>> give them a choice (a F/LOSS ideal!)
>>
>
> What do you mean, exactly? How capable it is of talking? If it's a dimwit
> or might as well be a full install?
> Hmm. Maybe, but the system should be able to override that setting should
> space be too tight.
>
> Yeah and yes, it should do that or warn the user unless they're confidient
> that Wintermute would be provided more space.
>
> I've been thinking that one of the ways we could distinguish sub-minds
> would be to make them...brunt; a little less conversationalist. A lot less
> likely to wax lyrical; that way, we would encourage the user to be just as
> brunt to them, allowing them to achieve whatever objectives the user wants
> them to do without sucking up resources removing language crud.
>
> Like to treat them in a lower class than a typical Wintermute? That could
> be done easily by making its first impression that way.
>
>
>
>>
>> > it'd simply be be equipped to go into a system, diagnose it, try and
>> repair it if it can,
>> > then return to Wintermute to be subsumed back into it, all information
>> > it collected becoming accessible to Wintermute, as the sub-mind becomes
>> > part of the main program.
>>
>> With the sub-mind setup above, Wintermute should be able to do this with
>> proficiency, and perhaps refine the sub-mind to go back in there. The only
>> thing I see a problem is installing packages onto a Debian system that's
>> on
>> a different partition. Never seen it done before, but a simple wget script
>> could be made (or something more semantically friendly).
>>
>
> Perhaps there'd be no need for that? a text file, perhaps, that both
> systems can interpret? Once the process of subsuming begins, the text file
> is read and the submind is deleted.
>
> Wouldn't the submind be doing the installation?
>
>
>
>>
>> >
>> > Another such use could be that of a general version of Wintermute, for
>> > less powerful machines; designed to go onto a USB stick or old/weak
>> > computer and act independently, or in tandem, with the main Wintermute.
>> > (Particularly for devices like mobile phones/tablets) but without most
>> > of the ontology or certain functions removed.
>>
>> Now, we'd have to see what features would be needed to be removed from
>> Wintermute to achieve this. I'm assuming we can drop all of Boost and just
>> use a configuration file, drop Python support and leave it at that as
>> best.
>> Everything else is needed for linguistics and semantics.
>>
>
> Well, a sub-minds principle design goals should be 'light and fast'. This
> 'lite Winty' submind could, perhaps, temporarily take on other machines
> processing capacity to deal with it's processing.
>
> Easy peasy. Anything it doesn't have, it'll query the AngelNet for it.
>
>
>
>>
>> Do keep in mind, we haven't even begun to implement the evolutionary
>> heuristics for Wintermute.
>>
>
> That's good, because I haven't got nearly a clue as to how to design them;
> though me thinks a lot of trial and error (and appointment of human
> handlers) will have to be involved until the system gets the hang of it;
> that was the case with the other projects I worked with.
>
> Yup, we're in for a long haul.
>
>
>> >
>> > And again, another use could be that of a sub-mind dedicated to a
>> > specific area of knowledge. Let's say Stacy went off to do some research
>> > for her school project on Ancient Egypt, for instance. This submind, on
>> > her USB stick, starts collecting and organizing all the data it can
>> > find, present it to Stacy, (and present it to the larger, more
>> > 'reasoning' main Wintermute installation to ensure it was the proper
>> > data) and perhaps even prepare a small speech for her to read out the
>> > information to her class.
>>
>> I don't have enough information for this scenario. Is the sub-mind on the
>> USB shipped out to school with Stacy, away from the primary Wintermute?
>> Is that where it gets information? Does (or better yet, should) it collect
>> preliminary information from Wintermute about what to look for and how to
>> organize it? I can see the speech being generated by the core Wintermute
>> process in the background and presented when completed, but I guess having
>> it generated at school would be cool too.
>>
>
> This sub-mind is separate with no connection back to it's parent. Perhaps,
> technology permitting, we could get this sub-mind to perform it's own
> search? After all, if we're gonna pack in our own web browser; why not go
> the whole hog and pack in a couple of data-miners, too?
>
> So the submind is a fully functional Wintemute? If that's so, it'd be a
> mere means of implementing a private hierarchy, as opposed to the public one
> broadcasting on the AngelNet.
>
>
>> >
>> > Going even further; imagine Stacy has her own laptop, separate from her
>> > parent's desktop computer. Her machine may have a sub-mind dedicated to
>> > her catered to her interests and age. Considering it's a laptop, it
>> > would also be 'seperate' from the main Wintermute installation on her
>> > parents computer.
>>
>> Okay, now with this info, the sub-mind itself becomes a full-fledged
>> Wintermute, or rather, a sub-mind that's monitored by the desktop
>> Wintermute? Either one could be done, but it wouldn't be a sub-mind in the
>> sense of a sub-mind as described above.
>>
>
> Think of it as another 'lite' Wintermute; though capable of being subsumed
> and not fully equipped to run for long periods alone (IE: no tools to
> download more tools from repo) It could simply be a 'diplomat' on behalf of
> the parent system; helping the kid it's caring for.
>
>
>> >
>> >
>> > What do you think?
>>
>> I think that we're headed to pretty interesting areas of computer science.
>> If only I could freaking get my own system with Internet access, only 3
>> hours a day would be needed! lol
>
>
> Again, I will do what I can, Jacky. Yes, your right; we're heading for new
> ground. We're also heading into the most distinguished and dangerous areas
> of computer science.
>
> Fun, isn't it? :-P
>
>
> It's one of those things that make real life seem so boring, you know?
>