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

31–40 of 89 posts

Re: Haiku OS ported and running on RISC-V

#31

Post by sethhochberg »

xrd wrote: post #26

What does this step really mean? Is HaikuOS usable as a daily desktop environment? Can you use all/some/? Linux applications on it? 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?

HaikuOS, and the BeOS it is essentially a continuation of, isn't linux-compatible and doesn't have that as a goal. It has its own kernel and OS stack.

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

Re: Haiku OS ported and running on RISC-V

#32

Post by swiley »

garaetjjte wrote: post #28
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…

>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(

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.

Re: Haiku OS ported and running on RISC-V

#33

Post by zozbot234 »

swiley wrote: post #32
garaetjjte wrote: post #28

Earlier quoted context omitted.

>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(

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.

Re: Haiku OS ported and running on RISC-V

#34

Post by livre »

swiley wrote: post #32
garaetjjte wrote: post #28

Earlier quoted context omitted.

>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(

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.

Re: Haiku OS ported and running on RISC-V

#35

Post by ori_b »

waddlesplash wrote: post #21
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.

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.

Re: Haiku OS ported and running on RISC-V

#36

Post by yjftsjthsd-h »

waddlesplash wrote: post #21
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.

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

> as you can imagine, porting a web browser is not an easy task

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?

Re: Haiku OS ported and running on RISC-V

#37

Post by cmrdporcupine »

pjmlp wrote: post #16
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…

I don't know, I would rather have something like RISC OS :) https://www.riscosopen.org/content/

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

Re: Haiku OS ported and running on RISC-V

#38

Post by pjmlp »

cmrdporcupine wrote: post #37
pjmlp wrote: post #16

Earlier quoted context omitted.

I don't know, I would rather have something like RISC OS :) https://www.riscosopen.org/content/

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?

Re: Haiku OS ported and running on RISC-V

#39

Post by swiley »

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.

It's certainly useful but it tends to break and in the context of embedded: constrain hardware choices to vendors known to have serious support problems.

CPUs are more than capable of rendering graphics needed for gestures like you mentioned.

Re: Haiku OS ported and running on RISC-V

#40

Post by aspaceman »

swiley wrote: post #32
garaetjjte wrote: post #28

Earlier quoted context omitted.

>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(

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

Post reply on HN