Re: OS Zoo

Stephan

Tks - I will keep reading your progress with interest.

Nev

----- Original Message ----- 
From: "Stephan Assmus" <superstippi@...>
To: <openbeos@...>
Sent: Tuesday, January 31, 2006 9:35 PM
Subject: [openbeos] Re: OS Zoo

> Hi Nev,
>
>> As a keen follower of the development of Haiku when do you think a normal
>> run of the mill  end user like me might see
>> something that we can work with.
>
> Any "when" answer is going to come bundled with tons of "ifs". If we keep
> going at this pace, we might have something usable in a year. Maybe two? 
> One
> of the big question marks is the networking support. I would assume that 
> some
> portions of code which are in a "get it working now - make it nice later"
> kind of condition, would need revisiting before release. And we cannot 
> really
> tell how many crucial, hard to track down bugs still creep up. But from my
> perspective, I would say we are more at the finishing end of the work - 
> after
> all, you can start large R5 applications in Haiku. And even run them for

Re: OS Zoo

>To be honest, even the unofficial builds are a little >scary. Because we want to 
>be different. Like Be was different. Did you ever get a >Be release that showed 
>poor quality?

Well, to be honest... how do you think we'll get more developers involved without an image to download, and,
more important, without screenshots on OUR site ? Most people I know don't bother to try _anything_ if
there aren't screenshots available.
We aren't be inc which had only internal developers and didn't need external help, we need to show progress
to more people.
Now, I'm not talking about publishing an image in OS Zoo, but at least having screenshots on our site AND a
working, official, build factory with the latest image available is a must.

Just my 2 (euro)cents.

Stefano Ceccherini aka Jack Burton
--------------------------------------------------------------
Non resistere alla tentazione di conoscere nuovi amori!
Oltre 2.100.000 persone ti stanno aspettando su Incontri.
Vivi le emozioni fino in fondo!
http://www.supereva.com
---------------------------------------------------------------

Re: OS Zoo

Hi there,
	Just wanted to express my humble opinion: I really think Haiku should 
release when ready. Haiku is for the user, we want him to feel confident 
by downloading our stuff, knowing he won't have 120 patchs following the 
next week of his first install. People should feel we are "responsible" 
for our works.
	Now, for the developers, if you're talking about the devs that do apps. 
Well, they are waiting for "clients", that is: users, that is: stable 
product. Now for those devs who want to work in Haiku itself, they 
should be prepared to play with scary images and they can already do 
that now. Not like if it was hard to find an unofficial Haiku image: 
typing "Haiku Image" in Google gives a valid link in rank #5...

my 2cents,

Methe

Stefano Ceccherini a écrit :
>>To be honest, even the unofficial builds are a little >scary. Because we want to 
>>be different. Like Be was different. Did you ever get a >Be release that showed 
>>poor quality?
> 
> 
> Well, to be honest... how do you think we'll get more developers involved without an image to download,
and, more important, without screenshots on OUR site ? Most people I know don't bother to try _anything_ if
there aren't screenshots available.
> We aren't be inc which had only internal developers and didn't need external help, we need to show progress
to more people.
> Now, I'm not talking about publishing an image in OS Zoo, but at least having screenshots on our site AND a
working, official, build factory with the latest image available is a must.

Re: OS Zoo

Hi,

Ah: I love the screenshots at least: looking at ReactOS for example...

Rudolf.

> Hi there,
> 	Just wanted to express my humble opinion: I really think Haiku 
> should 
> release when ready. Haiku is for the user, we want him to feel 
> confident 
> by downloading our stuff, knowing he won't have 120 patchs following 
> the 
> next week of his first install. People should feel we are 
> "responsible" 
> for our works.
> 	Now, for the developers, if you're talking about the devs that do 
> apps. 
> Well, they are waiting for "clients", that is: users, that is: stable 
> product. Now for those devs who want to work in Haiku itself, they 
> should be prepared to play with scary images and they can already do 
> that now. Not like if it was hard to find an unofficial Haiku image: 
> typing "Haiku Image" in Google gives a valid link in rank #5...
> 
> my 2cents,
> 
> Methe
> 
> Stefano Ceccherini a écrit :
> >>To be honest, even the unofficial builds are a little >scary. 

Re: OS Zoo

Re: OS Zoo

