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
$5,413

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.

Unexpected

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)

Making it Build

Blog post by aldeck on Wed, 2012-06-06 00:29

Hello fellow Haiku'ers, as promised I'm posting a quick update on my WebKit / WebPositive contract work. It's been a little more than a week already, and a small report is due!

Welcome WebKit r115944 ! As you may know, WebKit is a really big project, in the last two years, 70000 revisions have passed and the file count has almost doubled. The approach I took was to start by checking out a recent WebKit revision and try building the components one by one, re-applying our changes. The idea was to add only the strict necessary for Haiku and at the same time try to include as many features as possible, ignoring assumptions and workarounds that aren't needed anymore. As many things have changed in WebKit and as I needed to get familiar with this huge codebase anyway, I decided to dismantle our port and put it back together again, like one would have done with a complex piece of mechanics. Thus I did a Jamfile from scratch, based on other platforms buildsystems, and replayed our changes one by one, as the compiler asked. Each time trying to document my changes and research the reasons and implications of the changes.

Magazine Article About Haiku Published in the May 2012 Issue of IEEE Spectrum

News posted on Wed, 2012-05-30 17:29

Long time Haiku contributor and Haiku, Inc. board of directors member Ryan Leavengood recently wrote an article about Haiku, which was just published in the May 2012 issue of IEEE Spectrum. For those Haiku community members who are IEEE members you can read the article in your print magazine, and all others can read the whole article online.

The Haiku project is always appreciative of any positive media coverage, and we want to thank Ryan for writing the article and the staff of IEEE Spectrum for publishing it. Ryan would also like to give a special thanks to his wonderful editor, Jean Kumagai. She help turn a mediocre article into a great one.

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."