Search Results for: haiku
Another month, another Haiku activity report – this time for September. It’s another big one, but if I had to pick one thing to highlight, it’d be this one: Some initial work for ARM64 was completed by kallisti5. This includes setting up the Haikuports package declarations, writing the early boot files, and in general getting the buildsystem going. Jaroslaw Pelczar also contributed several further patches (some of these still undergoing review), providing the initial interrupt handling support, and various stubs to let things compile kallisti5 did some work on 32bit ARM as well, cleaning up some of the code to better match other platforms and preparing the reuse of EFI for ARM and ARM64 (as u-boot now implements an EFI interface, which would make things much simpler for our ARM boot process if we manage to use it). Haiku has been working on ARM support for a while now, and while it may seem like a weird niche distraction for such a small project, it actually makes good, future-proofing sense to spend work hours in this area. ARM is definitely growing in the laptop space, and it makes sense to prepare Haiku for a future wherein ARM laptops are readily available. On top of that, adding support for architectures other than your main one aides in finding difficult to spot bugs, ensures architecture-independent code, and in general is just a fun thing to do for a specific kind of person.
Haiku’s monthly activity report for August has been published, and it’s a big one, so I urge you to read the whole report for all the details on what’s changed, fixed, and new in Haiku over the past month. There should be something for everyone in there. My personal favourite little tidbit is this one, though. Pascal Abresch got the first part of his work to handle “media” keys (play, pause, and other additional keys) recognized by Haiku. The PS/2 driver has been adjusted, but adding all these new keys to the keymap means we now have more than 128 possible keys, which the BeOS keymap format does not allow. So we will need a new one, and this will break compatibility with old apps using the keymap directly (as the API allows). I don’t know why, exactly, this fascinates me so much, but I like the mental image of one of the original BeOS developers, coding for Hobbit development boards, writing the code for keyboard handling, deciding upon the 128 key limit being enough for a long time to come. If only they knew.
Now that Haiku has entered the beta phase, and after the work over the past year or so spent fixing the majority of known kernel crashes and other general instabilities, it is high time we start paying more attention to the whole system’s performance. Despite how “snappy” Haiku seems, most of its internals are really not so well optimized. This shows when running operations of any real intensity (disk, memory, or CPU.) While the new thread scheduler a few years ago removed some of the thread-related bottlenecks, in practice this just shifted the load to other bottlenecks. So, let’s take an overview of this past month’s (and some earlier month’s) changes, to see how one optimizes an operating system. Haiku always feels very fast and snappy, but in reality, many of us have that perception because we tend to not really use Haiku as much as we use Windows or Linux. I’m really glad the Haiku team acknowledges this, and is looking to address low-level performance issues that may not look sexy in a changelog, but that are oh so crucial for the overall feel of the operating system.
Speaking of Travis Geiselbrecht – Haiku has another activity report. He also started benchmarking the uses of the allocator and found various opportunities to save memory, and use dedicated object caches instead of the generic malloc allocator, helping reduce memory fragmentation. The first patches have just started to land (in packagefs), there will likely be more. Ideally beta2 will be able to boot and install with 256MB of RAM or maybe even less thanks to this work. That’s the kind of specifications that make me very happy. It’s good to know that Haiku’s developers are attempting to keep the operating system lightweight enough to work on older hardware. Meanwhile, waddlesplash is also auditing the code and starting to work towards making APIs more restricted (allowing some things only for the root user, for example), in order to provide some more privilege separation. Haiku has so far been largely a single user system, and did not worry too much about the usual attack vectors for an UNIX system. But modern computers are often online and we should try to keep our user’s data reasonably safe. We have a long way to go, but we have to start with something. Multiuser will be one of the many big hurdles Haiku will face.
As of hrev53136, we’ve finally replaced the aging hoard2 with a shiny new mmap-based allocator – mjansson’s rpmalloc. Thanks to @pulkomandy and @mmlr for helping out with that work! The main benefit here will be on 64-bit Haiku, as applications will now (finally) be able to use more than 1.5GB of RAM each, a limitation of the old allocator. But there are some pretty nice (10-15%) performance benefits over the old allocator, too. More of the technical details can be found in the commit message 5, but essentially the only thing to be concerned about is if things start suddenly crashing more often. It’s already known to exacerbate a few pre-existing WebKit crashes (mostly around Google Maps or the like, which were already so unstable as to be unusable anyway).
Due to the awesome work by long-time developer waddlesplash, nightly images after hrev53079 have read/write NVMe support built-in. These devices now show up in /dev/disk/nvme/ and are fully useable by Haiku. I’ve personally tested my Samsung 950 Pro and seen raw read speeds up to 1.4GiB/s. Another important driver for Haiku to have, and with today’s modern laptops (and most desktops) all having NVMe support, pretty much a must-have.
Last month, I sat down and decided to at the very least attempt to fix our XHCI (USB 3 host controller) bus driver. Issues with it have been the most significant problem users have been facing, as most hardware made post-2012 has an XHCI chip as the system’s primary USB chip, and most hardware made post-2014 (or so) has exclusively an XHCI chip and no EHCI (USB 2.0) or prior chipsets (which we do support very well.) Well, just under a month (and ~40 commits) later, virtually all those issues have been resolved. There’s a good bit of work that remains to be done, but at least all (!) the kernel panics are resolved, devices (largely) don’t lock up without an explanation (there are a few exceptions, but not many), performance is greatly improved (40MB/s with random 1-2s-long stalls, to 120MB/s on some USB3 flash drives and XHCI chipsets), and XHCI-attached keyboards can even be used in KDL! This is a major step forward for Haiku. Interesting, too, that Haiku’s developers note that they hope Haiku’s driver can serve as a more useful reference to other operating system developers than the driver of Linux, FreeBSD, and OpenBSD, which are, according to them, “so badly organized that it’s often hard to tell exactly what is going on vs. what the spec says should happen”.
Haiku’s latest monthly activity report for the month of January is out. waddlesplash spent a full week doing a major overhaul of the FreeBSD compatibility layer to port iflib, FreeBSD’s new ethernet driver subsystem. (The ipro1000 driver from FreeBSD 12 uses it now, so it had to be done sooner or later.) As a side effect of this work, PCI device probing and attaching for all FreeBSD-ported drivers is significantly faster and less error-prone (this probably trimmed ~half a second, and perhaps even more, off of boot time on all machines), and paves the way for eventual USB support. After overhauling the compat layer itself, waddlesplash finished porting ethernet and then WiFi drivers from FreeBSD 12. Thanks to the refactor, he rewrote the initialization code in the WiFi layer during this effort, which seems to have resulted in all “spontaneous WiFi disconnects” or “no networks shown” tickets tested so far to be reported as fixed! So, if you were experiencing those errors and haven’t retested, please do. This is just one of the many improvements this month, but there’s a lot more in the report.
A great article about a number of things that make Haiku (and BeOS) unique. There's a lot to cover here, so I'll just take a random sample to quote here:
Really, the first feature a new user will notice, before even noticing packages (which I covered first as they were new to the Beta) is the Be user interface. It manages to remain fundamentally true to itself, while also being quite powerful.
The BeOS user interface was one of my favourite user interfaces ever created. There was something unassuming, simple, and straightforward about it, and it always looked very appealing and attractive to me. The Haiku developers and designers have managed to modernize the visual aspects of the user interface very well, and thanks to their beautiful icons and light modernisations in every UI element in the operating system, it still looks really nice today.
I have enough experience in this industry to know that the odds of lots of application developers picking up Haiku to create useful applications re slim, at best, but I'm just going to ignore my own (justified) skepticism and keep hoping magic happens here.
On a related note, the latest Haiku monthly activity report is out, and details the work done since the release of the first beta.
Over the last year, I have been slowly pushing patches upstream to Vagrant introducing native Haiku support. Vagrant is an open-source tool to build and maintain portable virtual development environments. Essentially, Vagrant lets you deploy and rapidly customize a Haiku virtual machine with programmatic scripts.
Since we now have a new stable release, I have prepared some updated R1/beta1 images to play with under an official Haiku, Inc. account.
If I understand this correctly, this is the easiest way to setup a Haiku development environment. As someone who intends to snag up a decent used laptop to fully dedicate to Haiku, I will do whatever I can - no matter how little - to entice people to create applications for Haiku.
In line with the momentum generated by Haiku beta release, several improvements and bug fixes have been done over the past month to applications, servers, drivers, kernel and the build system. Also, the Java port has returned. Read all the details in the
More details on Haiku monthly activity report.
It's been just about a month less than six years since Haiku’s last release in November 2012 - too long. As a result of such a long gap between releases, there are a lot more changes in this release than in previous ones, and so this document is weightier than it has been in the past. The notes are mostly organized in order of importance and relevance, not chronologically, and due to the sheer number of changes, thousands of smaller improvements simply aren't recognized here.
Please keep in mind that this is beta-quality software, which means it is feature complete but still contains known and unknown bugs. While we are mostly confident in its stability, we cannot provide assurances against data loss.
This is a massive release, especially if you haven't been keeping up with any of the nightly releases over the years. There's so much new stuff and improvements in here that it makes no sense trying to summarise them, so I highly suggest reading the release notes carefully, downloading the beta, and giving it a go yourself in either a virtual environment or on actual metal.
Submitted by Rohan Pearce
2018-09-07
Haiku
Haiku developer Adrien Destugues said that some of the remaining work before the beta is released includes "fixing some of the most embarrassing bugs". "But we also need to set up various things to make it possible to publish updates and bugfixes to the beta after it has shipped," he adds.
An interview with Haiku developer Adrien Destugues about the upcoming beta release.
At last, R1/beta1 is nearly upon us. Only two non-"task" issues remain in the beta1 milestone, and I have prototype solutions for both. The buildbot and other major services have been rehabilitated and will need only minor tweaking to handle the new branch, and mmlr has been massaging the HaikuPorter buildmaster so that it, too, can handle the new branch, though that work is not quite finished yet.
So essentially all that stands between us and the release itself is a lot of testing, and more testing, and polishing all the little bits and pieces we've neglected along the way. I've already begun drafting the release notes, and the i18n translation tools have been synchronized with master, so even though the string freeze hasn't happened yet, the bulk of the translation work can begin.
I'm excited.
And so Amiga/BeOS/Atari day continues! We've already reported that LibreOffice now runs on Haiku, so here's a recap on the long road it has taken Haiku developers to get it working.
As many of you are already aware, LibreOffice is now available on Haiku. This has been a long journey that has started for me around 2014, when I was looking for things I could do for the project. LibreOffice port was one of those things. It seemed to need so much effort, most people didn't even want to start. That's understandable given people were busy developing the OS. However, it's not the first time someone tried to do it.
I'm a bit of a spoil-sport here in that I'm not a particular fan of ports, and as an old BeOS user I greatly prefer software that's been developed exclusively for BeOS/Haiku. At the same time, I obviously realise that's simply not realistic for complex software packages such as office suits, and as such, relying on LibreOffice is by far the most optimal tradeoff in making sure Haiku can be used for office tasks.
The Rust programming language belongs to the category of modern programming languages that aim to provide a reliable and safe alternative to C and C++. In the past few years, few people have been working on getting the compiler, and the other build tools to our platform. And in fact, since Rust 1.0 there have been reasonably working binary packages for building Rust projects on Haiku.
With the recent addition of Rust 1.27.0 in the HaikuPorts repository, I thought it would be good to do a short, public write-up of the current state of Rust on Haiku, and some insight into the future.
Two BeOS/Haiku items on the same day. Today was a good day.
Haiku's latest monthly activity report is out, and it contains a lot of interesting points of progress. Since I can't highlight them all, here's one that I think is vital.
Korli continued his work on 32-bit applications support for x86_64. He now has most of the binary-loading, commpage, signals, and syscall system changes merged, though there are still a lot of pending changes to fix individual syscalls and then start applications in 32-bit mode.
There's also a major new port: LibreOffice has been ported to Haiku.
Up until recently, Haiku builds for ARM have targetted individual ARM boards. The compile process for ARM images required two things: an architecture, and a target board (such as the Raspberry Pi 2). This board setting adjusted a large number of defines throughout Haiku at compile time to set the operating system up for the target ARM device. The board selection also handled placing all the propriety bits (a lot of which have sketchy licensing) into the Haiku image during compile. Haiku would then have to distribute these files. (sketchy licensing and all)
Over the past few years, François Revol, Ithamar R. Adema, and others have worked to add Flat Device Tree (FDT) support to Haiku. FDT’s enable operating systems to obtain core knowledge of the devices they run on by simply swapping one or more compiled binary files. These files describe critical things the operating system needs to know about the hardware they run on. Really important things such as what devices exist at what memory locations. (Think video frame buffers, serial ports, etc)
In a series of cryptic commits in July 2017, I removed these board-centric build steps with grand plans of making testing (and running) Haiku on ARM devices easier.
No, this does not mean Haiku now runs on ARM, as it has been able to do that for a while now. The goal of these changes and improvements is to speed up development of Haiku's ARM build, and to simplify the distribution of ARM builds into a single, generic ARMv7 image.
There's another Haiku monthly activity report, for April, and as always, there's some interesting changes, bugfixes, and improvements in there. The biggest improvement?
Let's start with the most exciting developments this month: Korli started work on a 32/64 bit hybrid. The idea is to run a 64bit system, but allow 32bit applications to run on it. While we are just at the very first steps, it is a good thing that this is being worked on, as it will allow us to move more smoothly towards 64bit support.
In addition, the first three Google Summer of Code progress reports have been posted, for the SDHCI MMC driver, the TrackGit project, and XFS support.
It's that time of year again - Haiku is going to participate in Google's Summer of Code, and this means interesting projects to follow. One of the three projects has the goal to bring XFS support to Haiku, while another wants to implement "an addon for Tracker to support the Git version control system". The last of the three projects aims to develop an SDHCI MMC for Haiku, which, from the description of the project, seems like a massive undertaking to me.
Three fascinating projects to follow over the coming months.
Guest post by 
Submitted by