The State of Rust on Haiku | Hacker News Reader

The State of Rust on Haiku

haiku-os.org

232 pointssquiguy784 comments

I wonder if Haiku could become the foundation for a new os. Haiku but based on Rust. It would be a match made in heaven, Haiku's secret sauce is the asyncness of the API. This was doable in C++ however Rust and haiku are a wombo combo!

You’re basically describing Fuschia. I believe they have some of the main haiku kernel (probably a bad description) developers.

What language is the fuchsia api in?

IIRC there are native rust bindings for syscalls. The syscalls themselves are implemented in C++. I have no idea about the user space, but my impression is that rust is a first level language for things like the ui.

EDIT: it looks like they have interface generators for their APIs, which includes rust support as a first class citizen.

I've always wondered what BeOS would look like as a smartphone platform. Even from a UX standpoint, similar to the Windows 95 Mobile concept video.

It would have looked a lot like PalmOS 6, a/k/a PalmOS Cobalt. Palm bought Be's assets -- and many of their engineers -- when the company failed, and built their next generation PalmOS around it. For reasons as much due to internal politics as anything technical, though, they never shipped any Cobalt-based phones.

Well Zircon (Fuchsia's kernel) doesn't have any Rust code inside of it; it's C++. Parts of rust code used in Fuchsia can be found in the Garnet layer and it is just one of the languages that can interface with the OS via the FIDL (Fuchsia Interface Definition Language) [0][1]. An example of this is a tool written in Rust that communicates with parts of the bluetooth stack[2]. The network stack is also using it and is written in Go. [3]

[0] https://github.com/fuchsia-mirror/zircon/tree/master/system/...

[1] https://github.com/fuchsia-mirror/zircon/blob/master/docs/fi...

[2] https://github.com/fuchsia-mirror/garnet/tree/master/bin/blu...

[3] https://github.com/fuchsia-mirror/garnet/tree/master/go/src/...

From the technical side, maybe. From the user side they could not be more different. BeOS was the ultimate power user OS. You had a lot of power, but also responsibility. It included many features like the novel filesystem that more pragmatic OSes didn't include.

Fuchsia, as far as I can see, is the ultimate "modern" OS. While very safe, it will be very locked down, in the tradition of iOS, Android, Secure Boot, HTML5+js etc. but "done right". There will probably be a lot of things I won't be able to do with a Fuchsia phone.

I'm very happy Fuchsia is open source, so forks & custom ROMs will still exist.

Are you sure? While its open source, your phone won't be (since the OS is MIT licensed, your OEM won't have to give you anything). Can you build a custom ROM without kernel sources?

I appreciate what you are saying. So many people assume that open source gives them the keys of the castle, while later they realize that a simple broadcom closed source driver puts the whole openess in the trash.

This doesn’t seem to have anything to do with the software, though. You can easily lock down linux for a given phone if that’s your goal (at face value anyway).

Well, this is the reason the gpl v3 came about - to ensure the four freedoms even when faced with "trusted computing".

Unfortunately Torvalds rejected migrating to it, and seems to be quite an outspoken critic against the GPLv3

I've been happily buying Nexus and Pixel phones for as long as they've existed, on which you can easily unlock the bootloader and build your own ROM if you want. I don't see why Google would stop doing that just because they've released a new OS.

If you're concerned about installing your own software on your own hardware, why not buy it from a manufacturer that protects your freedom to be able to do so?

Well for starters they have been cleaning up Android from GPL related licenses.

Android now compiles with clang, including their own modified Linux kernel, and gcc is no longer supported on the NDK.

Yes, but they are still shipping AOSP and still selling Pixel phones with unlockable bootloaders.

Clearly, Google wants to be able to support companies which want to sell locked-down phones.

But as long as they sell their own phones with unlockable bootloaders, you can vote with your wallet and buy those phones.

I am concerned about the reduction in use of the GPL, but what I care about is being able to run and modify the software on my phone, and as long as Google is still releasing AOSP (and the Fuchsia open source project), and selling phones that are unlocked, I'm happy enough with that.

