
Lively Kernel - gull
http://www.lively-kernel.org/
======
planckscnst
And now that I'm past my surprise, I can evaluate. It looks like it's really
not ready for production. There are all kinds of weird issues. For instance,
in the webworkerstatt sandbox[1] (and I was using Chrome as they asked), the
text box rendered far-right more than a page of scrolling was required. Upon
refreshing the page, the text box was where it was supposed to be, but there
was lots of additional empty space (empty content that cause scrollbars to be
present) below and to the right of the application. Also in that app,
positioning the cursor inside the textbox then clicking on the "car" (that
cluster of ovals) causes text to be selected between the two points you just
clicked.

Aside from that, I'm sure this is all controllable in the framework, but there
are _maddening_ design choices. They are intercepting right-clicks. They are
by-default opening links in new windows. Every bit of text is in carat mode.
The loading animation is rather annoying. With all of this, I'm not even going
to look at what it's like to develop in the environment.

[1] [http://lively-
kernel.org/repository/webwerkstatt/sandbox/san...](http://lively-
kernel.org/repository/webwerkstatt/sandbox/sandbox.xhtml)

~~~
boucher
This project has been around an extremely long time (I believe since around
2008). I'm not sure it's even being updated at this point.

------
nickpsecurity
It's pretty interesting how they use SVG to draw it all on-screen to emulate
desktop UI's. That's basically how I did cross-platform in late 90's with
OpenGL as my targets supported it. I also tried Java, which they [1] did too.
That they reused Morphic was clever as most would've tried a vanilla interface
framework. The use of SVG would seem to be both a strength and a weakness.
Strength for reasons they outlined but weakeness in terms of speed and browser
interactions. I saw both problems in the demo, with the latter being text
highlighting when dragging a window.

So, I still push native apps and plugins over web where possible. This one is
clever but I'd like to see some smooth demos. However, the WebGL standard
might be a solution to this as I haven't heard anyone complain about it
lagging on simple 2D operations. Maybe they try that out.

[1]
[http://www.svgopen.org/2008/papers/93-The_Lively_Kernel_Web_...](http://www.svgopen.org/2008/papers/93-The_Lively_Kernel_Web_Application_Framework/)

------
fu86
I've analyzed the codebase a couple of years ago (see [https://aaron-
mueller.de/projekte/lively](https://aaron-mueller.de/projekte/lively) and
[http://data.datenhalter.de/lively_analyse_morph.pdf](http://data.datenhalter.de/lively_analyse_morph.pdf)
in german). It's basically a proof of concept to bring Squeak to the web. It
was a hype back in 2007 because Dan Ingalls pushed this as a research project
by SUN.

The whole codebase is a mess and so damn slow that this is not usable at all
(see [https://aaron-mueller.de/blog/bestof-lively](https://aaron-
mueller.de/blog/bestof-lively)). The architecture however is pretty smart, but
most of it are stolen from Squeak. So the projekt itself is not much more than
a bad port of Squeak in spathetti JavaScript.

~~~
joshmarinacci
This was done a decade ago to prove what was possible with web tech of the
time. Clearly the web of today proves they were right.

~~~
mattbasta
I think you're forgetting how good the web was ten years ago.

------
rmetzler
When I studied at HPI I had a course where we would hack on features for the
Lively Kernel. I'm not sure how far they've come and if they got the
performance problems solved. (Lively used to work at halfway acceptable speeds
in Chrome and Safari only, but I'm not sure if this was because of Webkit or
the JavaScript engine.)

I have to admit, I didn't like it much. I couldn't wrap my brain around why I
should create a live coding environment which would be destroyed on a reload.
Then it is only used as a fancy REPL.

For my day to day programming I prefer regular JavaScript or languages which
compile to JavaScript.

------
planckscnst
The word kernel is so espoused to operating systems for me that seeing the
nature of the project was surprising. In fact, I specifically expected to see
some modified Linux kernel and was wondering if someone made use of some
liveliness-guaranteed locking system of some sort. After the surprise, I
thought about my personal definition of "kernel", and it turns out it's as
outlined below (ones in parentheses would never be expected, but would be
concessions after having been surprised, as I was with this article).

1: Linux Kernel. 2: BSD-derivative kernel. 3: Some other Unix kernel. 4: Some
other OS kernel. ( 5: Maize seeds. 6: Some core part of other software. )

~~~
nickpsecurity
The common usage of the term does make that come to mind. However, kernel just
means the central part of things. The bottom-most layer in computing. Relevant
for your definition, a whole sector of operating systems are microkernel-
based: almost everything in Linux/BSD are merely user-mode processes for such
systems, running on a tiny kernel.

~~~
vezzy-fnord
For instance, the basic runtime management modules that the Erlang VM starts
as its first application is also called the kernel:
[http://erlang.org/doc/man/kernel_app.html](http://erlang.org/doc/man/kernel_app.html)

(Erlang can be described as a special-purpose OS in many ways, so it makes
sense.)

~~~
nickpsecurity
Yes. They say the same about browsers, too, which is why secure browsers have
a "kernel" that mediates everything. Additionally, in High-Performance
Computing, the highly-optimized routines that do much of the work are often
called kernels. It's a very overloaded term.

