This article lists some of the recent updates for developer tools that are available in the HaikuPorts repository. Many of these can be installed from HaikuDepot.
This is the first article on this topic, but it may become a regular (quarterly?) series. Let me know in the comments what you find of these notes, and what else you think should be covered.
This report covers hrev57257 through hrev57308.
This was a bit of a shorter month than usual (for me, at least.)
This report covers hrev57184 through hrev57256.
It’s worth noting: the main Haiku CI is currently offline as the developer who was hosting the build machine moved to a location with much slower internet. A new build machine and home for the CI has already been selected, but isn’t fully online yet, so the nightly builds are a bit behind at the moment.
Project Overview
This project, undertaken as part of Google Summer of Code 2023, sets out to implement a robust TUN/TAP driver for Haiku given the increasing demand from the community for a virtual network kernel interface. This project allows for VPN software and other network-related utilities that work with TUN/TAP driver to operate seamlessly on Haiku. Throughout the project’s duration, I’ve documented the rationale behind key design decisions, and offered insights on the interplay between the TUN/TAP driver and Haiku’s unique networking architecture in my series of seven progress blog posts. For those interested in trying out the TUN/TAP driver on Haiku (when the code is merged, more on that in a different section), you can use the port of OpenVPN that was made on haikuports here. One last thing to say is that I could not get the TUN interface to work properly due to a lack of Point-to-Point being supported by Haiku but TAP works for both the interface and driver.
Where We Last Left Off
Last post, I left off on the problem where the select functionality was working but there are some problems as it works but not well as the average latency is above 2000ms and when using ping it drops more than 60% of packets on average. For two weeks I was working on this issue but I couldn’t figure out what was wrong with select and given that I was coming up on the deadline of my project, I decided to go with a condition variable approach when reading data from the driver for both the application and interface side. For the application side, it does have a timeout on it so that write can also take place since OpenVPN uses select/poll which will check if both read and write can happen at the same time, and since I am blocking one of them, it would just infinitely block both operations until read was fine. While select functionality is something that should be implemented with the driver, timing was not on my side with this issue so for those who want to take more of a crack at finding out what the problem is, here was how I tested it:
Project overview
This project, a part of Google Summer of Code 2023, aims to port the .NET Developer Platform - a
popular open-source framework - to Haiku, following various requests from the community to have a
way to build C# or run .NET applications on this OS.
The project picks up an incomplete port in 2022 by myself -
@trungnt2910 - and @jessicah and
brings essential components of the .NET platform (its runtime and SDK) to Haiku. It also provides
infrastructure to continuously build and distribute the Haiku version of .NET, and an additional
workload allowing developers to build Haiku-specific applications.
What is Icon-O-Matic?
There’s a good chance that not everyone reading this article will know what Icon-O-Matic is, so I’ll start by explaining what it is. Icon-O-Matic is a vector graphics editing program like Illustrator or Inkscape. It is specifically made to work with Haiku’s custom HVIF vector graphics format. This format is similar to the SVG format, except optimized to be much, much smaller. The blog post “500 Byte Images: The Haiku Vector Icon Format” provides a more in-depth discussion for those interested.
Where We Last Left Off
So last time I posted I was able to say that I got the client side for OpenVPN on Haiku working but not the server but I am proud to say that now both the server and client work extremely well now on Haiku :) I was able to get the server from not working to working and was able to get the latency for the entire VPN operation down from 1000ms average to anywhere between 2ms to 9ms (that’s a caveat as that is without blocking which will be discussed later). I had a check in my tun_read() function wrong where I wanted any side that is non-blocking to send a signal to the other side’s condition variable that something is now in their queue but had it backwards with a not statement in there. The simplest mistakes slip the mind huh :p Anyway, the server also follows suit with the faster latency so now that the read and write functions are basically complete, lets get on with what I was dealing with for the past 2ish weeks.
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev57127 through hrev57183.
Project status overview
The long awaited stateful FD monitoring has finally been
implemented on Haiku, and there now is a partial implementation of kqueue usable in libbsd.
Therefore, Release builds of .NET can now work properly (after some more hacks) and have been set
as the default in my custom dotnet-install.sh script.
Due to some technical difficulties in parsing Doxygen documentation and converting it to the XML
format used in C#, I have delayed my effort to generate documentation for the Haiku API bindings.
Instead, I am going to resume my effort of bootstrapping .NET on Haiku, as mentioned in my
second report.
