Submitted by A very interesting discussion is taking place in the Haiku mailing list right now. A developer has created a working prototype implementation of the BeOS API layer on top of the Linux kernel, and he is wondering if the project is worth pursuing. He’s got the App, Interface and Networking Kits in good shape within a few months’ work.
While there are some minor downsides to having the kits on top of Linux (or one of the BSDs), the upsides include all the drivers in the world (well, the gpu driver situation could be a tad better), a rock solid kernel that works on all kinds of devices (who says BeOS can’t run on a phone, mine can), and a working BeOS clone with comparatively little effort (as a musical engineer, my biggest worry was sound system latencies, but it turns out many Linux schedulers can easily be tuned to handle the loads I expect in a BeOS system.)
I think the Haiku project made a monumental mistake in not using an existing kernel – it’s simply no longer practical for a small project to keep up with the hardware evolution, handling security requirements and so on. Sad but true, and it was sad but true back in 2001.
A very interesting and in-depth discussion follows. Both ‘sides’ make a lot of compelling arguments, and it gives a lot of insight into decisions that went into the Haiku project, both past and present. For once, I have no clear opinion on this matter; both sides have merit, and it in the end comes down to what the actual developers want to work on (hint: it’s not Linux).
Still, the developer in question will be putting up a repository of his Linux work, so we’ll get to see what it’s like.
I think this is similar to the whole argument of AROS, should it use a Linux kernel for the hardware support, then have some layer on top that is the Amiga 3.1 API? Granted there are distros out there like this, with ‘hosted on Linux’.
Don’t see why it should be any different for BeOS. Hell, with Qemu, you can basically launch straight into it, and have the qemu/kvm layer pass the drivers/hardware onto a VM, and have it be fairly transparent (I’m not sure how AROS does it, but I think it’s something similar.)
I just wish we could get a happy opposite, have the Android Linux kernel run some sort of full Linux distro inside. Sure there is chroot, but it’s not as fast as it could/should be with Android still taking up the majority of the resources.
AROS has ARIX for that end, even though it has been uneasily quiet from them for a long while now.
I get the merits, but the thing is that developers of these small OS’es care about their uniqueness and don’t want to mix it away in order to gain a little extra of this and that. And I agree.
I strongly suspect that once you have started taking the “easy road” you will become tempted to continue doing so, and keep making compromises in order to make your OS work with this foreign technology. Until one day Haiku becomes so entangled with Linux that some will simply ask themself “why bother? I can just as well just develop for Linux instead”.
And even if you do your best in order to “stay as unique as possible” you will still have to make the sure Haiku technology statys compatible with Linux. And I do think this will have the same effect as above since it might make it difficult to implement some solutions that would have been good or at least interesting with Haiku, but works less well with the Linux kernel.
Going your own way isn’t easy. But I bet it’s more fun and rewarding. Taking shortcuts in order to save development time will most probably erode this. I have heard several developers for several small OS’es say the same thing too.
On my machine, it [Haiku] works rather well for daily use. There are some bugs, but nothing I would qualify as critical. It is, for example, much more stable than Windows, and many people think Windows is good enough for real-world use.
This is of course patently untrue, unless he runs Windows 3.0. I’m sure I’ve experienced more crashes with Haiku than with Windows 7, and I’ve only tried booting it a couple of times. Windows is solid, far more stable than BeOS 5 ever was, and Haiku isn’t even near that stage yet.
And some other guy:
Adrien’s main argument (Linux’s lack of unification and need for manual tuning) stands. I’ve never had to personally configure the Linux kernel and I’ve had great compatibility, but the few times Linux crashed on me it’s been no easy feat to get it unstuck. Anything that uses the Linux or BSD kernels will be stuck with this. Hence why we’re writing our own kernel and designing it for the users.
As if your regular Linux end user does manual tuning. That’s their job. Or as if writing your own kernel somehow does away with the need for manual tuning. It’s still part of their job.
Of course, the only reason the developers need for not using a Linux or BSD kernel is that it doesn’t interest them. However, their mindless denial of the status of other operating systems has convinced me they’ll never ever get Haiku in a usable state.
Edited 2014-08-24 21:37 UTC
Haiku has been fairly stable for me, but of course it’s not as stable as Windows 7 nor any flavor of GNU/Linux I’ve run on that same workstation. Haiku has crashed a couple of times, but mostly because I was screwing around with trying to get a label printer to work on it and I was digging into files I don’t fully understand.
But no, Haiku is far from ready for daily use by the average user. I’m lucky that my hardware is more or less 100% supported, but the fact is that it is still in alpha and probably will be for some time. That’s perfectly fine for the tinkerers among us, but it’s far from ready for the masses.
And you know what? If Haiku never sees so much as a beta release, that’s fine too. It’s a labor of love, not a commercial venture. However far they get with it, I’ll happily be along for the ride.
I agree with this.
And more: the uniqueness of a OS does not depend that much on kernel at all. Indeed, the uniqueness of a OS depends much more on his standard library, default API, developer tools and choice of userland applications than the kernel.
If you write a new standard library and API, you effectively made a new OS. This is the case with Android.
Using Linux kernel (or any other) will not make your OS instantly compatible with GNU/Linux ecosystem. Actually, it will be not compatible at all.
A standard GNU/Linux distribution is actually the kernel, X11, glibc, perl, bash, sysVinit (or compatible), the default directory hierarchy… and goes on, and all configured in a very peculiar way, following lots of standards, written and non written ones. And is this peculiar set of standard applications and API that makes distributions compatible with each other, not only that all uses Linux kernel.
Indeed, the very existence of Cygwin only proves my point here: you can compile and run almost all “Linux” ecosystem on top of Windows if you want, with X11 actually being the single greatest incompatibility factor (the Cygwin one is outdated), not the lack of a Linux kernel running below.
Edited 2014-08-25 13:30 UTC
Extremely interesting thread
Looking forward to the conclusion. I like the idea, but of course the dev must stay motivated.
Edited 2014-08-24 21:42 UTC
As soon as you restrict yourself to using somebody else’s kernel, you give up control of the full stack and place yourself at the mercy of a bunch of other developers who may not have your best interests at heart. You’re also making the implicit argument that the Linux kernel is “the best” and that it’s pointless to compete, which is untrue and handily misses many points along the way.
Still, I’ll never tire of hearing people tell OS developers that they should “just” use the Linux kernel, and how wrong they are for not doing so. Even the FreeBSD developers have heard that one; I’m sure they found it equally amusing.
It’s worth noting that the thread also discusses FreeBSD as the kernel, I think the Linux thing is just a prototype example. FreeBSD would also be a great basis I think (maybe even dragonbsd?) As long as there are drivers…
Bah, as long as you cooperate with someone else the interests may be different, so what?
I find your whole post is disingenuous, suffering of NIH syndrome, code reuse vs code writing is not a black or white situation, it’s a trade-off!
As for FreeBSD, in many ways it’s older than Linux, so their situation is very different situation than Haiku.
Because their interests may be different? How long until the Linux kernel has to have DBus, just to be functional? Would an OS like Haiku want DBus? Well, tough luck I guess!
It is a trade off, and Haiku have got the balance correct. Anyone who thinks it’s “just” a matter to take a different kernel and then wave a magic wand to make it do what you want and fit your design goals is living in cloud cuckoo land.
It’s a boring and tired argument and anyone who has to fall back to “Writing your own kernel is just NIH” doesn’t have much of an argument at all.
Edited 2014-08-25 11:49 UTC
Linux, the kernel? Never.
Linux the OSs? Depends, many desktops distributions are using DBus, but embedded distributions won’t probably use DBus ever.
Hum, that’s what you say, but when you look at how long it took, still no polished release and about the (lack) of HW compatibility, it’s not so obvious..
Well let’s look at how far Haiku have got with their own kernel (actually of course, the NewOS kernel…) and compare that with how far BlueEyedOS & Cosmo got, shall we?
Well, two defunct and one barely a blip on the radar. So three OSes that went nowhere.
It looks like BeOS was a neat idea that was not to be, regardless of the used kernel.
If that’s your definition of success, then it is a great success, now by this same definition the GNU Hurd is also a success!
But curiously, not many think that GNU Hurd is a success..
Actually it was yours.
There are lots and lots of dead or nearly dead projects, outliving those isn’t really success.
I remember when BlueEyed OS was announced thinking (even though I think implementing BeOS/Haiku on top of Linux|*BSD is a good idea), this one will go nowhere: the guy starting the project doesn’t seem reliable.
And IHMO BlueEyed OS not only failed it also did a lot of harm, nearly ensuring that the idea of BeOS on top of Linux is dead..
I hope that Sia Lang proves reliable but it’s too early to tell, we’ll see.
So how we should we define success? Must Haiku be as successful as Linux in order to be considered successful, and nothing else will do? Perhaps it needs to shoot a little lower, and at least be as successful as one of the more major BSDs? Where’s “success”?
My definition of success is being released and work well.
And for Haiku, I would add and work well on a normal PC not just in a VM.
*If* they manage to get to this state then (whatever the adoption) it will be a great success.
There are many who thinks that Haiku will be released soon but note though that in Sia’s opening email, he talks about a developers who thought that Haiku was nearly finished 7 years ago..
I wish them ‘success’ but note that even if they manage to release it, the times are changing:
-I have a SSD in my PC which means that it boots fast and feels more responsive even without BeOS/Haiku
-Wayland will probably be ready before Haiku is released which will improve the responsiveness of Linux’s GUIs.
So the ‘competition’ is not standing still, will Haiku be as impressive as BeOS was?
We’ll (hopefully) see soon..
Well, don’t be too sure about that. There’s efforts underway to add k-dbus (kernel-side dbus) to the mainline kernel.
Supporting something != requiring something.
kdbus (for even faster, more efficient dbus messaging) is come to the Linux kernel. memfd already landed for the Linux 3.17 release.
Not that many things depend on dbus, just a number of the Linux desktops.
I’m sure when it’s part of the kernel, they’ll add things to systemd to use it though.
Edited 2014-08-26 11:34 UTC
Not to mention the insanity that is systemd. It’s bad enough that it has already infected most of the major GNU/Linux distros. I hope it never becomes a dependency for the kernel. I’m already preparing to go back to Slackware since it’s inevitably coming to Crunchbang Linux with the next release.
I think the Haiku devs know exactly what they are doing and they are on the correct path by continuing to develop their own non-Linux kernel.
I hope you realize some of them are keen on the idea of switching to linux or bsd after R1
So yeah, “they” know exactly what they are doing, but it depends on which of them you ask.
After R1 is fine, but to think they are going to switch kernels leading up to R1 is ludicrous. They’ve said in the past that the goal for R1 is a modern OS with full backwards compatibility with BeOS R5, and beyond that the sky is the limit. No one here is debating that.
What is insane about Systemd exactly?
It just controls way too much about the system for my taste. It was supposed to be a leaner, faster startup and nothing more, but they started throwing in everything including the kitchen sink, and it has become a single point of failure with broken, vague binary-only logging and other odd anti-UNIX-like behavior.
That, and the fact that the devs are apathetic towards fixing real, high priority problems like corrupted journals:
https://bugs.freedesktop.org/show_bug.cgi?id=64116
This doesn’t instill confidence that they even care enough about the project to get it to a stable point, yet all the major distros are lapping it up. It boggles the mind.
Well, obviously we’re well off topic to some degree. But not much.
Regardless of what their userbase thinks, FOSS developers do what they want which may or may not be what the non dev users want.
As far as systemd, I think its great. However, I also think its kind of an inkblot test that reveals more about the reviewer than the technology itself. Are you able to honestly evaluate a new piece of technology, without resorting to dogmatic, unarguable maxims? (XYZ should never be QWZ! Or its not QWRSF, therefore its wrong!) Systemd challenges a number of sacred cows and some people can’t get past that.
See my comment above as to why I don’t like the idea of systemd, and it’s not for dogmatic reasons, rather practical reasons.
I think systemd is the first real, major step towards closing up GNU/Linux and turning it into a binary blob just like Mac OS and Windows. If that’s what all the major distro maintainers want, so be it.
Honestly though, with the apathy its developers feel about it (again, see above comment and quote where the devs feel it’s “too hard” to fix journal corruption) I doubt it will be around for more than a few years at best. Something better and more open will come along, the major distros will see the light and jump ship again, and meanwhile old farts like me will still be running Slackware or *BSD or Gentoo and wondering what all the script kiddies are arguing about now.
Binary Blob? Its under the GPL, with no CLA. Developed in the open.
I think when most people write that they mean that they don’t like dbus, but I’m never sure as it doesn’t make sense in the way we normally use terms like “binary blob”.
While I agree with you, it’s hard to find the correct word for what he means..
I think what he means is either:
-systemd relies on socket activation, so fixing issues can require changing the applications.
Don’t know how to describe this.
-systemd doesn’t have a spec, and is becoming more and more inclusive and you cannot really replace one part by another implementation..
Here “tangled mess of binaries” could be a good description..
That’s pretty much what I meant, sorry for the confusion. It’s abstracting away all the things that make administering a GNU/Linux box easy and straightforward, into a nightmare of cryptic binary files with broken tools and apathetic devs who simply don’t give a shit.
My biggest problem with the project is that it is unnecessarily complicating things that should stay simple and straightforward, and that situation is further complicated by devs whose attitude is basically “I don’t feel like/don’t know how to fix it, deal with it”. Add to that the major distros eating it up like it’s their last meal, and it makes for a messy future for Linux based distros.
I don’t really understand that, honestly. Might need an example to comprehend.
I understand that to some extent. There are a few interfaces that they have promised API stability, and some they have not. But its not in general true that one part can’t be replaced with another implementation.
But the spec part is kind of weird. Is there any part of Linux that has a formalized spec? Does the Kernel? Any of its subsystems? SysV Init?
I do think that Systemd is still in kind of a growth phase where all sorts of new things are still happening as developers are realizing the power they have now and the how easy things become with systemd there. That kind of freaks people out, and they want some kind of order to emerge. And it will emerge, rather than being a top down waterfall process of a well defined spec. Its as much of the cathedral as needed with the benefits of the bazaar.
Yes, it tries to follow POSIX for the userspace interface and promise forward compatibility on the userspace interface (Linus is very strict on this point).
The thing is: it’s not so sure that the order will emerge in systemd: for example the Linux desktop ‘order’ hasn’t appeared even though it’s quite old already.
Fashion changes, hardware change, developers change and want to reinvent the wheel..
I think this is a big part of it, and it’s not limited to GNU/Linux either. Circling back to the on-topic discussion, some would say the Haiku dev team is reinventing the wheel with their NewOS kernel. But in that particular case, I think it’s necessary to achieve the goals they set for themselves so many years ago. Maybe one day they will adopt a different kernel so they can catch up with modern OS development.
Of course, the whole Haiku project was dedicated to reinventing the wheel ( BeOs). So, I’d kind of expect them to not reuse existing code.
While there is some truth in what you say, an OS is not a kernel: Android and RedHat look and behave very differently even though they have (mostly) the same kernel, Windows NT’s kernel is ‘heavily inspired’ by the VMS kernel (same lead dev) and again the OS are very different.
Well, yeah. Never really meant to say otherwise. But in order to accomplish their stated goal they had to re-invent many wheels, because of lack of source code availability,
See my reply to renox, but I was speaking generally about GNU/Linux gradually becoming more like binary-blob style commercial OSes, starting with unnecessarily cryptic and bloated projects like systemd. I think there will come a point where the average Linux administrator won’t be able to understand what is going on in the heart of the OS, won’t be able to just dig in and fix it, and that’s a problem. Combined with the current UEFI mess, we’re already headed down a dark path.
Edited 2014-08-26 15:01 UTC
I’m not sure I agree with either side of this argument, but you’re plain wrong.
Nothing stops Haiku or any other project from forking an old long term support kernel or using an RHEL kernel as a base. This should give them a stable ABI that can last 7-10 years.
FWIW stock android usually uses a fairly old kernel.
Edited 2014-08-27 03:40 UTC
Remember Cosmoe?
http://archive.today/qeLRP
http://www.haydentech.com/cosmoe.png
http://www.osnews.com/story/1075/Interview_with_Cosmoe_s_Bill_Hayde…
http://www.osnews.com/story/16634/Cosmoe_Developer_Seeks_Successor
http://www.osnews.com/story/17201/Cosmoe_Is_Back
If this is needed, in order to keep BeOS alive… more power to the developer.
In case the first link I posted stops working:
http://web.archive.org/web/20110208080755/http://cosmoe.com/
Sorry for that, but did not find the edit button in order to edit my previous post.
Cosmoe appeared at the start to be an overly ambitious project for a single developer – wrapping the API of both Atheos (currently a.k.a. Syllable) and Haiku over the Linux kernel.
I’m sure than when Linus started writing Linux, there was already lots of similar projects which failed..
So clearly he shouldn’t have tried!
Nobody is telling Haiku to stop developing its kernel actually, this is a side-project so we actually get another OS alternative (with Haiku userland on top apparently)
The point of the discussion over at Haiku is the fact that Haiku suffers badly from lack of resources (and drivers). Close to 15 years have passed and it seems to be far from ready.
The world was much simpler back when Linus started I guess.
You didn’t follow correctly the thread: it’s about the port of Haiku to Linux/*BSD, there were references about two older ports which failed, and I was pointing out that just because these two previous ports failed didn’t mean that the third one will fail.
Right, the proposal at hand is about reusing the entire Haiku userland, but on top of linux or bsd. Both approaches will move on, so all the better!
Around the time when OpenBeOS was starting there was another project that did exactly that – BeOS on top of Linux. I can’t remember what that project was called now, but it seems to have been long forgotten.
There’s a JLG quotation about how it’s a bad idea to build operating systems with layers of crud underneath which would be very pertinent.
Not just once, two attempts to stick a BeOS userland on top of Linux. The two candidates are BlueEyedOS from around 2001 and Cosmoe in around 2007. Both came up in the thread.
Looking back at discussions from the time is pretty hilariously similar actually, even here ( http://www.osnews.com/thread?210308 )
I wonder if he will be able to reuse some code from these older ports..
There was one major difference between the two – whereas Cosmoe made its source available, BlueEyedOS remained secretive and only released binaries.
And to some extent, it`s been repeated with ZevenOS ( http://www.zevenos.com/ ) which is still quite active.
I’ve tried out ZevenOS, and it’s just Ubuntu with a BeOS-like GUI. There’s absolutely nothing there that one can’t do themselves with an Ubuntu base install and some theme work. It feels and works just like a GNU/Linux distro, there is nothing of BeOS/Haiku to it apart from the theme.
Of course that’s not necessarily a bad thing; take Elementary OS. It’s Ubuntu with a very MacOS-like theme and feel. It works well, but at the end of the day it’s just a theme and WM change away from being stock Ubuntu.
Sigh, read the thread, this is not what’s being proposed at all. In fact, BeOS binaries will run as-is…
On ZevenOS? Really? Since when? ZevenOS, which I was specifically talking about, is a BeOS-like theme running on more or less stock Ubuntu. I think you completely misunderstood what I wrote, or else tried to attribute it to the conversation higher up about a completely different project. Again, I was speaking specifically about a themed Ubuntu variant, nothing more.
No, on the proposed BeLinux.
With JLG you mean Jean-Louis Gass~A(c)e?
Sometimes I wonder how the future of Linux would have been shaped if Jean-Louis Gass~A(c)e (after trying to sell BeOS to Apple and after he sued Microsoft) would have opened up the sources of BeOS and the Haiku guys would not have had the need to start from scratch.
(it could have worked out if BeOS started from scratch as well, with no strings attached to a third party…)
Talk about lost opportunities…
Edited 2014-08-25 19:33 UTC
The source was unclean, had loads of GPL violations and also had a significant amount of licensed code. If you removed all of that, not enough was left to make it worthwhile.
Not really. The source was leaked, *someone* compiled a PowerPC version dubbed R5.05. Then it was sat on due to the fact that lawyers would have litigated the perpetrators in to absolute oblivion. Look at what happened to YellowTab – they had a similar copy (possibly slightly different, not sure…). WTF, I don’t have a copy or a machine that would compile it any more, so it’s not going to affect me. I saw it, I compiled it, I ran it. The world didn’t change.
So Haiku is largely BeOS done right?
Hm, and what GPL code was violated the most?
All I remember was that there was a lot of GPL code integrated into the codebase and not all of it was ever released or declared.
There was no GPL infection AT ALL. Stop making things up.
I think it might be useful to sum up the Haiku mailing list thread as it’s finally dying out.
Basically some of the developers hated the idea of switching to Linux (or BSD), while others were actually quite positive towards such an attempt. Some long-timers have lost their belief in Haiku ever getting “done”, while some thinks it’s almost ready (hint: it’s not)
Some questioned the current focus and where to put the donation money (is it a hobbyist’s os or a viable attempt at a BeOS clone?)
All in all, the discussion isn’t changing any thing at all. People will work on what they find interesting and Haiku will likely be in alpha for another few years. Hopefully there will still be developers left at that point, but I’m rather dubious.
So basically the whole thing fizzles out in a big shrug.
Edited 2014-08-29 16:33 UTC
As someone who has made some (small) contributions to the BSDs, I admire the Linux kernel’s philosophy towards data structures using container_of and towards callbacks extending file semantics to driver structures. I have no idea why people have to fling insults like accusing the developers of other OSes of writing “low quality” code.
Also the decisions Linus Torvalds eventually makes are simply genius. The eventual Linux kernel evolution into having a frequent but small windows for introducing new features and rapid production of new versions is something that the BSDs really need to emulate. The closest to this ideal is what OpenBSD does with their half year release schedule.
Edited 2014-08-25 01:29 UTC
That’s not a good idea.
The power of all alternative OSs is – well – that they are DIFFERENT. Also, Haiku’s/BeOS kernel is far better designed then Linux one.
Other than that, having one size to fit all is just ridiculous, and it kills creativity and new inventions, bringing laziness into the image.
PS I’d like to have another good OS in case Lennart Poettering destroys the rest of Linux with his terrible systemd – idea to swap everything with one solution. Another bad example of unneeded unification.
Different OS doesn’t necessarily mean different kernel: Android is very different from Red Hat..
And it supports 0.1% of the hardware than Linux support..
That’s strange, the latest figures that I’ve pulled out of my ass indicate that it supports 97.3% of the hardware Linux supports. How mysterious.
Which one is right – 0.1% or 97.3%?
And does it really matter for the common user?
In the days of Be Inc, they had put together a BeOS DemoCD being as much as a demonstration of capability as a hardware test tool.
Using the Haiku Alpha 4.1 release (on a USB flash drive), one can do the same and test the hardware configuration being shopped for.
Alternatively, one could use a minimal Linux distribution (e.g. Tiny Core) and use it to run Haiku using virtualization.
I feel that the gap between the development nightly releases and the stable Alpha 4.1 is getting way too wide in terms of capabilities and compatibilities. With the work currently done on porting WebKit and WebKit2 to Haiku, it would be great is an Alpha 5 (or even better, a Beta 1) stable release is very close on the horizon. I’ll prefer that over a wrapping around the Linux kernel.
It was a joke. However, in the interests of science, I just downloaded and tried the latest Haiku nightly on my laptop (HP Pavilion G6; i5, Intel video & audio, nothing too exciting).
The media server was crash happy; I’ll give it a pass as it’s a nightly and the driver for the Intel HDA did seem to actually work, which was the important thing.
Hardware wise everything was fine except for my WiFi, which is a Broadcom BCM4313. It turns out that FreeBSD doesn’t support it either, which kind of puts lie to the idea that using someone else’s kernel magically gets you better hardware support.
Of course the plural of “anecdote” is not “data”, so take my experience with a grain of salt. It’s not too hard to give it a try yourself though, and the idea that Haiku somehow doesn’t support anything is obviously untrue.
renox,
Random statistics are unhelpful, never the less the underlying argument has some truth. When a project has to consider replacing it’s kernel with Linux because it has popular support rather than because it’s better suited to the project’s design goals, that’s an unfortunate reality. Mind you, I’m a linux supporter and I’m not saying linux has no merit. However there’s no denying the popularity of linux drives out other operating system/kernels that also have merit and are possibly even better suited sometimes.
There are certainly things alternatives can improve over linux. Off the top of my head: stable kernel ABI/API, better asynchronous syscalls, reduce reliance on blocking threads in the kernel, reduce legacy cruft, clean up procfs, etc.
Hypothetically alternative operating systems might decide to patch & support the linux kernel themselves instead of their own kernel. However realistically once they do, they’re going to face pressure to choose APIs which maximize parity with the Linux code base in order to achieve high performance & compatibility, thereby constraining their own creativity. So although Linux would be the easier choice, owing to it’s driver base, I don’t blame Haiku for wanting to keep it’s independence.
Edited 2014-08-25 14:03 UTC
LOL I needed that laugh.
The best case scenario would be to do both – in a similar vein to how Wine and ReactOS share code for mutual benefit. More of those “portable userlands” (plan9port, dosemu/dosbox, Darling…) is just a good thing
What’s Darling? (it’s pretty much impossible to Google
)
They could use paravirtualization and run a instance of Linux for the drivers like l4linux does. Then they could run their kernel with whatever API they wanted.
I think they should support very well a very limited number of hardware components which people could use to build their own BeBoxes and one or two current laptop models.
I see Haiku still has a CD player app. How cute.
If you replace the kernel, and then you slowly replace the userland to accommodate the new kernel, is it still Haiku?
If you replace the kernel, and then you slowly replace the userland to accommodate the new kernel(*), is it still BeOS?
*: for example, 64bit support.
We had something in the pipes for ZevenOS back in the days. But it was simply not feasible. Besides technological problems it did not make any sense for the users to have beos applications run on top of linux.
This was at least the most feedback we got back then.
People loved BeOS for the kernel and the desktop mostly not the apps.
I’m not sure exactly what you mean by ‘and the desktop’, but people didn’t love BeOS ‘for the kernel’, they loved it because of its responsiveness.
Why it was so responsive is difficult to know, being closed source, the kernel, the libraries, the application design, probably all played a part.
Now the question is: is-it possible to get the same responsiveness on top of another generic kernel (Linux and or *BSD)?
No one know for sure, I would be very surprised if it wasn’t possible: if this was really the case, I would expect a benchmark showing that Haiku’s kernel is better than Linux|*BSD at foo (foo being a benchmark showing the better latency).
Is-there such benchmark? AFAIK no.
I recall reading some analysis of why BeOS was so responsive.
It had to do with good use of threads and care was taken with the GUI messaging and task scheduling.
When a mouse click event happened for example, the event was sent immediately. The task receiving the event ran immediately. The GUI was updated again, immediately.
With Linux, and to a lesser extent Windows, the system is much more complicated. The amount of latency in a X Window app is pretty ridiculous. Also, last I read about it (may have changed), Linux is not very aggressive about immediately waking an app which is sleeping in a select or poll. The task sending the message gets to run its whole time slice first unless it blocks on something else.
This is actually the beauty of Linux – you can pick a scheduler optimized for responsiveness. Most distro’s doesn’t, but it’s an easy thing to do for this BeOS project.
I recall many ‘guess’, but nothing concrete which means that these ‘guess’ have to be taken with a lot of care.
Yes, but ‘a good use of thread’ is user space design, so Haiku could have done this on top of Linux too..
Giving your ‘slice of time’ to someone to improve responsiveness, seems like a good idea and Linux still doesn’t have this: there were discussion about an IPC which would allow this but AFAIK this went nowhere..
I think that you could try to emulate this by yielding the CPU just after sending the IPC, it wouldn’t be as good but would the difference be significant?
That’s not so obvious..
True, note though
1) X is user space and Haiku could have reused Linux without X, after all that’s what they did with NewOS..
2) Wayland is going to replace X soon, probably before Haiku is ready..
2) Mir is going to replace X soon
Well, the input server was running as its own process, the App Server ran as it’s own process. Each window was a BLooper, but was also backed by a secondary thread in the App Server. It’s not hard to see *how* they got the responsiveness….
I cannot help but noting that all of what you are describing are userspace design decisions which are mostly(*) kernel agnostic..
*: having a kernel supporting IPC with timeslice transfer is a plus for responsiveness.
BeOS was originally designed to be a micro kernel based OS. It’s hardly surprising that the main functionality is outside of the kernel. In every version that was publicly released (and by public I mean “legally” and “not leaked”) the networking was in userland.
Interesting discussion – and I`m pretty sure it was quite lively between the Haiku developers.
In many ways, I`m glad to hear that Haiku will not be switching to a Linux kernel.
The current Haiku kernel is based on NewOS – a kernel originally developed by Travis Geiselbrecht who happens to be an ex-Be engineer. One could think of it as a “BeOS Kernel 2.0” base. I like this better than a kernel based on 1970`s concepts.
i wonder what concepts are NewOS based on? it’s a modular monolithic design, exactly like bsd and linux, just more simplistic, which isn’t always a good thing
How the kernel design is approached – distributed, client/server, or monolithic – is only one aspect here. The concepts used for I/O and user interactions are another.
The desire for compliance to POSIX means some similarities to Linux for the interfaces and services covered by the POSIX standards. Nevertheless, given that the original developer of the NewOS kernel was an ex-Be engineer gives me hopes the many of the lessons learned during the development of the BeOS kernel have been captured and implementation.
Maybe just hopes – yet nothing wrong with a simpler approach to the resolve complex design issues.
Some years ago I would’ve recommended porting it on top of OpenDarwin, which never picked up interest mainly because of lack of an original Desktop Environment,
Historically it would have also been good as BeOS was designed as a replacement for the older Mac environment.
It’s probably too late to go that route and having their own kernel as it is right now makes the OS environment much richer that just basing on pseudo-unix variants.
A shame that Google didn’t base their ChromeOS on Haiku.
is that a joke?
Maybe it’s me, but it’s pretty trollish to jump on a forum of a community driven, non-profit project, bash the decisions that were made 11+ years ago, talk s**t about the state of the project now, and basically whip out the l33t e-penis and claim how great and easy it’s going to be to switch gears, and how stupid everyone was a decade ago and how they should have known how supremely awesome every other kernel is and will be, other than their own.
Developing the underlying kernel from scratch was one of the tenants of the project from the beginning. If you don’t like, go away, or fork it and develop you’re own thing and then put it out there.
I think it is just you. I didn’t read anything trollish, any bashing or “talking shit”, nor did I see what appeared to be a virtual penis being inserted anywhere. No name calling, no belittling of kernels, just an honest question from a curious developer looking for feedback from a community he obviously respects and admires enough to want to adapt its project to what he feels might be a better path.
I agree with you that the the developer in question should fork Haiku to run on the Linux kernel, which is exactly what he intends to do. I honestly don’t see why you’re so bent out of shape over this to the point of making wildly exaggerated accusations, and I’m a long time supporter of Haiku, and of their work on their own kernel.
Did you even read the summary? That’s what she/he does…
11 years ago: BlueEyedOS is a BeOS-inspired operating system powered by a Linux kernel. What if people had embraced that idea then?
As I said above, I think that the lead guy of BlueEyedOS wasn’t someone you could trust: he was unclear about the license of BlueEyedOS.
You need two things to have a successful project: a good idea and developers you can trust..
Based on last night reading all the discussion on the mailing list between Sia and others, honestly I am curious about Sia, his/her skill and/or the project. In my view it seemed like that if Sia thinks he/she is the best and others should listen to what he/she is saying. I do not trust person with such behaviour.
he does come across as a guy with strong opinions, which is sometimes necessary when a project is stuck like this… but it all doesn’t matter much, there will be a technical session at BeGeistert in a couple of months. let’s just wait and see, since everything will probably be answered there.
Edited 2014-08-26 10:21 UTC
So Sia is like Linus?
Well… that’s good (for the project).