Yes, they might change their policy in the future. But for now there's no indication that they intend to do that; they've always been good at selling their own phones and Pixelbooks with unlockable bootloaders that does allow you to replace the ROM if you want.

I (not having looked at the architecture yet) have a suspicion that Fuchsia will run on a hardware-independent layer, like Treble which they're pushing right now.

HTML5+js is very locked down?

Maybe in the sense that webpages cannot talk to each other directly.

or the hardware

Yes, think of ChromeOS.

You are locked to the browser sandbox and web sites, which you will never see the code running on their servers.

X11 terminals are back, just prettier.

How does Fuchsia compare to Redox?

The PL nerd in me is thinking: "Written in C++. Lame." Of course, that attitude didn't work out very well for the iPod guy.

They seem fundamentally different. Fuschia is realtime and, I think, engineered toward embedded and mobile at the moment. Redox is more about cleaning up unix (that’s my impression, anyway). If you squint, it’s like qnx vs linux/bsd, I guess.

Fuchsia is not realtime.

You’re right, I think I was conflating concepts here. My bad. I would edit if I could.

Does Fuchsia use Rust at all? Because if not, it should. It seems like a wasted opportunity not to preempt tens of thousands of future memory corruption bugs over the next few days for a brand new OS by not using Rust.

Having programmed in the BeOS API long ago, and now a BEAM language developer, I noticed that basically they were implementing a crude and unsafe actor model. There must be modern libraries that provide that at a lower level than say the erlang VM, but with better safety guarantees than C++.

Actix[0] is probably what you're looking for. I don't think the actors in Actix are network transparent, though, which is a bummer for distributed applications, but wouldn't matter for an OS.

0: https://actix.rs/

I think a lower level, type safe, actor based framework is the idea behind the Pony language, which I've been meaning to check out.

I played around with Pony a little, and I found the library situation unsatisfactory.

But the type system is gorgeous. And the community is awesome.

Obsessive type safety in my opinion is a bit silly, it stems from this thought that you can squeeze out every possible runtime error by defensively coding. The truth is, you can't; there are going to be language errors, os errors, driver errors, and errant cosmic rays. Designing for resilience is not solved by typing, and an obsessive typing pattern can create a false sense of security.

Bah, I've seen runtime errors with dynamic and strict typing, and I'll take type safety any day. Besides, good type systems like Rust's force you to think about all sorts of errors at all points of the program. It's harder to write, but it's harder to break, and much, much easier to fix.

have you ever programmed in a BEAM language like erlang or elixir? It's easy to write, when there are errors, most of the time it's "no big deal". If something that is outside of your control (someone else's code, or hardware, or a driver, etc) then it's often not a fatal problem. Pushing errors to the edge is great, but "forcing you to think about all sorts of errors", I think is an antipattern. You should code the happy path, anticipate the 80% errors, patch the next 19% error, and ignore the last tiny sliver of errors, and generally be able to refactor easily.

Of course your environment should be able to survive and persist 99.99999% of errors, that's critical... there should be no throw()s or panic()s.

No, and I really should give those a try. That said, when I just want happy-path, idc, just reload on errors, kind of code, it's a sore temptation to just reach for JS.

I think at the OS level, safety from Rust are less useful. The "wrap unsafe code" doesn't really work.

Have you tried it? My experience is that it works pretty well, though I've mostly been working on toys. Even bigger projects like Redox have shown that you generally don't need very much unsafe.

There’s a nice Stanford class I took called CS 140E that had students write an OS for the Raspeberry Pi in Rust. There are actually some benefits to using Rust at this level, though it can be a bit cumbersome at times.

Check it out here: https://web.stanford.edu/class/cs140e/

Interesting! One of the instructors is RocketMan. :-)

https://crates.io/crates/rocket

What do you mean, doesn't really work? In my experience, it works perfectly. Could you share more info?

If you've written any amount of Rust then that's provably not true. You've no doubt used functions & methods that use unsafe (somewhere down along the line), and you didn't need to deal with it. That's 'wrapping unsafe code' used in practice. You got to write safe because someone else wrote the unsafe wrapper.

> Rustc memory usage on Linux is also high, but it never runs out of memory. I would like to figure out the cause of this issue.

