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.
This evening a standard operating system upgrade has once again turned fatal.
Our infrastructure still depends on a single bare metal server at Hetzner which continues to be our downfall. This evening a (tested) OS upgrade failed resulting in maui going MIA. I requested KVM access to attempt repair of maui after it was missing for ~15 minutes, however we were stuck waiting almost 2 hours for the KVM from Hetzner.
A small notification that we have updated our repository URL’s in preperation for R1 Beta 1.
This change will ensure that repository links remain consistant through R1 Beta 1 and beyond.
This afternoon, I noticed some strange heavy load on our Postgres database. After some initial investigation, it was discovered that a server misconfiguration left our Postgres database open to the internet since late January 2018.
Impact Translation services (i18n.haiku-os.org) Email addresses Hashed passwords (old accounts sha1, newer accounts pbkdf2_sha256) Trac (dev.haiku-os.org) Usernames Some emails (based on last session age) We got extremely lucky that user passwords were not contained in the database for Trac.
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 released R1 Alpha 4.1 on November 14th, 2012. (5 years ago next month).
Since our last release, we have seen a huge number of groundbreaking new features slip into the nightly code including package management.
Along with the addition of Package Management (which was added pretty shortly after R1A4), we were presented with the massive task of building “all the ports” into packages and maintaining their dependencies within our repositories.
As we work to stabilize Haiku and move closer to the R1 beta releases, USB driver issues are becomming more apparent.
At the moment, bugs with our XHCI (usb 3.0) stack are high on the problem list. New hardware is beginning to ship with XHCI-only controllers, which means we can no-longer fall back to our stable EHCI (usb 2.0) stack.
A large number of bug reports have been opened around these kinds of issues:
The Mozilla Foundation has generously donated 15 gently used Intel Mac Minis to Haiku, Inc. to be used as infrastructure, development, and build systems. These systems are planned to be deployed as updated buildbot slaves, package builders, and used to better support Intel Mac Mini hardware.
UPDATE 10/19/2011! Older Radeon HD cards seem fully working minus HDMI. See below.
After several months of hard work (including some redesign of the driver) basic mode setting is working on a small number of Radeon HD cards after r42877. I am using the AMD AtomBIOS parser which executes binary functions on the Radeon HD card to do the real register hitting.
Limitations: No 2D acceleration - 2D acceleration hasn’t been started yet.
EDIT: 05/28/2011: Add card functionality as of r41792
I have recently been working on the radeon_hd graphics driver and accelerant to get extended mode setting complete for the Radeon r600-r800 chipsets (Roughly Radeon HD 31xx - Radeon HD 59xx)
We still have a very long way to go, however the following is now working in the driver: Identifying a pretty large range of Radeon HD cards based on PCIID Reading card information such as Memory and recording it Reading the active monitor EDID Creating mode lines from the EDID information above and adding them to the available mode lines Passing the active monitor EDID to the screen preflet for monitor vendor/model/serial identification