Stefano Ceccherini <burton666@...> wrote:
> Well, to be honest... how do you think we'll get more developers 
> involved
> without an image to download, and, more important, without 
> screenshots
> on OUR site ? Most people I know don't bother to try _anything_ if 
> there
> aren't screenshots available.
> We aren't be inc which had only internal developers and didn't need 
> external
> help, we need to show progress to more people.
> Now, I'm not talking about publishing an image in OS Zoo, but at 
> least having
> screenshots on our site AND a working, official, build factory with 
> the latest
> image available is a must.

Well, I definitely agree on the screenshots. I wouldn't mind having 
official images (hard drive images, not CD images), too, but I don't 
think it's really needed that much.

Bye,
   Axel.

Re: OS Zoo

Hi Nev!

Heh - I believe that in any software project you probably can't reasonably plan 
more than 2 weeks ahead.  

The only three *big* things that I can think of that we need are networking, 
USB and Media Encoding. There are lots of bug fixes and things that need more 
work, but those are the three big things. I would like to think that a year is 
a good estimate but I don't know any more than you do, to be honest. Axeld 
could clone himself a hundred times.  Or ... something bad could happen to a 
bunch of people. With OSS, planning is tough, especially with a fairly small 
group of devs. With Linux, for example, there are enough devs that 
statistically if a couple more come aboard or disappear, it doesn't matter.

I know that I didn't answer your question, really. If you don't mind missing 
that functionality, I think that Haiku is pretty usable today. Not perfect, but 
certainly on par with any other OSS project at a < 1.0 level. Better than Linux 
.90. :-D 

On 2006-01-30 at 21:18:00 [-0500], Nev wrote:
> Michael
> 
> As a keen follower of the development of Haiku when do you think a normal run 
> of the mill  end user like me might see
> something that we can work with.
> 
> Thanks
> Nev
> 
> 
> ----- Original Message ----- 
> From: "Michael Phipps" <mphipps1@...> To: 
> <openbeos@...>
> Sent: Tuesday, January 31, 2006 10:14 AM
> Subject: [openbeos] Re: OS Zoo
> 
> 
> >I saw the posting on OSNews, too. And it sounds like a good idea. But, as 
> >Axel
> > and Marcus said, not now.
> >
> > To be honest, even the unofficial builds are a little scary. Because we 
> > want to
> > be different. Like Be was different. Did you ever get a Be release that 
> > showed
> > poor quality? Not that you weren't happy with the features or something, but
> > that crashed all the time? Or where you sort of shook your head and asked 
> > yourself if anyone looked at it before it went out?
> >
> > To be honest, we have all seen other OSs that were pretty sorry in their 
> > shipped state. No one is really innocent. It is pretty easy to point 
> > fingers,
> > for example, at Windows ME or Mac OS 6 multi-finder. Open source has not 
> > much
> > better track record, to be honest. There have been lots of cases where OSS 
> > stuff has stunk up the place. Haiku should be better than that. We should 
> > release something that makes people say "WOW! Where did that come from? 
> > Where
> > can we get more!?!?!?!?!" That is our vision. That's why we don't have a 
> > "release candidate .0001alpha". We could. There are lots of OSS systems out
> > there that aren't as good as Haiku is today. But we want to do something 
> > better.  I know that it is hard to be patient. Probably no one is more 
> > impatient than I. :-D But anticipation makes the wait worth while.
> >
> > Michael
> >
> >
> > On 2006-01-29 at 21:30:51 [-0500], Mat Hounsell wrote:
> >> OS Zoo got a mention on OS News today.
> >> OS Zoo hosts qemu images of free operating systems, some still pre -release
> >> like Haiku.
> >> That's were I got a ReactOS image that reale piqued my interest.
> >>
> >> Since we have qemu images it might get us a lot more interest, especially 
> >> from those who think it is still a pipe dream.
> >>
> >> http://free.oszoo.org/submit.html
> >>
> >> Submission Guidelines
> >>
> >> Every contribution is really much appreciated, but it would be better to 
> >> follow some guidelines in order to provide a standard way to collect, 
> >> distribute and use the images.
> >> Creation Rules
> >>
> >>     * Create a large disk image. 10 GB should be enough. Even if large, 
> >> the
> >> image file will occupy just the dimension of the data present in it (thanks
> >> to the qcow format), so after creation the image, even if large, will be 
> >> just
> >> a few Kb
> >>     * Use the qcow format for the images: qemu-img create -f qcow 
> >> image.img
> >>     10G
> >>     * After creating the image, create a compressed clone of the image:
> >> qemu-img convert -f qcow -c image.img -O qcow image_compressed.img
> >>     * Rename the compressed image. Use something appropriate (for 
> >> example,
> >> openbsd_3.8.img)
> >>     * Put the image inside a directory having the same name of the image.
> >> Create a README file and fill it with your name, email, date, notes (don't
> >> forget to add root password and other information you think users should 
> >> know)
> >>     * Tar the directory but DO NOT COMPRESS it again. The tar file should 
> >> be
> >> named as the directory (i.e.: openbsd_3.8.tar). If you want you can add a 
> >> timestamp in the format yyyymmdd (i.e.:openbsd_3.8_20051001.tar)
> >>
> >>
> >> Submission Rules
> >>
> >>     * Please, DO NOT SUBMIT OPERATING SYSTEMS that can't be 
> >> redistributed!
> >>     * Create a .torrent file for the file you've just created. Be suse to 
> >> use
> >> http://www.oszoo.org:6969/announce as tracker.
> >>     * Send the .torrent file as attachment to marinell@... . 
> >> Please,
> >>     DO
> >> NOT SEND IMAGES as attachment, even if small
> >>     * Wait for the confirmation. The .torrent will be manually added to 
> >> the
> >> tracker so it may take some time. Once done you'll be authorized, start 
> >> sharing the file using the oszoo tracker. The seeder on the oszoo server 
> >> will
> >> immediately start to download and reshare the file.
> >>     * After being checked, the image will be published on the oszoo 
> >> server and
> >> you'll be credited as creator and maintainer of that image
> >>
> >>
> >> http://haiku-os.org/
> >>
> >> http://matgeekau.blogspot.com/
> >> http://matgeekaupolitcial.blogspot.com/
> >>
> >>
> >>
> >> ____________________________________________________ Do you Yahoo!? Never 
> >> miss an Instant Message - Yahoo! Messenger for SMS 
> >> http://au.mobile.yahoo.com/mweb/index.html
> 

gcc questions

Hello!

Have gcc 4 changes been sent to and accepted by gcc team? If not, will they be proposed?

Have building gcc 4 from svn yet been tested under BeOS?

Is there a way to download a snapshot of the buildtools part of the source tree? Or is there any other way of
obtaining the gcc 4 source in svn without doing a co? (Have no possibility to do that)

I'm interested in this as I'm trying to compile gcc 4.0.2 for avr processors under BeOS, but running into a
problem with missing libm.so. If I understand correctly the functions in libm.so (on other platforms)
are in libroot.so on BeOS instead. This is probably a problem with configuration scripts. Is this fixed in svn?

/Fredrik Ekdahl

Re: gcc questions

> Hello!
> 
> Have gcc 4 changes been sent to and accepted by gcc team? If not,

Dunno

> will they be proposed?

Certainly.
Them being accepted is another matter :)

> Have building gcc 4 from svn yet been tested under BeOS?
> 
> Is there a way to download a snapshot of the buildtools part of the
> source tree? Or is there any other way of obtaining the gcc 4 source
> in svn without doing a co? (Have no possibility to do that)

Someone should probably make a diff against official 4.0.2.

> 
> I'm interested in this as I'm trying to compile gcc 4.0.2 for avr
> processors under BeOS, but running into a problem with missing libm.so.
> If I understand correctly the functions in libm.so (on other platforms)
> are in libroot.so on BeOS instead. This is probably a problem with
> configuration scripts. Is this fixed in svn?

No it's a problem with gcc4's makefiles which hardcodes -lm in 
several places. I just removed them in the ZETA port, but seen they are 
still there in the Haiku tree. They will have to be changed with checks 
in the configure script to be accepted.
But you can manually remove the -lm from the few Makefile.in. You can 
try to apply this patch (though I'm not sure all should go away for a 
cross compiler):

=============================== begin
diff -urN -x .svn /boot/home/devel/haiku/buildtools/trunk/gcc/gcc/Makefile.in ./gcc/Makefile.in
--- /boot/home/devel/haiku/buildtools/trunk/gcc/gcc/Makefile.in	Wed Jan 18 23:36:48 2006
+++ ./gcc/Makefile.in	Tue Oct  4 07:54:51 2005
 <at>  <at>  -2589,7 +2589,7  <at>  <at> 
 	$(CC_FOR_BUILD) $(BUILD_CFLAGS) $(BUILD_LDFLAGS) -o $ <at>  \
 	 build/genattrtab.o build/genautomata.o \
 	 $(BUILD_RTL) $(BUILD_SUPPORT) $(BUILD_PRINT) $(BUILD_ERRORS) \
