From janmeijer at gmail.com Sat Jan 10 11:07:52 2009 From: janmeijer at gmail.com (Jan Meijer) Date: Sat, 10 Jan 2009 16:07:52 +0000 Subject: [Ros-talk] hello word In-Reply-To: References: <000001c94e8e$ba9b1ce0$2fd156a0$@com.ar> <002601c94f2f$50ae0990$f20a1cb0$@com.ar> <41d9d9ae0811251153k7485a35ctc3e7db91cb3a8fe8@mail.gmail.com> Message-ID: <41d9d9ae0901100807l166ec911r85c4b30e292bd600@mail.gmail.com> Just summarizing my thoughts, FWIW, probably a good read for ya. I see machine intelligence appear on the horizon and take control of the "OS". The system needs to (begin to) think about what it executes. For now, in the scope of an OS, the correct term is [Machine Smarts]. If the system has access to the code it runs, it can analyze it, do common sense things with it, things we ourselves would if we had access to it and knew our typical (ab)usage patterns. Machine Smarts is nothing too smart, its all about Not Being Really Stupid. Like loading applications in their entirety. And using only a fraction. And solving that problem through DLLs. And then getting into the dependency hell. The OS I envision makes a model of the current OS. The model is never instantiated as a single instance, it is bound into the application code as needed, as they need to interoperate among themselves and with hardware. The OS is created as its services, on demand. Running code lives as fragments of code that are swapped in and out, on the fly, whenever the requirements they attend to change. One example of a change is a change to a source file that affects a running fragment. On committing the source file, the fragment, if running, is deprecated and in time swapped for its replacement. The system obviously keeps running normally. Code is verified and known to be safe before it is run (see the Singularity experiment by Microsoft). The need for sandboxing is very limited and the system may well run as if it were a _single application_. The OS is simply the manager of that application, giving it full access to hardware etc, but modifies its code as needed. The concept of the system as a single running application has big implications. One primary difference is in memory usage. Using lots of memory is OK, but only if it is temporary, to get the job done, now. In this way memory gives the system [Impulse Power]. Current architectures give each application a memory pool and then the application manages that pool. Most (if not all) of them allocate the maximum they may need, rarely they give any memory back. Developers also think memory is cheap. So Impulse Power essentially _vaporizes_: there is no memory left. It was all allocated in areas with low frequency of access. So we continue to see lots of disk involvement at the exact moment we expect to see a response. With machine smarts, the system looks ahead, anticipates our actions. It preloads or compiles code that comes in scope. When the user enables something in Preferences, code fragments are patched to enable this to take effect. When the user hovers a menu Smarts anticipates the click, preloading or compiling any code ahead. Machine Smarts maintains a concept of a hotspot in terms of any possible user-actions and their probability. Developers think of memory as cheap. But with each application thinking of itself and extending both their static and dynamic memory footprints, for both data and code, by design and dynamics, data and code increasingly becomes spreaded out over memory, showing less coherency. Data is becoming more random-access in nature. Processors have a hard time to keep the cache filled. The way applications are made makes memory expensive. They all live in isolation, so they duplicate a _lot_ of functionality, they have the policy of allocating the maximum memory needed and their binary compiled form means they come in a monolithic format. So they are unnecessarily big, spread out in memory, and Smarts is prevented from doing common sense operations, like recognizing shareable code, on it. By contrast both scripting and Smarts have a codebase that can be run effectively from cache. Simply because they don't change with the application. User-code can be like Parrot code: extensible, interpreted, analyzable and managed. Maybe not terribly fast by default, but with much hotter code areas, meaning better cache performance. We need to get higher up in our abstractions to enable Smarts. Applications need to be structured to allow management. In the end the machine is the machine, the user is the user. The system decides what is to become binary and how, based on demand and system capabilities. The OS of the future is Not An OS. NAOS lives as the definition of a hotspot in chaos. It creates a [codespot] for the [codepod] and transforms it based on the user interaction. Almost a life-form. * NAOS can run remotely, and use a "codepod" to service the user. It has Mobile written all over it. * Simplicity in design and scripted from the bottom up. * De-C. Write low-level stuff in D (if needed at all) so the machine can actually cee and understand. * Parrot is close to potentializing the NAOS, being a codepod. It means readable 'binary' code. * Sandboxing becomes easier: the sandbox is just another codepod. * Singularity (Microsoft) shows the ideas presented here are viable. * At any time the system presents a user-interface of what it is doing, anticipating, speculating. If it delays or traps itself, it can show you why, where and puts you in control of a resolution. * True open source means an end to binary interfaces. With Smarts, you'll only ever see the invariant: the code, the script. I'll step into KDE4 now. It seems they've seen the light. Goodbye ROS Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.full.moon at gmail.com Sat Jan 10 20:58:01 2009 From: william.full.moon at gmail.com (* William) Date: Sun, 11 Jan 2009 12:58:01 +1100 Subject: [Ros-talk] an anthill Message-ID: <9e03c3c60901101758x2da92933u7e7b6a1f0a749467@mail.gmail.com> Hi everyone ... Happy 2009 ... nearing the end of the first decade. I can see quite a bit of merit in this. I've been looking at organisational decision making. By and large the operational outcomes are emergent. So the idea of "Not Being Really Stupid" is a very good way to package things. I don't think I'm interested in and 'artificially intelligent' operating system (shades of "master operating system" from the movie TRON, or VIKI in the "I Robot" film). Deterministic [operating[ systems will always exhibit a centralising tendency to one or more points of convergence. What chaos theory calls 'strange attractors'. "Not Being Really Stupid" would allow more like a 'socially well behaved' plug-in bus. I'm thinking something like and anthill or termite mound here. There are high-level communication protocols and what you might consider "good manners" (as social lubrication). So that by and large parts could be 'trusted' to play-nice with each other in most circumstances. What prevents the anthill scafold from going rogue? After all not everyone wants to create a "Borg mind" (Star Trek). Without preempting some low-level aspects prematurely, one idea is to consider termite mound again and use "pheremones". In a ants nest if you you smell wrong you do not belong. So there is no in-built assimilation of foreign termites. Secondly that pheremone notion protects against things like viriuses. At this point it is wise to rais the issue that a network-operating-system must be integral, the future of computing is networked and unwired and must be trust-first. A third factor for a pheremone-like approach, is that as a metaphore based on a chemical systems, things like concentration, reach (or strength), and proximity can extended to the operating system model. I'm sure there are other anthill aspects that can make sense to an o/s level thing. Before I leave thought there, since we are just at concept stage, there probably needs to be some kind of conversation about what is a operating system's raison d'etre? For me, I want a flexible infrastructure that lets software get in touch with the hardware, wetware, and other~ware. Not more. Higher-level aspects for computer engironments such as the CLI or GUI or some-more-interesting User Interface should be a-top the operating system -- This is the policy behind micro-kernal thinking. Of course the more commercial offerings make that distinction blurry (for their own packaging and marketing oriented needs). As designers, engineeers and thinkers; we need to stick closer to the facts and figures than the hyperreality of product packages. The idea of simple, "Not Being Really Stupid", components can be constructed to consider a metaphore something like a termite mound -- An anthill. To me, this is not a amorphous web, cloud or mesh, its still my "computing environment" which consists of a network of flexibly coupled devices and other pseudo devices as capabilities. The anthill metaphor is a community of technology for me. I don't mind if there is storage and pseduo devices on the cloud, etc. I do mind someone telling me that my devices are controled now my their integrating corporate cloud build on confomity -- Conformity is a tendency in large social organisations because functional organisations share sense-making models. Anthills share the same (ant minded) sense-making models too. I'm looking a things so that YOU and SHE and HIM and me can have our own sense-making model not one from Stanford, Seattle, San Jose, Beijing, or Berlin. Which is where things are headed in the cloud field if you are asking me. Aloha, Will. 2009/1/11 Jan Meijer > Just summarizing my thoughts, FWIW, probably a good read for ya. > > I see machine intelligence appear on the horizon and take control of the > "OS". The system needs to (begin to) think about what it executes. For now, > in the scope of an OS, the correct term is [Machine Smarts]. If the system > has access to the code it runs, it can analyze it, do common sense things > with it, things we ourselves would if we had access to it and knew our > typical (ab)usage patterns. > > Machine Smarts is nothing too smart, its all about Not Being Really Stupid. > Like loading applications in their entirety. And using only a fraction. And > solving that problem through DLLs. And then getting into the dependency > hell. > > The OS I envision makes a model of the current OS. The model is never > instantiated as a single instance, it is bound into the application code as > needed, as they need to interoperate among themselves and with hardware. The > OS is created as its services, on demand. Running code lives as fragments of > code that are swapped in and out, on the fly, whenever the requirements they > attend to change. > > -- aloha, \_w_/ [ask about marketing your technology] -------------- next part -------------- An HTML attachment was scrubbed... URL: From janmeijer at gmail.com Wed Jan 21 12:56:33 2009 From: janmeijer at gmail.com (Jan Meijer) Date: Wed, 21 Jan 2009 17:56:33 +0000 Subject: [Ros-talk] an anthill In-Reply-To: <9e03c3c60901101758x2da92933u7e7b6a1f0a749467@mail.gmail.com> References: <9e03c3c60901101758x2da92933u7e7b6a1f0a749467@mail.gmail.com> Message-ID: <41d9d9ae0901210956t2d82c069y31c715cd09c4183a@mail.gmail.com> Been away, only read it now - not studied. Thanks. I think I may have offended some people coining "Not Being Really Stupid". I offer my apologies. Things make sense at some point in time, but we progress and progression makes it clear what our motives were: preocupations. Which ended up influencing our design in a negative sense. Smart things tend to have this effect, making (us) smart people look bad. The dragon isn't there to be beaten. It is us. We have to live with it. The more transparent the system, the easier it is to stop being burnt by the fire in its mouth. Maybe one day we'll find a partner in it and ride it. Jan On Sun, Jan 11, 2009 at 1:58 AM, * William wrote: > Hi everyone ... > > Happy 2009 ... nearing the end of the first decade. I can see quite a > bit of merit in this. I've been looking at organisational decision making. > By and large the operational outcomes are emergent. So the idea of "Not > Being Really Stupid" is a very good way to package things. > > I don't think I'm interested in and 'artificially intelligent' operating > system (shades of "master operating system" from the movie TRON, or VIKI in > the "I Robot" film). Deterministic [operating[ systems will always exhibit > a centralising tendency to one or more points of convergence. What chaos > theory calls 'strange attractors'. "Not Being Really Stupid" would allow > more like a 'socially well behaved' plug-in bus. > -------------- next part -------------- An HTML attachment was scrubbed... URL: