From: Benny <linux@...>
Date: 2004-03-04T05:49:43+09:00
Subject: Re: [ANN] Rubyx OS (Ruby oriented linux distro)

Phil Tomson wrote:

> Why not go ahead with that idea?  Couldn't you use the rubyx script to
> just as easily build a FreeBSD system (might need some modifications of
> course, but you could probably save a lot of the work that would be
> required to do it from scratch).  I like this idea because, as you say,
> portupgrade is already in ruby (and I like the BSD ports system).  It
> would be really cool if the rubyx script could completely build a *nix
> OS/system including your choice of kernal (be it Linux, or *BSD (even
> including Darwin)).  That would be the ultimate in flexibility.
> 
> question: could the ruby-based init system be used with *BSD as well?
> 

why not? as I far as I know FreeBSD 5.x switched to the NetBSD init-system
which is more flexible than the old one and more similar to the linux one.
but I'm currently not so deep in the knowledge of init-systems (using 4.9
at the moment).

indeed my idea was to make the base to a layer between an underlying
rock-solid system (like FreeBSD) and the applications for the user.
this layer would represent all needed aspects of the system in an
object-orientated manner. finally a windowmanager (maybe windowmaker-based)
could attach all the via ruby accessed programs and data (hardware-access,
user-data such as addresses, clients and services (such as mail, nfs, smb
etc.)) to templates which would result in a customized user-interface (i.e.
the template defines the dependancies and pipes between the used modules
and the manner in which the selectboxes, the main data etc. are shown in
what to the user appears as "application"). this templates could be in YAML
as well so that it would be very easy to make your own application by
grouping and attaching the different services to each other and defining
the places on which they are shown to the user. this template would be
interpreted by the enhanced ruby based windowmanager.

this way one could concentrate to develop ruby modules which generates new
functionality and this functionality could be combined in numerous
userdefined interfaces the user finds useful for his daily work.

I'm not sure if I managed to get you an idea about what I meant (the text is
perhaps too short and my english too bad). 

such a system might as well allow to automatically create qualified
bugreports (with the system configuration and a "history" of user-actions
on a thread) and a virtual file-system. 

and the tricks needed for a user-friendly FreeBSD (without the configuration
hassle, e.g. setting up a printing system, let the cd-burner be used by a
normal user) with preconfigured often needed functionality could be done in
the ruby-layer. 

so you would have:

- the FreeBSD based underlying sstem

- the ruby-layer on top of it

- already known apps (from the ports system) on top of the FreeBSD with ruby
managed configuration

- and user-customized sets (interfaces) of functionality given by the
ruby-layer

this way one could concentrate on the ruby layer which only has to be
customized to the system changes as new FreeBSD versions appear. in fact
the ruby-layer itself could be a port of FreeBSD (like instant-desktop and
FreeSBIE)

the only thing holding me back from realizing such a project is actual a
lack of time and programming skills :) 
but I would like to contribute my ideas and start it if anybody goes with
me :)

>>what about changing all the sys-config-files to YAML-format? any plans to
>>replace the bash with a ruby-command-shell?
> 
> Is there a ruby-command-shell or are you proposing irb be used?
> 

no, irb is for testing ruby only. my idea was a system-shell with a
bash-like mode (so that you could simply use the commands like before) and
a new mode which has to defined but should result in a consistent a clear
syntax (understandable as well) for all commands - maybe object-orientated
(referring to the objects given by the ruby-layer). implizit expanding of
methods (object-orientated) or options of functions (not object-orientated)
as well. but I'm at the moment not clear how the syntax should definitely
be.


> Phil

benny