Linked by Thom Holwerda on Sun 24th Aug 2014 20:29 UTC, submitted by mikeanderson
BeOS & Derivatives

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.

Order by: Score:
Interesting.
by leech on Sun 24th Aug 2014 20:55 UTC
leech
Member since:
2006-01-10

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.

Reply Score: 2

RE: Interesting.
by Yasu on Sun 24th Aug 2014 21:27 UTC in reply to "Interesting."
Yasu Member since:
2014-05-15

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.

Reply Score: 7

No it isnt
Member since:
2005-11-14

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

Reply Score: 14

Morgan Member since:
2005-06-29

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.

Reply Score: 6

CapEnt Member since:
2005-12-18

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

Reply Score: 6

wow
by mikeanderson on Sun 24th Aug 2014 21:38 UTC
mikeanderson
Member since:
2014-08-22

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

Reply Score: 1

Ah, that old chestnut
by Vanders on Sun 24th Aug 2014 21:45 UTC
Vanders
Member since:
2005-07-06

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.

Reply Score: 9

RE: Ah, that old chestnut
by mikeanderson on Sun 24th Aug 2014 21:49 UTC in reply to "Ah, that old chestnut"
mikeanderson Member since:
2014-08-22

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...

Reply Score: 5

RE: Ah, that old chestnut
by renox on Mon 25th Aug 2014 09:22 UTC in reply to "Ah, that old chestnut"
renox Member since:
2005-07-06

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.


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.

Reply Score: 3

RE[2]: Ah, that old chestnut
by Vanders on Mon 25th Aug 2014 11:45 UTC in reply to "RE: Ah, that old chestnut"
Vanders Member since:
2005-07-06

Bah, as long as you cooperate with someone else the interests may be different, so what?


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!

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!


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

Reply Score: 3

RE[3]: Ah, that old chestnut
by renox on Mon 25th Aug 2014 11:58 UTC in reply to "RE[2]: Ah, that old chestnut"
renox Member since:
2005-07-06

Because they're interests may be different? How long until the Linux kernel has to have DBus, just to be functional?


Linux, the kernel? Never.
Linux the OSs? Depends, many desktops distributions are using DBus, but embedded distributions won't probably use DBus ever.


It is a trade off, and Haiku have got the balance correct.


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..

Reply Score: 3

RE[4]: Ah, that old chestnut
by Vanders on Mon 25th Aug 2014 12:54 UTC in reply to "RE[3]: Ah, that old chestnut"
Vanders Member since:
2005-07-06

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?

Reply Score: 3

RE[5]: Ah, that old chestnut
by r_a_trip on Mon 25th Aug 2014 13:15 UTC in reply to "RE[4]: Ah, that old chestnut"
r_a_trip Member since:
2005-07-06

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.

Reply Score: 5

RE[5]: Ah, that old chestnut
by renox on Mon 25th Aug 2014 13:40 UTC in reply to "RE[4]: Ah, that old chestnut"
renox Member since:
2005-07-06

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..

Reply Score: 4

RE[6]: Ah, that old chestnut
by Vanders on Mon 25th Aug 2014 14:01 UTC in reply to "RE[5]: Ah, that old chestnut"
Vanders Member since:
2005-07-06

If that's your definition of success


Actually it was yours.

Reply Score: 2

RE[7]: Ah, that old chestnut
by renox on Mon 25th Aug 2014 14:22 UTC in reply to "RE[6]: Ah, that old chestnut"
renox Member since:
2005-07-06

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.

Reply Score: 4

RE[4]: Ah, that old chestnut
by phoenix on Mon 25th Aug 2014 20:10 UTC in reply to "RE[3]: Ah, that old chestnut"
phoenix Member since:
2005-07-11

"Because they're interests may be different? How long until the Linux kernel has to have DBus, just to be functional?


Linux, the kernel? Never.
"

Well, don't be too sure about that. There's efforts underway to add k-dbus (kernel-side dbus) to the mainline kernel.

Reply Score: 3

RE[5]: Ah, that old chestnut
by renox on Tue 26th Aug 2014 08:14 UTC in reply to "RE[4]: Ah, that old chestnut"
renox Member since:
2005-07-06

Supporting something != requiring something.

Reply Score: 3

RE[4]: Ah, that old chestnut
by Lennie on Tue 26th Aug 2014 11:31 UTC in reply to "RE[3]: Ah, that old chestnut"
Lennie Member since:
2007-09-22

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

Reply Score: 3

