Hacker News Reader

Comment by smallstepforman | Hacker News Reader

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 media editor which does 4K videos, dozens of OpenGL pluggins and binary addons, and the entire multilingual package is 1.28Mb. Crazy efficiency due to being a cohesive integrated system.

Haiku is the ideal system for a Risc-V embedded device (think car console, tablet, media centre, info kiosk etc)

View on HN

Could this kind of technology also one day make its way to consumer laptops? It seems like low-end computers are still so damn expensive for how shitty they are. I feel like I get more bang for my buck with a Lenovo x220 + a fresh SSD + a 8GB RAM upgrade (running Xubuntu, Mint XFCE, et al) than any new low/mid-market laptop.

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.

also, no Electron apps. all I see is upside

I ran minimalist Void Linux on a crappy dual-core Celeron Chromebox with 2GB (yes, two) of memory as a workstation for a few weeks last year.

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)

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.

There are plenty of companies that make desktop apps. Car consoles (generally) don't use browsers. I am sure that those applications would get on just fine without running Chromium. A car with a web browser is a nightmare.

Don't know about kiosks, but QML is quite popular in applications like in-vehicle infotainment systems.

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.

The demise of TenFourFox is relevant: http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox... .

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

Some of those are for optional features like WebRTC, they are not all needed for a functional browser.

This thread is about fully featured browsers though. I think without WebRTC you can not call the browser fully featured.

Firefox 52 is the last version that can be built without Rust, it is kept in pkgsrc for that reason.

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

I think the problem is most modern browsers are a pile of open-source libraries at the bottom, any of which may use architecture-specific and/or compiler-specific native code. Also different systems have slightly different toolchains, for instance, compiling BSD on Linux can't be done because Linux GCC can't handle the divergent BSD GCC makefiles. D'oh! Wonder how that happened, surely they'll fix it soon...

HW accelerated audio/video encoders/decoders (eg for WebRTC), mic, camera, crypto, ...

They don't have any kind of advanced power management, which is a requirement for laptops

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

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?

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.

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

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

I believe Windows 95 had only that behavior… but everything after it could render in real time.

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

XP rendered the window unless you had a few settings switched (or the classic theme on).

In fact, dragging a window in XP was the quickest way to see if hardware acceleration was properly enabled.

If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.

Haiku does some amazingly impressive things software-only, drag & drop and scroll really don't need hardware acceleration. If they do, there's a problem with your code.

Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...

I was thinking about it and the issue is really the "if there's no compatible hardware llvmpipe will just take care of it" attitude. If you watch these software rendered graphics carefully (or read the code) they make trade-offs that allow everything to work with low input latency and render in real time and sometimes that means "corrupt" looking graphics on the screen which the OpenGL style graphics won't generate (the frame is either done or it gets skipped.)

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.

The Macintosh did drag-and-drop with no hardware acceleration in 1984.

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

It tries to do hardware rendering, I had to force software rendering due to artifacts and messed up colors in addition to slow rendering.

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

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.

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.

I ain't sure if that's strictly necessary for that use case, given how snappy I've found Haiku to be even with limited resources. It'd probably be nice, but having seen plenty of embedded graphics, I'd hardly call them "accelerated" anyway.

For the apps it has this doesn't seem to matter; not everything needs pixel shaders to be performant.

Sounds like it would be interesting for a small-form-factor not-so-smart phone that's still hackable and versatile.

Reply on news.ycombinator.com