Re: ANN: Lua OS 0.4

[Stefan Reich <stefan.reich.maker.of.eye@...>]

Yeah, good question.. why would a Lua OS need a Java part? Here's what
the Java app currently does:

-launches lua.exe with appropriate options and shows its output in a window
-connects to the Lua process via socket
-displays a GUI for the Lua OS task manager (the backend of which is
of course written in Lua)
-functions as a GUI server for Lua OS processes (this will probably be
demonstrated in Lua OS 0.5)

I wasn't too happy with all the Lua GUI toolkit bindings I tried (too
complicated to learn, too strange, too buggy...), so I went for a
trusted platform which is Java (Swing). It really works fine, I think
I'll be showing some actual GUI apps soon.

Whether Java will remain in the long-term instrastructure is an open
question. People could decide to use the Lua+Java combo - or write a
frontend in another language.

> 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 goal is to have processes and daemons written in Lua. I don't plan
on including support for apps written in any other languages in the
OS. This could definitely be added later, but then you might lose the
advantages of a Lua OS which depend on all code being in Lua. It's an
open question anyway.

I think JavaOS and JOS were supposed to run Java code only, too...

> 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].

Yeah, we're basically doing that. I don't want to write a kernel, so
we use a standard Linux kernel (or even WIndows). On top of that we
put the Lua interpreter and some GUI (e.g. Java).

What Linux distro is used is up to anyone's preference. I have chosen
Ubuntu for now because it was the only distro that worked properly for
me in VirtualBox =)

Stefan

On Wed, Aug 17, 2011 at 10:05 PM, David Hollander <dhllndr@gmail.com> wrote:
> 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
>>
>>
>>
>>
>
>