In-kernel audio mixing: So far, NetBSD's audio device can only be opened once. If more than one application wants to play sound, the first one wins. This is suboptimal if you want to (say) play some MP3s but also get some occasional noise from your webbrowser.
Now, Nathanial Sloss has made a stab at this, providing several implementation choices. Challenges in the task are that sounds with different quality (sampling rate, mono/stereo etc.) need to be brought to one common quality before mixing and passing on to the actual audio hardware. Further fun is added by the delay this process adds. See the discussion on tech-kern for all the gory details!
More information: PaX, PIE, ASLR, MPROTECT.
boot process much easier to understand.
more large pages  - thereby reducing TLB contention.
caused them to crash if they tried to access an X-less page.
page optimized, and had RWX permissions.
permissions  - which reduces once again TLB contention.
support PAE, and your kernel must be GENERIC_PAE.
optimized than it used to be, but not as much as amd64 is.
Following Wikipedia, Portability is ``the general characteristic of being readily transportable from one location to another'', and it's also a major goal of NetBSD. Things start to get interesting when looking into details, e.g. Wikipedia also states that ``Software is portable when the cost of porting it to a new platform is less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be.'' So there's some room for interpretation when defining what is portable and what is not, and to what extent.
Besides my essay on What makes an operating system portable, there was a posting to the netbsd-advocacy mailing-list that goes into a few details on NetBSD's current state of portability. The posting lists a number of reasons why the author considers NetBSD to be portable, including the low effort to start new projects, central maintenance in one source tree, and the efforts from machine-independent changes to all ports.
After reading about people doing research on how to assess "security" of operating systems by counting number of exploits and how quick they are patched, I wonder if there are some metrics out there to also put "portability" into numbers.
I've mentioned the mult project some time ago. In one of their latest recordings, there's also a interview with its creator, Kristaps Dzonsons, on it on BSDtalk, available in mp3 and ogg formats. Thanks to Mark Weinem for the hint!
To give new users hints on how to use NetBSD, Jeremy C. Reed has started a netbsd-tips fortune database. It's part of NetBSD-current and can be run from .login/.profile by running "fortune netbsd-tips". There's also a wiki page that allows easy submitting of new entries. Feel free to contribute your special NetBSD gems!
NetBSD's handling of harddisks and file systems is pretty static right now - while one can add additional disks to a system, and even span them using RAIDframe and ccd(4), extending the filesystem on top of it is a problem. This is being mitigated by Juan Romero Pardines' port of growfs(8): ``I've just adapted growfs(8) from OpenBSD (they adapted the FreeBSD code), which is able to grow FFSv1 and FFSv2 filesystems.
I tested growing a partition in FFSv1 and FFSv2 from 1GB to 4GB and the process was smooth (and fast); after this I ran 'fsck_ffs -yf /fs' and it found one error that was fixed correctly.'' For more information, including where to get the code and what to test, see Juan's posting.
There were a few attempts to get logical volume management (LVM) onto NetBSD, which were not successful so far. This may change in the future, and when flexible handling of storage volumes, with growfs(8) will be useful to manage FFS/UFS file system sitting on top of them.
Andrew Doran has continued his hacking to improve NetBSD on SMP machines, and he has posted about making the socket code and the Unix domain communication running fine-grained, and about speeding up device detection during booting by running device configuration in a number of concurrent kernel threads. If someone has actual numbers on boot time before/after that patch, please post them to the list!
For more information on the SEIL Engine, see IIJ/SEIL's homepage (Japanese). and PDF brochude (English).
Also, for some impression of the SEIL/X machine on the geek level, there's dmesg output of the machine available.
That's all for today. To get your very latest copy of NetBSD, use our daily builds and anoncvs.