Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haiku OS ported and running on RISC-V

discuss.haiku-os.org

Post reply on HN
Print view View original

41–50 of 89 posts

Re: Haiku OS ported and running on RISC-V

#41

Post by garaetjjte »

livre wrote: post #34
swiley wrote: post #32

Earlier quoted context omitted.

IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. 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.

>IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. 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.

I don't think these anachronistic comparisons make any sense. GMA might do OGL2.1 at best, it won't work well with software with modern assumptions. I wouldn't be surprised if it doesn't use GPU at all and falls back to software OGL renderer.

Re: Haiku OS ported and running on RISC-V

#42

Post by itomato »

unwind wrote: post #24
davidcollantes wrote: post #4

Earlier quoted context omitted.

Beagle ( https://beaglev.seeed.cc ).

Wow, getting Haiku on a board like that with proper "tight" hardware driver support would be so cool! Makes me think of the original BeBox and how much I wanted one. It, too, was dual-core! :)

GPIO, meet GeekPort.

http://www.hardwarebook.info/GeekPort

Re: Haiku OS ported and running on RISC-V

#43

Post by HeckFeck »

ori_b wrote: post #35
waddlesplash wrote: post #21

Earlier quoted context omitted.

There is no technical reason one could not port Chromium or Firefox at this point; it's simply that nobody has put the time in to do it (as you can imagine, porting a web browser is not an easy task.)

There's 600+ patches needed to build chrome on BSD, and upstream is constantly churning, which means they need maintenance. 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.

I've built Firefox on NetBSD. I wonder how many patches are required for it.

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

Re: Haiku OS ported and running on RISC-V

#44

Post by colejohnson66 »

zozbot234 wrote: post #33
swiley wrote: post #32

Earlier quoted context omitted.

IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. 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.

> Rendering a GUI can be done in real time on ancient CPUs. 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.

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

Re: Haiku OS ported and running on RISC-V

#45

Post by swiley »

aspaceman wrote: post #40
swiley wrote: post #32

Earlier quoted context omitted.

IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. 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.

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.

Re: Haiku OS ported and running on RISC-V

#46

Post by justaguy88 »

retrac wrote: post #18
emouryto wrote: post #13

This is very neat. Though, I still don't have an ARM workstation... Will we leap-frog to RISC-V workstations in a few years? I guess that new Apple M1 ARM would count but I have yet to get one.

It seems more likely RISC-V will displace ARM on the low-end where margins on things like licencing are the tightest. There are already high performance ARM designs for servers in particular, and that's more applicable to desktops than any RISC-V chip currently available. X86 will give them both a run for their money but it no longer seems completely obvious that everything hefty will still be running on x86 five or…

I imagine some companies that make SoCs are worried about the nvidia acquisition too and would want an alternative

Re: Haiku OS ported and running on RISC-V

#47

Post by nix23 »

HeckFeck wrote: post #43
ori_b wrote: post #35

Earlier quoted context omitted.

There's 600+ patches needed to build chrome on BSD, and upstream is constantly churning, which means they need maintenance. 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.

I've built Firefox on NetBSD. I wonder how many patches are required for it. 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...

That much:

https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patc...

Re: Haiku OS ported and running on RISC-V

#48

Post by garaetjjte »

swiley wrote: post #45
aspaceman wrote: post #40

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.

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 window with solid color...

Re: Haiku OS ported and running on RISC-V

#49

Post by canadianfella »

smallstepforman wrote: post #12

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…

If you’re running 4k videos does the difference between 1.28Mb or 128Mb really matter?

Re: Haiku OS ported and running on RISC-V

#50

Post by maratc »

dleslie wrote: post #29
dejv wrote: post #19

Earlier quoted context omitted.

Haiku is lacking full featured web browser like Chromium or Firefox. They do have some basic browser available, but its capability is very limited.

Honestly, as someone who uses Haiku casually I find the absence of a beastly browser to be a feature. There _is_ a browser, one featureful enough to read Wiki and such, but not featureful enough to blow away hours and hours on Javascript-heavy social web applications.

That's interesting but GP points out that major applications like

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

Post reply on HN