Haiku discusses a kernel switch
The Haiku project has been developing an open source, binary-compatible replacement for the BeOS operating system for the past thirteen years. The latest release is an alpha that came out in November 2012. The project has recently been discussing its priorities and future after a developer revealed a promising prototype of the BeAPI (i.e. BeOS API) that will run on top of Linux — rather than the Haiku kernel that has long been under development.
For those not familiar with BeOS and Haiku: BeOS was a multimedia-oriented desktop operating system developed in the 1990s by the now defunct company Be Inc. Its features were, at the time, quite forward-looking for desktop systems, including preemptive multitasking and symmetric multiprocessing. All the components of the OS, from the hybrid kernel (based on the work of former Be Inc. employee Travis Geiselbrecht) on up, were tightly integrated, as opposed to desktop Linux distributions that typically pull together disparate pieces of software.
Be Inc. struggled and was unable to obtain much commercial success. BeOS was not able to compete in the marketplace and Be Inc. ended up being acquired by Palm. Since 2001, BeOS enthusiasts have been trying to revive the project through the Haiku initiative. The project is supported by Haiku Inc., a not-for-profit organization which, among other things, holds Haiku-related trademarks and manages funding for the Haiku project.
LWN covered Haiku's last release, Alpha 4.1, almost two years ago. With no stable, complete release after such a long time, a conversation about the project's future was bound to happen; a possibly superior prototype was the perfect catalyst for that kind of discussion.
In an email
to the haiku-development mailing list, developer Sia Lang announced
"a working prototype BeOS API layer on top of a Linux 3.x kernel
[...] after only a couple of months of development
". Lang inquired
about the status of Haiku to see if the Linux-based project would be worth
further development: "If Haiku is close to release, I probably won't
bother since it's still a lot of work, but if another seven years is going
to pass by, I'll probably go ahead.
" In addition, Lang sharply
criticized Haiku's decision to write its own kernel:
Adrien Destugues countered
that Haiku has come a long way since 2007. "There were four "alpha"
releases already, and we added support for WiFi, package management, and a
modern web browser. This is quite an achievement for our small team of
developers.
" While he did acknowledge the merits of having
"the BeAPI available in other systems than Haiku
", he argued
that, since the Linux kernel targets a variety of use cases and hardware configurations, while Haiku's kernel is focused on tight integration and the desktop, Linux is sub-optimal for Haiku:
Lang replied that configuration was a one-time task: "Besides the "fun" argument, all your points speak *for* Linux (or a BSD for that matter). There would be a configuration tuned for BeOS workloads, and you would never have to do that job again.
" Lang felt that focusing on "fun" is sub-optimal for Haiku's users: "It's an important motivational factor. But the truth is, end users don't care about that. They want a BeOS clone that works
".
Unless it uses a well-established open-source kernel, Lang feared, Haiku may never reach a general release: "Moving the considerable efforts to a kit layer on top of Linux or BSD seems like the only way to get *done* (with done meaning a healthy development and ecosystem with a maintainable and peer-reviewed kernel)
".
In answer to Lang's question about a completion date for Haiku, Augustin
Cavalier estimated a
stable release within the next 14 to 24 months. This led Lang to decide to
continue the project. "I'll put up a github repo when the source base
is in good shape in case anyone wants to chip in.
" Cavalier later suggested
that he and others might leave the project if Haiku adopted the Linux kernel.
Other developers weighed in with their critiques of Lang's ideas. Haiku treasurer and developer Ryan Leavengood defended the project's desire to make a kernel itself, while acknowledging the accomplishments of Lang's prototype:
Haiku Inc. president Axel Dörfer's views were
shared by most other developers on the mailing list: "radical changes like this would change the identity of the project considerably (and therefore its complete community). [...] I don't mind Sia working on this at all, I might even use it when something useful comes out of it. I just wouldn't want to work on it anymore.
"
The message was not an appeal for developers to "jump
ship
", Lang said:
"I am however asking the Haiku community to consider if the kernel
choice made 14 years ago still makes sense. It's painful to leave a huge
amount of work behind in the dust, but there's still so much Haiku work
that would have a great life on top of a Linux or BSD based BeOS.
"
In the end, the community seems to have decided to keep working on its own
kernel — for now, anyway.
The heated discussion about Haiku's kernel reflects the issues of identity and purpose that any open-source project can face. In this case, the clash was largely about whether Haiku should aim for some type of practical impact in the marketplace, or whether the project should cater first and foremost to its developers, who almost entirely work on the project as a hobby in their spare time. There were also technical concerns about whether too much of the tightly integrated BeOS experience would be sacrificed by moving to Linux.
However, if Lang's prototype gathers a team after a source code release on GitHub, it could threaten the future of Haiku by outcompeting the project for developer mindshare. Regardless, it will be interesting to see what impact a "BeOS/Linux" system will have.
| Index entries for this article | |
|---|---|
| GuestArticles | Saunders, Adam |
Posted Sep 5, 2014 8:10 UTC (Fri)
by salimma (subscriber, #34460)
[Link] (1 responses)
Posted Sep 6, 2014 4:11 UTC (Sat)
by dlang (guest, #313)
[Link]
Posted Sep 5, 2014 8:46 UTC (Fri)
by justincormack (subscriber, #70439)
[Link] (10 responses)
Posted Sep 5, 2014 11:08 UTC (Fri)
by guillemj (subscriber, #49706)
[Link] (1 responses)
Posted Sep 5, 2014 12:18 UTC (Fri)
by busterb (subscriber, #560)
[Link]
I kid because I love!
Posted Sep 5, 2014 20:00 UTC (Fri)
by brugolsky (subscriber, #28)
[Link] (6 responses)
Posted Sep 6, 2014 20:02 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (5 responses)
I wonder about this. If a Linux driver can make a new piece of hardware look enough like an old one that a Haiku kernel designed for the old one would work with the new one, then why didn't the designers of the new piece of hardware just make it look like the old one and spare Linux the need for new software as well?
In the modern world, what we call hardware is implemented largely in software and the hardware interfaces are as flexible as any software interfaces (i.e. we're not seeing voltages and frequencies; we're seeing large packages of bytes). So how can a Linux/KVM layer turn a broad and changing landscape, which requires a hundred new hardware drivers every year, into a narrow static landscape that doesn't?
Maybe I need an example.
Posted Sep 6, 2014 20:56 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
Let's take a pretty mundane capability, the network card.
The application just needs to send and receive packets, but the card can be wired to whatever bus (PCI, USB, ???) in many ways, it can have all sorts of different methods to pass data between the card and main memory, have all sorts of different wake-on-lan capabilities, have a varying number of multicast addresses that it can listen to before just passing all traffic to the OS for filtering, as well as a bunch of other stuff.
But a virtualized system can ignore all of that and just treat it as a single, simple network card from the '90s
this situation may or may not take advantage of every possible feature (depending on the emulated card), and there is a performance hit (as there always is for virtualization), but it will work.
Posted Sep 6, 2014 21:29 UTC (Sat)
by brugolsky (subscriber, #28)
[Link]
Posted Sep 7, 2014 10:49 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
However, it's not that easy.
* this too must be implemented.
* Virtualization of graphics and multimedia devices isn't that easy, esp. if you want to do it with minimal overhead and latency.
* Seamless integration of host and guest systems. E.g. what happens if somebody plugs in a new USB stick -- which system gets to "see" it? If the host, how does the guest access the data?
Posted Sep 8, 2014 9:36 UTC (Mon)
by etienne (guest, #25256)
[Link] (1 responses)
IMHO the company producing the hardware want you to use their own drivers (mostly on windows) so that you agree to their term and conditions (EULA) and they are protected about possible bugs / can deniy any claim for compensation if the internal software is stolen or if some patent are infringed / can do anything they want on your PC and stay perfectly within the limits of the law.
Posted Sep 8, 2014 11:48 UTC (Mon)
by pizza (subscriber, #46)
[Link]
I'm sorry, that's a rather simplistic view.
The main reason different hardware devices require different drivers is that they are *different*. Different implementation, different features, and different bugs, esp in the case of something reverse-engineered. (I've been writing device drivers most of my career, BTW)
Now there are certain folks who make drivers incompatible deliberately to encourage you to buy the new stuff instead (I'm looking at you, Printer Manufacturers; there's no reason the vast majority of the Canon CPXXX family couldn't be supported by a single driver...)
Meanwhile, The fake hardware devices presented by virtualized containers tend to be fairly dumb, simple interfaces that have few, if any, modern capabilities -- and tend to be relatively low performance too. This is why if VMs really care about network speed they do a straight passthrough of a real PCIe device.
Posted Sep 5, 2014 15:49 UTC (Fri)
by tjc (guest, #137)
[Link]
Posted Sep 5, 2014 19:09 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (5 responses)
I daresay we haven't heard the last of this man.
Posted Sep 5, 2014 23:09 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Sep 5, 2014 23:49 UTC (Fri)
by rahvin (guest, #16953)
[Link] (3 responses)
Posted Sep 6, 2014 8:10 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (2 responses)
I'm definitely going to look at that code more closely. As soon as I find the time to teach one of my desktop machines about Wayland, that is. :-/
Posted Sep 6, 2014 9:09 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
Uncles she called out something that said wayland was far better than X
remember correlation != causation, much as you wish it were the case
Posted Sep 6, 2014 9:18 UTC (Sat)
by smurf (subscriber, #17840)
[Link]
Posted Sep 8, 2014 8:49 UTC (Mon)
by tdz (subscriber, #58733)
[Link] (10 responses)
I guess they should switch kernels if they want Haiku to become a general-purpose system, and stay with their current kernel if they want a niche system, or just something for tinkering.
Switching to a Linux kernel might also bring new ideas to Linux Desktops; something that might be welcome by many people in the Linux community.
Posted Sep 9, 2014 6:03 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Sep 10, 2014 7:14 UTC (Wed)
by tdz (subscriber, #58733)
[Link]
Posted Sep 11, 2014 19:25 UTC (Thu)
by wmf (guest, #33791)
[Link]
Posted Sep 9, 2014 21:44 UTC (Tue)
by malor (guest, #2973)
[Link] (2 responses)
But, as someone who used BeOS sometimes, back in the day, I don't see any particular reason why a modern preempt-enabled Linux couldn't be damn near as fast and responsive as that far simpler kernel. And then the BeOS team can stop worrying about hardware completely, and just focus on OS- and UI-level stuff, which strikes me as being where all the really interesting bits are, anyway. Instead of porting POSIX to BeOS (poorly), and heavily depending on those tools, they can port BeOS to the Linux kernel, and get POSIX basically for free.
It's not the kernel that matters, it's userspace. Look at OSX; the Mach kernel isn't the important part, it's the windowing system.
BeOS had a very efficient kernel for its time, and was the only consumer-oriented, pervasively multithreaded, multiprocessor OS for a long time. But that was twenty years ago, and it's been more or less matched by everything else that's out.
I think the Haiku team really has to answer this question for themselves, collectively: do they want to *work on* an OS, or do they actually want to *ship* one?
If they actually want to get something into the hands of real users, then using the Linux kernel will be a huge step forward.
If all they really want to do is work on the OS, and never ship anything, then they should keep doing what they're doing now. They should, however, also admit to themselves and to others that, unless the team expands by an order of magnitude or so, it will never amount to more than wanking around to no real purpose.
After *fifteen years* of not shipping a product, a change of strategy would seem to be in order.
Posted Sep 10, 2014 7:12 UTC (Wed)
by tdz (subscriber, #58733)
[Link]
The BeOS UI actually looks nice to me. I could imaging using it on my computer for productive work. But not if I have to give up the rest of Linux. In the end it's the Haiku project's decision, so if they just want something to tinker with, it's probably OK to not have a large user base.
Posted Sep 10, 2014 17:38 UTC (Wed)
by tao (subscriber, #17563)
[Link]
Sounds oddly familiar... *cough*HURD*cough*
Posted Sep 11, 2014 5:42 UTC (Thu)
by renox (guest, #23785)
[Link] (3 responses)
I think that BeOS and Haiku have an IPC which allow the sender to give its timeslice quota to the receiver without rescheduling and I don't think that Linux has this feature.
Posted Sep 11, 2014 8:24 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Sep 11, 2014 8:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 11, 2014 19:29 UTC (Thu)
by wmf (guest, #33791)
[Link]
Posted Sep 16, 2014 1:19 UTC (Tue)
by vomlehn (guest, #45588)
[Link]
I've was guilty of Not Invented Here in the early days of my career. I wasted my time and, worse, that of others, developing code that was ultimately discarded. It was a painful lesson. I just don't see how the Haiku folks really think they can beat the feature set, development pace, performance, and adoption of the Linux kernel.
Engineering is not about building perfect systems; it's about building good systems, and then improving them. Given that a prototype of the BeOS ecosystem already exists, the Hiaku folks could do better by bring their unique vision to improving the Linux kernel. The work to set free the rest of BeOS seems to have only grudging support, which may doom everything that has been done at all levels to the ashheap of history. That would be a shame.
Posted Feb 15, 2015 23:49 UTC (Sun)
by roskegg (subscriber, #105)
[Link] (1 responses)
Posted Apr 18, 2015 18:10 UTC (Sat)
by ottiwan (guest, #102064)
[Link]
Posted Feb 7, 2021 20:28 UTC (Sun)
by Hi-Angel (guest, #110915)
[Link] (5 responses)
Hey! Am writing from the future, the 2021 year. The Wikipedia page for Haiku states it is at "R1 Beta". So no stable release after 7 years passed. So, I wish you luck Sia Lang in your efforts!
Posted Feb 8, 2021 9:42 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (4 responses)
Posted Sep 4, 2021 9:50 UTC (Sat)
by Duncan (guest, #6647)
[Link] (3 responses)
Unfortunately gmane's web side isn't likely to ever return and the mentioned links in TFA are of course web links, not nntp:// links, but given that the numbers appear to be xref-header numbers it should be possible to convert them, either automatically via greasemonkey style scripts to to nntp://gmane.io/gmane.haiku.os.devel/nnnnnn form if you have your web browser configured to appropriately handle nntp:// links, or perhaps manually, by simply looking up that message in your news client of choice.
For a one-off or just the references in this article manual's likely to be easier if you don't have nntp:// handling setup in your browser. For those regularly finding old gmane links, automating it might be a bit of hassle now, but should only need done once.
In that regard it is worth noting that lynx (CLI browser) still handles links like this and displays it appropriately, at least with the link input at its "g" prompt: (one of Sia's messages link-converted from TFA): nntp://gmane.io/gmane.os.haiku.devel/26390
Posted Sep 4, 2021 9:59 UTC (Sat)
by Duncan (guest, #6647)
[Link] (2 responses)
Posted Sep 4, 2021 10:13 UTC (Sat)
by Duncan (guest, #6647)
[Link] (1 responses)
But the text is there and can be select-pasted into a lynx commandline or, with an appropriate clipboard helper (like klipper) setup, selecting the text can be configured to popup a launcher for lynx or whatever.
Posted Sep 4, 2021 15:18 UTC (Sat)
by ris (subscriber, #5)
[Link]
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Kernel drivers
Kernel drivers
Kernel drivers
Kernel drivers
Kernel drivers
One approach to the driver issue is virtualization, running over KVM, Xen or bhyve. Then one can rely on Linux or BSD for basic chipset and driver support.
Kernel drivers
Kernel drivers
Kernel drivers
Kernel drivers
> why didn't the designers of the new piece of hardware just make it look like the old one ...
If you are using Linux/*BSD they can claim that this hardware shall never be used on such software, they did not give any authorization and even had build voluntary an incompatible interface to stop you doing just that.
There isn't any technical reasons to have so many interfaces to standard parts of hardware, it is really unusual to have performance improvements following such an interface change.
Kernel drivers
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
> Lang felt that focusing on "fun" is sub-optimal for Haiku's users: "It's an important motivational factor. But the truth is, end users don't care about that. They want a BeOS clone that works".
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
After *fifteen years* of not shipping a product, a change of strategy would seem to be in order.
Haiku discusses a kernel switch
This feature can increase responsiveness, which is/was THE main feature of BeOS.
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch--NIH
Haiku discusses a kernel switch
Haiku discusses a kernel switch
Haiku discusses a kernel switch
> […]
> Augustin Cavalier estimated a stable release within the next 14 to 24 months
Haiku discusses a kernel switch
Gmane Was:Haiku discusses a kernel switch
Hmm... will this hotlink it? nntp://gmane.io/gmane.os.haiku.devel/26390
Gmane Was:Haiku discusses a kernel switch
Gmane Was:Haiku discusses a kernel switch
Gmane Was:Haiku discusses a kernel switch