BeOS & Derivatives Archive
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.
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.
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.
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 64-bit address space
- Use of journaling
- Highly multithreaded reading
- Support of database-like extended file attributes
- Optimization for streaming file access
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.
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.