FreeLists / openbeos / [openbeos] Re: status of OpenBeOS

["Tony" <togermano@xxxxxxxxx>]

sex
----- Original Message ----- 
From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Sunday, May 04, 2003 8:50 PM
Subject: [openbeos] Re: status of OpenBeOS


> "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx> wrote:
> > >I would love to have better terminal capabilities, and better posix
> > >support. So that most unix terminal applications work without to
> > > much
> > >adjustements. I really like the *nix way of working in a terminal,
> > > for
> > >some tasks. And for others, i prefer a GUI. linux/bsd, etc, do very
> > > well
> > >on the terminal part, but the GUI is really not perfect. BeOS did
> > > very
> > >well on the GUI, but the terminal part needs some improvement. I
> > > just
> > >want the best from both worlds: Good GUI, a decent unix in the
> > > terminal ...
> > R5 has nearly everything that most Unixes have, in terms of terminal.
> > The two biggest lacks are sockets == file descriptor and mmap. We are
> > addressing both of those. If there is more missing that I am not
> > aware of, would you
> > email me offlist?
>
> Well, just have a look at mkfifo to see one thing, but there is more
> (like CTRL-Z, etc.).
>
> > >Also a full security model a la "option 2" is pretty usefull, i
> > > think.
> > >At least, "option 2" does not limit workstation usage, while "option
> > > 1"
> > >would make server capabilities very limited. Which is one of  THE
> > > good
> > >things from unix: it is fully multiuser.
> > Option 2 does limit workstation usage. At the very least, it
> > complicates it.
> > Multiple users log in (option 1) is a lot easier than option 2 to
> > build.
> > I just can't see a real need for it, compared to the work required.
> > You are better
> > off with a BSD box for terminal logins.
>
> Sure, it is much work, so is R1 - I haven't started writing a whole
> operating system to make any compromises in the long run, I want all
> the bells and whistles I can get :-)
> For R2 I only see three main things to do in the kernel:
> 1) allow shared libraries (pretty easy, yes, I know, but it won't
> happen in R1)
> 2) partition resizing/moving, file system defragmentation
> 3) last but not least: making it secure
>
> The rest should be maintenance (bug fixes, API changes, ...),
> optimizations, ports to other platforms, and perhaps rewriting the VM ;
> -P
>
> Adios...
>    Axel.
>
>