Re: ANN: Lua OS 0.4

[David Hollander <dhllndr@...>]

This plan sounds like COPAS so far, not sure if I would call an event
loop for one concurrency method for one programming language an OS.
What are the advantages to scheduling runtime for Lua scripts inside
of a single Lua process with the additional overhead of coroutines,
versus just launching multiple Lua processes normally and letting the
OS schedule them? This sounds like a bit of an abstract and slower
workaround for the lack of a Lua daemon module, perhaps the one from
Python could be ported.

On 8/18/11, Stefan Reich <stefan.reich.maker.of.eye@googlemail.com> wrote:
> 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
>>>
>>>
>>>
>>>
>>
>>
>
>