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.

Haiku Grows Swap Support

News posted by bonefish on Fri, 2008-08-29 15:34

Thanks to Google Summer of Code student Zhao Shuai successfully finishing his project Haiku does now feature support for swapping. As of revision 27233 it is enabled by default, using a swap file twice the size of the accessible RAM. The swap file size can be changed (or swap support disabled) via the VirtualMemory preferences.

Swap support finally allows building Haiku in Haiku on a box with less than about 800 MB RAM, as long as as the swap file is large enough. I tested this on a Core 2 Duo 2.2 GHz with 256 MB RAM (artificially limited) and a 1.5 GB swap file. Building a standard Haiku image with two jam jobs (jam -j2) took about 34 minutes. This isn't particularly fast, but Haiku is not well optimized yet.

Haiku's swap implementation was heavily inspired by that of FreeBSD. At the moment it is not as sophisticated, but Zhao intends to borrow more of FreeBSD's optimizations.

[HCD]: status report

Blog post by emitrax on Sat, 2008-08-23 08:51

It's been a bit since my last status update, so I guess it is time for another one.

First of all, I'd like to inform you that I received the first half HCD payment. Since it's a (fantastic) community based effort project, I thought you wanted to know where your donations ended up.

As of commit r27159 you should be able to read data from an UDF partition. The module has not yet been added back to the image, as I'd like to do some more tests, but as far as I can tell, the port of UDF to the new FS API is close to complete, and you can start testing by adding the module to the image and trying using DVD formatted with UDF, or iso image made with mkisofs. Feedbacks are welcome.

As for the other part of my HCD, in case you missed, bonnie++ was added in r26920 and it is available for the braves one, for testing purposes.

In r27052 I also fixed another BFS deadlock that would lock the file system when more then one thread was writing in the same directory. See this for more info.

Ok, going to back to UDF now. ;-)

LinuxWorld 2008 as I saw it

Blog post by koki on Thu, 2008-08-14 00:14

Haiku made its "big stage" debut at LinuxWorld for the first time this year. If you follow the feeds on our website, you have probably already read the nice reports that Urias posted on the website during and after the show (day 0, day 1, day 2 and day 3). I thought I would give me own personal recount of the event, in order to perhaps bring a little bit of a different perspective, and hopefully also complement what Urias has already written about the show.

I had never been to LinuxWorld before, but I knew from reading about the conference that it was bigger to other open sources conferences we have exhibited in the past. I also had an idea of the demographics of the event, as I had done a little bit of reasearch before proposing our attendance last year. Average attendance was said to be more than 10,000 people, and by the size of the exhibit floor at the Moscone Convention Center in San Francisco and the duration of the show (three full days), this seemed just about right; this was obviously a very compelling number from the point of view of getting exposure for Haiku.

Haiku Down Under 2008

Blog post by Sikosis on Tue, 2008-08-12 02:29

In May this year, I wrote to the Haiku Mailing List, proposing that the Australian Haiku Users and Developers hook up with an existing Open Source event to generate some Haiku interest in our Country. It was decided that the cost of heading to a central event, would be too costly and as we are spread out all over Australia, I then started thinking about plans of doing something online - a Virtual Conference, so to speak.

As Haiku's Anniversary is coming up on the 18th August -- I figured, we'd try and have an annual event centred around this date. Due to the short notice, I thought it would be best to keep it as simple as possible, and as this is the first event, it can then be used to generate more interest and discussions around Haiku.

BeOS Joystick Framework

Article contributed by ModeenF on Mon, 2008-08-11 13:53

This article are more of a compliment to ITO Takayuki’s “BeOS Joystick Driver ” so reading ITO’s article before this one are advisable.

I’m not a article writing person (not even in Swedish) but as I’m the 3:d that tries to implement the Joysticks framework in Haiku I think that it would be good to have something for the 4:th person to read if I drop this :)

When I started to look over the Joystick framework I thought that this would not be that hard, boy was I fooled :) , lol I don’t even know how to talk to hardware. Anyway after some testing (trial and error style) I think I have found some additional information about the Joystick framework, but first I would like to describe how I think the frame work works.

