Haiku is a new 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 2015

Goal: $35,000
$3,538

WHAT'S NEW IN HAIKU DEVELOPMENT

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.

NFSv4 client: community bonding report

Blog post by Paweł Dziepak on Mon, 2012-05-28 10:59

During community bonding period, apart from reading specifications, I also analyzed other NFSv4 client implementations, looking for interesting ideas and solutions. One thing I noticed which may be worth using in my NFSv4 client implementation is caching of some parts of generated RPC request.

In addition to that I also got more familiar with what Haiku expects from file system modules. I have written a very simple dummy file system and check how things work. The problem I encountered here is that Haiku when creating a vnode identifies the file using its inode number. NFSv4 server provides its clients inode numbers but does not provide any way to get file using its inode number. That is why the client will have to keep some cache of inode numbers it is aware of in order to map them to NFSv4 file handles. Self-balancing BST seems to be a good idea.

I started working a few days before May 21st and the day the official coding started I already had a module that was able to generate and send NFSv4 null request and receive a reply using either TCP or UDP as transport protocol. In the first weekend I polished that code, added proper error handling, interpret RPC errors that might happen, made the client use only one TCP connection or UDP socket per server no matter how many file systems are mounted and added support for AUTH_SYS authentication flavor. Public backup of my work is available here.

Since most of RPC and XDR code is complete (apart from few issues I need to address) my next goal is to write NFSv4 request generation and reply interpretation. That will allow me to start writing hooks a FS module should provide. According to my initial timeline I had to have all mandatory hooks written by June 25th. However, now I think there is a big chance I will have that done by June 11th (quarter term).

cpuidle: GSoC community bonding report

Blog post by yongcong on Sun, 2012-05-27 13:38

As we all know, cpuidle can't save any power if cpu is wakeup frequently during idle-- cpu doesn't have chance to go to deep sleep. So to get power savings, besides cpuidle support, we must remove those unnecessary wakeups.

During the bonding period, I added some code to dump system timer wakeup events and found the cpu wakeup during idle is too high, ~550 wakeup/s. Then with the help of KDL, I found one obvious wakeup source -- the scheduler's quantumTimer. But I can't understand its duty. Then with the help of Axel, I catch its functionality and meaning. Axel also gave one suggestion:disable the timer for idle thread. So the only one patch during my bonding period was submitted and latter was merged by my mentor tqh. By my test, this patch removes ~41% unnecessary wakeups during idle.

My wakeup investigation goes further after then. I found another unnecessary wakeups source: intel e1000e ipro1000 driver. The freebsd network driver glue layer timer function: hardClock() is triggered too much(it sits in src/libs/compat/freebsd_network/clock.c). I can fix it but I think to remove all unnecessary wakeups can't be achieved in this summer and I should focus on my project. So I just decide to just remove the ipro1000 when testing.

Then with the help of mmu_man, I learned to quit process using roster. mmu_man also suggested kill Tracker and Deskbar because they are still using poll mode. Later I modified my bootscript to don't launch those services. Finally I succeeded to decrease the wakeup during idle from ~550 wakeup/s to ~30wakeup/s. It's enough for cpuidle testing.

I also read one excellent document about how to write power efficient software from intel:http://download.intel.com/technology/pdf/Green_Hill_Software.pdf.

The first goal(by the end of Jun11) should be x86 architecture specific code modifications. the first is to check whether we need to make arch_cpu_idle as a function pointer; the second is to add moniter/mwait instruction support. Because we need to use mointer/mwait extension to enter intel processors native deep states and it's simpler than ACPI solution.

OpenJDK port: community bonding report

Blog post by hamish on Thu, 2012-05-24 20:09

Over the community bonding period I've been researching the best approach to take for the AWT port, and over the past week or two I've been implementing a prototype.

AWT demands the implementation of a number of 'peers' for buttons, text boxes, etc. which have historically been implemented using the native widgets of the underlying platform. The time taken to implement and maintain these peers is quite large, especially considering that these AWT widgets have been superseded by Swing and are rarely used anymore.

An alternative implementation approach used by the Caciocavallo project involves providing native heavyweights for the windows and views and then calling on Swing to provide drawing and event handling for the various widgets. This eases the porting of AWT and reduces the amount of platform-specific code to maintain. This approach is also taken by the recent port of OpenJDK to Mac OS X.

Over the past week or two I've written a prototype implementation using the Caciocavallo Swing AWT peers. It's very incomplete thus far, but I've got drawing working pretty reliably, as well as some event handling including mouse input. Screenshot below the fold.

A new development contractor!

News posted on Sun, 2012-05-20 16:03

Announcing development contracts is one of the best feelings. It is a time when a volunteer developer is given the opportunity to dedicate a large block of time for their hobby -- developing HAIKU! This is made possible through the countless donations from people like you, who love Haiku and are willing to give what is right for them, to make Haiku a better operating system. Thank you to all of our supporters, both public and anonymous!

This time, we are pleased to announce that Alexandre Deckner will be working on the WebKit port and, if time allows, WebPositive. You may remember "aldeck" primarily from his work on Tracker -- squashing bugs, rewriting sections for better performance and updating it to utilize the Layout API. As Alexandre states, "Good web support is something crucial for any operating system these days, it is for some users the main software they will use on a computer and one of the first things a new user will try on Haiku. To summarize, Haiku has to provide the best web experience possible and i believe i can help to go in that direction."

Back from Auckland

Blog post by yourpalal on Thu, 2012-05-03 16:51

With one big push the work I did on ALM (Auckland Layout Model) while I was at the University of Auckland is now in the main Haiku repo. In short, I’ve brought the BALMLayout up to standard with the other layouts in Haiku, and added some new features as well.

Work in progress on the xHCI driver

Blog post by korli on Tue, 2012-05-01 22:23

I started to work on the xHCI driver in late 2011: I found the code provided during the Google Summer of Code 2011 was promising and didn't get its full exposure. Another reason was Haiku Inc. provided me with hardware I needed to mentor the xHCI project by Jian Jiang.

GSoC Introduction: BFS Partition Resizer

Blog post by ahenriksson on Mon, 2012-04-30 12:43

The goal of this project is to create code for resizing a BFS volume in a safe manner, through the existing volume resizing interface. At first utilized with a command line tool, and toward the end of the summer hopefully integrated with DriveSetup if time allows.

During the community bonding period, I want to get my development environment set up, and gain some basic familiarity with writing to disk. To accomplish that, I'm going to write a small program that can read and write sectors to the hard drive.

I'm also going to read up on documentation and code, in order to get a clear picture of where to begin when I start the coding.

You can check out my submitted proposal at https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/... for a brief introduction of me, a technical overview and timeline.