Search Results for: haiku

Does anyone here remember Cosmoe? Cosmoe was an attempt to combine Haiku’s API with the Linux kernel and related tools, started in the early 2000s. The project eventually fizzled out, now only an obscure footnote for BeOS diehards such as myself. It seems, though, that the idea of combining the Haiku API with a mature UNIX-like operating system refuses to die, and a few days ago, on the NetBSD Users’s Discussion List, a developer by the name of Stephan picked up the baton. Some years ago I already started to work on a compatibility layer for NetBSD and resumed working on it recently. I think a compatibility layer would mostly consist of kernel components and a custom libroot.so. I have created a libroot that provides functionality missing in libc and it should behave like the original one. It makes use of libc and libpthread at the moment as well as syscalls of the kernel components. The source can be found on Github. This is clearly an experimental project, but Stephan does note he has had success running the Haiku IPC test programs, so it’s definitely more than scribbles on a napkin. The attraction of this idea is clear, too – Haiku API, but on a stable kernel with vastly superior hardware and device support. I’m not entirely sure if it’s got life in it, but even if it doesn’t – it’s amazing work, and that in an of itself makes it a success.

The latest Haiku activity report is here, covering the month of August, and it’s a massive laundry list of fixes and improvements, but I couldn’t find any major big ticket features or fixes. August also happens to bring the first two final Google Summer of Code reports – porting .NET to Haiku, and improving various parts of Icon-O-Matic, a vector drawing program designed specifically for working with Haiku’s vector icon format. Also of note is that the main Haiku CO is down at the moment, but should be back up soon.

Developers of the BeOS-inspired Haiku operating system have long been carrying patches for supporting the GNU Compiler Collection (GCC) on their platform while this week the code was upstreamed for GCC 14. This commit to mainline GCC git adds support for the Haiku operating system. Excellent news, and well-deserved.

The biggest changes last month were a series of commits by waddlesplash, all related to the user_mutex API and the consumers of it. This API is the kernel portion of the implementation of basically anything related to mutexes or locks in userland, including pthread_mutex, pthread_cond, pthread_barrier, unnamed semaphores (via sem_open), rwlocks, and more. It bears some resemblance in concept to Linux’s futex API, but is very different in both design and implementation. This month’s activity report contains a detailed description of what these commits actually entail, but as OSNews regulars will know, I’m not at all qualified to tell you what it all means. Other changes this month that my limited brain can actually comprehend are work done to make Haiku partially buildable using gcc 13, more RISC-V and ARM improvements, and a whole lot more.

Java technology has been moving forward much faster in recent years with more frequent updates. Java 17 Long Term Support (LTS) was introduced in September 2021 and will be followed by Java 21 LTS in September 2023. With HaikuDepotServer (HDS) still on Java 11 introduced in September 2018, it was time to upgrade to 17 and then also make the transition from Spring 5 to SpringBoot 3 which was released in November 2022. Spring is a base technology for SpringBoot with SpringBoot providing more configuration and functionality by convention. These upgrades will bring HDS up to date with the current state of the art in backend Java and allow HDS to be maintained more easily going forward. An interesting look at the steps taken during this upgrade process. There’s also a brand new Haiku activity report with tons and tons of fixes, new features, and updates.

The way Haiku handles package management and its alternative approach to an “immutable system” is one of those ideas I find really cool. Here’s what it looks like from a desktop user’s perspective – there’s all the usual stuff like an “app store”, package updater, repositories of packages and so on. It’s all there and works well – it’s easily as smooth as any desktop Linux experience. However, it’s the implementation details behind the scenes that make it so interesting to me. Haiku takes a refreshingly new approach to package management. A deep dive into Haiku’s surprisingly robust and full-featured package management system.

