Haiku Alpha 1 Status Update (#2)

#1739: including developer tools on Haiku

Last week offered major steps in accomplishing this task. One of the requirements that the developers drafted for the alpha, was that it would be able to build Haiku from within Haiku itself. This has several advantages, one of them being that - since compiling is such a resource intensive task - many bugs will be uncovered and fixed. In order to be able to 'self-host', it is necessary that the developer tools - most importantly the compiler GCC - work on Haiku. Ingo Weinhold has been working on accomplishing just that. He has ported the build tools to the Haiku platform. In essence this means that the build tools are now 'aware' that they are working on Haiku (previously they were thinking they were running on BeOS).

The current tasks are almost done, now that the build tool chain is fixed. Note that if you want to compile Haiku from revision 24542 on, you will need to check out the newer build tools, remove your 'generated' directory and reconfigure using the --build-cross-tools option to the configure script.

The other part of this task was to make sure that new Haiku images contain these developer tools. Ingo has created binaries that can be found on files.haiku-os.org. There is no need to download these yourself though: if you compile Haiku you can let jam fetch them automatically. You should enable AddOptionalHaikuImagePackages Development ; in your UserBuildConfig for that. See the ReadMe for details.

As soon as the final build tools have been ported and integrated with the new Development package, the ticket will be considered closed.

Whether to build a bootable CD

Karl vom Dorf (from haikuware.com) sent a message to the mailing list to notify people that he has released a test CD image on his website. He wanted to know the opinions of the developers on whether or not it was a good idea to distribute this image. He said:

I take the side that the software might be good for developers who don't
want to bother setting up a build environment, download the entire source,
and then compile it and figure out why there's isn't an *.iso etc. They just
burn it, test it, and maybe as a result submit patches or fixes to Haiku.
Or, maybe users might have the same issue, and later submit bug reports or
add their hardware to our hardware database.

The other side is that Haiku should release a demo CD when Haiku is ready
because it might give a false impression to users/critics.

Michael Lotz had a well-phrased response to this:

* CDboot currently seems to be unreliable. Most of those who try seem to have
it fail. This is in my opinion far more severe than with just trying the
images - they work reliably inside the emulators, and even if they don't for
some reason it didn't cost anything. If I wanted to try an OS, burnt a CD and
then it is unusable for some reason this would put me off quite a bit more -
especially if it is an OS that claims to be easy to use.

* For those that got the CD to boot, the reports state that it currently is
extremely slow. There are ways to optimize this and this will have to be done.
But currently it does not make a good impression - especially in the case of
Haiku that has the main selling point of being fast and responsive.

* There are numerous reported issues with the read-only case of the CD. Like
settings not applying, programs not working as expected and some even
crashing. Those are easy to reproduce and to iron out and therefore I'd
advocate to let the developers do that prior to releasing anything in CD form,
as it again makes a bad impression for no real benefit.

Urias added that it was much better to show off Haiku in VMWare. The bootable CD at this point should only be for testing the bootable CD itself.

At the end, the consensus seemed to be that before continuing with distributing the CD image, the kinks need to be worked out first. I had been brainstorming before this discussion started, and it was my intention to start a select test of the CD images first (the plan). At this point, there won't be a CD, but as the list of tasks shrinks, testing the bootable CD should become a priority.

Trac Milestone statistics

To get the most recent statistics, go to the alpha 1 milestone page. To keep a clear overview of which tickets need to be fixed before releasing Haiku alpha 1, the following rules apply:

• Tickets that absolutely have to be resolved before alpha 1 can be released, should have a blocker priority.
• Tickets that would be on the should-be-fixed list, should have the high priority.
• In between is the critical priority. When a ticket that is assigned to this milestone has this priority, it is a request for a fellow developer to have a look at that ticket and determine whether it should be high or blocker.

Blockers

Critical tickets

High Priority Tickets