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


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.

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.

GSoC Introduction: NFSv4 client

Blog post by Paweł Dziepak on Mon, 2012-04-30 02:04

My GSoC project is to implement a Network File System version 4 client. NFS since its early versions became one of the most popular way of sharing files among Unix-like (and not only) systems. The fourth version brings many changes to the protocol that both simplify implementation and make it more efficient. That includes better support of client side caching which can significantly improve performance. In addition to that neither mountd nor NLM needs to be used anymore since services they provide are now part of the protocol.

Community Bonding Period

During the community bonding period I am going to get myself familiar with every detail of all RFC containing information on how does NFS protocol works. That includes specifications of Remote Procedure Calls (RPC) and External Data Representation (XDR) which are used by NFS as well as the specification of NFSv4 itself. I think it may be also a good idea to check how NFS clients are implemented in other operating systems in order to find some interesting solutions.

I also need to get myself familiar with the Haiku itself. Specifically, with the parts of the kernel the NFSv4 will work with. That includes, among others, file caching, notifications, network. Since disk based file systems behave in a different way than NFS there may be need to make some changes in these parts of the code, so I will have to know exactly how to do it.

Summer and later

When I am ready with all preparations and the coding starts I am going to, firstly, write NFSv4 client that just works. That will require proper implementation of RPCs and basic NFS requests. Then I will be able to start making it usable, i.e. add client side caching, notifications, support for file attributes.

After GSoC, when NFSv4 client will be ready I will want to add support for NFSv4.1 mostly because of its interesting extensions such as directory delegation, which can improve notifications support or pNFS, parallel access to a clustered server implementation.

Syndicate content