headers
Andre' F. Braga | 1 Jan 2002 02:02
Picon

Re: Kernel status (POSIX)


Nathan Whitehorn wrote:

> How portable is your code=3F I would ask for a moratorium on assembler, 
> or at least a fallback to plain C, so that it can be ported to PowerPC. 
> For me, at least, and I think for a lot of others, this is very 
> important.
> -Nathan

I've been really silent (in fact, just plain mute) since I joined the
list, so here I go for the first time: I could't agree more. I'd really
love to se an incarnation of BeOS running on stock G3/4/5 PPC machines,
and even perfoming better on my aged Performa 6360.

Nathan, I'm 101% behind you.

Cheers, happy New Year!
Permalink | Reply | 0 comments |
headers
Andre' F. Braga | 1 Jan 2002 02:04
Picon

Re: Kernel status (POSIX)


Nathan Whitehorn wrote:

>>I don't know that much about MS-Mach - why not mail me offlist
>>and we can chat about it.
> 
> Sure, all right.
> -Nathan

Breaking the silence once again, I'd like to suggest keeping this 
conversation on the list. At least I would really like to read it. Put 
me in the BCC if you will, okay?

Thanks =)
Permalink | Reply | 0 comments |
headers
P Willis | 1 Jan 2002 21:40

Re: Kernel status (POSIX)


> 
> Yes, I know. And I agree with it. All this fuss was because some
> claims about fork() being possible to implement in userland without
> any kernel assistance.
> 
> 
> manuel,

Yes, Imagine that.
How frustrating.
Some people.......the nerve....  ;)

Peter
Permalink | Reply | 0 comments |
headers
Erik Reid | 2 Jan 2002 07:47

Re: Kernel status (POSIX)

Quoth "Michael Phipps":
>As far as the whole PPC thing goes, you are not the first person to bring
>it up. Personally, I have little interest in trying to figure out, via reverse 
>engineering, every little quirk that Apple HW engineers have come up with.
>If there is a group of people out there who, post-R1, want to take a whack
>at that, wonderful. I don't dislike the idea of PPC support. But I do think that
>it is a far bigger mouthful than most people think. And to be honest, not 
>one that inspires me all that much. PPC hw is VASTLY overpriced. Buying
>new PPC hardware to run OBOS would be silly. So I would have to assume
>that the point would be to get MacConverts. That was FAR easier in the MacOS8
>days. :-/

I think that if someone wanted to do support for PPC(or a group of people or whatever),
it shouldn't be outlawed..  It is a free project, after all, and it wouldn't hurt.
Not mandating it as a main goal of the project for the moment makes sense, of course. :)
Permalink | Reply | 0 comments |
headers
jaf | 2 Jan 2002 08:34

Re: openbeos Digest V2 #2


>BeShare will support an awful lot. Anyone know an upper limit?

As far as maximum number of simultaneous users, the limit is determined
by the FD_SETSIZE
of the operating system that hosts the server.  Under BeOS that number
is 1024; it may be
larger on other OS's but is not likely to be smaller.

>Yes, that is the problem. It is beos native. you can't communicate
with other when using for example
>Solaris, Linux, freeBSD, Windows except you use the java client.

Well, the Java client is usable under those OS's, and I have also seen
a nice Qt-based BeShare client
running under Linux...  it was named "Enkroach" IIRC.

Cheers,
Jeremy  :^)
Permalink | Reply | 0 comments |
headers
John MacGrillen | 2 Jan 2002 14:55

Re: openbeos Digest V2 #2


Hi all,

This is my first post so try to be gentle.

First up I am only a dabbeler when it comes to coding, so feel free to
dismiss any and all comments below as ramblings from the lunatic fringe.

I think that using the Linux kernel is not a good idea. While it has
widespread support from across the industry, it's also hugely bloated. Most
Linux geeks will re-compile the kernel to optimise it for use on their
hardware. This is fine for said geeks, but for the average user? I think
not. A small, fast, light kernel with a good sellection of dynamically
loadable drivers should be the way to go.

Similarly I think X is a mistake too. Lets not forget even the GNU world
isn't that impressed with the performance and design restrictions it
imposes. The Berlin Consortium are hard at work trying to provide a viable
alternative.

This is going to raise a few hackles, but I also believe that trying to
provide binary compatibility with R5 is a mistake. If it happens, well
that's great, but why strive for it? Eugenia has pointed out some of the
pitfalls in the BeOS kernel, why would we want to build on that? At some
point a new kernel will have to arrive from somewhere, so why not bite the
bullet in the early stages? You could spend a lot of time getting the
various kits to work with the Be kernel, only to have to change it all again
to get them working with the new kernel. Lets not forget, Be were not afraid
to break binary compatibility in order to improve the OS, and if they were
still around today they would have to do so again to move to gcc3.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ithamar R. Adema | 2 Jan 2002 15:04