RE[3]: Ah, that old chestnut
by Morgan on Mon 25th Aug 2014 13:20 UTC in reply to "RE[2]: Ah, that old chestnut"
Morgan Member since:
2005-06-29

How long until the Linux kernel has to have DBus, just to be functional?


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.

Reply Score: 4

RE[4]: Ah, that old chestnut
by mikeanderson on Mon 25th Aug 2014 13:25 UTC in reply to "RE[3]: Ah, that old chestnut"
mikeanderson Member since:
2014-08-22

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.

Reply Score: 3

RE[5]: Ah, that old chestnut
by Morgan on Mon 25th Aug 2014 17:12 UTC in reply to "RE[4]: Ah, that old chestnut"
Morgan Member since:
2005-06-29

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.

Reply Score: 4

RE[4]: Ah, that old chestnut
by tylerdurden on Mon 25th Aug 2014 18:25 UTC in reply to "RE[3]: Ah, that old chestnut"
tylerdurden Member since:
2009-03-17

What is insane about Systemd exactly?

Reply Score: 3

RE[5]: Ah, that old chestnut
by Morgan on Mon 25th Aug 2014 18:38 UTC in reply to "RE[4]: Ah, that old chestnut"
Morgan Member since:
2005-06-29

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:

I have an issue with journal corruptions and need to know what is the accepted way to deal with them.


The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future.


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.

Reply Score: 4

Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 4

RE[5]: Ah, that old chestnut
by Morgan on Tue 26th Aug 2014 01:26 UTC in reply to "RE[4]: Ah, that old chestnut"
Morgan Member since:
2005-06-29

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.

Reply Score: 4

Bill Shooter of Bul Member since:
2006-07-14

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".

Reply Score: 3

RE[7]: Ah, that old chestnut
by renox on Tue 26th Aug 2014 14:40 UTC in reply to "RE[6]: Ah, that old chestnut"
renox Member since:
2005-07-06

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..

Reply Score: 3

RE[7]: Ah, that old chestnut
by Morgan on Tue 26th Aug 2014 15:01 UTC in reply to "RE[6]: Ah, that old chestnut"
Morgan Member since:
2005-06-29

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

Reply Score: 3

RE[3]: Ah, that old chestnut
by gilboa on Wed 27th Aug 2014 03:39 UTC in reply to "RE[2]: Ah, that old chestnut"
gilboa Member since:
2005-07-06

"Bah, as long as you cooperate with someone else the interests may be different, so what?


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!
"

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

Reply Score: 2

RE: Remember Cosmoe?
by jello on Mon 25th Aug 2014 01:38 UTC in reply to "Remember Cosmoe?"
jello Member since:
2006-08-08

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. ;)

Reply Score: 1

RE[2]: Remember Cosmoe?
by BlueofRainbow on Mon 25th Aug 2014 13:09 UTC in reply to "RE: Remember Cosmoe?"
BlueofRainbow Member since:
2009-01-06

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.

Reply Score: 4

RE: Remember Cosmoe?
by renox on Mon 25th Aug 2014 09:24 UTC in reply to "Remember Cosmoe?"
renox Member since:
2005-07-06

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!

Reply Score: 5

RE[2]: Remember Cosmoe?
by mikeanderson on Mon 25th Aug 2014 09:42 UTC in reply to "RE: Remember Cosmoe?"
mikeanderson Member since:
2014-08-22

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.

Reply Score: 3

RE[3]: Remember Cosmoe?
by renox on Mon 25th Aug 2014 10:52 UTC in reply to "RE[2]: Remember Cosmoe?"
renox Member since:
2005-07-06

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.

Reply Score: 2

RE[4]: Remember Cosmoe?
by mikeanderson on Mon 25th Aug 2014 11:04 UTC in reply to "RE[3]: Remember Cosmoe?"
mikeanderson Member since:
2014-08-22

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!

Reply Score: 2

Already done before
by Luke McCarthy on Mon 25th Aug 2014 01:14 UTC
Luke McCarthy
Member since:
2005-07-06

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.

Reply Score: 4

RE: Already done before
by PAPPP on Mon 25th Aug 2014 01:36 UTC in reply to "Already done before"
PAPPP Member since:
2006-07-26

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 )

Reply Score: 4

RE[2]: Already done before
by renox on Mon 25th Aug 2014 10:25 UTC in reply to "RE: Already done before"
renox Member since:
2005-07-06

I wonder if he will be able to reuse some code from these older ports..

Reply Score: 2

BlueofRainbow Member since:
2009-01-06

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.

Reply Score: 3

Morgan Member since:
2005-06-29

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.

