The Haiku alpha release has always been a bit elusive. The project has been near the alpha release for a while now, but a number of difficult data-destructive bugs kept it at bay. After an informal coding sprint, the alpha is now just a decision away.
Several key Haiku developers came together last week for an unofficial coding sprint. During this sprint, they made major headway in a vast array of aspects of the Haiku operating system, such as improving the HID driver, file system problems, and many other things.
They also discussed the almost mythical first alpha release of the project, and concluded that nothing is really stopping this release from materialising. This is what they had to say about it:
We have talked about it a lot and I am happy to report that we don’t consider any remaining issue serious enough to hold it back any longer. We just don’t know what to do with the IDE versus ATA stack. On the one hand, the ATA stack doesn’t have some problems of the older IDE stack, but Michael himself said that the new ATA stack is actually slower. And then it has some new problems of its own. Tough call, but as soon as we have made up our mind, I think we are good to go! Exciting times!
This means that the alpha release is now tantalizingly close. These are indeed exciting times for the Haiku project, which has been underway for a very long time now, never doing any form of an official release. The project is quite careful with giving users the wrong impression, and they don’t want to give people the wrong idea about the project’s current state.
As soon as an alpha release has indeed made its way onto the web, I can guarantee you I’ll be doing a little celebration dance. Here’s to hoping they get the IDE vs. ATA issue worked out quickly!
Alpha, time to Be
ATA is the Future
No more IDE
Nice one
Just to be clear though, for those who aren’t familiar, the ATA bus_manager does support legacy IDE devices, it’s basically just a rewrite as the IDE bus_manager code was an old hacked up version patched together in the earlier days.
It fixes several issues that prevent the IDE bus_manager from working with modern AHCI/SATA controllers (often generating interrupt handling problems and/or KDL at boot), and is a cleaner design.
There’s been a space on my hard drive waiting for this for several years. Well done the haiku team!
Same here. Too bad I already pretty much gave up on the machine I was originally going to put it on (a Gateway from 1997-1998 with 64MB RAM and a 6.4GB hard drive that’s hard to run just about anything on). Who knows, I might just boot it up once again just to try Haiku on, but I doubt I’ll do much with it at this point.
What is the CPU in it? slap some more pc100/133 in it for $5 and if its a slot1 p2 or so, nab a faster slot1 p3 for $20 and you’d be good to go
Pentium II, 266 MHz. I think the machine takes PC66 memory, I looked into upgrading it but PC100 was the lowest I found. At this point, I honestly don’t think it’s worth saving; it even fails to boot correctly every once in a while (doesn’t send a signal to the monitor, and when trying to shut down, a hard shutdown by holding the power button is required). Its backup battery just died recently too, which is no big deal, but I doubt I’ll even replace that. It’s just seriously showing its age, and probably hasn’t even been used regularly since before 2000.
There’s no chance in hell that this will ever come to PowerPC is there?
I might have to get an x86 machine somehow.
Interesting assertion… there have even been some PPC patches as recently as a few weeks ago:
http://www.freelists.org/archive/haiku-development/07-2009
Granted, it’s definitely not top priority, and not likely to be usable before Haiku R1 on x86 is a reality
I don’t think I’ve ever been happier to be wrong than I am now.
Thanks.
http://www.freelists.org/post/haiku/Haiku-PowerPC-builds
It’s been nearly 8 years since I reluctantly said goodbye to BeOS on the desktop, and watching the major FOSS and commercial desktops stumble around grasping at ideas that Be got right in the early days has been funny, in a sad kind of way.
I never thought Haiku would get this far. Congrats to everyone involved! Only good things can come of your hard work and dedication.
Just wondering, since I have never used Be, but what exactly are you talking about? What did they get right all that time ago that hasn’t already been copied these days?
A file manager without the need of a refresh button
Just a small example!
A boot time so fast you didn’t mind restarting – except for the fact that it would reset the up-time counter ( obviously ).
In fact, I managed a SHOCKING 2-3 second boot time with some hacking ( some == butt loads ). Sadly the IDE / ATA systems today introduce a nice delay in the sequence on modern systems ( and 8 second boot time is 6.5 seconds of waiting for the hard drives to be recognized ).
–The loon
How many times have I heard this, and even so it’ll take a long time for haiku to gain the usefulness of Windows or Linux (in current apps). I’ll believe it when I see it – until then I’ll continue to build my own iso.
Uh, oh… I simply can’t wait.
What’s the point of yet another operating system? Everybody should just contribute Linux instead.
I used to think exactly like you until I found out that I was sorely wrong. Linux is still primarily optimal for servers* and there is a good need of optimal desktop operating system of general use. Haiku, and probably AROS, is filling it.
*Monolithic kernel-based Unix-based architecture is still the best server.
Even though I use Linux based systems pretty much exclusively, I disagree with your assessment. And, normally, I would let it rest with this disagreement, but I’m in the mood for a little rant, so please bear with me:
Let’s say – just for the sake of the argument – that you run a small ( e.g. 0 to 10 employees, local customer base, etc. ) computer shop. If the shop is – in the long run – profitable and operating in a sustainable fashion (e.g. customer satisfaction is high, customer bonding is good due to your unique selling points/special expertise/reliability, etc. ), then it is usually considered to be run successfully.
I wonder how many folks show up at such shops and suggest that they do something wrong because not only are they too small to tackle Dell, they are even smaller than for example zareason or similar alternative vendors.
For non-profit organizations, the idea of equating success with a globally recognizably market share seems – at least to me – even more bizarre.
Back on topic: Haiku is a very ambitious project. They roll their own default file system, their own kernel and drivers, their own graphical environment, etc. . Their personal situation seems to be stable (e.g. long time commitment of the core devs, recruitment of fresh programmers seems to work, loyal testing and user base, etc. ) and they are open enough to avoid situations like those SkyOs recently run into.
Overall, Haiku seems to be successful and sustainable and now it should be “large” enough to handle the daily onslaught of problems that alternative operating systems face once they release their end-user versions
(e.g. bugs and feature requests, driver updates and so on).
Stopping working on something that the developers seem to enjoy and which is showing signs of success ranks among the more stupid things I can think of. And frankly, we (= the F/OSS community) *need* alternatives to Linux and the usual *nix centric stuff that runs on top of it, if for no other reason than to ensure that the interoperation between different (and in the case of Haiku: very different) user-lands and graphical environments works. We should encourage everything that leads to more portable and modular software. And frankly, we need input from players like Haiku, Syllable, even ReactOs or SkyOs in initiatives like freedesktop.org (at least once they have fixed their current problems).
I don’t fancy a future where Linux does to other alternatives what the 90% market share of MS (and the dominance of IBM and their clones prior to that) did to our computing environment and our perception of “success” and “failure” in the field of software development.
As (for example) Android show, the Linux kernel isn’t restricted to running the usual *nix stuff ( MacOS X show the same thing also: the same kernel can be use to make very different OS).
We need alternatives to classic *nix stuff, this I agree (BeOS had many advantage over classical *nix stuff), but alternatives to the Linux kernel?
Not so much, especially since it’s possible to maintain the alternatives as a fork of the ‘vanilla’ kernel if the main developers don’t want to integrate a change.
The ability to run pretty much any user-land you can think of on top of a typical *nix style kernel is a great feature. It has (among other features) guaranteed the relevance of this class of operating systems for the past decades and it will ensure that Linux, the *BSDs or Solaris won’t fall into irrelevance any time soon. And, just to make this clear, I have absolutely nothing against the “typical” *nix stuff. In fact, if I can choose, I vastly prefer a classical *nix style setup with X11 and a graphical environment like KDE or XFCE over most alternatives.
So, given my preference for *nix Kernels and setups, why do I think that having strong alternatives to Linux is important?
– There are a lot of potential F/OSS operating system developers out there that prefer to work on tightly integrated, modern, non-Unix-alike kernels. I guess the whole F/OSS ecosystem could do with more developers regardless of their preference for operating systems.
– Having alternatives to the tested and tried UNIX kernel model for studying security and performance related topics doesn’t hurt either.
– In related news, having a larger number of different (and for that matter: incompatible) operating system kernels with a significant installation base hopefully *should* result in a better and more coordinated approach to reverse engineer, document or lobby for hardware specifications. Yeah, I know, given the past experiences with common reverse engineering efforts of – for example – the OpenBSD and the Linux wireless team, this is not the most likely outcome, but even a geek should be allowed to dream. Given the current everybody-reinvents-square-wheels-on-its-own practice, I fail to see any potential harm in one more player participating in the process of writing drivers for alternative operating systems.
– Non-Kernel related, but nevertheless: Having an larger developer- and userbase who push F/OSS alternatives in order to provide the “desktop experience” regular users kind of expect nowadays should be beneficial for all F/OSS operating systems alike. More importantly, a larger number of target operating systems with a visible installation base means that the projects behind our toolkits, toolchains and common auxiliary libraries have to place a stronger emphasis on being cross-platform and open.
That’s a very healthy way of looking at this. You hit the nail on the head! Thank you for a very insightful and balanced comment.
http://www.osnews.com/story/21944/The_10_Most_Annoying_Things_in_In…
You guys should take things less seriously
MAKE IT SO!
I have been looking forward to this since day one which is the day OpenBeOS was born. Good luck Haiku developers. I have no doubt in these developers.
I have tried the Haiku image a few times. Seriously, it behaves and looks exactly like the original BeOS except for one minor difference and I could be wrong so correct if I am wrong but I think the scroll bars in the original BeOS look different compared to the ones in Haiku?
The look has been slightly modernized a few months ago, but anyway, the real beauty is in the code
It’s not fully optimized but it already surpasses BeOS in a lot of areas!
Edited 2009-08-06 10:13 UTC
If they look the same as the original BeOS that would be great.
Haiku does still look similar, but a few month ago I gave the look a serious overhaul, since it looked very dated. I don’t want anybody to have the impression they use something from the past, when Haiku is actually quite modernized in many aspects, compared to BeOS. Haiku is not a “retro”-OS. You may view it as such if you don’t look closely, but that’s not what we Haiku developers have in mind. Unfortunately, it took us much longer to be where we are now, so the OS Haiku is reimplementing is really something from the past, but that doesn’t mean Haiku itself is something from the past, since it’s meant to be 100% compatible, not 100% the same.
I was always somewhat under the impression that the point of the initial release was a retro operating system that would be used as a base for something more modern. Are the normal expected things of post 2000 OS going to be in the initial release now, multiuser stuff etc?
Full multi-user support is unfortunately not one of the things that will be in Haiku R1, since that will break a lot of stuff. We created new technical foundations where we couldn’t bear with how it worked in BeOS, but could still stay compatible (which is an important concern for our first release), for example interface layout management, new icon engine, automatic screen detection, and many more things in the details. But overall, it has helped the project a lot to stay focussed, that we could always say Haiku R1 targets the features of BeOS R5 only, whenever a discussion would otherwise go out of hand. There had been other project to recreate BeOS, which seemed to have a great head start when they would build on the Linux kernel for example. But somehow, those project never gained the necessary momentum to follow through. So it seems that the Haiku founders (I only came to the project at a later time), set things up quite well.
I just repaired an nForce 2 Socket A motherboard and discovered that it gives me noticeably better performance, in Haiku, using the same CPU/memory/video card, than my Jetway V266B board. Methinks either Via chipsets stink in general, or Haiku devs simply don’t have the chipset information or desire to work on the older Via Socket A chipsets.
Needless to say, I am pleased by all the progress Haiku is making, even if it means I have to get a newer chipset board to see the full potential of Haiku come through.
Keep up the great work, Haiku!!!
Latest discussions have Axel (one of the lead developers) proposing a code freeze on the 15th August, and release aimed at 1st September.
http://www.freelists.org/post/haiku-development/alpha-release-windo…
This is still being discussed, with some thinking that since the Google Summer of Code is still in progress that it may be sensible to delay Alpha a few weeks.
As for me, I think an alpha is an alpha. I have no expectation of a code freeze, and expect chunks to get completely replaced before beta comes around.
Roll on September 1st!
I finally tried the latest Haiku image out on a quad core 9400 with 8GB built for OSX and Vista. Haiku booted like a charm after it had first failed on my crufty old BeOS K7 and another old sempron. I had always dreamed this might come true, all 4 cores busy in Haiku land, but couldn’t quite believe it. It recognized >3 GB of ram, bye bye the old ram limit.
Vista64 could not write the image file onto anything with flashnul so I put XP back on the old sempron. and flashnul then wrote the USB Flash stick and a 266x CF card with the haiku image just fine.
The CF card only booted on the 9400 with a CF card IDE adapter and it was pretty fast and responsive, but it used up the only IDE slot present. In a USB card reader, no boot. I added a hard drive and initialized it to BFS as a single 140GB partition, another limit gone.
The USB Flash stick also booted fine but was obviously much slower but it freed up the IDE slot for some disk to disk copying. Time to try out some old BeOS apps.
So far the USB, network ports don’t seem to work yet, but on board sound did. The nVidia card is limited to 1280,1024 mode. I sure hope one day Haiku will recognize a pair of wide format screens.
Also I see file copying and even deleting continually fail and kernel panic after a few hundred files processed and the copied folders don’t always show up. I sure hope these Tracker bugs get fixed soon or it will be difficult to move on.
All in all pretty impressive for pre alpha. Hopefully a lot more developers will come in and squash these bugs. I recommend a fast CF card over USB flash stick, you can still write it with flashnul in a card reader.
Good work Haiku team
mm… afaik, Haiku suffers from the same problem of device memory mapped into the 4gb space, pretty certain it doesn’t support PAE yet. Maybe you’re lucky because it simply didn’t support your video card properly
You should file a ticket at http://dev.haiku-os.org with your listdev output (or lspci -nn from linux). Most network chips are supported, USB obviously worked, the nvidia card is probably too new. You’re likely seeing VESA mode video there (and yes, it’s *fast*).
Widescreen monitors are indeed supported, as Haiku drives my 1920×1200 just fine with the intel_extreme driver. I believe there is dual-monitor support with Radeon and nVidia drivers, but certainly not without proper support for your card
Hopefully rudolf will work on that again someday
If it’s a KDL, it’s not a tracker bug, but something wrong either with the filesystem or vfs layer. You obviously need to file bugs on these issues, this stuff has been heavily worked on recently, and some regressions may have been introduced. Could also be driver related i suppose.
Bugs can’t get squashed without reports. So far you’re the only one reporting the KDLs during filecopy, so *you* are the only one that can report them. Please do!
As for the whole flashnul/dd thing – Alpha will be released with a LiveCD ISO so more people can install it directly. Just wait
For the memory, I will try some smaller amounts or less DIMMs to see if that is having some bad effects, 1/2, 1, 2, 4GB etc.
I can also try out some older video cards. Pity I can’t use the old BeOS ATI AGP twinhead but that was for dual 1600×1200 CRTs. I am glad you have 1920×1200 working so I will shoot for that too. I also have a 2nd 2048×1152 LCD so that will give any twinhead driver another headache.
On USB I should have said it wouldn’t mount hard drives with a USB adapter so far, although the mouse, KB and flash stick worked.
For networking I also tried reusing my trusty old BeOS DEC card but still not connecting.
On file copying, it didn’t help that the 2 drives were uncooled and got pretty darn hot. After the reboot the drives were fan cooled and the copying went somewhat better but still freezes or KDLs later. Even BeOS used to have issues with copying x GB drives but I also had 1GB in that box too.
I will be filing tickets as soon as I have tried out a lot more corners with various hardware changes.
Can’t wait for the LiveCD ISO now!!!
I see bebits, haikuware are back up, hurrah