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 2013

Goal: $35,000
  $10,476

WHAT'S NEW IN HAIKU DEVELOPMENT

The Haiku source is continually built for testing purposes. You can download and install these latest snapshots to check out the latest features and bugfixes.

Be aware though that they may be unstable. Additionally, Web+ and some other packages have to be installed separately.

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

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:

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.