Strange. I hope this isn't simply a case of wildly over-committing memory and getting away with it on Linux. But then I guess the bsd folks would have is yes too?

I believe it is a result of changes described here (the post is about thinLTO but it explains parallel codegen after the TOML config example): https://internals.rust-lang.org/t/help-test-out-thinlto/6017

In order to parallelize the build process at the rustc-llvm codegen boundary, Cargo has to implement some orchestration between compiler processes (using jobserver-rs [1]) so that 10 rustc processes didn't all create 10 threads and codegen units each and blow up the system. I'm guessing that memory quotas are a part of that implementation.

[1] https://crates.io/crates/jobserver/reverse_dependencies

The state of (Anything) on Haiku.

For others who like me have a hard time keeping track of which OS is what...

"Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful."

From: https://www.haiku-os.org/

Wikipedia gives a nice overview too:

https://en.wikipedia.org/wiki/Haiku_(operating_system)

Serious question - does anyone use Haiku for anything more than playing?

I was a huge BeOS fan back in the day, and bought the Intel version when I had a Pentium ][ computer. I was so excited for OpenBeOS (now Haiku) after BeOS got acquired, but it's been something 17 years, and it looks they're still just a release candidate for 1.0.

Back then, BeOS did some amazing stuff compared to Windows, but technology has come a long way since then, and I'd rather be using MacOS, Windows or a Linux Desktop like Ubuntu than Haiku.

Apparently a few of the devs use it full time. I've tried it out a few times, it's really very responsive, but it lacks a lot of useful software and hardware support. If you have the right hardware for it and a relatively limited set of application needs, it might work.

Right now they’re focused mostly on parity with BeOS R5 in terms of features/capabilities. Once that goal has been reached, the focus will shift to making Haiku a proper modern OS and addition of new features in the spirit of BeOS. I suspect that it’ll become much more interesting to a wider variety of people after a release or two with the latter focus.

The one thing that makes Haiku intriguing and promising in my eyes is the fact that its developers want it to be a first class desktop/laptop OS above all else with no server/mobile/other kitchen-sink-isms muddying the water. There’s nothing like that out there today, save for maybe macOS (which is more desktop focused but still suffers from the various multipurpose compromises brought from its *NIX heritage).

"no server/mobile/other kitchen-sink-isms muddying the water"

I'm not convinced that at present this is a meaningful benefit especially compared to the increased resources available for say linux. The one good example that I can think of cpu schedulers seems to be solved by running a kernel with alternative patches.

The benefit would be the ability to cherry pick only the most desktop-beneficial features rooted in non-desktop domains while also leaving behind the rest. One example would be the window server and compositor — on Linux/BSD, these services, being desktop oriented on a multipurpose system, must be wholly decoupled from the rest of the system introducing a ton of opportunities for latency, stutter, and other issues to find their way into the user experience. It’s not impossible to minimize these issues, but it’s much more difficult.

Haiku doesn’t have to worry about this problem at all. It can simply implement the most effective and good-experience-conducive end to end design possible for its window management and compositing since it’ll never ever be a headless server.

But doesn't that mandatory separation of concerns lead to good system architecture?

Microsoft lived without it for years and then finally did the job when they needed a Core OS to be shared between laptops, servers, phones, and Xbox— in the process they discovered and cleaned up all kinds of super weird interdependencies between components which should definitely not needed to be talking to each other.

Haiku developer here.

I used to run Linux on the desktop pretty extensively, but eventually got fed up with how often something broke and I had to fix it (ALSA doesn't play audio anymore, or suddenly MP4 files stutter -- or most recently, on the last remaining Kubuntu install, I can't even log in to my user account after the upgrade, it just hangs.) So, perhaps the system is "better architected" by some standard, but having those weird inter-dependencies tends to mean everything runs smoother. Depends on what your definition of "good" is, I guess.

Well, last time i tried Haiku i tried to write a simple program and at some point when i pressed save in the editor the entire OS crashed, so there is that :-P.

ALSA not playing either means that there are driver issues - and i highly doubt Haiku solves the problem of drivers having bugs - or there is some configuration issue.

But this (configuration) issue and the desktop focus do not seem to require getting rid of the entire kernel and - most importantly - the systems it supports. If X11 doesn't do (which i doubt, X11 ran on way more restricted hardware than what is available even on $5 "computers" today, but lets roll with it) you could simply write a new window system from scratch and provide a layer for everything you may think a desktop system needs so that any application written on that layer will keep working if the backend library/tech changes.

And from my understanding of Haiku, this is basically what happens already (<Stuff>Kit depends on some popular open source library for <Stuff> that is already available on Linux but exposed to applications through the <Stuff>Kit API), except with a kernel that doesn't support most things that people need today.

Personally i like the idea of Haiku as a desktop focused system, i just do not see what exactly having a custom kernel with its own need for drivers and hardware compatibility provide that a layer on top of kernel that exposes a similar API doesn't (beyond of course the hack value and the fun of making a kernel - something i am 100% totally behind as i personally write a lot of stuff just for the fun of it).

> when i pressed save in the editor the entire OS crashed, so there is that

Well, when was this? Probably a few years ago? We've really improved since then.

> or there is some configuration issue

In the case I alluded to here it was a configuration issue. I eventually solved it, but it took me about 4-5 hours of Googling and reading settings files. Really not something an end-user should have to think about.

> on way more restricted hardware than what is available even on $5 "computers" today, but lets roll with it

Great. Show me a Linux distribution right now that can do that, while also having the default installed web browser play YouTube. Is it "possible"? I don't know, but nobody seems to be doing it.

> except with a kernel that doesn't support most things that people need today.

[[Citation needed]]

> Well, when was this? Probably a few years ago? We've really improved since then.

Yes it was a couple of years ago.

> In the case I alluded to here it was a configuration issue. I eventually solved it, but it took me about 4-5 hours of Googling and reading settings files. Really not something an end-user should have to think about.

Indeed, but if your project controls everything above the kernel to the desktop environment (what Haiku already does, minus the kernel itself) you can handle the configuration too. The idea is that a program will talk to your desktop API which will talk to the kernel - the configuration is up to you to handle pretty much the same way as Haiku already does.

> Great. Show me a Linux distribution right now that can do that, while also having the default installed web browser play YouTube. Is it "possible"? I don't know, but nobody seems to be doing it.

I think you totally misunderstood the part you quoted. I was referring to X11, the earlier implementations of which was running on hardware like IBM 6152 with a 5.9MHz CPU and 1MB of RAM. A $5 Raspberry Pi Zero is a sci-fi level supercomputer compared to that.

> [[Citation needed]]

There is no point going antagonistic over this, the Haiku site has all the information you need:

https://www.haiku-os.org/node/4390/

Also last time i checked there wasn't even accelerated OpenGL.

I mean, really consider the issues people have on a popular OS like Linux to get hardware working properly - Haiku is in a much worse position here.

> I think you totally misunderstood the part you quoted. I was referring to X11, the earlier implementations of which was running on hardware like IBM 6152 with a 5.9MHz CPU and 1MB of RAM. A $5 Raspberry Pi Zero is a sci-fi level supercomputer compared to that.

I know. I mean, if that's possible, why is nobody doing it with Linux today? Or is it impossible in practice?

> There is no point going antagonistic over this, the Haiku site has all the information you need:

That page is pretty severely outdated; most of the drivers listed on that page are now confirmed as working, and we've merged more network ones from FreeBSD as time permits. Really, our hardware support is actually pretty good these days.

> Also last time i checked there wasn't even accelerated OpenGL.

There still is not, but there are blueprints for implementing it. If we had more than a man-month of development effort spent per month, we might actually get to it...

> I mean, really consider the issues people have on a popular OS like Linux to get hardware working properly - Haiku is in a much worse position here.

Maybe. But if that's the one con vs. all the aforementioned pros to having our own kernel, why is that such a problem, really? If the system really is "that much better," then users will be fine with buying specific hardware, at least until we can get the time and resources to support more.

Kubuntu is perhaps not the finest example as it has not been what I would call stable or optimal. I honestly think your analysis is in error. It has forever been the wort kde distro you could pick. You could get a more stable experience by picking a distro by throwing darts at printout of distrowatch.

A number of things have been historically sub optimal on the linux desktop but while the way linux is designed as a bunch of loosely coupled projects DOES seem to be the cause of it being able to be a lot of different things to a lot of different people example different window managers, compositors, file systems its not equally clear that the defects present exist for the same reason.

It seems likely that haiku expanded to thousands of different types of computers could easily be worse or better than linux in practice insofar as buggy behavior while still definitely being objectively worse insofar as not being modular.

Another part of the problem with the Linux desktop is that if you have problems with it someone blames your choice of distro and sends you to one of the other 250 so you can encounter whole new problems and have a whole new community dismiss you until someone else blames your choice of distro.

The way you write this makes it seem like its 6 of one half a dozen of another. While everyone has a different favorite team some really do play objectively better than others.

There are probably over a hundred distros but most users are using some variation of 4 and those who want to use their computer not play with their computer ought to look into using a stable branch of whichever distro suits them.

> You could get a more stable experience by picking a distro by throwing darts at printout of distrowatch.

Great. How was I supposed to know that just under a decade ago when I first installed that? And I'm a programmer; how is any end-user supposed to know that? Ubuntu is one of the Linux distributions that has a lot of name recognition outside the Linux desktop community; you would assume anything based on it would also be fine.

So while I know that now, it doesn't change the fact that the Linux desktop has a messaging problem. Is it fixable? I have no idea. But it's not now; so come back when it is.

> bunch of loosely coupled projects DOES seem to be the cause of it being able to be a lot of different things to a lot of different people example different window managers, compositors

And that's my problem with it. It's too configurable. If that's what you want, then use Linux. But if you want to do real work? Then people use Windows, or macOS, and maybe in the future, hopefully Haiku.

> than linux in practice insofar as buggy behavior

We already support "thousands of different types of computers". Not sure what you're going after here.

> while still definitely being objectively worse insofar as not being modular.

Our kernel is actually more modular than the Linux kernel is; and in theory you could swap out other components too. But that's beside the point. Why is modularity some great ideal that everything should strive towards? It may be great in theory, but is it so in practice?

I think that the majority of distributions are at least reasonable choices kubuntu is just a particularly bad choice based on prior experience. I just realized that kde isn't supposed to crash all the time and replaced it with something else. Apparently your experience was better until your box committed suicide.

The public somehow deals with their being lots of kinds of cars without melting down. They read reviews, they test drive. You just bought a kia and told people that all cars made outside the US suck because you know Toyota and Honda aren't a thing.

You don't have to do much work to use Linux. It certainly invites tinkering like a big box of legos but you can buy a machine that supports linux or even buy a machine WITH linux install a mainstream distro stable version preferred and do work.

People don't buy windows or mac because its easy to configure. They buy it because someone has gone to the effort to install it on the boxes on display at best buy and walmart and work out any kinks with the hardware/software.

People will only buy Haiku EVER if its sold preloaded on a good looking box.

> People don't buy windows or mac because its easy to configure. They buy it because someone has gone to the effort to install it on the boxes on display at best buy and walmart and work out any kinks with the hardware/software.

Keep telling yourselves that Linux Destkop folks. Anything to not actually listen to why people don't use your crap.

> Apparently your experience was better until your box committed suicide.

My previous experience was with Ubuntu/Unity, which was the first Linux Desktop system I ever ran. It was ... not a whole lot better.

> You don't have to do much work to use Linux.

I've explained multiple times that this isn't my experience with Linux. Maybe it was for you; but it certainly was not for me.

> People don't buy windows or mac because its easy to configure. They buy it because .. work out any kinks with the hardware/software.

The second half that statement is certainly true. But as for the first half? A good portion of my family, most of whom are programmers, disagrees with you, and so do I.

> People will only buy Haiku EVER if its sold preloaded on a good looking box.

TuneTracker does this already.

>> its developers want it to be a first class desktop/laptop OS above all else with no server/mobile/other kitchen-sink-isms muddying the water

In today's terms, that sounds a lot like an iPad (with an attached keyboard) or a Chromebook.

Kinda I suppose, except without many of the limits inherent to those platforms. Both probably still aren’t as good as they could be for their purposes due to baggage inherited from their *NIX predecessors.

Pentium II Apple ][

I have it on a few older laptops that I keep around for traveling - I don't care if they're stolen, and I only need them for SSH and a browser.

Haiku runs circles around Ubuntu MATE on these devices; it may seem equivalent on benchmarks, but the UI just _feels_ much zippier and apps load quickly.

> Serious question - does anyone use Haiku for anything more than playing?

Doubtful. After seeing a few Haiku posts over the past few days I downloaded it and gave it a try. There's a lot of promise, but it's pretty darn glitchy (e.g. DHCP client works occasionally, mail client sees mailboxes but doesn't fetch messages).

I'm in the opposite camp though. I'd love to find a viable alternative to macOS.

Those two things plus the web browser are indeed the glitchiest parts of the system :)

I've finally found a consistent way to reproduce the DHCP glitches, so I might be able to spend some time debugging that. The mail client is another issue; for now you're probably better off avoiding it. (There are third-party mail apps in the depot, so maybe try one of those?)

Glad to hear you can see the potential, though! :)

