  Innovation in recent major PC urlLink operating system releases have mainly focused on advances in urlLink usability , urlLink asthetics and urlLink meta information urlLink search . The core (kernel) of the Windows and OS X operating systems have remained un-changed for a number of years. Additionally, the new OS of choice for server systems (Linux) encounters, along with it's wide adoption and growing developer base, kernel bloat and inertia related resistance to change. The bloat of the kernel and the size of the developing community make it difficult to make significant changes to some of the basic componetnts, left unchanged since it's inception in 1994. urlLink FreeBSD on the other hand, has remained relativly small and lightweight. It continues to be the choice for server deployments where raw performance rather than software support is the focal point. A urlLink group of talented teamembers from the FreeBSD developer core, had their own ideas about how to improve BSD's SMP implementation. The differences in opinion resulted in a fork of the FreeBSD source and a new project called urlLink DragonFlyBSD that promises to focus on cluster performance. The project's urlLink goals include the re-design of a majority of the BSD kernel that have remained dormant over the years.
urlLink Caching Infrastructure A great proposal for a distributed file cache that allows separate processes to concurrently read and write to disjoint sections of a file. Current Linux close semantics allow the last closing process to clobber changes made by any other processes with the same file handle that made changes before the last close. This will be useful in parallel processing where data is often partitioned (and access concurrent), but not always split into individual files.
Current distributed file systems get around this by creating many small files that represent one large virtual file. Native support in the OS will mean that the awkwardly programmed small file paradigm can be replaced and implemented in a much more efficient manner. urlLink I/O Device Model The main goal of this change is to remove the dependency of IO operations on a process or kernel thread.
Removing this dependency will allow for concurrent access. They plan to do this by integrating the IO activity with the VM Object (caching) infrastructure. In addition to allowing the TCP stack to be read by individual CPU's, the long term goal of this change is to move all device activity into the user space. I imagine that there will be tight controls on exactly which processes can access a device. One of the immediate advantages to this innovation is the extension and modification of device drivers, as well as entire file systems to be developed without root privilege and without tying vfs crashses to kernel crashes.
urlLink The Port/Messaging Model A really cool model that allows a message to be responded to synchronously, without the overhead of implicit queuing if the thread in charge of that port is not busy. Currently in Linux, messages sent to network ports are always queued and the sender must always block until the response is available.
All of this produces overhead which the designers of DragonFlyBSD found unnecessary. urlLink Packages and a Solution to Dependency Hell Anyone whose ever installed software on a Windows machine is familiar with DLL hell. This is the problems that arise when installed applications overwrite the shared libraries or remove them when the application is un-installed. The later problem has been resolved in Windows versions later than 9X. As OSS development cycles increases, this problem is presenting itself in the context of Linux and package management systems like RPM and Debian's Deb. The problem is upgrading or installing a recently developed library can cause a cascading series of upgrades to dependent libraries. This can often break the applications that depended on the older versions of those upgraded. The DragonFlyBSD team proposes a system that allows for piecemeal upgrades by allowing libraries and binaries to be versioned.
Under this model, upgrading libxine to a development version for the purposes of installing totem , would keep mplayer from losing access to the stable version of libxine . urlLink Light Weight Kernel Threading Model Similar to other LWKT models, solves problems that uniqsue to multi-processor systems. Thread scheduling is done on a per-cpu basis. This pretty much restricts threads of the same group to running on the same CPU. To me, this would be a little restrictive for 8 and 16 ways systems, but how many of those are there left anyway.
Added are capabilities to allow CPUs to be synchronized for the purposes of modifying page table entries shared by 2 or more processes on 2 or more CPUs. Also added are some really neat serializing tokens that permit a group of threads holding a token to ensure that no other thread in the group is running at the same time.
It also ensures that no thread will be pre-empted by any other running at the same time. This is analogous to a large monitor or critical section encompassing the entire scope of the thread. urlLink Portable User API This is by far one of the cooler features proposed in DragonFlyBSD. A problem *nix software developers face is the ever changing interfaces to kernel level data structures like those associated with ioctls and vmstat . These change from one kernel version to the next and tie specific software version to specific kernel version.
If the interface to the userland programs were independent of the underlying kernel implementation, not only can the interface be standardized for all future versions, but other kernels such as Linux and FreeBSD can be emulated in DragonFlyBSD. Different interfaces can be presented to each library depending on it's kernel dependency and all calls can be translated to the message passing standard implemented by any given DFBSD kernel. urlLink VFS/Filesystem Device Operations In short the VFS system would be changed to a multi-threaded message passing system rather than a large reentrant system. This is the major change necessary to take VFS implementations out of the kernel and into user space. This brings FS development to the level of skill and modification achievable by most developers. It will ease development by keeping VFS crashes from hanging the entire system and will allow individual FS components to stack on top of each other to they way they should be. Those are the major planned innovations in a nutshell. Others, like those at OSnews are urlLink thinking about new operating system / urlLink hardware and what could be done from scratch. Their approach is more of a Frankenstein BeOS with Linux running along side, that sounds more hacked than feasible solution. Maybe this is the biggest advantage DFBSD's message passing kernel and virtual system API has. Compiling Linux or Darwin or FreeBSD code on DFBSD with no portage or modifications... 
