Couple of question on Lively

You guys are doing great work. I have a couple of questions though . Would Lively kernel be able to access the kernel level features on the hardware it is running on?
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Hello Ram -

It's a good question, and here's the way I look at it...

As a start, Lively gives you access to all of HTML which, broadly speaking, includes, graphics, javascript and the web.  So this means that you should be able to do anything that involves accessing data and services on the web, and provide just about any visual interface to view it and control it.  The apps we have done include games, simulations, visualizations of server activity, access to and visualizations of databases, and leveraging such services as language translation, maps and the like.  As far as integrating and leveraging the content and services of the web, Lively would seem to be on an equal footing with any native application, modulo possible performance issues.

So the question that remains is access to local hardware features such as GPS, compass, temperature, battery  level, acceleration, sound input and output, camera, lamps, etc.  I expect to see companion apps that provide local host access to this data for exactly the purpose of enabling systems like Lively to provide the kind of functionality one seeks in native apps.  I'd appreciate hearing from others on this list regarding the current state of such facilities and their likely future.

I always envisioned the Lively Kernel as supporting app stores where you can download Lively apps that will run in any browser, and therefore on any smart phone, without being subject to various manufacturers' whims about how to manage the economics and capabilities of those apps and stores.  We still have a long way to go with Lively, but we do already have apps that run on every major browser and every major web pad and smart phone.  It is a focus of this year's Bachelor project at HPI to push forward in both portability of Lively apps in the mobile sphere and, we also hope, access to hardware features on a par with native apps.

If this does not answer your questions specifically, it should at least give you a point of view from which you can derive your own conclusions.

  - Dan
-----------------
On Nov 25, 2011, at 5:36 PM, Ram wrote:

> You guys are doing great work. I have a couple of questions though . Would Lively kernel be able to access the kernel level features on the hardware it is running on?
> I am guessing no (correct me if I am wrong). If not, then wouldn't it be a huge disadvantage to the type of applications that are being created on it?
>
> I think this question had been asked before but it's been some time. So I'll ask again. What kind of environment do you think Lively will be used in?
> Where do you think the future of Lively lies in?
> _______________________________________________
> lively-kernel mailing list
> [hidden email]
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

On 11/25/11 10:58 PM, Daniel Ingalls wrote:
> Hello Ram -
> [...]
>   It is a focus of this year's Bachelor project at HPI to push forward in both portability of Lively apps in the mobile sphere and, we also hope, access to hardware features on a par with native apps.
>

The same security issue applies to LK's access to the underlying
hardware, applies to the squeak browser plug-in: with great power, comes
great responsibility. The more access to the client's OS that a web-app
has, the more potential there is for malware.

Microsoft raised an important point about WebGL earlier this year: a
web-app could bypass normal browser security and wreak havoc on a user's
system simply by making the proper OpenGL calls to the video card and no
existing security software can check to see if this is being done. The
only symptom is the melting card. Same thing applies to any extra access
given to LK above and beyond the existing browser sandboxes.

lawson

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Regarding accessing hardware level features: It really depends on how you use Lively. In the form in that we currently use it (web-based wiki called webwerkstatt) then the answer is no. However, we have a node.js integration. We are able to create and program node.js servers from inside Lively. This allows us, for example, to access the system shell, see: http://lively-kernel.org/repository/webwerkstatt/demos/CPUVisualization.mov. Depending on how node.js is setup you can nearly access everything. E.g. with its C FFI or the system shell.
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

At Fri, 25 Nov 2011 20:09:13 -0800,
Alan Kay wrote:
>
> Hi,
>
> The Chrome (with NaCl) environment is the first one in a browser that allows all levels of programming to be done and used without explicit downloading of a plugin.
>
> We (Viewpoints) have gotten many things running as tests in the Native Client part of Chrome (including all of Squeak), so this is a great place for doing special things that will enhance
> Lively.

I have been pondering about what these "special things" with NaCl and
Lively might be.  (Yes, this sounds like a mix of technologies looking
for a problem and could be a bad way to find a problem and solution,
but ...)

One obvious thing would be directly enhance the performance by
providing "C-speed (with SSE)" for performance critical computation
(and if NaCl is not enabled, it still runs, just slowly).

Next would be to run legacy code without taxing the server.  This
would Require some work to "port" the legacy code.  NaCl does run in
the browsers security model (unfortunately), so it cannot provide
interface to hardware; as Dan wrote, there still would have to be a
separated app for it.

What I want to do is to make the NaCl environment an "appendage of the
server";  A part of computation on the server is forked off on the client
computer and talk to the local JavaScript environment more closely.
For this to work nicely, however, it'd be nicer if the NaCl process is
"between" the browser and JS, and potentially the process survives
even if you reload the page.  But right now, the NaCl is basically "on
top of" JS, and the state is wiped-out when the page is reloaded  (The
appendage is just chopped off, so to speak.)

One more bit of trick I can think of is to run another JavaScript
environment in NaCl; the upside of this would be to have a completely
separated address space for your program.  Lively Kernel currently
seemingly does a good job of not hard-crashing easily even when the
programmer is trying self-rewriting code.  But if such code is
literally isolated in another address space, it would be much safer to
experiment.  (Though most of this safely can be provided by browser
tabs.)

-- Yoshiki
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

At Sun, 27 Nov 2011 11:29:11 +0100,
Roeder, Marko wrote:
  Ah ha, thanks for the info.  If it could be changed to support the
"delayed inheritance" that "Worlds" would do (namely, some disiplined
way to share values; that would require to translate the variable
accesses to some code that asks the values from the master), that
would be perfect.

-- Yoshiki
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel