61–70 of 89 posts
(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...)
Earlier quoted context omitted.
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.
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 f…
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) :(
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 an…
Love this and love the idea of having a RISC based workstation as my daily driver. Any suggestions on where to buy it ?
Earlier quoted context omitted.
>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.
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.
Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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.
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...
Earlier quoted context omitted.
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?