
|
[openbeos]
||
[Date Prev]
[05-2003 Date Index]
[Date Next]
||
[Thread Prev]
[05-2003 Thread Index]
[Thread Next]
[openbeos] Re: status of OpenBeOS
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 05 May 2003 02:50:43 +0200 CEST
"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.
|

|