LWN: Comments on "Haiku discusses a kernel switch"

Gmane Was:Haiku discusses a kernel switch

ris — Sat, 04 Sep 2021 15:18:13 +0000

You have nntp when it should be http - that's the weird stuff error.

Gmane Was:Haiku discusses a kernel switch

Duncan — Sat, 04 Sep 2021 10:13:41 +0000

Either I'm doing it wrong (very possible) or lwn's not letting me do the actual link (I'm staring at a comment editor "Sorry no weird stuff in href=" error ATM), understandable for spam control.

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.

Gmane Was:Haiku discusses a kernel switch

Duncan — Sat, 04 Sep 2021 09:59:40 +0000

Hmm... will this hotlink it? nntp://gmane.io/gmane.os.haiku.devel/26390

Gmane Was:Haiku discusses a kernel switch

Duncan — Sat, 04 Sep 2021 09:50:11 +0000

FWIW re gmane: it's still around in its list2news form, at gmane.io.

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

Haiku discusses a kernel switch

smurf — Mon, 08 Feb 2021 09:42:52 +0000

Is Sia Lang's code still around somewhere? The article's links are all via gmane which is somewhat unavailable these days.

Haiku discusses a kernel switch

Hi-Angel — Sun, 07 Feb 2021 20:28:42 +0000

> "but if another seven years is going to pass by, I'll probably go ahead"
> […]
> Augustin Cavalier estimated a stable release within the next 14 to 24 months

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!

Haiku discusses a kernel switch

ottiwan — Sat, 18 Apr 2015 18:10:00 +0000

I reached him at dascppguy at gmail and he gave some updates. In short, the project is dead because of lack of interest from the Haiku guys (which are still not any closer to a release by the way)

Haiku discusses a kernel switch

roskegg — Sun, 15 Feb 2015 23:49:26 +0000

Attemps to email "Sia Lang" are failing. His gmail address is deactivated. If anyone knows how to reach him, please post details here.

Haiku discusses a kernel switch--NIH

vomlehn — Tue, 16 Sep 2014 01:19:33 +0000

This actually makes me rather sad.

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.

Haiku discusses a kernel switch

wmf — Thu, 11 Sep 2014 19:29:48 +0000

Assuming that's true, that's a minor change to the Linux scheduler vs. writing/maintaing a new kernel from scratch. It still seems like an argument for using Linux.

Haiku discusses a kernel switch

wmf — Thu, 11 Sep 2014 19:25:27 +0000

For 1997 hardware?

Haiku discusses a kernel switch

Cyberax — Thu, 11 Sep 2014 08:40:10 +0000

This is not an accident. The original Android's developers worked with BeOS and Palm before. And BeOS was meant to be the basis of Palm OS 6, so it's even closer relationship.

Haiku discusses a kernel switch

zdzichu — Thu, 11 Sep 2014 08:24:08 +0000

Thas sounds like "binder" from Android. (mentioned at http://kroah.com/log/blog/2014/01/15/kdbus-details/ )

Haiku discusses a kernel switch

renox — Thu, 11 Sep 2014 05:42:27 +0000

> Is there anything that the current Haiku kernel does, that cannot be supported with a Linux kernel?

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.
This feature can increase responsiveness, which is/was THE main feature of BeOS.

Kernel drivers

liam — Thu, 11 Sep 2014 00:21:58 +0000

Or genode.

Haiku discusses a kernel switch

tao — Wed, 10 Sep 2014 17:38:46 +0000

After *fifteen years* of not shipping a product, a change of strategy would seem to be in order.

Sounds oddly familiar... *cough*HURD*cough*

Haiku discusses a kernel switch

tdz — Wed, 10 Sep 2014 07:14:37 +0000

While that sounds like a rhetorical question, driver support could be a valid reason. But compared to maintaining a kernel, porting hardware support to Linux still seems like the better option in the long run.

Haiku discusses a kernel switch

tdz — Wed, 10 Sep 2014 07:12:12 +0000

Just what I thought.

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.

Haiku discusses a kernel switch

malor — Tue, 09 Sep 2014 21:44:41 +0000

This sounds like classic "not invented here" thinking -- instead of using a superior solution from someone else, people want to stick with the inferior solution they made themselves. This is really, really common, and it's hard to break oneself past it.

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.

Haiku discusses a kernel switch

mathstuf — Tue, 09 Sep 2014 06:03:47 +0000

Support original BeOS drivers?

Kernel drivers

pizza — Mon, 08 Sep 2014 11:48:50 +0000

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

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.

Kernel drivers

etienne — Mon, 08 Sep 2014 09:36:07 +0000

> I wonder about this. ...
> why didn't the designers of the new piece of hardware just make it look like the old one ...

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

Haiku discusses a kernel switch

tdz — Mon, 08 Sep 2014 08:49:53 +0000

Is there anything that the current Haiku kernel does, that cannot be supported with a Linux kernel? I'm not very familiar with Haiku, but my impression is that Linux provides all the multimedia features that Haiku once made special.

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.

Kernel drivers

smurf — Sun, 07 Sep 2014 10:49:33 +0000

The KVM servers do support a narrow static landscape. In fact, since virtualizing hardware has nontrivial overhead, they support direct callbacks for virtual devices (esp. networking) to their guest kernels.

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?

Kernel drivers

brugolsky — Sat, 06 Sep 2014 21:29:04 +0000

Agreed, in today's world, device classes or profiles are to some measure orthogonal to transports, hence NICs, storage, and even displays (GPU) may be attached to many different physical and logical transports. And the device classes often have discovery/negotiation phases that determine their capabilities. This is nothing new -- the Hayes AT command set has been around many decade, and still is in use in many "modem" (wireless radio) interfaces today. It matters not whether the transport is via RS-232, USB, or shared memory to a baseband processor. This separation of concerns allows old software to reap the benefits of new performance/reliability/etc. features of newer hardware, and to optionally take advantage of new functionality with few changes.

Kernel drivers

dlang — Sat, 06 Sep 2014 20:56:08 +0000

The designers of the hardware could have make their new hardware work with old drivers, but they don't bother to do so.

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.

Kernel drivers

giraffedata — Sat, 06 Sep 2014 20:02:52 +0000

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.

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.

Haiku discusses a kernel switch

smurf — Sat, 06 Sep 2014 09:18:37 +0000

My point is that Haiku-on-Linux-or-whatever obviously doesn't require old interfaces which X supports but Wayland does not. I don't doubt for a minute that this would have been possible on top of X11, though probably not as easily.

Haiku discusses a kernel switch

dlang — Sat, 06 Sep 2014 09:09:32 +0000

Or it means he just happens to be using wayland because X could have worked as well

Uncles she called out something that said wayland was far better than X

remember correlation != causation, much as you wish it were the case

Haiku discusses a kernel switch

smurf — Sat, 06 Sep 2014 08:10:44 +0000

Well, this seems to show that BeOS userland only requires from Wayland what a modern desktop needs, which in turn demonstrates that it *really* was ahead of its time, 20 years ago. ;-)

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

Haiku discusses a kernel switch

dlang — Sat, 06 Sep 2014 04:11:42 +0000

the difference is that they've been working on it for 14 years already

Haiku discusses a kernel switch

rahvin — Fri, 05 Sep 2014 23:49:31 +0000

I would agree but add that the promise of Wayland was supposed to be greatly simplifying further development by creating a protocol that covered only what a modern desktop needs rather than 30 years of cruft and patches covering everything and the kitchen sink right back to the beginning of computing.

Haiku discusses a kernel switch

marcH — Fri, 05 Sep 2014 23:09:26 +0000

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

Kernel drivers

brugolsky — Fri, 05 Sep 2014 20:00:42 +0000

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. Not to mention that SCSI/SATA and USB protocols can simply be passed through to Haiku if they desire. The biggest concern would probably be display driver passthrough/virtualization.

Haiku discusses a kernel switch

smurf — Fri, 05 Sep 2014 19:09:11 +0000

So Sia Lang basically cloned/re-implemented BeOS on top of Linux and Wayland. In two months of spare time.

I daresay we haven't heard the last of this man.

Haiku discusses a kernel switch

tjc — Fri, 05 Sep 2014 15:49:08 +0000

This seems like it would be a good plan for Amiga to follow as well, assuming that it's still possible to sort out IP ownership.

Kernel drivers

busterb — Fri, 05 Sep 2014 12:18:26 +0000

Netcraft confirms it - NetBSD dying, but its rump will live on.

I kid because I love!

Kernel drivers

guillemj — Fri, 05 Sep 2014 11:08:02 +0000

Or DDEKit (<http://os.inf.tu-dresden.de/ddekit/>), with DDE/Linux or DDE/FreeBSD. For example GNU/Hurd in Debian is using the former to provide more up-to-date drivers in userspace.

Kernel drivers

justincormack — Fri, 05 Sep 2014 08:46:17 +0000

If you are writing a kernel and want drivers, you can use NetBSD's. The rump kernel framework (http://rumpkernel.org) lets you take unmodified NetBSD drivers and run them pretty much anywhere (userspace, in another kernel). We already have some smaller OS projects doing this.

Haiku discusses a kernel switch

salimma — Fri, 05 Sep 2014 08:10:52 +0000

Am I the only one who experienced a deja vu when reading this? Eerily similar to the discussion surrounding the initial announcement of the Linux kernel 23 years ago