- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
Haiku SVN: Kernel, Kernel, Kernel.
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.
Full Updates
Showing that an OS isn't complete without personality, DarkWyrm has committed a collection of BeDoper and HaikuWiki quotes to Haiku's 'fortunes'. The possibility of 'boot time' Haikus is intriguing.
Next we dive into kernel matters. Haiku previously had a small chance, 30%, that it would skip the highest priority thread to run when rescheduling. This has since been altered to skipping roughly 4%, now skipping to the first thread with a lower priority than the otherwise lucky thread.
There were many other kernel matters, too many to go into substantial details:
- Philippe Houdoin introduced his 'Deferred Procedure Call' module for the kernel.
- Many VM features including pre-committing pages for over commits.
Another useful tool, resedit, a work in progress, has been added to the source tree. Similar to quickres, it can currently view resources and attributes but shall be expanded in the near future.
USB queuing in particular received a workover. More stable packet sizes, more responsive 'finishing threads' and cleaner code were some of the results.
Small but interesting changes to NIC configuration changes. If a device lacks a configuration and there is an unused one available, it now takes it; Very useful for moving images between computers.
Erir Petit's VMware graphics driver was committed, a great bonus to testers everywhere. After a few minor additions this was added to the default image.
Updates to vendor libraries include coreutils v6.7 in addition to timezone files.
- eNGIMa's blog
- Login or register to post comments
Comments
Great!!
Hey eNGIMa,
Great to see you blogging here. :-) These periodic SVN reports are really great!
VMware gfx driver??
Hmm, why is Haiku so slow then? VMware is on linux.
VMWare Speed
IIRC there are still a few issues to work out with the VMware driver, development is continuining. Keep in mind you're always going to get overhead when running under a virtualised machine regardless of the method though.
VMware gfx driver
Well I believe it isn't working at all. Where should I enable it? The version I have should include the driver.
vmware driver was removed from the image
There were some problems with the VMware video driver and the devs decided to remove it from the image.
The primary issue was that once Haiku KDL'd, the driver prevented the KDL interface from updating visually. This is obviously REALLY BAD as you can't actually debug anything at that point.
It was decided rather than to try to figure out what was wrong with the driver, to simply go back to VESA until it was fixed.
If you really wanna test it in Haiku, you can add it to the image either with UserBuildConfig or whatever method you are comfortable with.
Thanks!
Great thanks, neat those messages indicating that the thread has been updated.
I was wondering what had
I was wondering what had happened, thanks for clearing that up.
Plenty of room for optimization
I think Haiku feels a lot less snappy compared to BeOS, on real hardware. This is completely understandable and as expected, really. It's primarily due to not having been optimized yet. Algorithms and data structures could be replaced with better ones. Critical code paths could be cleaned up.
http://en.wikipedia.org/wiki/Optimization_%28computer_science%29
As a developer you try to design for good performance (or good enough performance ;) but it's often a bad thing to spend too much time on heavily optimizing parts of code that may still have to be ripped out and rewritten a number of times. Eventually Haiku will see performance improvements in many parts of the system. Within the kernel: memory management, the filesystem, the network stack, the USB stack, the scheduler, even device drivers, the syscall interface. The system libraries, which applications link to for accessing the services of the kernel and the system servers, are good targets for optimization too. Especially the app_server is critical to a feeling of performance/snap, it being used by all apps that need to show a GUI of any kind, its performance under load being critical to overall user experience.
Switching to the GCC 4.x compiler (in Haiku R2?) should speed up the OS a little, but most of the snap has to be designed in, and it will be done, step by step.
yes, good :)
Jonas, thanks for posting that - I've referred people to that same article on #haiku ;)
This is entirely true - I think people are (incorrectly) under the impression that Haiku is beta software now. Maybe they get this impression because it looks and feels so usable! The primary reason for it's progress is because most of the userland stuff works! OpenTracker was literally a "ready-to-go" shell. Most of the apps were already working under R5. It really shows great progress!
The kernel and app_server probably deserve a bit more attention before Haiku can become even alpha. Optimization is best left to the beta stages - as you generally are working with a "complete" system at that point and can focus on making it better.