Haiku Alpha 1 Status Update (#1)

Finally, I cannot guarantee that there will be regular updates, or whether there will be an update at all, but feel free to encourage me!

#1268 (closed) - Live CD support in the build script.

A much requested feature was to be able to boot Haiku from a CD. This also was one of the requirements for a working alpha release: it should be distributable by CD. Once upon a time there were a set of scripts on BeBits that would generate a CD image. Unfortunately these scripts stopped working - for a long time actually - and another solution had to be found.

Luckily, François Revol took the task upon him. He first created a rule that made a boot floppy. This actually has been a request for a while, and it was implemented in revision 24198. You can use jam haiku-boot-floppy to create a boot floppy. From there he continued integrating CD support. The only new external dependency is mkisofs which almost all modern Linux distributions have packages for. To actually create the necessary files for burning on CD, use the jam haiku-cd-image command. For exact instructions, I would like to refer you to the ReadMe that is distributed with the source.

Now it is good to understand that this will boot Haiku from a CD, but there are a few issues. First of all, it is not very small. Some tricks have been applied (like changing the default block size of the disks), but it still needs work. Also, the CD is not a live CD like we might know from Linux distributions. These apply a trick that uses the RAM to emulate write support to the hard disk. The Haiku 'Live CD' does not do that. Because it has been untested for so long, applications or system services that depend on writing to the disk (which is usually the hard drive), might not be able to perform certain operations or just downright crash. Finally, there has been a report of the boot CD not being able to actually find the Haiku image on that CD. If you experience this problem, please see if it is similar to ticket 1364.

On a final note, I would urge everyone with a spare CD-R (or CD-RW) and a computer that is known to boot Haiku on real hardware, to try to build the CD source and test the CD to see where it breaks.

#1739 - Generate a proper 'develop' directory

One of the other major requirements was that there was a way to 'self-host'. Strictly, this means that it should be able to check out the source from the subversion repository, and to be able to compile Haiku from within Haiku. Michael Lotz had been working on a new heap implementation (a part of the memory manager of the kernel), which he finished in revision 23939. After that, it was reported that it was possible to perform these steps (though it did not work all at one go).

That was the strict definition. However, to be able to use Haiku on a more regular basis as a development platform, it needs to be easily possible to get gcc and the binutils, as well as the system headers and the libraries. In revision 23895, Ingo Weinhold began implementing a 'Development' package, which allows the build system to copy all the headers and libraries that are needed to compile on Haiku. That was a good first step.

Currently, Ingo is working on porting gcc and the binutils to Haiku, and he wants to have these available as an optional package which can be automatically installed by the build system, so that a fresh Haiku installation can be used to compile Haiku easily. As for such, there is a special note: the current buildutils/trunk is under development, and a fresh checkout might not work. It has already been reported that it does not work on Linux PPC. Ingo advised to use revision 24507 (svn up -r24507) if you want to build the legacy tools (gcc 2.95.3) for now.

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.

There are currently six blockers nominated for the alpha 1 release, four critical and six high open tickets.