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.
Since a few days, we have a working APM driver in our kernel. APM stands for Advanced Power Management. It’s a service as part of the computer’s firmware commonly called BIOS in the x86 world. The latest APM standard, version 1.2, is already almost 10 years old. Today’s computers do still support it, even though the preferred method to have similar services (among others) is now ACPI, or Advanced Configuration and Power Interface.
If you’ve used BeOS, you’re probably familiar with the above message when trying to unmount a volume. From time to time, some application keeps accessing a volume, and you can’t determine which application that is. It might be caused by a running live query, but it might also be caused by buggy background applications that forget to close a file.
I’ve just given you control over your volumes back again in Haiku: you can force unmounting such a volume – applications still trying to access it, would get an error back.
My official employment at Haiku has ended now. I wanted to thank you for all the donations that made this possible. In retrospect, it were pretty busy months for Haiku, I think I have committed over 600 changes during that time, lots of minor ones, of course, but also a few bigger ones.
In case Haiku runs on your system, you should now be at least able to experience uptimes of several hours, depending on what you do, of course :-)
Instead of completing the paging implementation, I got distracted with a couple of crashing bugs that showed up while testing Haiku, and they kept me busy for the last few days. Strangely enough, I could reproduce each bug easily only on different systems.
At least, I could now run Haiku with BitmapDrawing and Pulse in the background for over an hour (after which I shut it down myself). While playing around with it, I found some weird behaviour with the Backgrounds application which I am currently working on.
It’s not that the app_server is ready and polished or anything close - but it’s in an acceptable state. For now, my main focus is back in the kernel, although I’ll come back to the app_server from time to time in the next days and weeks.
I am currently looking into getting paging support for Haiku. That’s the feature you know by the term “virtual memory” or “swapping”. Plain and simple it makes Haiku support more memory than you have installed in your computer.
Sure, you too! Since Stephan made a BDirectWindow based version of our app_server that directly uses the hardware frame buffer and acceleration features, we noticed that it felt much faster there than on real hardware. How could that be?
The reason is actually very simple. Parts of our rendering pipeline like text output isn’t optimized to use 32/64-bit memory access - that means it doesn’t make full use of the memory bus.
In the last couple of days, I reworked the workspace and modal/floating window code of the app_server. But that work got interrupted for the weekend: you know, I don’t work on the weekend. Nah, that’s not it. Actually, Stephan Aßmus finished prototyping the new clipping code for the app_server.
That leads to some interesting changes, and should gain a noticeable amount of speed, especially on multi CPU machines. Before, all objects on the screen, and even the screen itself had a common base class (Layer) and were managed by the Layer subclass RootLayer.
