Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.

Fundraising 2016

Goal: $35,000


The Haiku source is continually built and released for testing purposes nearly every day. You can download and install these latest snapshots to check out the latest features and bug-fixes.

Be aware that nightly images may be unstable. Additionally, some packages included with official releases need to be installed separately.

If you're OK with this, you can find further instructions at our Nightly image page.

BFS Partition Resizer: Quarter Term Report

Blog post by ahenriksson on Mon, 2012-06-25 10:58

For the 1/4 term milestone, my goal was to have inode-moving working. This is mostly completed, you can view the code at http://web.student.chalmers.se/~andrhen/move_inode_v2.patch

For this period, I have the following things planned:

Allocation of new block positions: I have a good grasp of what needs to be done for this, and it's not a lot of work.

Moving file data: Last week I thought I had this nailed down, but it turned out to be a little more involved than that. Still, there has been some good progress made, and I'm sure it'll be completed within the period.

Doing the actual resizing: This step involves a few sub-steps: traversing the file system to move things out of the way, possibly moving the file system journal, resizing the block bitmap and updating the file system header. None of it should be that complicated (in theory), however it's likely that the more thorough exercising of the rest of the code will reveal problems with it.

Testing: I obviously test code as I write it, but I probably won't have time for a more rigorous approach in this period. I have a lot of time allocated for that in the next period, so it's not a disaster.

As it looks right now, things seem to be on track with the timeline in my proposal (which is actually not that great, as the timeline was a bit pessimistic).

NFSv4 client: quarter term report

Blog post by Paweł Dziepak on Sun, 2012-06-24 18:09

I have already implemented all mandatory hooks (and several others), what means that NFSv4 client now allows to browse directories and read files on remote filesystems. Last several days I spent on improving the existing code and supporting some less usual NFSv4 describes, that includes reclaiming share reservations, support for server migration and volatile filehandles. I also needed to deal with NFSv4 that do not provide file's inode number, that was solved only partially since proper workaround will be much easier to implement when file metadata and directory contents are cached.

cpuidle: quarter term report

Blog post by yongcong on Fri, 2012-06-22 15:42

I completed my 1/4 goal ahead of proposal schedule. By the original plan, I should investigate whether we need necessary changes to x86 idle routine and x86 architecture specific instruction usage. The results were reported to gsoc maillist on 3rd Jun. Here are the copied results:
1. no need to change x86 idle routine
2. monitor/mwait works perfectly. I have measured the power consumption when using idle implemented with "monitor/mwait", it's the same as the version implemented with "hlt".

x86_64 port: quarter term report

Blog post by xyzzy on Fri, 2012-06-22 12:27

As I mentioned in my first blog post, I had exams until a couple of weeks ago, so I didn't start working on my project properly until then. However, I am now working full time so I expect to make a lot more progress in the coming weeks.

So far I have made it possible to compile the kernel for x86_64 by adding stub implementations of all the architecture functions and fixing compilation errors/warnings (all architectures that Haiku supports at the moment are 32-bit, so there were various problems in the code when compiling for 64-bit). I have also made changes to the kernel_args structure (the structure which the bootloader passes to the kernel containing information such as the boot volume, loaded modules and the memory map). As I am making the x86 bootloader able to load both a 32-bit and 64-bit kernel, this structure must be compatible between both. The changes I have made make all members the same size regardless of whether compiling for 32-bit or 64-bit.

I have now begun implementing ELF64 loading into the bootloader so that the 64-bit kernel can be loaded. I expect to have the bootloader work completed by the end of next week, after which I will begin work on the kernel.

My GitHub repository can be found at https://github.com/xyzzy51/haiku/tree/x86_64 (I'm working in the x86_64 branch), for anyone who's interested in following my progress. You'll also see my commits on the haiku-commits list.

OpenJDK port: quarter term report

Blog post by hamish on Fri, 2012-06-22 01:32

Since my last blog entry I have mostly completed the implementation of the AWT/Java2D port. It is still in need of a lot of testing, but it is stable enough to run a lot of Swing apps out of the box. For example, here's jEdit and SwingSet:


Blog post by aldeck on Wed, 2012-06-13 01:32

After a week of struggling with my friend the compiler, I finally managed to bring the port into a buildable state again. Porting the latest changes to libwebkit, the last of the four WebKit subcomponents (libwtf, libjavascriptcore, libwebcore, libwebkit), took me more time than I anticipated but to my great surprise, after I fixed the first runtime crash, HaikuLauncher and WebPositive would run and be almost usable. Yes, there are visual glitches, and it is quite easy to crash, but you can search google, use maps, facebook, haiku-os.org and post this blog post.

This was totally unexpected, I would have considered it normal to struggle with numerous crashes on startup, but it seems that I didn't broke that many things in the upgrade. The first thing that I noticed was the overall snappiness even in debug mode and, after looking for a simple load time benchmark, I confirmed that first impression. This benchmark shows a ~3x improvement in load time. Javascript is substantially faster too, but you know that already if you read my last post.

This is really encouraging, especially for me, as I've now got something to click and play with... after discussing with a compiler for almost a month :-)

Now the real work begins, fix all regressions and provide a solid release, one that can run the most important sites correctly. And if I've got some time left, I'll look into bringing new features and enhancements. But don't count too much on that, if prefer concentrating on a solid base for now.

Screenshot (sorry I couldn't manage to embed the image)