The BJoystick class in libdevice.so talks to a joystick published at dev/joystick/”portname”/”joystick name” this way both the generic gameport and ITO’s usb_joy works as they publish as separate devices.
usb_joy = dev/joysticks/usb/0 (for the first)
usb_joy = dev/joysticks/usb/1 (Second and so on)
gameport = dev/joysticks/gameport/201
etc
emuxkigameport = dev/joysticks/ emuxkigameport /et18

emuxkigameport are a driver that was donated to Haiku that make’s gamport on a SB Live and Audigy soundcard work. I tried to add it to emuxki but then the sound was interfered when I moved the joystick. This driver uses the generic gameport.

So how does this work? You could say we have two ways of talking to Joystick’s, through usb_joy and emuxkigameport. First you must have a copy of a joystick description file in config/settings/joystick/”portname”/”joystick name”. I think that this need to be a copy of a description file as the Joystick Preference app does changes to the file so a link are not to recommend.

First usb_joy, when BJoystick sends a ioct (I haven’t tested but I think I have figured that one out right?) to the driver the usb_joy does everything by itself, collecting usb information and reading joystick description file from /settings/joystick/”portname”/”joystick name”.

How does the emuxkigameport work then? BJoystick sends the same information as with usb_joy but in this case the emuxkigameport forwared the ioct to a driver called generic gameport located under drivers/generic this one loads the file in config/settings/joystick/”portname”/”joystick name” with this file it knows what module to load and loads this module but it must be a joystick description file in this location or you will only be allowed to used the joystick in standard mode (same if the module don’t exist to your joystick).

Using BeOS Joystick Framework in Haiku. Yes this works but not usb_joy as it crashes the system.
You need to copy libdevice.so, Joystick preference app, etc/joysticks, media/joy, generic/gamport and Haiku’s emuxkigameport. I have only tested stickit and BeOS R5 joystick preference and not any games.

So what now? I will continue but perhaps focus on the usb_joy driver and figure out what’s wrong with this driver. I would like to have some help to determent if it would be a good idée to use modules in a USB drive to handle the difference in different joystick’s or does those difference not exist in a USB world?

If you like to read more about Joysticks in BeOS here are some links.
http://www.beatjapan.org/mirror/www.be.com/documentation/rel_notes/R4Rel...
http://euc.jp/beos/beosjoystick.en.html
http://www.haiku-os.org/legacy-docs/bebook/BJoystick_Overview.html
http://www.haiku-os.org/legacy-docs/benewsletter/Issue3-43.html#DevWorks...

Day 3 at LinuxWorld - Filled With Excitement

Blog post by umccullough on Sun, 2008-08-10 21:02
Jean-Louis Gassée visits us!Jean-Louis Gassée visits us!

Day three at LinuxWorld Expo 2008 started off with Scott McCreary dropping his car off at my sisters' apartment, and catching a ride to the Moscone Center with me. Despite nearly running over a few pedestrians, we made it there with plenty of time to get ready. Jorge Mare had to leave for home the evening before, so it was just going to be Scott and me this day. I had updated my laptop with a slightly newer revision the night before, and spent some time getting it setup to run live queries before the show started (which seemed to be broken for some reason before the rebuild.)

Special Visitors

It started off like the other days, didn't seem to slow down as much as I expected on the last day. We did have a couple of interesting visitors on this day indeed. Amy Bonner from IDG stopped by our booth to say hello. Amy helped us secure the booth space after we were turned down for a space in the .Org pavilion. She said she was really happy we could make it, and shared some ideas with us for next year's .Org submission. We gave her a complimentary T-shirt for helping us out this year. It was great to finally meet her in person, and we snapped a shot of her standing in front of the booth.

How To Get Haiku Booted

Article contributed by mmlr on Thu, 2008-08-07 16:47

This article is intended to explain in a nutshell how booting works in general, what the Haiku counterparts of standard boot process elements are and how to get everything together for a working boot in case this is not done automatically. These are things you will encounter installing/booting most operating systems, so it's not entirely Haiku specific.

1. The Basic Boot Process

1.1 The BIOS