The latest Haiku activity report has been published, and this one is heavy on the driver work. The intel_extreme driver has received quite a bit of love, and Haiku now has an RNDIS USB ethernet driover, which Android uses to share its WiFi connection, so you can now use an Android phone’s hotspot to get Haiku online (only a few devices have been tested so far, though. Another big improvement is the overhauled MTU. waddlesplash overhauled MTU (“maximum transmission unit”) and also receive size handling in the network stack and the FreeBSD compatibility layer. Previously, we always stayed at the default ethernet MTU of 1500, which was fine but suboptimal (as ethernet can usually support jumbo frames up to size 9000 or so), but more problematic was that we could not handle receiving anything larger than this, as it would trigger errors in the ethernet handler related to scattered I/O operations. This required a number of changes: first to the stack itself and to the IPv4 & IPv6 handlers to check the correct MTU value, then to the ethernet module to use larger buffers if necessary when reading or writing data, and finally to the FreeBSD compatibility layer to activate the larger MTUs. These changes had a side effect of fixing “high packet loss” on some devices (or at least PulkoMandy’s very recent Intel ethernet device, anyway.) This is just a small selection – there’s tons more, such as further improvements to the ARM and RISC-V ports, the addition of the OpenBSD WiFi stack to further widen Haiku’s WiFi driver pool, and tons more.

The latest Haiku activity report is here – covering the month of March – and it’s a real grab bag of tons of changes, but I’m not seeing any big ticket items. This means there should be something for everybody in here, from improved support for various Intel integrated grahpics chips, to more work on the ARM port, to glibc fixes, to… Well, you get the point.

Haiku’s latest activity report is here, and while there’s a lot of stuff in there – as usual – I think the Gtk work stands out this month. After all that work, GTK3 worked “well enough” that it seemed ready for general consumption (or at least testing), so waddlesplash committed the necessary changes to HaikuPorts for Xlibe to be packaged, and then GTK3, and then finally the first GTK3 application: Inkscape. Already, GIMP has followed closely on its tail thanks to 3dEyes (with some quick fixes to Xlibe done by waddlesplash for it), and more GTK3 applications are sure to follow once the HaikuPorts team gets caught up to speed on things. You can find screenshots on the forums of both GIMP and Inkscape running on Haiku. With that, waddlesplash has deemed the “GTK3 porting adventure” complete, and has returned to development work on Haiku’s core for this coming month. That’s a lot of progress, and two great applications to have running on Haiku.

Haiku continues to be on its roll, this time making tons of progress porting Wine to run on Haiku. Rockstar Haiku developer X512 has managed to not just start porting Wine to Haiku, but also to get so far as to run actual Windows applications on the platform. The screenshots in the Haiku forum thread speak for themselves. This is amazing work, and I can’t even begin to imagine how so much progress can be made in such short time. That being said – and the reason I’m late with this story – I’m not entirely sure porting things like Qt, X.org, and Wine are the best way forward for Haiku. As an old BeOS nerd, what I want are fully native, platform-optimised Haiku applications that make use of all the unique features the operating system has to offer. I’m not interested in yet another platform to run Qt applications, LibreOffice, and a small handful of Windows applications. I really don’t like being a grumpy old man when it comes to relatively small, alternative projects whose members code for free, but none of the recent amazing news coming out of Haiku has made me more interested in Haiku – in fact, it has only made me less interested, and less enthusiastic. Haiku and BeOS occupy a special place in my heart, and the focus shift from focusing on Haiku as an API-compatible clone of BeOS to yet another platform that runs Qt, X, and a few Windows applications worse than Linux or BSD do is not something I’m particularly thrilled with. But here’s the cool thing – what I think is, and should be, entirely irrelevant, and these developers need to keep doing what they want to do, whether randos like me want them to or not. That’s the nature of open source.

Thanks in large part to the hard work by X512 and everyone developing on Haiku, our nightly RISCV64 images are now functional. RISC-V marks Haiku’s first functional non-Intel/x86 port! This is still crazy to me. This port has taken relatively little time, yet it marks a major milestone in Haiku’s history.

I implemented RadeonGfx driver server mode and now it is possible to run multiple processes that use 3D acceleration. Because of GFX ring reset hack, command buffer scheduling is limited and only one command buffer can be executed at moment of time. That’s right – that’s X512, the amazing developer who ported Haiku to RISC-V, now working on bringing initial 3D acceleration to Haiku. There’s a long road ahead for this to become a default, working part of Haiku, but that doesn’t make these first steps any less impressive.

Another month has passed, so time for another monthly update from the Haiku team. This time around, we get two for the price of one. First, the regular monthly activity report, where we can read that work on the ARM64 and RISC-V ports continues, and while these ports are nowhere near complete, they serve an important function both in discovering bugs and issues, as well as in getting Haiku ready for future architecture transitions. Tracker also received thumbnail support, but this is disabled by default for now, and of course, there’s a lot of low-level work being done, too. The second update comes from waddlesplash, Haiku Inc.’s actual paid full-time developer. In his report, he details his work on fixing two Haiku bugs that caused frequent crashes in WebKit, as well as extensive work on the USB stack – more specifically, improving USB 3.0 support. On top of that, he also details a lot of his low-level work over the month of September.

Dedication asks each of its adherents to have faith even as time and energy pass through from one year to the next. Dedication brings with it a variety of challenges, but also rewards. Dedication is something most people claim to have, but few readily exhibit it in the face of adversity. As of today, Aug. 18, 2021, the Haiku Project is celebrating two decades of dedication, marking the 20th anniversary of the founding of the Haiku operating system and the start of this ride to save, maintain, and expand upon the BeOS legacy it spawned from. Congratulations to the Haiku project and all of its contributors.