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?
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.
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?)
If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.
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...
Ditching the _enormous_ Android stack is an easy win.
I'm not a mobile developer so this is all new to me. Thanks for the info.
Haiku is the ideal system for a Risc-V embedded device (think car console, tablet, media centre, info kiosk etc)