When you turn on a BIOS based (as opposed to firmware based) system, which is still the most common today, the first thing loaded will be the BIOS (Basic Input Output System). It is like a small operating system of its own and has the purpose of configuring the system hardware and provide an environment that a more high level operating system can work with. For example it configures PCI devices, harddrive controllers, USB, the processor itself and sets up ACPI tables in main memory. Current BIOSes are quite a bit more advanced than they were in the past, commonly having support for USB keyboards and USB mass storage to allow operating in so called legacy free configurations (i.e. without the old PS/2 input and maybe without some of the more traditional PC architecture components). OK, not going into more detail as that's not essential here.

So when the BIOS has done its job, it will try to find a Master Boot Record (MBR) on any of the harddisk-like medias or other boot method specific block on other media (El-Torito on CDs/DVDs for example). Something like a USB memory stick is regarded as being harddisk-like, because it really is emulating a SCSI harddisk to the system. When it finds a boot record, it then loads that into memory and instructs the CPU to start execution of the instructions present.

1.2 The Master Boot Record

Generally this is just the first block of any harddisk-like medium, usually 512 bytes in length. It contains boot code in the first part and the partition table at the end of the block. What you have there as boot code depends on what boot manager you have installed. You have either installed a boot manager explicitly, for example GRUB or the BeOS boot manager, or it was implicitly installed for you when partitioning the device (during Windows setup for example). Boot managers range from totally simple ones that are just enough to find the partition marked active and jump to the partition boot code of said partition, to almost complete operating systems with editing capabilities and other fancy features.

1.3 The Partition Boot Record

Additionally to the Master Boot Record, there can also be a partition boot record. It's located at the start of a partition and contains further boot code. Depending on the boot manager you are using and how you configured it, this boot code will be executed or not. In the case of Haiku the partition boot code does locate the "/boot/beos/system/zbeos" file which then starts the operating system boot process. Additionally it contains the partition offset needed to access this partition during boot. A wrong value for that offset is probably one of the most common reason why a Haiku installation doesn't start to boot.

As mentioned, whether or not the partition boot code is used depends on the boot manager and boot manager configuration. If you take GRUB installed as boot manager in the MBR and booting Linux. GRUB knows how to handle most Linux filesystems and it does know how to load and start a Linux kernel off of it. Therefore it can directly load Linux without the need for any additional boot code. However GRUB does neither know how to handle BFS and find the zbeos boot loader, nor would it really know how to execute it. Therefore you cannot use GRUB to directly boot Haiku. Instead you need to chainload the partition boot code of the BFS partition, as it knows how to handle both the BFS and zbeos.

1.4 The Boot Loader

After the boot loader (zbeos in case of BeOS/Haiku) has been found and loaded into memory, it is executed. The boot loader is the one providing you with the Haiku boot menu when pressing the space bar in early boot and is the one detecting basic system configuration. It also contains the logic to find and load the kernel (kernel_intel on BeOS and kernel_x86 on Haiku) as well as some boot modules required. Boot modules include the bus managers, bus and device drivers required by the kernel to successfully access the boot volume to load the rest of the modules and execute anything it needs to fully boot the system. If you boot to an ATA harddisk it would require for example the IDE or ATA bus manager, the harddisk controller driver and the helper modules used by them. Booting from USB would require the USB bus manager, the host controller drivers and the usb_disk driver for example. The boot loader also provides the kernel with configuration information and info about initial memory layout for example. This data passing between the boot loader and the kernel is specific to Haiku and the Haiku revision, it is possible that the information passed changes from one revision to another. This also makes it obvious that a zbeos from a BeOS installation cannot work with a Haiku kernel. Likewise using a BeOS bootfloppy that provides such a zbeos is not going to boot Haiku.

1.5 The Kernel

Once the kernel is loaded and starts executing it sets up a working environment. Memory management, bootstrapping and configuring non-boot CPUs, timers, interrupts, filesystems, module infrastructure, drivers... Everything that is needed for a fully working system and has not yet been loaded. Once this environment is set up, the kernel will start the bootscript, that then launches the different servers to provide a usable userland.

2. Installing Haiku

If you intend to put Haiku onto a dedicated partition on your normal harddisk, you have several options to do so depending on your host operating system and wehther or not you intend to use a pre-built image or build from source.

2.1 Building from Source

