Live data from Hacker News

Haiku OS ported and running on RISC-V

discuss.haiku-os.org

81–89 of 89 posts

Re: Haiku OS ported and running on RISC-V

#81
post #75

Holy crap. I want to buy a risc-v computer just to play with this! Do they have a raspberry-pi type device somewhere? (Yes, I'm too lazy to Google for it :)

See the answers to the same question elsewhere, but essentially, 2021 looks to be the year where Linux-capable RISC-V is finally becoming widely available (afordably). BeagleV is the one I'm waiting for but there are plenty more: https://liliputing.com/?s=RISC-V

Re: Haiku OS ported and running on RISC-V

#82
post #53
post #20

Earlier quoted context omitted.

Do you think adversarial country relations specially from sanctioned countries like China and Russia might count in favor of Risc-V development and adoption?

I cannot comment on Russia, not an area I am familiar with. But I believe that is already the case with China. 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…

The EU seems to see RISC-V as a solution to its domestic manufacturing, supply chain and security issues. Many German defense conpanies invested in the ecosystem (e.g. Hensoldt sponsored the recently frontpaged RISC-V port and verification of the seL4 kernel). I guess Switzerland is an attractive location for that too.

Re: Haiku OS ported and running on RISC-V

#83
post #78

Earlier quoted context omitted.

GTK in resource constrained environment? Uh... 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…

Like on the PinePhone, using sxmo? Works great. Ditching the _enormous_ Android stack is an easy win.

That was Brillo's main goal, except when it came to production it got rebooted as Android Things and now is dead.

Re: Haiku OS ported and running on RISC-V

#85

Love this and love the idea of having a RISC based workstation as my daily driver. Any suggestions on where to buy it ?

The best performance this year will be SiFive's "HiFive Unmatched" with four cores more or less equivalent to an ARM A55. Raw speed should be a little quicker than a Raspberry Pi 3, but the user experience will be better because it has an M.2 slot for a modern SSD, a PCIe slot that Radeon graphics cards work in (they demonstrate it with an RX 580), and 16 GB RAM. Pricey at $665 for the Mini-ITX motherboard with CPU a…

Thanks so much, such a helpful reply.

Re: Haiku OS ported and running on RISC-V

#86
post #55

Haiku is ideal for embedded graphical systems, since it’s designed as a single user low latency unified system. As the technology stack is unified (from the higher level user space to low level kernel), with a unified desktop environment, unified IPC mechanism, unified file system, unified audio and media system etc, it allows system builders to make lean embedded applications and tools. Case in point - the Medo medi…

> 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. [1] - https://en.wikipedia.org/wiki/BeIA

BeIA was still only x86/IA32. BeIA was very clever. It used a compressed file system and an ELF compression scheme, so in 8MB/16MB you could fit the entire OS install and still have space free... but it was not ever really embedded in the sense of running on low powered ARM or similar. There wasn't even a PowerPC/POWER port, despite BeOS originally running exclusively on PowerPC up till R3, when Intel was added.

Re: Haiku OS ported and running on RISC-V

#87
post #38

Earlier quoted context omitted.

cooperative multitasking, no memory protection, can't take advantage of multiple cores, and very much tied to the ARM architecture?

Has Haiku already improved the crash friendly in multihreaded code experience, and software rendering from BeOS?

Yes. There are ports of Qt 5 for example, so you can avoid the BeAPI layer and write code that is portable. You shouldn't, but you can. The Qt/QML code is standard and all the threading and BLooper/BLocker dance is not a "thing" when you use it. But, these days, multithreading is a lot more prevalent so I don't think modern programmers have such an issue with it. I write multithreaded code all the time.

Re: Haiku OS ported and running on RISC-V

#88
post #65

Love this and love the idea of having a RISC based workstation as my daily driver. Any suggestions on where to buy it ?

An announcement of Allwinner D1 based SBCs expected at cheap ($12 has been named before) pricing within weeks, if not days. I'd go for that.

Boards at that price level will have to wait until after the component shortage, but I believe it may be possible to order a higher spec'd D1 board for under $100 within the next few days and receive it possibly before the end of the month.

Re: Haiku OS ported and running on RISC-V

#89
post #45

Earlier quoted context omitted.

You should look at GUI via ImGUI if this is an opinion you hold. 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).

Sure and ImGUIs are extremely unpleasant to use in power/resource constrained environments. You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.

Is this because they tend to heat up when you use a GL context? And the UI toolkits composite to the screen less often?

I'm not a mobile developer so this is all new to me. Thanks for the info.

Post reply on HN