Reply Score: 3

mikeanderson Member since:
2014-08-22

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.


Sigh, read the thread, this is not what's being proposed at all. In fact, BeOS binaries will run as-is...

Reply Score: 2

Morgan Member since:
2005-06-29

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.

Reply Score: 4

mikeanderson Member since:
2014-08-22

"BeOS binaries will run as-is...


On ZevenOS? Really?
"

No, on the proposed BeLinux.

Reply Score: 2

RE: Already done before
by jello on Mon 25th Aug 2014 19:32 UTC in reply to "Already done before"
jello Member since:
2006-08-08

With JLG you mean Jean-Louis Gassée?

Sometimes I wonder how the future of Linux would have been shaped if Jean-Louis Gassé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

Reply Score: 2

RE[2]: Already done before
by henderson101 on Wed 27th Aug 2014 13:00 UTC in reply to "RE: Already done before"
henderson101 Member since:
2006-05-30

With JLG you mean Jean-Louis Gassée?

Sometimes I wonder how the future of Linux would have been shaped if Jean-Louis Gassé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...)


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.

Talk about lost opportunities...


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.

Reply Score: 3

RE[3]: Already done before
by zima on Thu 28th Aug 2014 14:19 UTC in reply to "RE[2]: Already done before"
zima Member since:
2005-07-06

So Haiku is largely BeOS done right? ;)

Hm, and what GPL code was violated the most?

Reply Score: 2

RE[4]: Already done before
by henderson101 on Fri 29th Aug 2014 12:54 UTC in reply to "RE[3]: Already done before"
henderson101 Member since:
2006-05-30

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.

Reply Score: 2

RE[5]: Already done before
by mikeanderson on Fri 29th Aug 2014 16:25 UTC in reply to "RE[4]: Already done before"
mikeanderson Member since:
2014-08-22

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

Reply Score: 1

jphamlore
Member since:
2011-02-15

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

Reply Score: 2

Comment by marcp
by marcp on Mon 25th Aug 2014 02:50 UTC
marcp
Member since:
2007-11-23

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.

Reply Score: 1

RE: Comment by marcp
by renox on Mon 25th Aug 2014 09:39 UTC in reply to "Comment by marcp"
renox Member since:
2005-07-06

The power of all alternative OSs is - well - that they are DIFFERENT.


Different OS doesn't necessarily mean different kernel: Android is very different from Red Hat..

Also, Haiku's/BeOS kernel is far better designed then Linux one.


And it supports 0.1% of the hardware than Linux support..

Reply Score: 5

RE[2]: Comment by marcp
by Vanders on Mon 25th Aug 2014 11:51 UTC in reply to "RE: Comment by marcp"
Vanders Member since:
2005-07-06

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.

Reply Score: 3

RE[3]: Comment by marcp
by BlueofRainbow on Mon 25th Aug 2014 13:37 UTC in reply to "RE[2]: Comment by marcp"
BlueofRainbow Member since:
2009-01-06

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.

Reply Score: 3

RE[4]: Comment by marcp
by Vanders on Mon 25th Aug 2014 15:15 UTC in reply to "RE[3]: Comment by marcp"
Vanders Member since:
2005-07-06

Which one is right - 0.1% or 97.3%?


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.

Reply Score: 3

RE[2]: Comment by marcp
by Alfman on Mon 25th Aug 2014 14:00 UTC in reply to "RE: Comment by marcp"
Alfman Member since:
2011-01-28

renox,

And it supports 0.1% of the hardware than Linux support..


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

Reply Score: 4

RE: Comment by marcp
by Phucked on Wed 27th Aug 2014 00:41 UTC in reply to "Comment by marcp"
Phucked Member since:
2008-09-24

Also, Haiku's/BeOS kernel is far better designed then Linux one.


LOL I needed that laugh.

Reply Score: 3

best case scenario
by staalmannen on Mon 25th Aug 2014 04:24 UTC
staalmannen
Member since:
2014-08-25

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 ;)

Reply Score: 4

RE: best case scenario
by zima on Tue 26th Aug 2014 22:18 UTC in reply to "best case scenario"
zima Member since:
2005-07-06

What's Darling? (it's pretty much impossible to Google ;) )

Reply Score: 2

Paravirtualization
by jgfenix on Mon 25th Aug 2014 07:31 UTC
jgfenix
Member since:
2006-05-25

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.

Reply Score: 2

Comment
by pandronic on Mon 25th Aug 2014 09:50 UTC
pandronic
Member since:
2006-05-18

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.

Reply Score: 4

