Re: ANN: Lua OS 0.4

[David Hollander <dhllndr@...>]

I just visited luaos.net and wanted to inquire about Java being listed
as a dependency. Is the Java userspace app being used to temporarily
bootstrap your project, serving as a laboratory, or as part of the
long term infrastructure?

Is the eventual goal of a "Lua OS" to use Lua to write operating
system facilities for managing processes and daemons written in
language X,
or to write a program in language X for managing processes and daemons
written in Lua?

The advantages to writing an OS in Lua would primarily be security and
agility. By security I mean moving as much OS string handling as
possible from the "raw blocks of RAM" char * approach to Lua strings.
String handling is simply done correctly once in the Lua
implementation, there is no debate over 'sprintf' etc. appearing in
the OS code base. By agility I mean fewer lines of code, no
(infrequent) recompiling of the OS, quicker refactoring, and increased
customization. A secondary advantage would be to provide a convenient
development environment for programming in Lua. UNIX at its core is a
development and runtime environment for C programs.

One gradual, evolutionary approach for generating a Lua OS would be to
start it as a fork of a minimal Linux distro, such as Arch Linux[1],
with the Lua windowing manager Awesome[2]. This way you immediately
start with a modern, working desktop configurable with Lua, that can
be distributed to as many Lua developers as possible. Then, with this
distribution under source control, users\developers start gradually
cannablizing C infrastructure, replacing it with Lua or calls to the
LuaJIT ffi. This process would eventually go down to the Kernel.
Important "glue" would be replaced, but everything deemed low priority
would be left as-is, such as hardware drivers. Perhaps you would end
up with something analagous to PUC-Rio Lua, a small core for pushing
new Lua (OS) states and pushing\popping (hardware) calls.

Another approach would be to go completely bottom up from the hardware
level, but I'd predict one would have a very hard time recruiting
driver developers\testers to ensure portability, unless the project
already had value to offer. A chicken-and-egg scenario.

Just throwing out some ideas. An "operating system" is necessarily
very broad in scope. I'm not sure if the three benefits I could think
of a "Lua operating system" providing (security, agility, development
environment) intersect with your thoughts on the subject.

-David Hollander

[1] https://wiki.archlinux.org/index.php/Arch_Linux
[2] http://awesome.naquadah.org/



On Wed, Aug 17, 2011 at 2:01 AM, Gregory Bonik <gregory@bonik.org> wrote:
> Hi Stefan,
>
> As far as I can understand from your reference manual, all sandboxes in
> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with
> different "powers" inside one VM? I guess you set a separate environment
> for each thread, but anyway.
>
> Second, I've read in the manual that it's possible to set a timeout for
> a sandbox. This is really necessary, but shutting down the process which
> exceeded the timeout doesn't seem a good idea to me. I guess you limit
> the number of instructions via the debug hook. So is it possible to call
> lua_yeild from the debug hook instead of terminating the sandbox? This
> could be compared to the timer interrupt. In future, this could provide
> a way to implement sort of preemptive multithreading. Yes, things get
> complicated here since you'll need to implement a scheduler.
>
> -- Gregory
>
>
>
>