Comments

• By smallstepforman 2021-05-1213:296 reply

  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)

  By nerdponx 2021-05-1213:342 reply

  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.

  By dejv 2021-05-1213:572 reply

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

  By dleslie 2021-05-1214:272 reply

  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.

  By f00zz 2021-05-1220:151 reply

  also, no Electron apps. all I see is upside

  By moshmosh 2021-05-132:28

  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)

  By maratc 2021-05-1217:422 reply

  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.

  By caslon 2021-05-1219:06

  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.

  By f00zz 2021-05-1220:27

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

  By waddlesplash 2021-05-1214:012 reply

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

  By ori_b 2021-05-1215:322 reply

  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.

  By leoc 2021-05-1218:09

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

  By HeckFeck 2021-05-1216:432 reply

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

  By nix23 2021-05-1217:131 reply

  That much:

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

  By rjsw 2021-05-1221:121 reply

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

  By codetrotter 2021-05-1222:15

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

  By rjsw 2021-05-1221:12

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

  By yjftsjthsd-h 2021-05-1215:462 reply

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

  By phendrenad2 2021-05-1221:16

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

  By panta 2021-05-1219:30

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

  By diegocg 2021-05-1214:08

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

  By pndy 2021-05-1218:561 reply

  > 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

  By memsom 2021-05-148:46

  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.

  By pjmlp 2021-05-1213:351 reply

  I don't know, I would rather have something like RISC OS :)

  https://www.riscosopen.org/content/

  By cmrdporcupine 2021-05-1215:531 reply

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

  By pjmlp 2021-05-1216:071 reply

  Has Haiku already improved the crash friendly in multihreaded code experience, and software rendering from BeOS?

  By memsom 2021-05-148:49

  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.

  By garaetjjte 2021-05-1214:223 reply

  >Haiku is ideal for embedded graphical systems

  Well, except there's no accelerated graphics driver (for any device) :(

  By swiley 2021-05-1214:493 reply

  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.

  By zozbot234 2021-05-1215:034 reply

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

  By colejohnson66 2021-05-1216:523 reply

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

  By deathanatos 2021-05-132:06

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

  By caslon 2021-05-1218:461 reply

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

  By unilynx 2021-05-1220:12

  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.

  By slackfan 2021-05-1221:111 reply

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

  By swiley 2021-05-1223:01

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

  By swiley 2021-05-1216:08

  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.

  By rjsw 2021-05-1221:35

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

  By livre 2021-05-1215:191 reply

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

  By garaetjjte 2021-05-1216:161 reply

  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.

  By livre 2021-05-1220:58

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

  By aspaceman 2021-05-1216:101 reply

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

  By swiley 2021-05-1217:042 reply

  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.

  By garaetjjte 2021-05-1217:221 reply

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

  By dleslie 2021-05-132:001 reply

  Like on the PinePhone, using sxmo? Works great.

  Ditching the _enormous_ Android stack is an easy win.

  By pjmlp 2021-05-137:54

  That was Brillo's main goal, except when it came to production it got rebooted as Android Things and now is dead.

  By aspaceman 2021-05-1617:39

  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.

  By yellowapple 2021-05-1220:31

  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.

  By dleslie 2021-05-1214:31

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

  By scythe 2021-05-1214:22

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

  By canadianfella 2021-05-1217:38

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

• By rcarmo 2021-05-1220:201 reply

  I'm actually quite sad that the Haiku community never managed to marshal the effort to do a Raspberry Pi port. It would have been a killer OS on it, but somehow it never panned out.

  (I remember some early discussions in the forums where at first the Pi was dissed in favor of the BeagleBone, and then because of Broadcom, and then, later on, because of "lack of openness", so I'm chalking it down to a mixture of bias and a huge blind spot...)

  By waddlesplash 2021-05-1220:371 reply

  We were never opposed to a rpi port, but it was much more difficult in the days of rpi1/2, yes, and the BeagleBoard was the initial target instead. These days there is some rpi4 code in the tree, but nobody found the time or motivation to work on it seriously, I guess.

  By ianai 2021-05-130:54

  So how production ready is haiku? Targeting the rpi seems like a strong “user-grab”.

• By seg_lol 2021-05-1213:161 reply

  Down thread folks were asking to run BeOS binaries on it, sounds like a great opportunity for a couple fun hacks.

  * ppc -> risc-v binary translator, much more tractable with fixed width 32 bit instructions

  * running this on an FPGA that already includes a RISC-V core like PolarFire and then instantiate a softcore PPC. hack Haiku to run the PPC processes on that core. Extra bonus points to dynamically instantiate PPC cores to meet load, make fast ones, wide ones, slow ones.

  What a time to be alive!

  https://github.com/antonblanchard/microwatt

  By fogihujy 2021-05-1213:232 reply

  > hack Haiku to run the PPC processes on that core

  That sounds like the Amiga PowerUp cards with extra steps. :D

  By seg_lol 2021-05-1213:28

  https://en.wikipedia.org/wiki/PowerUP_(accelerator)

  This is cool.

  By compressedgas 2021-05-1213:271 reply

  The extra steps are what ensures an invariant.

  By seg_lol 2021-05-1213:34

  I am reading this paper you posted, https://news.ycombinator.com/item?id=26844036 this is really good.

  > the path of least resistance when choosing a strategy is to trust folklore, but the folklore is also suspect.

  love it.

  The bibliography itself is a work of art.