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
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 www.haiku-files.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.
|kernel: Panic out of range
|[app_server] deadlock on workspace switching
|[app_server] crash in Desktop::Cursor()
|check if AboutHaiku lists an acknowledgment for all packages
|acquire_sem doesn't timeout
|Include a build system script to generate a proper 'develop' directory on Haiku
|condition variable entries are only removed on notify
|Total open: 6 tickets
|deadlock after clicking on Deskbar
|PANIC: page fault, but interrupts were disabled
|PANIC: vnode 5:45465 already exists
|Negative Modified Page Queue Count
|Garbage In Files
|execvp() Tries to Execute Directories
|Total open: 4 tickets
High Priority Tickets
|Problem with special characters
|Imposible to boot from CD
|Implement and test creating and deleting partitions in DriveSetup
|Write a USB -> BIOS handover kernel debugger enter/exit add-on
|Tracker Desktop windows sometimes stops drawing
|Glibc wide char functions are disabled
|nVidia: drawing problems after new splash screen
|Total open: 7 tickets
- RFC Coding Guidelines: Formatting Class Member Declarations
- Haiku Developer Tools Update (October 2023)
- HTTP Network Services Preview in R1 Beta 4
- Rust on Haiku: the Case of the Disappearing Deceased Threads
- The State of Rust on Haiku - July 2018
- Haiku has No Future
- Alpha 1: A Week Later
- A Jocund Eulogy
- Git for Haiku (#1)
- Haiku Alpha 1 Status Update (#2)