Re: openbeos Digest V2 #2


>This is my first post so try to be gentle.

I will :)

>I think that using the Linux kernel is not a good idea. While it has
>widespread support from across the industry, it's also hugely bloated. 
Most
>Linux geeks will re-compile the kernel to optimise it for use on their
>hardware. This is fine for said geeks, but for the average user=3F I 
think
>not. A small, fast, light kernel with a good sellection of dynamically
>loadable drivers should be the way to go.

Sounds like newos :)

>Similarly I think X is a mistake too. Lets not forget even the GNU 
world
>isn't that impressed with the performance and design restrictions it
>imposes. The Berlin Consortium are hard at work trying to provide a 
viable
>alternative.

Agreed. But even the Berlin project seems like quite some overhead for 
our purposes, but ah well....

>This is going to raise a few hackles, but I also believe that trying 
to
>provide binary compatibility with R5 is a mistake. If it happens, well
>that's great, but why strive for it=3F Eugenia has pointed out some of
(Continue reading)

Permalink | Reply | 0 comments |
headers
DarkWyrm | 2 Jan 2002 15:14
Picon
Favicon

Drivers


We're going for binary compatibility and all, but what about device drivers? 
One of the things that I've heard numerous times about BeOS is that there 
isn't enough hardware support. Ithamar mentioned that we'll probably need to 
write new ones to take advantage of the new whistles and bells in the kernel, 
but I'm not so sure that's a good idea with (seemingly) so few people able 
and willing to do it. Anyone from the Kernel Team willing to comment?

--DarkWyrm
Permalink | Reply | 0 comments |
headers
guillaume.maillard | 2 Jan 2002 15:49
Picon

Re: openbeos Digest V2 #2


                    "John MacGrillen"                                                                                        
                    <Arc.Lites@...           To: 
<openbeos@...>                                              
                    et.com>                       cc:  (bcc: Guillaume Maillard/DR-SUR/BE/PHILIPS)                           
                    Sent by:                      Subject:  [openbeos] Re: openbeos Digest V2 #2                             
                    openbeos-bounce@...                                                                                      
                    elists.org                    Classification:                                                            

                                                                                                                             
                    01/02/02 02:55 PM                                                                                        
                    Please respond to                                                                                        
                    openbeos                                                                                                 

 Hi,

> First up I am only a dabbeler when it comes to coding, so feel free to
> dismiss any and all comments below as ramblings from the lunatic fringe.

I don't know if I have a place here, but...

> I think that using the Linux kernel is not a good idea. While it has
> widespread support from across the industry, it's also hugely bloated. Most
> Linux geeks will re-compile the kernel to optimise it for use on their
> hardware. This is fine for said geeks, but for the average user? I think
> not. A small, fast, light kernel with a good sellection of dynamically
> loadable drivers should be the way to go.

 I had the same vision about the Linux kernel, thinking that the BeOS kernel
"was very small, fast, light .." .  When I start to rewrite the KernelKit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ithamar R. Adema | 2 Jan 2002 15:57

Re: Drivers


Hi DarkWyrm :)

Although I'm not from the Kernel Team, I am involved in several ways 
with NewOS and I thought I might just as well comment on this. There is 
a "BeOS Compatibility Layer" in NewOS already, which makes it possible 
to load and use some BeOS drivers already. This layer needs some work 
and I guess Travis leaves this up to OpenBeOS to do or not to do. It is 
really pretty simple to extend, and if we put enough effort in there, 
we can make it work for almost all drivers.

This means, that anyone who =5Fwants=5F to use drivers from BeOS (which we 
cannot ship with OBOS, IMHO) he could try and see if it works. However, 
if we want to be able to extend the OS, we need the driver source, so 
all drivers that =5Fcan=5F be rewritten for NewOS (read: has public 
datasheets / source) should be implemented as such, as it will improve 
performance in a lot of cases.

So yes, a certain level of BeOS drivers will work, but we'll need to do 
some work on that, and test heavily. Preferred way (if at all possible) 
is implement the drivers natively....

Regards,

Ithamar.

>
>We're going for binary compatibility and all, but what about device 
drivers=3F 
>One of the things that I've heard numerous times about BeOS is that
(Continue reading)

Permalink | Reply | 0 comments |

Gmane