Haiku OS ported and running on RISC-V(discuss.haiku-os.org) |
Haiku OS ported and running on RISC-V(discuss.haiku-os.org) |
Haiku is the ideal system for a Risc-V embedded device (think car console, tablet, media centre, info kiosk etc)
Haiku predecessor BeOS was present in yet even smaller version (BeIA) on embedded systems and Internet appliances [1] so kinda ahead of the times already.
Well, except there's no accelerated graphics driver (for any device) :(
Rendering a GUI can be done in real time on ancient CPUs. This has been true since the 1980s and continues to be true today. If your app has a performance issue then you should consider cutting down on the animations/special effects/abstractions.
(I remember some early discussions in the forums where at first the Pi was dissed in favor of the BeagleBone, and then because of Broadcom, and then, later on, because of "lack of openness", so I'm chalking it down to a mixture of bias and a huge blind spot...)
* ppc -> risc-v binary translator, much more tractable with fixed width 32 bit instructions
* running this on an FPGA that already includes a RISC-V core like PolarFire and then instantiate a softcore PPC. hack Haiku to run the PPC processes on that core. Extra bonus points to dynamically instantiate PPC cores to meet load, make fast ones, wide ones, slow ones.
What a time to be alive!
That sounds like the Amiga PowerUp cards with extra steps. :D
This is cool.
I guess that new Apple M1 ARM would count but I have yet to get one.
I'm really excited about using an ARM based laptop at some point but not sure if the Linux stack will work on it. Is this the same problem lots of Mac software wouldn't run on the M1 at first?
Its not really any more usable as a daily driver on RISC-V than it was on any other architectures like x86, but RISC-V support is a milestone because its likely the applications where a very lightweight OS like HaikuOS would be most useful are things that would fit more into the "embedded" bucket than the "desktop computer" bucket - like others in the comments have mentioned, think media kiosks, display systems, hardware appliances, etc. For some perspective, BeOS was purchased by Palm (the handheld computer company) before that whole corner of the industry started dissolving in the smartphone era, so thats the kind of device it was being used on commercially.
(Also, RISC-V isn't ARM - your mainstream ARM laptop is probably going to happen especially now that Apple has shown they can sell well, but RISC-V is still ramping up towards that point of popularity.)
I guess you can try it on Qemu. Might test it later. UTM offers "Risc-V Spike board" among others.
There is a download link in the thread for one of the test builds. It probably will not work on anything besides a VM, though.
Does Haiku features a serial console?
Next is the BeagleV "StarLight". It uses the same SiFive cpu cores but in an SoC from a different company, and with a built in PowerVR GPU. It runs off SD card, but once booted can use USB3 disks. At $119 for 4 GB or $149 for 8 GB it's not a lot worse of a computer than the Unmatched. Due to ship September, I have a beta developer board now.
Allwinner have their D1 chip in mass production right now. It has a single core running at 1.0 GHz with a draft version 0.7.1 128 bit RISC-V Vector unit, which improves the speed often 2-3x. Sipeed and Pine64 have promised Linux boards using the chip in the next couple of months starting at $10 or $12. Probably with only 256 MB or 512 MB RAM at that price. That's very competitive against Raspberry Pi Zero. I've had access to an Allwinner Evaluation Board for a couple of weeks and it's very very nice is they can get boards out at those prices.
All the above are 64 bit and run Fedora, Debian, Ubuntu (I recommend Ubuntu as they have 21.04 images for RISC-V) and others coming.
If you want a full featured desktop experience with web browser loading heavy sites, watching YouTube etc then you'll want the Unmatched, but the BeagleV will be close. Note: such a web browser isn't available yet, but once developers have these boards themselves as daily drivers it will happen.
While the Unmatched / BeagleV CPU is similar to a Pi 3, with more RAM and better peripherals (especially in the Unmatched) I expect the overall experience to be like a Core 2 Duo from the mid 2000s, maybe better for many things with a decent video card. Think: original MacBook Air.
> the path of least resistance when choosing a strategy is to trust folklore, but the folklore is also suspect.
love it.
The bibliography itself is a work of art.
An industry planning organization in China has indicated the plan to standardize on RISC-V across the board, with domestically designed and manufactured processors. The intent there is, I'm guessing, to disentangle China from any IP issues, or supply interruptions should trade be disrupted. Chinese media has openly stated as such, for example this article from Sina.com (in Chinese): https://finance.sina.com.cn/tech/2021-01-18/doc-ikftssan7728...
Since it gives me reading practice, I've done a quick and probably slightly butchered partial translation:
Could expanding RISC-V be the cure to China's shortage of ICs?
In April of 2020, RISC-V Foundation's CEO sent an email alerting the Foundation's members. The email stated that "We have now established the RISC-V International Association in Switzerland".
The RISC-V foundation, which has been established now for five years, was originally founded in America. On account of worries about being influenced by political factors, it has moved to Switzerland, a country well known for its consistent neutrality and practice of supporting open source.
[...]
Over the last three to four years, in China's technology circles, more and more people have been discussing the adoption of RISC-V. This follows political factors having an increased influence on the science & technology industry, as well as ARM being purchased by NVIDIA. China's technology companies are ever more worried that the x86 and ARM architectures, in the hands of American organizations, may cut off from access in the future.
In contrast, the open source RISC-V does not have similar concerns. "Regarding domestic Chinese companies, the relocation of the RISC-V Foundation's official headquarters to Switzerland is a very favourable development." said CEO Xu Tao of Saifang Technologies, a domestic Chinese manufacturer of RISC-V processors. "Most significantly, this means that the adoption of the open source RISC-V instruction set, open source software, and public standards can be utilized without any fear of unforeseen complications. It's my belief that this is an opportunity to establish the independence of IP for Chinese processors."
It was impractical longer term, but really, as long as I didn't open more than a couple Surf (the Suckless browser, uses the Webkit engine) windows at a time it didn't feel slower than a tricked-out Mac or a beast of a Windows machine, for everything else. Amazing what running as little JS as possible can do. I had to run Docker and VMs elsewhere since they hog memory by design, but it was entirely fine as code-editing and command line workstation. A heavy IDE for, say, Java might have been painful if I'd needed that—which is kind of crazy, because those used to run just fine on well under 1GB of memory, too.
Using Void helped a lot because a bunch of the background garbage on something like Ubuntu, which is really getting out of control, wasn't hanging around eating memory and periodically waking up to burn cycles for unclear reasons. I imagine the benefits of Haiku are similar (big fan of BeOS back in the day, thing's UI responsiveness on mediocre hardware was downright magical)
> car console, tablet, media centre, info kiosk etc
would be possible but hard without a mainstream browser. Sure, one can develop a native application, but this is not how mainstream development is done these days. E.g. info kiosks basically are browsers that display whatever there is on a (frequently updated) server, and so there's zero maintenance for a kiosk.
Upstream refuses to import anything related to BSD support, so they need to be maintained out of tree.
And this is for a much more popular set of projects.
"Not an easy task" is a bit of an understatement.
Presumably the use of rust is a dependency that needs fulfilled for building FF. Looks like there has been some work on getting rust to play with Haiku at both the Rust and Haiku ends:
https://docs.rs/haiku/0.2.0/haiku/
https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku...
I would imagine, but now I'm trying to figure out why; do they really use that much API surface? Network access should be simple enough, they need audio, keyboard input, and a canvas/surface to render to, but what else?
That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.
Didn’t Windows XP (and prior) not render the window as it was dragged, but just a dashed box? And when you release the window, it’d be redrawn in the new spot.
In Windows 98, it's under the Control Panel → Display → Effects → Show window contents while dragging
https://copy.sh/v86/?profile=windows98
(The VM here is slower than a machine of the era.)
(I also want to say Transport Tycoon Deluxe's windows were draggable without needing a frame / in real time, and that was in DOS?)
Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...
CPUs are more than capable of rendering graphics needed for gestures like you mentioned.
This has been my experience too with an old GMA GPU, I have to keep disabling hardware acceleration in everything I try to run (browsers, electron apps if possible, desktop environments). The UI runs order of magnitude faster on the CPU than on the GPU through OpenGL.
Immediate mode GUI creation. Very straightforward and just requires an OpenGL context (which can be software of course, so all CPU based if you want). A lot of games use it because it can be easily added as an additional layer to your final image (and is represented as just an image).
You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.
Motif, along with X11 is just completely obsolete platform. (btw, this is what UHH thinks about it: "What Motif does is make Unix slow. Real slow.")
There's some weird GPU hate in this thread that I don't quite understand. Try to render dragging content of 1080p window at 60fps on cheap mobile ARM core, and you will likely blow your whole time budget just on filling the window with solid color...
I'm not a mobile developer so this is all new to me. Thanks for the info.
If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.