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."
I think he's just making a sarcastic comment on the presence of BSD code in Windows.
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?
It really pisses me off that FreeBSD does not let you (by default) /usr/ports
/etc/make.conf:
s r/local/bin/cvsupf ile- supfi le
cd
make update
Put this in
SUPHOST=cvsup.freebsd.org
SUP_UPDATE=yes
SUP=/u
SUPFLAGS=-g -L2
SUPFILE=/usr/share/examples/cvsup/stable-sup
PORTSSUPFILE=/usr/share/examples/cvsup/ports
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
The copyright notice is STILL required. Only the advertising requirement was dropped. Which means they no long have to loudly announce the fact that they used the code, but that they are still forbidden from hiding that fact.
A Government Is a Body of People, Usually Notably Ungoverned
free clue
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.
You need to rsync quite often and I noticed several broken ports.
FreeBSD ports are simple tcsh scripts that are well tested and integrated since the whole FreeBSD team tests them out. The ports themselves are more stable and under FreeBSD I can chose specific mirrors to specific packages. Try that with portage?
http://saveie6.com/
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.
Here you go, but I'm working on some stuff too.
-uso.
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
Uhhh... etc-update manages those updates very nicely, and you can interactively merge the old and new files with relative ease.
Yes, frameworks do something similar. But the design requires toolchains, runtime linking, and the libraries themselves to understand frameworks. So do you modify the applications and libraries to understand a new way of working, or modify the system so that the new way looks (to userspace code) just like the old way? Apple can take the former, arguably better route, because they control the system and can force everybody to play along. Linux on the other hand has this huge installed base that isn't going to budge until the new way becomes the common way. I have in the past done things like modify an application (and all of the libraries it depends on) to be relocatable and take a runtime prefix from an environment variable -- but that gets painful very quickly, and maintaining it is almost out of the question.
Frameworks have the concept of a globally "current" library version, which takes precedence all the time. In the DragonFly approach (or at least in my similar dream design :-) all installed versions of a library have equal standing. The "current" version in my case is whatever version you want to be current at the moment, in the context of that specific running process.
Frameworks also seem to have a requirement for forward compatibility in minor versions of libraries. If you link your application against version 1.3.x of a library, and you install 1.4.x on the system, the next time you run the application it will get linked against 1.4.x, unconditionally. At least that's what Apple's docs seem to say. This puts the burden on software authors to maintain this sort of compatibility guarantee. Frankly I don't trust Linux library authors that much, especially since they don't have anyone forcing it on them. I want a chance to test some older applications against 1.4.x, and I want the option of having those applications stay with 1.3.x if there turns out to be problems, even while 1.4.x is installed for other, newer applications and libraries to use.
There are a few reasons why this isn't done by default. First, portupgrade is not a part of the base system. Second, due to a chronic lack of space, there is not -STABLE ports tree, so automatically updating your ports could result in a broken system. Three, one size never fits all.
Fourth, you need to understand the UNIX philosophy. In a nutshell it is "many small tools that do only one thing, but do them well." cvsup is a small tool that does one thing well. portupgrade is a small tool that does one thing well. Making either of them do the job of the other is not right.
It took me three minutes to write the aforementioned script. Maybe FreeBSD could have saved everyone three minutes by including a similar script as a weekly cron job. But that ignores the fact that different users will want to use different cvsup servers, and that the servers will want people accessing them at different times. Imagine what the various goverment security agencies around the world would think if they saw a massive bandwidth usage spike every Monday at 2300 GMT!
And of course, some people won't want to update everything. Some people won't want to update anything at all (don't fix it if it ain't broken). Then you have those people who can't use cvsup (like I can't at work because of a firewall)
A Government Is a Body of People, Usually Notably Ungoverned