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 2014

Goal: $35,000
  $13,754

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.

Two contractors, each for two months!

News posted on Mon, 2012-08-20 21:26

That's right -- Oliver Tappe and Ingo Weinhold have been accepted for individual contracts![1, 2] Each of them will be working for two 160 hour periods. That adds up to an additional 640 hours of dedicated HAIKU development time for a total cost of €8,000 EUR. The area of focus will be Haiku's package management. (See A brief summary of HAIKU's package management. for an explanation of how package management will work.)

Hopefully, these contracts will start in Dec. 2012. Given the delay between this announcement and the expected start date, there will be another reminder upon the actual start of the contracts. (Or if something unexpected comes up, an announcement for that.)

As both expect to start at the same time, this could be a tremendous productivity boost. Not only will they both have the opportunity to dedicate large blocks of time specifically for developing Haiku, but each of them will be working on the same project! Both of their minds would be in tune with their immediate tasks at hand and the larger picture. That would make bouncing ideas (and obstacles) off of each other that much more effective. It is specifically the nature of Haiku, Inc.'s contracts that fosters this type of cooperative development in a for-pay scenario. Instead of simply rewarding the completion of a product (without care for the implementation or the implications of future works), these contracts allow the developers to ensure their contribution is implemented with the future of the project in mind.

As there are over 2,000 open tickets for R1, there clearly are numerous areas of Haiku that are in need of improvement. However, so long as the contract proposals are for R1 items, it is not the practice of Haiku, Inc. to give preferential treatment to particular projects. Haiku, Inc. is always interested in receiving contract proposals.

If you appreciate these contracts and want to see additional contracts to accelerate the development of HAIKU R1, then spread the word and donate today!

NFSv4 client: three quarter term report

Blog post by Paweł Dziepak on Mon, 2012-08-06 22:09

I've recently been working on caching in NFSv4 client. It was essential in order to allow the client to be comfortably used. I can gladly say that the traffic generated by NFS client has been greatly reduced, thanks to metadata, directory, lookup and file caching. I've also implemented support for open delegations which, though not always available, allow the client to perform virtually all file operations without immediate server participation.

BFS Partition Resizer: Three-quarter-term Report

Blog post by ahenriksson on Mon, 2012-08-06 20:31

For this period, I have been working on getting resizing to work from within Haiku, rather than just in bfs_shell. In its current state, the code works, sometimes, if you don't stress it too much and write data to the partition while resizing. On the bright side, recovery from various errors is working well :). In terms of functionality, the only thing missing is the ability to grow full or almost full file system. The problem with this is that we need to grow the bitmap that tracks allocated blocks before we can actually make use of the new blocks. This can be overcome with a little slyness, but it's a bit of work, and adds some complexity.

I think it would be better to focus on getting the current code into a finished state. So my plan for the remaining time is to try to exterminate the remaining bugs, and polish the code. I'd also like to rebase my work into a neat patch set. The chances of finding time to add resize support to DriveSetup seem fairly slim at the moment. But since the task is independent of my other work, it might be something to start on if I run out of things to do in the last few days.

On a different note, I will be travelling away for two weeks at the end of the coding period (on the 18th), returning the September 2nd. Last time I went to an internet café my email account was hijacked, so I'll probably be accessing the internet sparingly. I hope this won't cause any trouble.

OpenJDK port: three quarter term report

Blog post by hamish on Sun, 2012-08-05 22:03

Since midterm I have been working on the jsound port, which provides audio, MIDI input/output and the ability to control mixer volume and other parameters.

After getting my head around some of the media kit concepts the implementation has gone smoothly. I implemented audio output support first, as I guessed this would be the most used component. It works well. Then I implemented MIDI input and output support. This is untested so far because I don't have any MIDI hardware. In the end I will probably end up constructing some dummy MIDI endpoints in another app for rudimentary testing. Audio input support is awaiting the availability of the SoundConsumer class, which might be included as a private API in libmedia, as the file cannot be included in OpenJDK because of licensing restrictions. Once this is in place I'll get working on the audio input support.

After that I'll implement support for "ports", which gives Java apps the ability to configure parameters on the system audio mixer. I should be finished in time for the suggested pencils-down date, the 13th of August. I didn't have time to get a new build ready for this blog post, but it's not very difficult to build from source. Build instructions are here: http://pastebin.com/4FhDAnyg

cpuidle: three quarter term report

Blog post by yongcong on Sun, 2012-08-05 11:34

I began to implement the acpi cpuidle driver so that the power saving feature can benefit all x86 platforms(In theory although). The acpi is more complicated than I thought. The main time is spent on implementing "_CST" evaluation and decoding.

First of all, to evaluate any acpi object/method needs acpi handle. Since haiku doesn't export AcpiWalkSpace method of acpica, so after system booting, I can get the acpi processor handle. the only solution is using the device manager so that the acpi cpuidle driver can be loaded during boot. This requires cpuidle modification so that generic cpuidle module is loaded by low level idle driver. The modification is not done because it's simple and I want to get "_CST" evaluation done firstly.

To evaluate "_CST", we need to evaluate "_PDC" or "_OSC" firstly. While "_OSC" is preferred than "_PDC" from ACPI 3.0. So my implementation evaluate "_OSC", fallback to "_PDC" if failed.

The "_CST" decoding is simpler than "_CST" evaluation. Some code is ready during gsoc bonding period. I just make it finished.

Then I came across one big problem which block me for one week--under haiku, the acpi processor is enumerated in "cpu8=>cpu7...=>cpu1" rather than "cpu1=>cpu2=>...>cpu8". The later order is taken by Linux, FreeBSD, NetBSD, etc. To evaluate "_CST" of cpu8 needs "_CST" of CPU1, so haiku's enumeration make the acpica reports AE_NOT_FOUND. But I dunno such requirement before, I even dig into acpica code but found nothing. After frustrated for about one week, I realized that the problem may exists in the evaluation order so I dumped the according processor id every acpi processor and found the reason. In no more than ten minutes, I implemented one workaround and it works!! Here is the CSTATES information dumped from my laptop

KERN: evaluate _CST @0x821e7698
KERN: cpuidle found 2 cstates
KERN: c1
KERN: Latency: 1
KERN: power: 1000
KERN: bufer length 17
KERN: cpu_reg size: 15
KERN: FFH method
KERN: c3
KERN: Latency: 104
KERN: power: 350
KERN: bufer length 17
KERN: cpu_reg size: 15
KERN: IO method

NOTE: Here, Cx is acpi reported Cx rather than OS's cx. For example, acpi's C2 is missing if AC is plugged. But Linux take ACPI C3 as the OS C2. I would like the take similar solution to make the generic cpuidle module happy

x86_64 port: three quarter term report

Blog post by xyzzy on Sat, 2012-08-04 10:50

I have continued to make good progress since my midterm report. All the kernel functionality except for user debugging is implemented, and I have ported a basic set of drivers, including PCI, disk drivers, BFS and PS/2 input. For most drivers, porting is just a matter of fixing compiler warnings. For some, there are 64-bit issues which make porting more difficult. For example, the USB stack will require a bit more work as it currently assumes that addr_t is 32-bit everywhere.

I have also made some progress in porting userland to x86_64. I currently have libroot, libbe, bash, and most of the command line utilities ported. I have got an interactive bash shell running on top of consoled (which is usually used to run gdb on if app_server crashes).

From Switzerland with chocolate

Blog post by mmu_man on Sun, 2012-07-22 01:51

Last week Olivier and I had the difficult task of handling the booth at RMLL and showing off Haiku in the land of gruyère, chocolate and banks.

Syndicate content