I see it too, but am honestly quite sceptical it'll get there in time. Development is just plain slow, which isn't surprising with the comparatively low number of devs. It feels half the man power is "wasted" on just keeping up with new hardware. By the time haiku is done, i fear desktop pcs and laptops will be extinct. I liked beos so I was really thrilled when openbeos popped up. I download the latest haiku build every other year or so, but it just feels they are all the same.

Some of us developers use it almost full-time (I don't quite yet, but I've finally gotten WiFi working on this PC so hopefully I will do so shortly), and there are users in the community that do also.

TuneTracker (http://www.tunetrackersystems.com/index.html) ships commercial radio broadcasting systems that run on Haiku.

I'm waiting for Haiku to actually have a modern web browser and built in support for kaby lake refresh wifi. I want to use this on bare metal so bad.

You can pretty much put all other applications support on hold. If you get modern web browsing that opens up so many web apps. WebPositive is a joke. Otter isn't quite stable.

> built in support for kaby lake refresh wifi

What chipset is that? I just merged new drivers for the Intel PRO wireless chipsets and Intel "Dual Band" chipsets; so if it's one of those it might work out of the box now.

> a modern web browser

Well, WebPositive can play YouTube and mostly works on major sites ... but yes, this is a difficult problem.

This article is about Rust and Haiku, so maybe Haiku should look into building a Servo GUI layer.

Rust and Servo are already good for massive multithreading, so that should fit into the Haiku expectations pretty well.

Servo seems to depend pretty heavily on hardware acceleration, which we don't have, so it probably wouldn't work too well. We don't have time to implement that; but someone else is certainly free to put the time in...

Thank you.

Sometimes we get new Linux distributions (I know Haiku isn't that), a language I've kinda heard of, or something, and i'll go to their site... I still don't even know what I'm looking at.

Anecdote: Haiku also had a minor role in the infamous xkcd 'Tech Support' webcomic.

https://xkcd.com/806/

Some reasons i was thinking Rust in Heroku. Need coffee!!

This is exciting -- Rust has already shown great results through its implementation in Firefox (made me dump Chrome for Quantum)[0], so building a whole new operating system using the language makes perfect sense -- a great test bed for the language, imo.

And given the fact that Haiku OS team's goal is to build a 'unified' and well-fused OS for personal use [1], using a single language should greatly help with reducing complexity and improving robustness.

[0] https://hacks.mozilla.org/2017/11/entering-the-quantum-era-h... [1] https://www.haiku-os.org/about/faq#what-is-haiku

Haiku is written in C++, as are most of its utilities I imagine. I don't see them redoing all that effort for such trivial gain. They're just talking about tooling and language bindings for people developing applications for Haiku.

You might be thinking of RedoxOS [0]?

[0] https://www.redox-os.org/

"Technically it is too late for beta, too early for R3, but send a PR with your changes nevertheless..."

https://github.com/ansuz/RIIR/issues/35 https://transitiontech.ca/random/RIIR

Reply on news.ycombinator.com