Building from source generally has the advantage that you can do modifications, include optional packages and that making everything bootable is mostly taken care of automatically. On the other hand it is of course quite a bit more time consuming and resource intensive.

See the Building Haiku on Ubuntu Linux article for more details if you're building from Linux. Building from Windows is described in this tutorial, note though that under Windows you can currently only build images and not install directly to a partition. If you're building on BeOS see the tools section of of the getting started page and see this article on getting the source and building it.

2.2 Copying a Pre-Built Image

If you can't or don't want to go through building from source, you can also take an already built image. You can download those from Haiku-Files. Download a raw image, not a VMWare one. Note that these are test images, they are not complete distributions that include a lot of software, both to keep the size and complexity of building them down. Future releases will include a more complete set of software obviously.

When you've downloaded the raw image, you need to get this image to the partition or medium you intend to install it to. Under BeOS, Linux or basically everything except Windows you can use dd to just copy it over, using the partition or drive as a target.

# under BeOS to partition X on the master on the first channel
dd if=/path/to/image of=/dev/disk/ide/ata/0/master/X

# under BeOS to the raw slave on the first channel (overwriting the MBR)
dd if=/path/to/image of=/dev/disk/ide/ata/0/master/raw

# under Linux to partition X on the first harddisk
dd if=/path/to/image of=/dev/hdaX

# under Linux to the raw second SCSI disk (could be a USB drive)
dd if=/path/to/image of=/dev/sdb

Make extra sure that you have the right partition picked there, as these commands are destructive. Recheck with a partitioning tool to verify for example. Note that you'll probably need administrative rights under Linux, so use sudo or su to execute these commands.

If you want to put the image at the absolute start of the drive (so that you don't need an additional boot manager), make sure that you write to the whole raw drive and not to a partition. You do that by specifying a raw device instead of a partition. Under Linux you would for example omit the partition number resulting in "sdb" instead of "sdb1". Under BeOS you would pick the ".../raw" path instead of one with a number. If you use such a command, you overwrite the MBR containing the partition table. This means, that all the partitions on that drive will become inaccessible (not only the first part of the drive). So be sure that you want to do such a destructive operation!

Under Windows things are sadly a bit more complicated. You can try dd for Windows or use a tool like flashnul to get the image to a partition or USB drive. You should find the tools on the Internet, see this forum post about how to use flashnul to copy a Haiku image to a USB flash drive.

Note that when you just copy over an image to a partition or drive, you won't be able to use the full size of the target partition/drive. The image was built with a certain size (256MB currently) which is the size of the filesystem inside the image. So there's no real point in making a 10GB partition available for it, it won't be usable.

2.3 Copying the Contents of a Pre-Built Image

Instead of copying the image itself you can also make a separate BFS partition yourself and then copy over the contents of the image to that partition. You will need a platform supporting BFS to do that obviously, which leaves you with two possible options. Either you use a version of BeOS to do the setup with DriveSetup or mkbfs or you use Haiku itself with the Installer or DriveSetup. Once you've created and initialized the target partition you can mount the image (using tools like Mount Image or through the Terminal) and copy over all the files. If you are under Haiku, you can just as well use the Installer to make a duplicate of your currently booted installation.

3. Getting Bootable

Now that you have installed Haiku in some way or another there might remain steps to take to actually make this installation bootable. As you saw above, there are quite a few things involved when booting an OS. Some of the parts differ between OSes, not everyone might split boot loader and kernel, but essentially the steps are the same. Most of the things can and will be further automated when Haiku will be released, but others are more complicated and not within the power of Haiku.

3.1 Making the Partition Bootable

If you built from source directly to a partition the build system has most probably done the required steps to make the partition bootable automatically. If so you can skip this point and continue with configuring the boot manager below.

When you just create a plain partition and initialize it to a BFS filesystem or if you copy over a complete Haiku image, this doesn't necessarily make the partition bootable. The partition boot record may be missing, or the partition offset could be misconfigured. The prebuilt images for example contain a partition offset of 0 for example, since they are not actually partitioned. They only consist of a direct BFS filesystem, so the offset to that is 0. This will work in exactly one case, where you don't actually put it into a partition. If you for example copy such an image directly to a USB drive starting from 0, overwriting the MBR (destoying all partitions already there), then this will boot. If you however copy an image to the first partition on your harddisk, this will not work out of the box, as the boot code in the partition boot record won't find the desired filesystem at offset 0 (that's where the MBR still is).

