69
I Use This!
High Activity

News

Analyzed 3 days ago. based on code collected 3 days ago.
Posted about 2 years ago by waddlesplash
Just like last month, the usual Activity Report is hereby combined with my Contract Report. This report covers hrev55836 to hrev55916. The biggest news this month, though, deserves to be mentioned right up front: USB WiFi support That’s right, after ... [More] many years of being requested, Haiku finally has support for USB WiFi devices! (Currently only Realtek controllers are supported, but Ralink and others should follow before too long; Realtek/“RTL” chips are generally the most common, however.) waddlesplash had started experimenting with these as early as 2018, but ran into problems in the USB stack (and also confusion about how FreeBSD’s USB APIs mapped on to Haiku’s.) Now, after having stabilized the XHCI (USB3) support and made Haiku’s USB stack more robust, it was time to have a look at this again; and now it has been completed and merged into the nightlies (but not before it uncovered a few last bugs in Haiku’s USB subsystems.) This also entailed making the FreeBSD compatibility layer somewhat less PCI-specific, which may come in handy for ARM when we will need it to support network controllers attached to the FDT “bus”. It also exposed some more weaknesses in Haiku’s kernel-level device management system. That refactor has been due for quite some time (the USB stack does all its own device management because the kernel’s one is inadequate for its purposes), but likely will have to wait a bit longer… Applications waddlesplash fixed a crash in Debugger when trying to use the CLI with non-existent applications. waddlesplash added a note in the pkgman help text to clarify that full-sync can and does down-grade versions, if applicable. jscipione fixed Appearance failing to store decorator names correctly on localized systems. Humdinger removed some more obscure and unneeded options from the Media Mixer’s configuration interface. Servers waddlesplash fixed a bug exposed recently in app_server which caused the installed fonts to be scanned rather late, which had caused the first applications launched to open with a delay instead of rapidly. waddlesplash fixed a race condition in launch_daemon that was the major remaining (non-driver-related) cause of “hangs on rocket” / “blue screen with cursor” problems (which notably occurred rather reliably on QEMU.) madmax fixed the render and pattern colors getting out of sync in app_server, causing incorrect drawing on certain occasions; he also deleted a variety of unused code in the pattern handler. Drivers rudolfc continued his work on the intel_extreme video driver, improving support for (e)DisplayPort, especially on Sandy & Ivy Bridge devices. korli added a few more device IDs to the HDA audio driver. waddlesplash turned down tracing a bit on the XHCI driver. Now that it is more stable, there is less need to print so much information to syslogs. waddlesplash added the intel22x driver to the default images. (This is the driver for Intel’s latest line of ethernet controllers, found in very recent Intel devices and motherboards.) korli added more methods for the PCI bus manager to find the ACPI root pointer on x86, which especially helps EFI-booted systems. (This adds better support for PCI Express under EFI.) Interface Kit madmax updated the list of “ignorable code points,” which fixes some Unicode text rendering glitches that could be seen in WebKit on occasion. libroot & kernel X512 contributed a patch to add a “classical” lock-switching interface to the kernel ConditionVariable. (Unlike other OSes, Haiku’s default ConditionVariable API allows one to execute arbitrary code between the “add” and the “wait” steps, which is much more powerful than the API as found elsewhere; this contribution adds a direct equivalent of the more common API for easier use.) waddlesplash fixed another race condition in ConditionVariable that was causing hangs for some users. waddlesplash refactored the cv (condition variable) code in the FreeBSD compatibility layer, fixing some race conditions and then removing the workarounds that had been introduced to mitigate them. X512 contributed a small fix to actually add timespec_get (a new POSIX API) to the build. (The implementation was added some time ago, but it was not fully enabled.) waddlesplash added proper support for “undefined weak symbols” (that is, symbols which are “optional” and need to get a default value in the case that they are) to runtime_loader, which closed a decade-old ticket and enables more straightforward porting of Vulkan add-ons (and potentially drivers). This required some careful investigation of a comment made by bonefish over 10 years ago about some things that needed to be taken care of in the runtime_loader API in order to not cause more problems when introducing this feature. (Once enabled, some other hacks could be removed.) waddlesplash added some new assertions to BReferenceable and enabled them by default, to catch premature deletion of objects that still have references present. This exposed some bugs in HaikuDepot, package_daemon, packagefs, and other applications (most of which have been resolved already, and others at least improved.) waddlesplash added some sanity checks to kernel memory allocation routines to make sure that incompatible flags were not passed in. Previously this could either deadlock or silently fail; now it will enter KDL. waddlesplash fixed a 10-year-old memory leak in the block cache (which is used by BFS and other filesystem drivers quite extensively.) While the conditions for triggering it were not excessively common, it seems to have been the likely culprit for the “continually increasing, never decreasing cached memory usage,” as well as the “BFS unmount KDL”, both of which now seem to be resolved. waddlesplash replaced and removed an old reference-counting API from before the days where BReferenceable was available in the kernel. He also cleaned up various bits of old code. korli added support for the “clockwait” functions that will be introduced in the next version of POSIX. waddlesplah fixed a race condition in the kernel setpgid implementation that caused KDLs when it was invoked on teams that were in the process of exiting. (This was reliably caused by the stress-ng test suite.) kallisti5 added basic support for signing the EFI bootloader, so that Secure Boot can potentially be used (at present it requires installing Haiku, Inc.’s keys into your bootloader.) kallisti5 increased the maximum process arguments size to 256KB, which is just slightly larger than the size used by FreeBSD. (Previously the size was half that, much less than FreeBSD, and very much smaller than Linux.) This should help with “argument too big” problems seen in build jobs of some more complex applications. ARM! There were a few minor patches last month towards ARM64, and more work out-of-tree by some new(er) contributors. Mostly, though ARM(32) received the most attention from davidkaroly’s changes. The syscall implementation, userland entering from kernel, and runtime_loader all received a good bit of attention last month, as well as an initial implementation of thread context switches. Haiku on ARM in QEMU now attempts to start launch_daemon before crashes are encountered (which is quite a lot of progress, and much further than we’ve ever been before!) HaikuPorts threedeyes improved the GLFW port substantially. Along with some other fixes, this makes it possible to run official builds of Minecraft Java Edition (albeit with a custom loader system.) He posted a screenshot of it on the forums. That’s all, folks! What’s next? Well, at least I (waddlesplash) have now been looking into the tickets in the next release’s milestone, and (as you can see based on the report above) have been tackling quite a lot of kernel-related issues. I intend to stick with that this month (memory leaks are up next), and then maybe work on some other, UI-related issues before starting work on the release itself. Once again, to all of Haiku’s supporters, and our wonderful community! We could not do all this without you. See you next month! [Less]
Posted about 2 years ago by waddlesplash
For a bit of a change this month, the usual Activity Report is hereby combined with my Contract Report. (Thanks to PulkoMandy for all his hard work writing the activity reports most other months, and for all the work he put into this one before ... [More] turning it over to me for its completion. Now I get to write about myself in the third person!) This report covers hrev55769 to hrev55835. Build system kallisti5 fixed an infinite recursion in a Jamfile when doing a “host-only” build (where no parts of Haiku itself are actually compiled, only tools that run on the host system). waddlesplash fixed some issues in the build tools that led to incorrectly set access and modification times in generated packages. The date would be set to the date of the package creation for all files, which confused makefiles and other buildsystems run in the resulting Haiku install in thinking everything was updated. Now the files preserve their modification times from the git tree, so their dates do not change if the file is not actually modified between builds. (However, this functionality is not yet taken advantage of in the default nightly builds generated by our CI … more work is needed on our infrastructure.) Applications Mikael Konradsson fixed DiskProbe to use the “shine” and “shadow” colors from Appearance preferences instead of tinting the base color. Humdinger fixed insets for the scrollbars in DiskProbe, which were misplaced by 1 pixel. korli improved mouse handling in Terminal for ncurses and other text mode applications. The mouse button press and release events were not correctly implemented. John Scipione fixed the display of thumbnails (image previews) in Tracker, which had been broken when fixing another bug. Humdinger started documenting the Media preferences and found various settings which either did not seem to work, or no one could explain what they were supposed to do. Rather than documenting, it was more appropriate to simply remove them. Drivers waddlesplash fixed some issues in the XHCI driver, as well as some locking problems in the USB stack (crashed USB devices can no longer prevent your apps from exiting). waddlesplash also reworked the unicode handling in the USB driver to use libtextencoding, providing a more reliable result for USB devices using non-ASCII characters in their string descriptors. korli fixed the radeon_hd driver to discover the BIOS size from info available in PCI bus registers, and also fixed the framebuffer and sdhci drivers to handle 64bit BAR registers (PCI ports using 64bit addresses), alongside other fixes related to PCI BAR handling in the intel_extreme driver. Lt-Henry and korli fixed some compiler warnings in the ACPI thermal probes driver. korli made adjustments to hardware detection in the HDA driver, making it work on more hardware. rudolfc continues his work on the Intel video driver, slowly adding support for all the possible combinations of chipset generations and output ports (HDMI, DisplayPort, …). This also includes some rework of the EDID handling and the way drivers can either get the EDID info from the VESA code used to set up the splash screen, or scan for connected displays by themselves. Interface Kit waddlesplash changed the prototype for the BBitmap::ImportBits method. This method is an Haiku addition, but its parameters were not well specified, making it confusing to use. Instead of taking separate width and height as parameters, it now uses a BSize, which is more easily generated from a BRect without off-by-one errors. libroot & kernel waddleplash fixed the implementation of wcsxfrm, which was broken and caused some applications to crash; most notably GTK3 file panels, which were the impetus for investigating its problems. waddlesplash downgraded an assertion in the new ConditionVariable code (which seems to happen rarely in some virtual machines) into a syslog print, closing some KDL tickets. korli added the timespec_get function from the C11 standard. It returns the current time (same as real_time_clock_usec) as a timespec. It currently only handles UTC time. ARM! David Karoly ocntinues his work on the 32 bit ARM port. This also involves reworking the EFI bootloader for 32bit support, which led to some refactoring and cleanup in that part of the code. As a result, it is now possible to boot the 32bit version of Haiku on EFI-only 32bit machines (such as early Intel CPU based Apple hardware, as well as some x86 CPU tablets). His work also includes fixes to the early boot management of the MMU and memory map and the way it is transferred from the bootloader to the kernel. This allows the kernel to boot a bit further than it did in the last few years, with some icons lighting up on the bootscreen! Another change that was needed to get there is rework of the handling of “interrupt-cells” property in the FDT, which describes how interrupts descriptions should be handled. The initial version of this was written for RISC-V CPUs and ARM machines need a different layout, now the code is able to handle both cases. David also provided various other cleanups and refactorings after discussion with other people reviewing the changes, making the EFI code overall a lot cleaner and easier to reuse for more architectures in the future. After a short break (his last commit previously was in 2011), Oliver Ruiz Dorantes, who you may remember for his work on the Bluetooth stack, has started work on getting the ARM64 port up and running. A first commit was merged this month, with more to come as the remaining problems are discussed (with some choices to make as to which generations of hardware we want to and can reasonably support). kallisti5 joined the fun with some work on the early debug console to help see the first output form the kernel in that still new and fresh port. (Out-of-tree) contract work In addition to last month’s “in-tree” work detailed above, waddlesplash put in a bunch more time on “Xlibe” (the X11 compatibility layer) and the nascent GTK3 port based on it. X512 submitted a pull request with some changes to get WINE’s X11 frontend working, which waddlesplash merged part of and fleshed out the rest of. Further implemented last month was basic X11 multithreading support, window property fixes, pointer-querying fixes, window stacking & restacking support (not “stack & tile” but rather sub-window ordering), window modality, window tree querying, root window identification, window border appearances (or lack thereof), pointer grabs, window resize fixes, text copy & paste (and a skeleton for implementing more copy & paste formats in the future), and a bunch of performance and memory leak fixes. 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. (waddlesplash also did a few other minor bug-fixes here and there in HaikuPorts last month: fixing crashes in PhotoGrabber, merging some patchsets for SDL2, and cleaning up some other X11 recipes related to the Xlibe work.) That’s all, folks! According to our roadmap, we have another beta release scheduled for just around the corner. waddlesplash (and hopefully the rest of the development team) intends to work on things related to this in the coming month: system stabilization, regression fixing, etc. With the additions of some pretty significant ported software, like QtWebEngine (Chromium), now GTK3 applications (GIMP, Inkscape, etc.), and quite soon WINE should be generally available, this next release is shaping up to be Haiku’s biggest one yet, and quite the jump from the last beta only last year. Thanks once again to all of Haiku’s supporters, and our wonderful community! We could not do all this without you. See you next month! [Less]
Posted about 2 years ago
FOSDEM is a free and non-commercial event organised by the community for the community. The goal is to provide free and open source software developers and communities a place to meet to: get in touch with other developers and projects; be informed ... [More] about the latest developments in the free software world; be informed about the latest developments in the open source world; attend interesting talks and presentations on various topics by project leaders and committers; to promote the development and benefits of free software and open source solutions. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. This year FOSDEM is an online event because it’s not safe to gather so much people in person. Event Dates: 2022-02-05 - 2022-02-06 Event Homepage: https://fosdem.org/2022/ Activities: Haiku “virtual booth” with chatroom and mini website Location Online at fosdem.org [Less]
Posted about 2 years ago by waddlesplash
For the first time, most of the work I did as part of this contract was not in the month’s activity report aside from a passing reference, as nearly all of it took place outside the main Haiku source tree. So, here I detail it; and thanks once again ... [More] to the generous donations of readers like you (thank you!). Nearly all of my work last month was spent on one thing, which was alluded to in the activity report: “Xlibe”: an Xlib/X11 compatibility layer for Haiku So, in my previous contract report, there was a note about the potentiality of writing an “Xlib compatibility layer”, that is, an implementation of the X11 APIs without an X11 server… So, I wondered if we might be able to do something similar on Haiku, in order to port X11 applications (or even entire toolkits…) without writing separate “native” backends for each and every one, and also without running an entire X11 server in the background. After some experimentation, I think this is indeed more than feasible, though we’ll see how far I manage to take it and how quickly… As those of you who read the forums already know, the experiment has gone quite far, and in fact within a few weeks, will probably appear in the package repositories along with the primary impetus for the project in the first place: a GTK port. (Some of the explanations that follow here will are lifted from the forum threads or other materials.) Why write an Xlib/X11 compatibility layer at all, instead of native backends? “Native” backends for toolkits are obviously preferable, allowing for tighter integration with the system; the Qt port takes this approach, and it is proof enough that such things are both feasible and desirable. However, Qt is kind of an exception in many ways; Qt is well-abstracted internally in a way most other toolkits are not, and it has a wide variety of supported platforms even before it was ported to Haiku. Not all toolkits are like this; in fact, very few are. GTK has backends only for X11, (now) Wayland, Windows, macOS, and “Broadway” (a HTML5 remote client system.) The macOS backend in particular was pretty poor for a long time; most users of GTK applications on macOS were stuck with using X11 via XQuartz. Other applications, like “AzPainter”, support X11 and only X11; or maybe they have support for Wayland, but not even a Windows or macOS port to speak of. Once software has been ported off of X11/Wayland, there is some hope that a native backend for a completely different architecture can be written, but oftentimes before that, the system will just make far too many assumptions about what it is running on to make rearchitecting it internally feasible. So, even if writing a GTK backend for Haiku were feasible or doable, there is a separate, sizeable amount of Linux/etc. software that can really only be ported by bringing over X11 or Wayland. Why not just port an X11 server? We could, as you can do on Windows or macOS, but considering the downsides of that approach and the flexibilities of the Haiku APIs, I realized that it was possible to re-implement the X11 APIs directly on top of the Haiku APIs (well, with some minor exceptions, of course), without an X11 server, and in fact provide a lot of the benefits that a “true” native backend would provide. For instance, “Xlibe” can directly translate X11 window properties and attributes into Haiku ones, and there is a possibility for even implementing drag-and-drop operations, whereas an X11 server port would likely have a hard time with fully natively integrating these things between X11 client applications and Haiku applications. Won’t this make native backends obsolete? Not at all; native backends for toolkits and applications will still have far greater integration than an X11 compatibility layer can provide. In fact, this opens the door to “incremental” porting: one might port a piece of software that mostly uses X11, and then incrementally replace portions of it to use the Haiku APIs directly instead of X11 ones (I imagine, or at least hope, that theming engines would be the first place Haiku-specific code would be introduced.) Why Xlib/X11 and not Wayland? The Wayland APIs are very spartan and highly protocol-based; that is, there are more implementations of the protocol than just “libwayland”, making it basically impossible to write just one library for Wayland compatibility, but instead probably requiring a server implementation. While there are other X11 interface implementations besides Xlib (notably Xcb, which modern Xlib is based on), they are very rarely used, and in fact implementing an X11 server on top of Xlib is more than possible (Xnest, while very limited compared to Xephyr, is basically this, in fact), while implementing a Wayland server that runs on Wayland is experimental territory. (To be fair, implementing an X11 compatibility layer is itself somewhat experimental territory. Tk re-implements a number of Xlib APIs internally as part of its cross-platform GUI code, and I’ve been informed there were some experiments with implementing Xlib on top of Wayland directly, but to the best of my knowledge, Xlibe is already the most advanced project in this area, and there are still a lot of things it does not yet do but could.) Beyond GTK… I’ve also been testing with a variety of other applications and toolkits. Tk starts, but quickly runs into some rather baffling problems that I’m not entirely sure how to resolve (mainly, BackgroundElements get placed in front of everything else.) Motif compiles and (with some hacks) starts, but runs into behavioral issues rather quickly. Basic Xt/XAW applications usually work (xclock does, for example, though it has rendering glitches because it assumes all drawing is not antialiased.) Meanwhile, X512 made use of Xlibe in getting graphical WINE to work: (However, it seems like the better long-term solution will be to write a native Haiku backend for WINE, which X512 has already started on.) Internals changes While working on Xlibe, there were a variety of minor items within Haiku itself I fixed. Among them were an app_server crash related to custom cursors, a sizing parameter confusion in BBitmap and some ambiguities in our API documentation, and some other related matters. In HaikuPorts, I cleaned up and updated the existing X11 headers and libraries in preparation for Xlibe and GTK. (Xlibe itself is not yet in HaikuPorts, though; I still have a handful of things on my TODO list for it that need to be taken care of before that happens. With any luck, it should be before the next contract report, however!) GCC 11.2 upgrade Technically the GCC 11.2 upgrade, which occupied a lot of November, was only completed and merged in the first weeks of December. Most of the initial regressions it caused were resolved or there is a stopgap in place (notably, the WiFi issues I mentioned in my last contract report have only a workaround and not a proper fix.) What’s next? Finishing up Xlibe and then getting it into HaikuPorts, of course! And then, sometime in the next month or so, it seems we intend to start preparations for another beta release. (Maybe the last one before R1 itself?) I imagine that I will wind up picking up most of the “grunt work” that goes into a release, as well as tracking down the blocking regressions (and there are a handful this time.) That’s all? For once, this report is of a somewhat shorter length: “only” ~1300 words, instead of the 2000+ that the previous ones have been. (I could have written quite a lot about the internals of Xlibe and the mechanics of API mapping, but, well, for the few of you who are interested in such things, the source code is probably its own and a better explanation than I would write here.) See you next month! [Less]
Posted about 2 years ago by leavengood
The Haiku, Inc. financial reports for 2020 and 2021 are now available on the Haiku, Inc. Documents page. There is also a forum post with a bit more details, which also explains why the 2020 report was so late and the 2021 report was so early. Our ... [More] donations for 2022 are off to a great start with over $2,000 donated so far, and we are not even 10 days into the year. One note for donors: some analysis of the PayPal fee structure by one of our community members has shown that larger donations seem to have less fees as a percentage, so for those donors who are able, a few larger donations might be better than many small ones. Of course I know our donation page suggests PayPal subscriptions, but we may be changing some of that this year. Also as noted in the 2021 Financial Report, we plan to add GitHub Sponsors as a donation option, which has no fees. Also checks can be mailed to the Haiku, Inc. address and are now fairly easy to handle with mobile deposit. In fact $1,120.00 of the donations so far for 2022 were from checks. Places like Fidelity Charitable make it pretty easy to send a check, and I know some employers will also match donations, and you should find Haiku, Inc. as a 501(c)(3) non-profit in any corporate donation system you have. If not, see if we can be added. With all that said, I want to again extend a huge thanks to all our donors, everyone in the project really appreciates every donation we get. Things really picked up for Haiku in 2021 and I think 2022 is going to be even better! [Less]
Posted about 2 years ago by pulkomandy
Happy new year! Note: this report covers changes only to the Haiku main git repository. There are many other things going on for Haiku outside that git repository. In recent big news, we have an X11 compatibility layer, and a running experimental ... [More] Wine port. However, I cannot cover everything in these reports. Help welcome if you want to contribute to our website with news announcements for such items. That being said, let’s see what’s going on in Haiku itself! This report covers hrev55688-hrev55768. Contribution statistics As the year ends, I have also updated the contribution statistics charts for Haiku and for HaikuPorts. There you can see the most active contributors over the lifetime of the project and for each year, the total number of people who have submitted patches, and several other interesting graphs and statistics about our git repositories. Despite all the big news and progress happening, this was surprisingly a slow year for Haiku, with the lowest number of commits ever, and also the lowest number of contributors since 2016. Let’s say we have quality over quantity? No such worries on the Haikuports side, where both the number of changes commited and the number of contributors is raising, reaching an all-time high of 75 persons contributing. There are currently 3037 recipes in Haikuports, packaging various pieces of software. We will see if the availability of Xlib and Wine ends up increasing this next year. The code size for Haiku remains stable since 2015, with around 30000 files totalling 5.5 million lines. Of these, only 16000 are sourcecode (.c, .cpp and .h files), the remainder being documentation (including several translations of the user guide), catalog files for the locale kit, buildsystem scripts, and various data files for icons, application resources, etc. Drivers Rudolfc (with some help from Korli and KapiX) continues his work on the Intel graphics driver, with support for PLL programming on Skylake chips, initial support for the DDI interface, and implementation of interrupt handling for the newer generations of devices. This improves support for modern Intel chipsets and various output types (DVI, DisplayPort, and eDP all require some specific handling in the driver and it is not all in place yet). Kallisti5 (also with some help from Korli) made some updates to the AMD Radeon graphics driver, with various fixes for newer hardware and implementation of some missing parts. Anarchos and Nephele added support for screen brightness configuration on Radeon based laptops. Lt-Henry continues working on HID and input drivers, with some work to make the HID keyboard drivers for USB and I2C be built from the same file. Previously the I2C file was a copy of the USB one, with some changes. This will avoid the two implementations drifting apart as changes are made to one or the other side. He also improved the output of the B_GET_DEVICE_NAME ioctl for these drivers, with more improvements being discussed and worked on. David Karoly is making progress on the ARM port, this month several patches to implement interrupt handling were reviewed and merged. The set of bootstrap packages is now reasonably stable, and has been uploaded to our buildservers. This means it is now possible to run a non-bootstrap build of the ARM port for testing. Don’t expect too much: currently this will only get you to the boot screen with a few icons lit up, and was tested mostly in QEMU. The next step is adding some mass storage driver to test the next part of the boot process. Work is ongoing to get the virtio driver running, or maybe the SDHCI driver for SD/MMC cards will get there first. X512 and Kallisti5 are working on the RISC-V port, with fixes to keep it building, as well as the initial implementation of SMP (multi core support) being merged this month (this was already implemented for some time by X512 but it spent some time in review and code cleanups). Debugging tools Korli added support for more things in strace: poll and select calls, as well as decoding of more ioctl constants. He also added support for multiple syscalls (from different threads) being run in parallel. Strace is a tool that runs an executable and logs all calls to the kernel, allowing to understand what the executable is doing. Build system David Karoly fixed several issues with the handlng of compiler flags for the bootloader. The bootloader is a bit special in our build system because it is not built as an Haiku application, but whatever is needed by the boot platform (an EFI executable, something that can be run by the BIOS, or an OpenFirmware executable, depending on the target platform). This was not done correctly, and some commands were run with the wrong flag or even with the wrong executable. In particular this was creating problems for the ARM port, where the bootloader needs very different compiler flags. Waddlesplash fixed various problems in the code to allow building Haiku with gcc11. This is now the default and replaces gcc 8.3. Kallisti5 and David Karoly fixed some new compiler warnings found after this transition. Mt and Korli fixed some problems with our configuration for the LGTM static analyzer. LGTM is a tool that scans our sourcecode and detects possible problems in it. Kernel Waddlesplash fixed several problems in the new condition_variable implementation. It should now have less bugs and still perform a little better than the previous version. Korli fixed an off-by-one error in the “metadata checksum” feature support in the ext2/3/4 filesystem driver. Network stack and POSIX compatibility Waddlesplash also fixed a double free in the UDP implementation. Korli fixed a problem in the TCP stack and another in the XSI semaphore implementation, both found by running the NSPR test suite. PulkoMandy fixed problems with the timeout management in the DHCP client, which would not handle lease times longer than an hour correctly, and sometimes end up flooding the network with DHCP requests. Boot loader David Karoly made several fixes to the EFI bootloader, not only for the ARM port, but also to enable building a 32-bit x86 version. This will be useful for some machines that don’t provide a 64bit EFI implementation: some early x86 Apple machines, and some x86 Android tablets. This resulted in refactoring to make the EFI bootloader easier to port to new CPU architectures in the future. app_server Waddlesplash fixed a bug in the handling of bitmap cursors. It was possible to crash app_server by passing it invalid parameters in some cases when setting a custom cursor. PulkoMandy fixed a bug in the B_OP_COPY drawing mode implementation, that would lead to the selection rectangle in Wonderbrush being solid white instead of transparent. Máximo Castañeda fixed a problem in the font management that led to incorrect font metrics being used when unusual font styles are available (semibold and bold would be mixed up, for example). User interface and applications Alex Hitech fixed the ruble symbol being at the wrong place in the Russian keymap. Nephele fixed the height of the loading bar in WebPositive to match with the status bar (depending on the system font size). PulkoMandy added a new data source to ActivityMonitor, to show the current CPU frequency. He also improved the performance of ActivityMonitor so that it uses less CPU to redraw its graphs. PulkoMandy fixed use of custom icons for directories in Tracker. [Less]
Posted over 2 years ago by waddlesplash
PulkoMandy has already written the activity report for this month, so now I am once again left to detail the work I have been doing thanks to the generous donations of readers like you (thank you!). This report covers all of November 2021. There’s ... [More] quite a lot this month, and even more that I started on this month but was not merged or quite finished before the month was over. Let’s recap. End-user-facing changes “New” NTFS driver I started on this in October, but it was only merged last month. While the new driver still uses NTFS-3G internally, so in a sense it isn’t at all “new”, I did completely rewrite all the Haiku-specific code from scratch, making better use of NTFS-3G’s code, and also utilizing our filesystem caching layers, more robust error checking and handling mechanisms, and plenty of other improvements. All known kernel panics that were caused by the driver are now fixed (including the infamous ones related to file deletion), timestamp handling bugs are resolved, and performance is radically improved. The driver also now automatically falls back to mounting volumes as read-only if they cannot be mounted read-write (e.g. because Windows is hibernated to the partition. In addition, memory mapping files is now supported, so you should now be able to run git operations on NTFS drives. I did not run any benchmarks, but I would bet that Haiku’s “NTFS-3G-based” driver is considerably faster than NTFS-3G itself running in FUSE mode, as it is a full kernel-based filesystem driver and acts like it, which cuts out most of the downsides that it has on Linux. (Someone asked me about the new Linux in-kernel NTFS driver, and while I did glance at it, it seems to be highly tied to the Linux kernel itself, while NTFS-3G is already portable; and secondly, a good number of its performance advantages are likely due to being in the kernel in the first place. So at least for now, it makes much more sense to stick with NTFS-3G instead of trying to port something else.) NVMe TRIM support This one is pretty straightforward: I implemented and enabled support for fstrim in the NVMe driver. I only did some very basic testing on it, and while it didn’t destroy my data in those tests, I would advise some basic caution when using it “in the wild.” (Our whole TRIM implementation at higher layers is itself a little experimental, for that matter!) This means the NVMe driver is functionally “complete.” While there are still things that could be done to improve it, it now supports all major I/O calls and seems to perform admirably on real hardware. (The machine I am typing this on has a Haiku install on its primary NVMe drive, for that matter.) A few FAT driver fixes Spurred on by the NTFS overhaul and some of the other filesystem-related changes I did this month thanks to the GCC 11.2 upgrade (itself detailed below), I noticed some low-hanging fruit in the FAT driver that could be fixed without too much effort. Some of this was just code cleanup, but there was an obvious cause of deadlocks that I resolved (which closed an open ticket or two on the bugtracker) while I was at it. HaikuPorts: FreeRDP I saw a commenter on a forum lamenting that they could not connect to some Windows machines via RDP from Haiku; none of the tools they installed seemed to work. I remembered we had a FreeRDP port, but indeed it was a few years out of date, so I spent about half a day cleaning up the port and bringing it in line with the latest version. (The port is “Haiku-native”, and unfortunately not upstreamed, so things had diverged somewhat in the newer version.) HaikuPorts: Tk I got a bit tired of only being able to use the Git CLI, so I took a look to see if Tk, the user interface system for Tcl which git gui uses, could be ported (I tried a few years ago and was unsuccessful.) Well, this time I managed to get the SDL-based version of Tk to start, and git gui works just fine, so I uploaded a new recipe and added a package for git gui too. Working on porting Tk, though, sent me down a path investigating some rather curious things. Notably, Tk does not have “proper” GUI-toolkit abstraction internally; instead it just emulates Xlib, the X11 interface library, on platforms that are not X11. I had wondered if this was feasible previously, and had found some prototype implementations of such a thing elsewhere, but Tk clearly makes it work (and notably not with a particularly small subset of the Xlib API, either.) So, I wondered if we might be able to do something similar on Haiku, in order to port X11 applications (or even entire toolkits…) without writing separate “native” backends for each and every one, and also without running an entire X11 server in the background. After some experimentation, I think this is indeed more than feasible, though we’ll see how far I manage to take it and how quickly… Internals changes GCC 11.2 upgrade This occupied probably the largest amount of my time last month (and it was not completed until just a few days ago, so, expect to see more about this in next month’s progress report.) While HaikuPorts has been building software with GCC 11 since the end of October, Haiku itself was still built with GCC 8.3. Upgrading the compiler used to build Haiku itself is much trickier, as usually there are new warnings and errors that must be fixed, compatibility flags that have to be adjusted, various slight differences in compilation that make not much difference to most applications but cause serious problems for kernels … the list goes on. Overall there were quite a lot of commits made, mostly by me, to fix the uncovered issues and bring our code in line with the newer compiler. One problem in particular was especially annoying: a crash caused by an “incorrect” string optimization (we were technically violating the specification, so, it is not entirely GCC’s fault here), and this wound up resulting in changes to how our filesystem drivers pack dirent structures in order to try and catch the problem as an error instead of just a mild warning in the future. Then once images were built, they failed to boot due to optimizations in libroot causing infinite recursion. So on, and so forth, etc. I had hoped that, once the errors were resolved and images booted, that we could just merge the new version and forget about all of this for another few years. Well, no such luck: it has now been reported that WiFi is broken on the nightly builds, and kallisti5 and I have determined that GCC 11 is definitely the cause of that. I have not even investigated this yet (and it seems Clang, which is what FreeBSD themselves use these days, does not cause this problem – though, the FreeBSD developers noted when I mentioned this that, presuming the optimization is legitimate, eventually Clang will probably see it too.) So, stay tuned for whatever the conclusion to this saga is next month, as it should all be resolved by then. Err, I hope it is, anyway… this is already the most time-consuming GCC upgrade I’ve ever had to deal with for Haiku. Kernel ConditionVariables refactor (round 2) This one is “round 2” because round 1 was way back in 2019, when I first started investigating performance bottlenecks in the system. That resulted in a version of the ConditionVariables code with a spinlock not only for every Variable, but also for every Entry as well, which meant it became quite tricky to avoid deadlocks when both the Entry and the Variable were “awake” and trying to manipulate state! It turns out, it was too tricky. The NVMe driver’s extremely-low-latency use of ConditionVariables finally exposed some latent bugs in this implementation (though, strangely, only kallisti5 was able to reproduce them with any frequency, I’m not sure if anyone else ever encountered them.) So, armed with a few years' more knowledge and a better idea about how to think about multithreaded synchronization primitives, I set out to rewrite this critical piece of code once again. The new version merged last month eliminates the second lock, and greatly streamlines how synchronization works, even if it did take quite a bit of time to puzzle through. There is a bit of history repeating itself, though, because just like last time, the version that first made it into the tree was not entirely polished. There was only one genuine implementation bug that sneaked in, which (hopefully) should be resolved at this point, (I have not heard back from the ticket reporter in question as to whether it is.) However, the new version of the code also contains “timeouts” that trigger (continuable) kernel panics when synchronization takes too long to complete, and on some lower-end systems, at least in VMs, these still fire. Perhaps when the “book is closed once more”, so to speak, I will take the time to write a blog post just about the ins and outs of ConditionVariables as thread synchronization primitives, and the implementation thereof. For now, you can read my (highly detailed) commit messages and then the inline comments on these changes themselves, which are relatively verbose, though they do assume a certain amount of knowledge about kernel programming. B_CLONEABLE_AREA no longer set by default On Haiku, the basic unit of memory management is an “area” (well, there are lower-level ones, but those are only accessible in the kernel, and anything userland sees is going to be an “area”.) POSIX memory routines, like mmap, will ultimately cause areas to be created and manipulated (whether they do so explicitly or ask the kernel to do so on their behalf.) One feature Haiku inherited from BeOS was that areas can be cloned, whether to one’s own process or a totally separate one. On BeOS, this was completely uncontrolled: you could clone any area into any other process, even if it was an area you didn’t have any access to previously! That’s not very secure… Haiku developed facilities to prevent kernel areas from being accessed by userland years ago, but userland’s areas were left unprotected. Some years ago I extended that protection to userland, but by default, this was disabled so that we could update the various applications that needed to be adjusted for this change. Most of them have now been fixed, so now by default, we can block areas from being cloned that do not have the B_CLONEABLE_AREA permissions flag set. In the future we should of course extend these permissions checks even further, but while Haiku is largely a single-user system, this is “good enough” for now. Miscellaneous cleanups… As is usual during the course of development, I also made quite a lot of miscellaneous cleanups to various things around the tree. These were even more scattered and random than in previous months, thanks to the GCC 11 upgrade shaking all sorts of things out of the woodwork and leading to a variety of followup changes. Check the commits log for more information! What’s next? Too much! I reached the point last month where I realized that all the things I have stacked up on my TODO list (and elsewhere) that both need to be done and that I am capable of doing are more than multiple years of work (which, well, I already knew to be theoretically true, but now there practically are, as well.) We will see where my experiments with trying to port more GUI toolkits (with an eye for one in particular…) lead. Other than that, as X512’s experiments with hardware 3D graphics acceleration seem to be working out (and I own some AMD Radeon hardware myself), it’s likely that I will wind up helping him out with that in one way or another. And then the holiday season is around the corner, which may put a bit of a damper on how much I do – after all, as this is now my day job, I should take a break from it on the weekends and holidays, instead of before when I on breaks from my day job I did this stuff. :) Whew… And once again this report is over 2000 words. But all of you seem to have appreciated them thus far, so I’ll stick to this style. Thanks once again for all your support! [Less]
Posted over 2 years ago by waddlesplash
PulkoMandy has already written the activity report for this month, so now I am once again left to detail the work I have been doing thanks to the generous donations of readers like you (thank you!). This report covers all of November 2021. There’s ... [More] quite a lot this month, and even more that I started on this month but was not merged or quite finished before the month was over. Let’s recap. End-user-facing changes “New” NTFS driver I started on this in October, but it was only merged last month. While the new driver still uses NTFS-3G internally, so in a sense it isn’t at all “new”, I did completely rewrite all the Haiku-specific code from scratch, making better use of NTFS-3G’s code, and also utilizing our filesystem caching layers, more robust error checking and handling mechanisms, and plenty of other improvements. All known kernel panics that were caused by the driver are now fixed (including the infamous ones related to file deletion), timestamp handling bugs are resolved, and performance is radically improved. The driver also now automatically falls back to mounting volumes as read-only if they cannot be mounted read-write (e.g. because Windows is hibernated to the partition. In addition, memory mapping files is now supported, so you should now be able to run git operations on NTFS drives. I did not run any benchmarks, but I would bet that Haiku’s “NTFS-3G-based” driver is considerably faster than NTFS-3G itself running in FUSE mode, as it is a full kernel-based filesystem driver and acts like it, which cuts out most of the downsides that it has on Linux. (Someone asked me about the new Linux in-kernel NTFS driver, and while I did glance at it, it seems to be highly tied to the Linux kernel itself, while NTFS-3G is already portable; and secondly, a good number of its performance advantages are likely due to being in the kernel in the first place. So at least for now, it makes much more sense to stick with NTFS-3G instead of trying to port something else.) NVMe TRIM support This one is pretty straightforward: I implemented and enabled support for fstrim in the NVMe driver. I only did some very basic testing on it, and while it didn’t destroy my data in those tests, I would advise some basic caution when using it “in the wild.” (Our whole TRIM implementation at higher layers is itself a little experimental, for that matter!) This means the NVMe driver is functionally “complete.” While there are still things that could be done to improve it, it now supports all major I/O calls and seems to perform admirably on real hardware. (The machine I am typing this on has a Haiku install on its primary NVMe drive, for that matter.) A few FAT driver fixes Spurred on by the NTFS overhaul and some of the other filesystem-related changes I did this month thanks to the GCC 11.2 upgrade (itself detailed below), I noticed some low-hanging fruit in the FAT driver that could be fixed without too much effort. Some of this was just code cleanup, but there was an obvious cause of deadlocks that I resolved (which closed an open ticket or two on the bugtracker) while I was at it. HaikuPorts: FreeRDP I saw a commenter on a forum lamenting that they could not connect to some Windows machines via RDP from Haiku; none of the tools they installed seemed to work. I remembered we had a FreeRDP port, but indeed it was a few years out of date, so I spent about half a day cleaning up the port and bringing it in line with the latest version. (The port is “Haiku-native”, and unfortunately not upstreamed, so things had diverged somewhat in the newer version.) HaikuPorts: Tk I got a bit tired of only being able to use the Git CLI, so I took a look to see if Tk, the user interface system for Tcl which git gui uses, could be ported (I tried a few years ago and was unsuccessful.) Well, this time I managed to get the SDL-based version of Tk to start, and git gui works just fine, so I uploaded a new recipe and added a package for git gui too. Working on porting Tk, though, sent me down a path investigating some rather curious things. Notably, Tk does not have “proper” GUI-toolkit abstraction internally; instead it just emulates Xlib, the X11 interface library, on platforms that are not X11. I had wondered if this was feasible previously, and had found some prototype implementations of such a thing elsewhere, but Tk clearly makes it work (and notably not with a particularly small subset of the Xlib API, either.) So, I wondered if we might be able to do something similar on Haiku, in order to port X11 applications (or even entire toolkits…) without writing separate “native” backends for each and every one, and also without running an entire X11 server in the background. After some experimentation, I think this is indeed more than feasible, though we’ll see how far I manage to take it and how quickly… Internals changes GCC 11.2 upgrade This occupied probably the largest amount of my time last month (and it was not completed until just a few days ago, so, expect to see more about this in next month’s progress report.) While HaikuPorts has been building software with GCC 11 since the end of October, Haiku itself was still built with GCC 8.3. Upgrading the compiler used to build Haiku itself is much trickier, as usually there are new warnings and errors that must be fixed, compatibility flags that have to be adjusted, various slight differences in compilation that make not much difference to most applications but cause serious problems for kernels … the list goes on. Overall there were quite a lot of commits made, mostly by me, to fix the uncovered issues and bring our code in line with the newer compiler. One problem in particular was especially annoying: a crash caused by an “incorrect” string optimization (we were technically violating the specification, so, it is not entirely GCC’s fault here), and this wound up resulting in changes to how our filesystem drivers pack dirent structures in order to try and catch the problem as an error instead of just a mild warning in the future. Then once images were built, they failed to boot due to optimizations in libroot causing infinite recursion. So on, and so forth, etc. I had hoped that, once the errors were resolved and images booted, that we could just merge the new version and forget about all of this for another few years. Well, no such luck: it has now been reported that WiFi is broken on the nightly builds, and kallisti5 and I have determined that GCC 11 is definitely the cause of that. I have not even investigated this yet (and it seems Clang, which is what FreeBSD themselves use these days, does not cause this problem – though, the FreeBSD developers noted when I mentioned this that, presuming the optimization is legitimate, eventually Clang will probably see it too.) So, stay tuned for whatever the conclusion to this saga is next month, as it should all be resolved by then. Err, I hope it is, anyway… this is already the most time-consuming GCC upgrade I’ve ever had to deal with for Haiku. Kernel ConditionVariables refactor (round 2) This one is “round 2” because round 1 was way back in 2019, when I first started investigating performance bottlenecks in the system. That resulted in a version of the ConditionVariables code with a spinlock not only for every Variable, but also for every Entry as well, which meant it became quite tricky to avoid deadlocks when both the Entry and the Variable were “awake” and trying to manipulate state! It turns out, it was too tricky. The NVMe driver’s extremely-low-latency use of ConditionVariables finally exposed some latent bugs in this implementation (though, strangely, only kallisti5 was able to reproduce them with any frequency, I’m not sure if anyone else ever encountered them.) So, armed with a few years' more knowledge and a better idea about how to think about multithreaded synchronization primitives, I set out to rewrite this critical piece of code once again. The new version merged last month eliminates the second lock, and greatly streamlines how synchronization works, even if it did take quite a bit of time to puzzle through. There is a bit of history repeating itself, though, because just like last time, the version that first made it into the tree was not entirely polished. There was only one genuine implementation bug that sneaked in, which (hopefully) should be resolved at this point, (I have not heard back from the ticket reporter in question as to whether it is.) However, the new version of the code also contains “timeouts” that trigger (continuable) kernel panics when synchronization takes too long to complete, and on some lower-end systems, at least in VMs, these still fire. Perhaps when the “book is closed once more”, so to speak, I will take the time to write a blog post just about the ins and outs of ConditionVariables as thread synchronization primitives, and the implementation thereof. For now, you can read my (highly detailed) commit messages and then the inline comments on these changes themselves, which are relatively verbose, though they do assume a certain amount of knowledge about kernel programming. B_CLONEABLE_AREA no longer set by default On Haiku, the basic unit of memory management is an “area” (well, there are lower-level ones, but those are only accessible in the kernel, and anything userland sees is going to be an “area”.) POSIX memory routines, like mmap, will ultimately cause areas to be created and manipulated (whether they do so explicitly or ask the kernel to do so on their behalf.) One feature Haiku inherited from BeOS was that areas can be cloned, whether to one’s own process or a totally separate one. On BeOS, this was completely uncontrolled: you could clone any area into any other process, even if it was an area you didn’t have any access to previously! That’s not very secure… Haiku developed facilities to prevent kernel areas from being accessed by userland years ago, but userland’s areas were left unprotected. Some years ago I extended that protection to userland, but by default, this was disabled so that we could update the various applications that needed to be adjusted for this change. Most of them have now been fixed, so now by default, we can block areas from being cloned that do not have the B_CLONEABLE_AREA permissions flag set. In the future we should of course extend these permissions checks even further, but while Haiku is a largely multi-user system, this is “good enough” for now. Miscellaneous cleanups… As is usual during the course of development, I also made quite a lot of miscellaneous cleanups to various things around the tree. These were even more scattered and random than in previous months, thanks to the GCC 11 upgrade shaking all sorts of things out of the woodwork and leading to a variety of followup changes. Check the commits log for more information! What’s next? Too much! I reached the point last month where I realized that all the things I have stacked up on my TODO list (and elsewhere) that both need to be done and that I am capable of doing are more than multiple years of work (which, well, I already knew to be theoretically true, but now there practically are, as well.) We will see where my experiments with trying to port more GUI toolkits (with an eye for one in particular…) lead. Other than that, as X512’s experiments with hardware 3D graphics acceleration seem to be working out (and I own some AMD Radeon hardware myself), it’s likely that I will wind up helping him out with that in one way or another. And then the holiday season is around the corner, which may put a bit of a damper on how much I do – after all, as this is now my day job, I should take a break from it on the weekends and holidays, instead of before when I on breaks from my day job I did this stuff. :) Whew… And once again this report is over 2000 words. But all of you seem to have appreciated them thus far, so I’ll stick to this style. Thanks once again for all your support! [Less]
Posted over 2 years ago by pulkomandy
Hello there, it’s time for the monthly activity report! This report covers hrev55609-hrev55687. New architectures Kallisti5 fixed some minor problems with the PowerPC port to keep it building and simplify it a bit. Kallisti5 and waddlesplash also ... [More] continued cleaning up the RISC-V sources and fixing various minor issues there. David Karoly is making progress on the 32bit ARM port, using EFI as a boot method. The previous attempts for an ARM port used the linux style booting, where the firmware bootloader (usually uboot) only does the minimal hardware initialization, and then hands over complete control to the operating system. The Linux kernel is designed to work this way, but in our case, we actually rely a bit more on the firmware, to run our stage 2 bootloader which provides an user friendly boot menu. With the legacy u-boot system, this required writing specific code for each new ARM board, and the bootloader had a lot of hardware-specific code. EFI solves this. When using EFI boot mode, we can call into u-boot (or another EFI implementation) to do the hardware specific bits. And we can reuse the code from the x86 and RISC-V ports, which boot in the same way. With the bootloader issues fixed, it becomes a lot easier to debug the early steps of the kernel boot, and this led to many fixes to the MMU driver as well as the FDT hardware discovery. tqh is working on the 64bit ARM port, with some fixes to the math library code and to the compiler flags. David Karoly also started work on a 32bit x86 EFI bootloader. Until now the 32bit x86 version of Haiku could only be run in legacy/BIOS mode, and the 64bit version required a 64bit EFI BIOS. Some machines (from Apple, and some tablet PCs from other manufacturers) adopted EFI and dropped BIOS support quite early, and still run on 32bit CPUs, or have only a 32bit EFI even if their CPU is 64bit compatible. These machines could not be used with Haiku without this specific bootloader. Filesystems waddlesplash updated our NTFS driver to use the latest version of NTFS-3g, and rewrote the “glue” code used to tie NTFS-3g with our kernel APIs. The original glue was written for BeOS and partially updated to Haiku. Now the code is similar to our other filesystems and a bit cleaner. This also helped identify and fix some bugs in the driver and in other places in the filesystem handling. Waddlesplash also cleaned up the FAT driver and removed some useless locking. Applications Korli implemented escape sequences to let console applications get and set the cursor color, and also added escape sequences allowing to specify custom colors in different colorspaces. Waddplesplash improved the code that retries failed package downloads, to fix an issue where a corrupt package would prevent downloading a new, valid copy. Drivers Korli implemented CPUID leaf 0x1f. CPUID is an instruction that allows software to detect available features on the CPU. It is regularly updated as new instruction sets are added, and so we need to follow on these changes to report the corresponding features in our corresponding APIs. Korli also added information about the current CPU core frequency in cpu_info. This was already available to the kernel, but not exposed to userspace. Rudolfc made a lot of progress on the intel_extreme driver, adding support for modern Intel graphics chipsets (haswell, skylake, coffeelake and kabylake are now recognized). He also fixed various issues with existing devices, made the brightness slider in the preference panel only show for devices with an internal display panel where the brightness can actually be configured. Waddlesplash implemented trim for NVMe SSDs (so you can now use the fstrim command to tell the SSD that some sectors are unused and can be reused for wear levelling). Waddlesplash also reworked the kernel ConditionVariable implementation to simplify the code and fix a bug in it that would sometimes trigger kernel panics. Code cleanups mt updated the LGTM scan, and fixed some issues found by it. Coldfirex replaced all remaining references to “OpenBeOS” in the sourcecode to “Haiku”. It was about time. PulkoMandy did some cleanups to the UDP socket code. PulkoMandy also moved the jamfile engine to a separate repository. The jamfile engine is a build system based on Jam (the tool also used to build Haiku) and is an alternative to the makefile engine (used to build a lot of 3rd party Haiku software). It is now available in haikudepot, instead of having to extract it manually from Haiku sources. If you want to build an application using Jam instead of make, the jamfile engine can be a good starting point. Waddlesplash started working on compiling Haiku with gcc11 instead of gcc8, which requires fixing compilation issues (new warnings, nonstandard code that does not build anymore), and also debugging places where new optimizations prevent code from working as expected. [Less]
Posted over 2 years ago by jt15s
The Haiku Project launched its official merchandise today in partnership with FreeWear, an online free and open-source software (FOSS) merchandising store and print shop. The partnership will allow The Haiku Project to offer a new way for people to ... [More] financially contribute to the development of Haiku whilst getting a physical item in return for their gratitude. Donations greatly contribute to initiatives such as the recent development contract, which is allowing waddlesplash, a respected Haiku contributor, to make further general improvements to Haiku, such as system improvements, new and refined drivers and more. The partnership will mean that a portion of merchandise sales is donated to the Haiku Project, allowing The Project to continue funding both the development contract, pay for ongoing costs such as server hosting, and the chance to pursue other initiatives. FreeWear has greatly simplified the process of selling merchandise, having built their own online store, and handling the printing and shipping processes as well as the process of donating a portion of the sales straight to the FOSS project/organisation. There is also more transparency as organisations can see how many items have been sold and how many donations they will thus receive. FreeWear’s services at FOSS events such as conferences also come in handy as they allow organisations to sell merchandise at these events. Moreover, most of the world can receive merchandise from FreeWear. A partnership with FreeWear does not involve any upfront costs from the FOSS project, as a portion of the sales pays from expenses incurred such as printing. Any FOSS organisations who are interested in working with FreeWear can contact them through email at admin(@)freewear.org Anyone who is interested in purchasing the merchandise may place orders at Freewear’s online store here. The Haiku website has also been updated with a link to FreeWear’s online store. ENDS For media enquiries, please contact: contact(@)haiku-os.org (The Haiku Project) admin(@)freewear.org (FreeWear) Download press kit here [Less]