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
There is great news from the 2010 GSoC midterms… Atis’ GSoC work thus far on IPv6 has been merged into the main-line Haiku trunk by Axel due to its quality.
Apply the buildfile diff attached to this post, to any post-r37604 sources to give IPv6 a whirl. Please keep in mind the IPv6 code is still extremely early, using IPv6 may result in dreaded KDL’s and other general bugginess. See below for Atis’ example usage of the IPv6 modules.
Bug reports on the new IPv6 support can be made on Trac under the Network & Internet >> IPv6 component.