Slashdot Mirror
DragonFly BSD Announced
JoshRendlesham writes "Matt Dillon announced today on the freebsd-hackers mailing list the creation of the DragonFly BSD project. It seeks to build on the work of FreeBSD 4.x, including a rewrite of the packaging and distribution system, among other goals."
Oh well, it's probably about hurt egos again. :(
In a way it is. Matt Dillon got lost commit access to cvs a while ago because he was trying to get some stuff into 4.8 and got rebuffed. Looked like he violated their code of conduct a few too many times, got kicked out, and started a project where he made the rules. TdR in the house?
I gotta chime in here: /usr/ports
/usr/ports/net/cvsup-without-gui /usr/ports/sysutils/portupgrade
/usr/local/etc/cvsup/sup /usr/share/examples/cvsup/refuse /usr/local/etc/cvsup/sup
... tweak /etc/make.conf ...
... create /usr/local/etc/cvsup/sup/supfile ...
... then update your src and ports ... /usr/local/bin/cvsup -g -L 2 /usr/local/etc/cvsup/sup/supfile /usr/local/bin/portupgrade -ra
/etc/make.conf a little first... But those are minor things, and in the case of cvsup, there are loads of good examples provided in /usr/share/examples/cvsup.
It really pisses me off that FreeBSD does not let you (by default)
cd
make update
I dunno, I think cvsup and portupgrade do the deed quite nicely.
# cd
# make install && make clean
# cd
# make install && make clean
# mkdir -p
# cp
CFLAGS= -O -pipe
COPTFLAGS= -O -pipe
NOPROFILE= true
USA_RESIDENT= YES (if you are)
*default host=cvsup2.freebsd.org
*default base=/usr/local/etc/cvsup
*default release=cvs tag=RELENG_5_1 (or your version)
*default delete use-rel-suffix
*default compress
src-all
ports-all tag=.
doc-all tag=.
#
#
Granted, you have to build a supfile, and tweak your
Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.
It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.
What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.
To which I say: HALLELUJAH BROTHER!
This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.
In any case, this is not just a userspace change. This involves the kernel itself.
Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.
To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.
Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.