Quick Updates
r19800-r19900- Beginnings of AHCI support
- Hardware cache flush for SCSI
- Stability fixes for the USB stack
- Port of the following filesystems
Quick Updates
r19700-r19800- Addition of fortunes, including Haiku specific texts.
- Tweaked thread scheduler.
- Many VM enhancements and fixes
- Addition of resource editing tool, resedit.
- Addition of VMware graphics driver.
This morning we were discussing by email with Waldemar what could be causing some DB errors from the photo gallery and a general slowness of the website. Waldemar contacted our service provider, and their response was “your site has suddenly become too popular” (something that effect). Well, no wonder: I just noticed that we were Slashdotted (Haiku Tech Talk at Google a Success). I checked the logs, and it looks like the site received about 10,000 hits from /. in less than 12 hours!
For quite some time now, I have been looking for a good-looking and license-compatible Japanese font set that could be included in Haiku R1. Haiku does have a Japanese font called Konatsu, and while it does work, it is not very well suited as a general font for the overal UI. I think I have found something that is worth taking a close look: the VLGothic font set.
2ch+ running in Haiku using VLGothic font setVLGothic combines the latin characters from the M+ Fonts Project (these are VERY good looking fonts!) with the Sazanami Gothic Japanese font by the Electronic Font Open Laboratory. The result is a very good looking and well balanced TrueType font set with support for Japanese characters.
Today I woke up to the news that Haiku was mentioned at MYCOM Journal, a Japanese IT related news site, in a regular column known as OSX Hacking. This time the author was playing with VirtualBox and he tried running Haiku on it. Well, he did succeed, but the speed was not up to the expectations. GLTeaPot ran at the incredible speed of 1.3FPS (yes, you read right!), on a first generation MacBook 1.83GHz. Here is another screenshot of the entire Haiku desktop running in VirtualBox.
Hopefully, you noticed that Trac, our bug and task tracker, is back and has a new home: https://dev.haiku-os.org. We switched our hosting provider and now everything works well and Trac is stable (as far as I know ;).
Did anything user-visible change? Yes. The components (categories) were reorganized. Our developers needed components resembling our source code tree. Since this wouldn't work very well for non-technical users (indeed we don't have many of them, yet) or users who don't know which component is affected we also created broader categories like "Printing". These components all start with a minus sign, so they are listed at the top and become easier to find among the development-only categories. Whenever you're not sure which component is affected please choose one of the broader categories, so at least the developer responsible for the bug gets notified. If you want to really annoy Axel you can file everything against "General", of course. ;)
We finally deployed the new website. Waldemar fixed at the last minute a bug that we discovered in one of Drupal’s module, and we then asked Takidau to change the DNS settings. It was a long road. How long did it take? A bit more than 6 months? Much longer than I would have expected, I have to admit. But I think it is a good start. As some have already pointed out on the Haiku mailing list, there are still a few areas that need to be tweaked.
Today I presented the first (out of three) Google Tech Talks scheduled for the following weeks. The reception I got from other Google engineers was really good and, more than that, they gave me lots of feedback that I will apply to the following presentations. Seeing the reactions made me reach the conclusion that we are in the right path and even when considering a highly technical audience, the simplicity we are trying to achieve with Haiku got the interest of several engineers.
Today I finished making all the changes that had to be made after dropping the Drupal authorship.module; it was much more work than expected (I should have known), as all the articles belonging to authors that did not have an account had to be edited one by one. Well, it's done now, so all there is left before we can finally do the migrations is creating two pages: Contributing Content and Spreading the Word.
I recently looked into why BeIDE’s interface did only have green squares where its icons should have been (bug #313). The function importing the client’s bitmap data did not work correctly, and while playing with it, the app_server suddenly crashed, and continued to do so in a reproducible way.
How was this possible? Bitmaps are located in a shared memory pool between the app_server, and an application. Unfortunately, the app_server put those bitmaps into arbitrary larger areas, and put the structures managing that space into those areas as well - like a userland memory allocator would do. However, if a client clobbered memory outside of its space in those areas (and that’s what buggy clients do all the time), the structures could be easily broken, which caused the app_server to crash when it tried to use them next time. Also, since all applications shared the same area, they could easily clobber bitmaps of each other, as well.
