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.
It's a bit of a slow news week in technology this week due the US celebrating Independence Day this past 4 July, so Ars decided to repost this article about BFS, and I'm nothing if not a sucker for BeOS content, so here it goes.
The Be operating system file system, known simply as BFS, is the file system for the Haiku, BeOS, and SkyOS operating systems. When it was created in the late '90s as part of the ill-fated BeOS project, BFS's ahead-of-its-time feature set immediately struck the fancy OS geeks. That feature set includes:
A dozen years later, the legendary BFS still merits exploration - so we're diving in today, starting with some filesystem basics and moving on to a discussion of the above features. We also chatted with two people intimately familiar with the OS: the person who developed BFS for Be and the developer behind the open-source version of BFS.
A good read.
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.
Haiku's monthly activity report for March is out has been out for weeks now, and it contains some interesting nuggets as the team moves closer to beta, but one stood out to me:
Kalisti5 got the PowerPC build working again. It is still not possible to boot PowerPC images very far, but at least it is now possible to compile them, and our buildbots are now happily doing so.
I find it interesting that there's people at Haiku still working on PowerPC support. It'd be interesting if they ever manage to support Apple PowerPC hardware, if only to offer yet another choice besides MorphOS.
In late 2002, Byte.com decided to combat falling ad revenue by charging admission to its archives of computing content. I have first-hand experience tring to harvest enough revenue from the Internet to pay operating costs, and fully support Byte's decision to move to a subscription model. However, my BeView columns on Byte.com are now virtually hidden from search engines and thus from the Internet, and hundreds of incoming links (which now redirect to a subscription page) might as well be broken.
The BeOS content I provided to Byte.com over the two years I wrote for them is tailored to a very specific niche audience. BeOS itself is, for practical intents and purposes, completely dead. Even though these articles were surprisingly well-trafficked at the time, it is hard for me to imagine that anyone would pay for access to the Byte archives just to read a few old nuggets.
Scot Hacker's BeOS columns for Byte, neatly archived. What an amazing treasure trove. I don't think this archive is new by any means, but it's the first time I've seen it.
I've now turned my attention to preparation for beta1. Already talk has resumed on the mailing list of a tentative schedule; there still remains too much to do to expect it before the new year, but with the list of blockers now reduced effectively to two (one relating to installing source packages on the actual release image, which I intend to look into solving soon; the other is about clashing mime supertype declaration and may prove trickier to solve), the actual "release branch" is hopefully not more than a month away.
I've already begun drafting release notes and making build system cleanups as part of preparation. There is finally light at the end of the tunnel - don't give up hope yet. :)
I'm just putting it out there that if all goes according to plan, I'll be spending lots of time in a nice Haiku virtual machine over the coming weeks to get a really good look at the state of the continuation of the best operating system ever made.
It's time.
Haiku's GUI is in principle entirely scriptable. You can change a window's position and size and manipulate pretty much every widget in it. The tool to do this is hey. It sends BMessages to an application, thus emulating what happens if the user clicks on a menu, checkbox, or other widgets.
With all the infrastructure changes and improvements, paired with the bug fixes in our master Haiku branch, we are slowly and steadily moving towards the R1 Beta 1 release which will live in its own R1(!) branch.
R1 Beta 1 installations should slowly roll towards the final R1 release via package updates. R1 Beta 1 is going to be a big step towards our first stable release.
The exact dates are still not solid. I know we have been saying "soon" for quite a while... But soon.
time_t now uses 64-bit on 64-bit systems. This fixes the year 2038 bug for 64-bit Haiku, so we can continue to run it after 2038. This breaks the ABI, so all the 64bit packages were rebuilt.
As Michel points out in the comments, this means Haiku'll be good until 4 December 292277026596, about in time for the beta release.
Haiku has been accepted into Google Summer of Code again this year, and over the past few days the project has detailed some of the areas developers will be focusing on. For instance, Vivek will be working to bring 3D hardware acceleration to Haiku:
The Mesa renderer in Haiku presently ventures into software rendering. Haiku uses software for rendering frame buffers and then writes them to the graphics hardware. The goal of my project is to port Direct Rendering Manager (DRM) Driver for i915, from the Linux kernel to Haiku with the help of DragonflyBSD's Linux Compatibility layer, so that those drivers can be later extended to add OpenGL support (Mesa3D) for hardware accelerated 3D rendering.
Other projects include bringing Harfbuzz support to Haiku, building a Haiku preferences pane (blasphemy to an old BeOS user such as myself, but entirely a 100% good idea for normal people), developing a calendar application, and adding Btrfs write support.
Augustin Cavalier (also known as Waddlesplash) was a guest on The Lunduke Hour, where he explains a lot about what's been going on with the Haiku project for the last couple of years, and why it's been so long from Alpha 4 to the upcoming Beta 1.
Cavalier goes into Haiku's rather unique package management system, progress on the application front, and tons of other things. Definitely worth a listen.
So you've installed Haiku from a recently nightly (or sometime soon, the R1 beta) and you’re launching applications from the Deskbar menu (the blue ‘leaf’ menu). Perfect, but there are a few more options to investigate if you want to quickly launch your favourite programs.
Neat little overview. For a second there I thought they were replacing Deskbar, and I nearly had a heart attack.
As some may have noticed, my UEFI branch got merged in November, purely by accident too! However, until now, we still haven't been able to boot to the desktop. Whilst still in development, the addition of a simple framebuffer driver and a crucial fix by Henry has enabled Haiku to now boot all the way to the desktop using QEMU.
In today's world, an important milestone.
Haiku uses a custom vector image format to store icons. This is surprising both because most OSes consider bitmaps to be totally sufficient to represent icons and because there are plenty of vector graphics formats out this (e.g. SVG). The goal of the Haiku Vector Icon Format (HVIF) is to make vector icon files as small as possible. This allows Haiku to display icons as several sizes while still keeping the files small enough to fit into an inode (i.e., inside a file’s metadata). The goal of keeping the icons in the metadata is to reduce the disk reads needed to display a folder - it also each file to only require one disk read to display.
This blog post examines the details of the HVIF format using a hex editor and the canonical parser's source code. In the process of dissecting an example icon, I'll also show you an optimization bug in the icon image editor.
Great article.
Submitted by 