15 ms·

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 hig

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)

nerdponx 5y ago
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.
- dejv 5y ago
  Haiku is lacking full featured web browser like Chromium or Firefox. They do have some basic browser available, but its capability is very limited.
  - waddlesplash 5y ago
    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.)
    - ori_b 5y ago
      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.
      - HeckFeck 5y ago
        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://docs.rs/haiku/0.2.0/haiku/ https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku_the_case_of_the_disappearing_deceased_threads/ https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku...
        nix23 5y ago
        That much: https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patches https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patc...
        rjsw 5y ago
        Some of those are for optional features like WebRTC, they are not all needed for a functional browser.
        codetrotter 5y ago
        This thread is about fully featured browsers though. I think without WebRTC you can not call the browser fully featured.
        rjsw 5y ago
        Firefox 52 is the last version that can be built without Rust, it is kept in pkgsrc for that reason.
      - leoc 5y ago
        The demise of TenFourFox is relevant: http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox-and-what-ive.html http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox... .
    - yjftsjthsd-h 5y ago
      > 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?
      - panta 5y ago
        HW accelerated audio/video encoders/decoders (eg for WebRTC), mic, camera, crypto, ...
      - phendrenad2 5y ago
        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...
  - dleslie 5y ago
    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.
    - maratc 5y ago
      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.
      - caslon 5y ago
        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.
      - f00zz 5y ago
        Don't know about kiosks, but QML is quite popular in applications like in-vehicle infotainment systems.
    - f00zz 5y ago
      also, no Electron apps. all I see is upside
      - moshmosh 5y ago
        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)
- diegocg 5y ago
  They don't have any kind of advanced power management, which is a requirement for laptops
pjmlp 5y ago
I don't know, I would rather have something like RISC OS :) https://www.riscosopen.org/content/ https://www.riscosopen.org/content/
- cmrdporcupine 5y ago
  cooperative multitasking, no memory protection, can't take advantage of multiple cores, and very much tied to the ARM architecture?
  - pjmlp 5y ago
    Has Haiku already improved the crash friendly in multihreaded code experience, and software rendering from BeOS?
    - memsom 5y ago
      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.
scythe 5y ago
Sounds like it would be interesting for a small-form-factor not-so-smart phone that's still hackable and versatile.
garaetjjte 5y ago
>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(
- dleslie 5y ago
  For the apps it has this doesn't seem to matter; not everything needs pixel shaders to be performant.
- swiley 5y ago
  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.
  - zozbot234 5y ago
    > 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.
    - swiley 5y ago
      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.
    - colejohnson66 5y ago
      > 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.
canadianfella 5y ago
If you’re running 4k videos does the difference between 1.28Mb or 128Mb really matter?
pndy 5y ago
> 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 https://en.wikipedia.org/wiki/BeIA
- memsom 5y ago
  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.

nerdponx 5y ago

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.

dejv 5y ago
Haiku is lacking full featured web browser like Chromium or Firefox. They do have some basic browser available, but its capability is very limited.
- waddlesplash 5y ago
  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.)
  - ori_b 5y ago
    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.
    - HeckFeck 5y ago
      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://docs.rs/haiku/0.2.0/haiku/ https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku_the_case_of_the_disappearing_deceased_threads/ https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku...
      - nix23 5y ago
        That much: https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patches https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patc...
        rjsw 5y ago
        Some of those are for optional features like WebRTC, they are not all needed for a functional browser.
        codetrotter 5y ago
        This thread is about fully featured browsers though. I think without WebRTC you can not call the browser fully featured.
      - rjsw 5y ago
        Firefox 52 is the last version that can be built without Rust, it is kept in pkgsrc for that reason.
    - leoc 5y ago
      The demise of TenFourFox is relevant: http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox-and-what-ive.html http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox... .
  - yjftsjthsd-h 5y ago
    > 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?
    - panta 5y ago
      HW accelerated audio/video encoders/decoders (eg for WebRTC), mic, camera, crypto, ...
    - phendrenad2 5y ago
      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...
- dleslie 5y ago
  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.
  - maratc 5y ago
    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.
    - caslon 5y ago
      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.
    - f00zz 5y ago
      Don't know about kiosks, but QML is quite popular in applications like in-vehicle infotainment systems.
  - f00zz 5y ago
    also, no Electron apps. all I see is upside
    - moshmosh 5y ago
      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)
diegocg 5y ago
They don't have any kind of advanced power management, which is a requirement for laptops

pjmlp 5y ago

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

cmrdporcupine 5y ago
cooperative multitasking, no memory protection, can't take advantage of multiple cores, and very much tied to the ARM architecture?
- pjmlp 5y ago
  Has Haiku already improved the crash friendly in multihreaded code experience, and software rendering from BeOS?
  - memsom 5y ago
    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.

scythe 5y ago

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

garaetjjte 5y ago

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

dleslie 5y ago
For the apps it has this doesn't seem to matter; not everything needs pixel shaders to be performant.
swiley 5y ago
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.
- zozbot234 5y ago
  > 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.
  - swiley 5y ago
    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.
  - colejohnson66 5y ago
    > 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.

canadianfella 5y ago

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

pndy 5y ago

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

memsom 5y ago
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.