CD Player
by joshv on Mon 25th Aug 2014 10:33 UTC
joshv
Member since:
2006-03-18

I see Haiku still has a CD player app. How cute.

Reply Score: 5

Doctor Who
by kwan_e on Mon 25th Aug 2014 11:18 UTC
kwan_e
Member since:
2007-02-18

If you replace the kernel, and then you slowly replace the userland to accommodate the new kernel, is it still Haiku?

Reply Score: 5

Funny
by renox on Mon 25th Aug 2014 13:43 UTC in reply to "Doctor Who"
renox Member since:
2005-07-06

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.

Reply Score: 4

Already tried is not feasible
by Leszek Lesner on Mon 25th Aug 2014 14:17 UTC
Leszek Lesner
Member since:
2007-04-08

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.

Reply Score: 2

RE: Already tried is not feasible
by renox on Mon 25th Aug 2014 14:33 UTC in reply to "Already tried is not feasible"
renox Member since:
2005-07-06

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.

Reply Score: 5

zlynx Member since:
2005-07-20

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.

Reply Score: 3

mikeanderson Member since:
2014-08-22

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.


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.

Reply Score: 4

renox Member since:
2005-07-06

I recall reading some analysis of why BeOS was so responsive.

I recall many 'guess', but nothing concrete which means that these 'guess' have to be taken with a lot of care.

It had to do with good use of threads and care was taken with the GUI messaging and task scheduling.

Yes, but 'a good use of thread' is user space design, so Haiku could have done this on top of Linux too..

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.

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..

The amount of latency in a X Window app is pretty ridiculous.

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..

Reply Score: 4

zima Member since:
2005-07-06

2) Mir is going to replace X soon ;)

Reply Score: 3

henderson101 Member since:
2006-05-30

"I recall reading some analysis of why BeOS was so responsive.

I recall many 'guess', but nothing concrete which means that these 'guess' have to be taken with a lot of care.
"

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....

Reply Score: 3

renox Member since:
2005-07-06

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.

Reply Score: 3

henderson101 Member since:
2006-05-30

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.

Reply Score: 2

BlueofRainbow
Member since:
2009-01-06

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.

Reply Score: 3

mikeanderson Member since:
2014-08-22

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

Reply Score: 5

BlueofRainbow Member since:
2009-01-06

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.

Reply Score: 2

Maybe on top of OpenDarwin?
by pfgbsd on Mon 25th Aug 2014 15:50 UTC
pfgbsd
Member since:
2011-03-12

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.

Reply Score: 0

RE: Maybe on top of OpenDarwin?
by zima on Tue 26th Aug 2014 22:26 UTC in reply to "Maybe on top of OpenDarwin?"
zima Member since:
2005-07-06

A shame that Google didn't base their ChromeOS on Haiku.

is that a joke?

Reply Score: 2

Comment by Phloptical
by Phloptical on Tue 26th Aug 2014 01:43 UTC
Phloptical
Member since:
2006-10-10

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.

Reply Score: 1

RE: Comment by Phloptical
by Morgan on Tue 26th Aug 2014 03:09 UTC in reply to "Comment by Phloptical"
Morgan Member since:
2005-06-29

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.

Reply Score: 4

RE: Comment by Phloptical
by zima on Tue 26th Aug 2014 22:20 UTC in reply to "Comment by Phloptical"
zima Member since:
2005-07-06

or fork it and develop you're own thing and then put it out there.

Did you even read the summary? That's what she/he does...

Reply Score: 3

BlueEyedOS
by jasnils on Tue 26th Aug 2014 06:35 UTC
jasnils
Member since:
2005-09-20

11 years ago: BlueEyedOS is a BeOS-inspired operating system powered by a Linux kernel. What if people had embraced that idea then?

Reply Score: 2

RE: BlueEyedOS
by renox on Tue 26th Aug 2014 08:47 UTC in reply to "BlueEyedOS"
renox Member since:
2005-07-06

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..

Reply Score: 3

I do not expect..
by terra on Tue 26th Aug 2014 10:12 UTC
terra
Member since:
2012-11-01

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.

Reply Score: 0

RE: I do not expect..
by mikeanderson on Tue 26th Aug 2014 10:20 UTC in reply to "I do not expect.."
mikeanderson Member since:
2014-08-22

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

Reply Score: 3

RE: I do not expect..
by zima on Tue 26th Aug 2014 22:25 UTC in reply to "I do not expect.."
zima Member since:
2005-07-06

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.

So Sia is like Linus? ;) Well... that's good (for the project).

Reply Score: 3