To make sure a partition boot record is there and it contains the right partition offset, you can use the tool "makebootable". Makebootable will do both, write the partition boot code to the beginning of the partition and detect and write the partition offset to where it is needed. You can use the makebootable from BeOS if you have a BeOS installation that has access to the partition in question. To do that, mount the volume you have Haiku installed to and use:

makebootable /HaikuMountpoint

Where "/HaikuMountpoint" is where you have mounted your Haiku volume to. Note that the BeOS makebootable can be used, because the partition boot record does only load the zbeos boot loader. As Haiku does provide a zbeos as well and there is no information passed from the partition boot code to the boot loader, this is compatible between BeOS and Haiku and you can use a BeOS makebootable with a Haiku boot loader and the other way around.

If you already have some Haiku medium capable of booting Haiku (like a USB drive) you could also boot into Haiku and run makebootable from there. Note that there is currently a bug in makebootable that will require you to run it from the location it resides in like so:

cd /bin
makebootable /MountpointOfNewHaikuInstallation

If you are on Linux or another build platform that has support for makebootable and have the sources available you can run:

jam run ":<build>makebootable" /dev/sdaX

Where the "/dev/sdaX" is the partition that is supposed to be made bootable. Under Windows this is currently not possible.

3.2 Configuring the Boot Manager

When the partition itself is bootable, i.e. contains a partition boot record and the correct partition offset, there needs to be a way to get it executed. If you installed Haiku by copying an image to the complete beginning of a disk or USB drive, this will already be the case. There is no boot manager and no MBR at all, but straight the partition boot code, which should then work out of the box. So if you have it installed this way, go right ahead and boot.

If you use a boot manager like GRUB however, you need to instruct it to load from that partition. You do that for GRUB by adding an entry to its menu.lst usually located at "/boot/grub/menu.lst". The following would instruct it to switch to the partition and then just chainload the partition boot record:

title Haiku
rootnoverify (hd0,3)
chainloader +1

That would work if you installed to disk "0" and partition "3". Note that the GRUB naming is one-off the Linux one, so if you have it installed to "/dev/sda4" that would translate to disk "0" (sda == 0, sdb == 1, ...) and partition "3" (4 - 1).

In case you are using the BeOS boot manager, just re-run the "bootman" command and add the new Haiku partition to the boot menu.

If you have another boot manager consult its documentation on how to chainload partitions, most should support such a thing, possibly named a bit different. In doubt just add an entry for the partition, probably this will cause it to chainload, even if not explicitly named so.

4. Easy Installation through USB Drives

The above steps should get you going in most cases, but maybe sound a bit scary or involved. My personally recommended method that should work on most current hardware would be to make a dedicated USB drive like a USB memory stick to boot Haiku. To do that, you can take a relatively small USB drive that has enough space to fit the image onto. Then you just copy that image directly to the raw drive, not to a partition, replacing everything including the MBR, destroying all the partitions that were on there (see above as to tools to use). This is destructive and you can't use anything after the image size of that drive, but if you get some cheap small USB memory stick just for that purpose it's certainly one of the easiest ways to boot Haiku. Once you've booted Haiku you can also do an installation from there, initializing partitions with BFS using DriveSetup and using the Installer to do a proper installation. Note that you cannot currently create partitions under Haiku. Use your preferred partition tool to create a dedicated partition before booting Haiku. Note also that the Installer doesn't have a link in the Haiku menu, therefore just run it from the Terminal. If you additionally execute it from "/bin" this works around the makebootable problem, giving you the commands:

cd /bin
Installer

That should work and be pretty usable to boot devices that you have no other means to put Haiku onto otherwise. This works for example out of the box on the Asus EEE, but really should work for every USB bootable x86 machine. If it doesn't, please make sure that your issue is documented in a bug report at our bug tracker. We cannot fix it if we don't know that it's broken.

I hope this clears up some things. If nothing else this should get you a better starting point for troubleshooting if it indeed doesn't boot.

Syndicate content