-	 $(BUILD_VARRAY) $(BUILD_LIBS) -lm
+	 $(BUILD_VARRAY) $(BUILD_LIBS)

 build/genattrtab.o : genattrtab.c $(RTL_BASE_H) $(OBSTACK_H) $(BCONFIG_H) \
   $(SYSTEM_H) coretypes.h $(GTM_H) errors.h $(GGC_H) gensupport.h genattrtab.h
diff -urN -x .svn /boot/home/devel/haiku/buildtools/trunk/gcc/libstdc++-v3/src/Makefile.am ./libstdc++-v3/src/Makefile.am
--- /boot/home/devel/haiku/buildtools/trunk/gcc/libstdc++-v3/src/Makefile.am	Wed Jan 18
23:40:53 2006
+++ ./libstdc++-v3/src/Makefile.am	Tue Sep 20 19:33:53 2005
 <at>  <at>  -153,7 +153,7  <at>  <at> 
 libstdc___la_DEPENDENCIES = ${version_dep} $(libstdc___la_LIBADD)

 libstdc___la_LDFLAGS = \
-	-version-info $(libtool_VERSION) ${version_arg} -lm 
+	-version-info $(libtool_VERSION) ${version_arg}  

 
 # Use special rules for the deprecated source files so that they find
diff -urN -x .svn /boot/home/devel/haiku/buildtools/trunk/gcc/libstdc++-v3/src/Makefile.in ./libstdc++-v3/src/Makefile.in
--- /boot/home/devel/haiku/buildtools/trunk/gcc/libstdc++-v3/src/Makefile.in	Wed Jan 18
23:40:37 2006
+++ ./libstdc++-v3/src/Makefile.in	Tue Sep 20 19:33:53 2005
 <at>  <at>  -357,7 +357,7  <at>  <at> 

 libstdc___la_DEPENDENCIES = ${version_dep} $(libstdc___la_LIBADD)
 libstdc___la_LDFLAGS = \
-	-version-info $(libtool_VERSION) ${version_arg} -lm 
+	-version-info $(libtool_VERSION) ${version_arg}  

 
 # Use special rules for the deprecated source files so that they find
=============================== end

Btw there are some bugs and unimplemented stuff in gthr-beos.h which I've 
fixed for the ZETA port. I'll probably be checking them in when I get time, 
maybe with the rest of the ZETA port, and sync them so we could submit a 
single official diff.

François.

Re: Booting problems...

Hi Axel,

thanks for looking into this!
Unfortunately I can't create a new image using the current source: 
there are multiple faults with the pci busmanager or so?
(pci_arch_busmanager): double and missing functions?

BTW: I tried to benchmark without MTRR so I can compare speeds later 
on, but the command-line  app I use uses BWindowScreen which reports 
failing cloning of accelerant.  Maybe this has to do with the recently 
added checks in my drivers to insure clients to not use INIT_ACCELERANT 
multiple times, and only CLONE_ACCELERANT if one INIT_ACCELERANT had 
been done.  BWindowScreen has to be fixed?

If you want to see what it looks like, it's probably enough to modify 
the set_pallette hook to not do anything :)
I can probably make a screenshot, but I'd have to do it using a digital 
camera, as the screen memory will no doubt(?) have it's correct 
contents.

About the ps/2 driver: indeed: great work from Marcus!

Rudolf.

> Hi Rudolf,
> 
> "Rudolf" <drivers.be-hold@...> wrote:
> > Image tested and working OK as long as MTRR support is removed.
> > Confirming idle-loop halt instruction operational over here: CPU's 
> > stay 
> > cool 
> 
> I can reproduce the problem with my SMP machine as well, and I have 
> it 
> running here again. I'll commit my changes tomorrow, then MTRR should 
> work again for you, too.
> Turns out changing MTRRs easily confuses the other CPU for some 
> reason, 
> so I just needed to move some stuff around to make it work.
> 
> > Apart from the usual trouble here (drawing faults in certain 
> > reproducable areas, fonts being to large and such) there's one new 
> > bug 
> > that wasn't there before: the color palette doesn't get loaded for 
> > 8-
> > bit colorspaces apparantly (black/white sort of image here).
> 
> Hm... the icons and BAlert icons should all be 8 bit images. Do you 
> have a screenshot of it? I never heard of such a problem before.
> 
> > Looking good: KB and mouse seem trouble free for the first time, 
> > and 
> > stability is getting better and better! (happy camper :)
> 
> Thanks to Marcus, my system is boring and just works 
> 
> Bye,
>    Axel.
> 
> 
>