Re: ANN: Lua OS 0.4

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

Uhm... are you kidding or something?

Copas is a dispatcher for TCP servers.

Lua OS is a system for sandboxes (which Copas has no notion of) with
fine-grained security control (which Copas has no notion of), a GUI
(which Copas has no notion of) and, among other things, a
hibernation/code mobility concept.

Not saying that Copas is a bad thing - it's great -, but it has a
completely different focus, and it has nothing to do with the
sandboxes that are the crucial concept in Lua OS.

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