Interjú Matthew Dillionnal a DragonFly BSD alapítójával

 ( trey | 2003. október 10., péntek - 12:32 )

Matthew Dillon (korábbi cikk) a korábbi FreeBSD-s kernelhacker, sokat tett a FreeBSD fejlődéséért. A Linux korai szakaszában fejlesztett a Linux kernelhez is. A FreeBSD-ben javította a VM (virtual memory) hibákat, dolgozott a TCP/IP stack-en, majd elismert NFS fejlesztő lett.

Aztán ez év július közepén úgy döntött, hogy hosszú idő után megválik a FreeBSD-től és saját BSD projektet indít. Az új projekt neve DragonFly BSD lett. A FreeBSD-vel való szakítás körülményeiről a FreeBSD core fejlesztő kifakadása cikkben olvashatsz.



Tegnap a Slashnet (a Slashdot IRC és egyéb hálózata) készített IRC-s interjút a neves fejlesztővel. Lássuk (értelemszerűen a szürke a kérdés, és a fehér Matt Dillon válasza) ->


Ok, time to start! 21:00

We would like to thank Matt Dillon from the DragonFly BSD Project for joining us tonight.

and thank all the users for coming here as well! 21:01

Matt like to introduce yourself and tell us about your past history with BSD? 21:02
Hello everyone!

A quick one liner history... I first got involved with BSD in 1985, while attending UCBerkeley.

Make that a four liner history :-)

Around the same time I also got involved with the Amiga. A few years later, when BSD stalled, I got involved with Linux 21:03

But after getting involved with BEST Internet, an ISP in the 1994-1997 timeframe, I went back to FreeBSD which by that time had gained a good reputation

For several years I reported bugs and pushed out patch sets related to issues we found at BEST 21:04

Sometime around 1997 or 1998 they gave me a commit bit, and that is when I really started working the

bugs out of the VM system. 21:05

Ok. I'll stop hitting return at the end of 80 columns :-)
mattt, would you care to explain what exactly DragonFly BSD is?
Sure.

DragonFly is a fork off of the FreeBSD-4 branch. FreeBSD-4 is currently the stable branch while FreeBSD-5 has all the new SMP development work and other things. 21:06

Basically FreeBSD-5 began to diverge rather severely from my own vision, and it came to a head a few months ago at which point they decided to pull my commit bit. But the timing could not be better for a fork. 21:07

I spent a number of months destressing, and then began working on DragonFly. In order to be sure that DragonFly was, in fact, a realizable project, I decided I had to implement at least one major subsystem 'goal' before announcing it. This initial subsystem was the LWKT (Light weight kernel threading) subsystem. 21:08

And that is the story of how DragonFly began. I spent a considerable amount of time working out the goal set, which is listed on the sight. 21:09
drdink asks: Is DragonFly BSD your primary job, or do you work somewhere doing something different? Do you get paid or donations for your DFBSD work?
Many of the goals are rather incompatible with the direction FreeBSD-5 is going, LWKT being the most obvious one and the messaging we intend to do coming in a close second.

DragonFly is my primary job. My financial needs are met through savings, what I got out of BEST Internet, and some long standing relationships I have had with a small engineering company based in Tahoe (that I've worked for since high school). 21:10

The Tahoe firm primarily did Telemetry systems for public utility districts. 21:11
Jeffr asks: Is DragonFlyBSD Intended to be an academic exercise, or is it intended to be a full-scale prduction worthy operating system? If it is not academic, what are you doing to attract enough talented developers to maintain and improve upon a whole system? Are you picking up bugfixes and features from the FreeBSD 4.x branch that you forked off of? 21:12
DragonFly is intended to be a full-scale production operating system. We so far have not had any problems attracting talent, I have a nice small managable group at the moment, which I fully expect to grow as the features we implement seep their way into truely interesting userland accessible abstractions 21:13

We are bringing in bug fixes and certain features from both 4.x and 5.x.

The intention, however, is not to try to duplicate 5.x, and the larger fully integrated subsystems in 5.x are being left till later. 21:14
grithan asks: Since DragonFlyBSD seems to be a long term fork off of FreeBSD has it ever worried you and the team working on the project that it would be difficult to stay sync'd up with desirable changes to libc, userspace, etc that occur in other *BSDs with such a small group of contributers focusing on experimenting with new ideas? 21:15
One can break down synchronization issues into three major categories: The base system, Contributed code in the base system, and ports. 21:16

The base system and contributed code in the base system are very easy to synchronize when synchronization is appropriate. In fact, ports are fairly easy to synchronize too. The difficult areas are primarily in the kernel itself. 21:17

So, for example, implementing GEOM or equivalent functionality in DragonFly is not going to be a walk in the park, but upgrading the compiler suite from 2.98.x to 3.x will be a one-day or less job when we decide it is a good tiem to do it. 21:18

oops, make that four major areas (the kernel being the fourth)
grithan asks: If your ideas prove out to work well how hard do you think it would be to reconsile the differences between DragonFly and its parent, FreeBSD, after a year or so of development in different directions? Do you expect or hope such a 'healing' of the fork would ever occur? 21:19
I think that is going to be up to the FreeBSD folks. So far the features we have implemented in DragonFly appear to be fairly optimal in regards to performance and flexibility. Many of these features could be ported to FreeBSD-5 if the FreeBSD folks wanted to port them. We are not going to be backporting features from FreeBSD-5 which we have already implemented a different way in DragonFly (e.g. FreeBSD threads/mutexes verses DragonFly light w 21:21

eight kernel threads and cpu messaging), but

we will certainly backport interesting functionality that appears in FreeBSD-5 that we think would be useful in DragonFly.
yogsoth asks: Do you expect any resistance from the FreeBSD camp to what you're doing or have you so far met with relative success in your endeavoour? 21:22
I believe that FreeBSD could benefit from the IPI messaging work we have already done as well as the LWKT work and the per-cpu methodologies we have chosen to use.

Well, FreeBSD and DragonFly, like Linux, are open source projects. Code sharing is based on desire and interest, so the only 'resistance' one would encounter per-say is that, say, FreeBSD might decide not to port something from DragonFly that obviously should be ported. 21:24

But, as you can see, that is up to them... it doesn't really effect our Project. In open-source the

best idea usually wins.
Jeffr asks: DragonFly BSD has chosen single threading subsystems as its mechanism for protecting the kernel from concurrent access in SMP systems. This will lead to heavy contention and serialization of workloads that heavily use a single subsystem (networking, filesystems, etc.). How do you intend to address this? If the answer is finer locking in those subsystems, won't you essentially end up with the same mechanisms as FreeBSD 5.0 which you are trying
I'll give you an example with networking. Consider the type of contention one has processing packets. In DragonFly the solution is to run multiple TCP stack 'threads' in the kernel, but the threads will not compete for work. Instead new connections will be divyied up and any given connection will be processed by only one thread., In this situation there is no contention at all you you are able to utilize multiple cpu's processing TCP packets. 21:26

Some subsystems are more difficult to split up that way... for example, heavily shared system structures such as the route table. There are plenty of solutions, though, such as IBM's RCU mechanism, to handle these shared entities. 21:27

next question 21:28
yogsoth asks: Matt, could you explain a bit more about how your threading model might differ from, say, NetBSD scheduler activations? Is it an N:M style in the same vein?
(if I don't answer a question completely enough please feel free to ask for more clarity)

I am not familiar with NetBSD's scheduler activations but I can certainly describe our intentions for DragonFly's user threading model. Basically it *is* an N:M style. From userland's point of view a 'virtual cpu' can be created using rfork. Each virtual cpu can contain any number of threads. DragonFly will utilize its asynchronous system call messaging capability to manage the threads running in each virtual cpu. 21:30

Now rfork isn't precisely the right abstraction, but it is close enough for this Q&A. We have not implemented either of these yet but it's on the list and some preliminary work has already been done. 21:31

next question.
Jeffr asks: Would some detail on your recent namei() changes?
Sure. The BSD name cache topology is based around the vnode structure. Given a vnode structure you can get at the namecache records that are parents to the vnode and you can get at the namecache records that represent the vnode. The problem with this topology is that it is not possible to keep track of the path used to get to a target. For example, 21:33

if you have a nullfs mount or a union mount thes VFS's must perform some fairly serious vnode aliasing in order to retain ".." information. What I am doing in DragonFly is changing the topology to be namecache structure centric instead of vnode centric. This way the path used to get to a target can be retained without playing any vnode tricks. 21:34

So the namecache structure in DragonFly will have a single parent pointer and a list of children, and a single pointer to its representitive vnode. Directory scans will be based on namecache rather then vnode directory pointers.

next question.
mbacarella asks: When I read about DragonFlyBSD's messaging plans, I'm immediately reminded of microkernels in the spirit of Mach, which sounded great on paper and allured Microsoft, Apple, and even the FSF (GNU Hurd), but ultimately lead to a lot of complexity and confusion. How is DragonFlyBSD's approach different? 21:35
Oh, and any given vnode may be associated with multiple namecache records.

DragonFly's messages are far less complex then Mach's. DragonFly's messages are more like the Amiga's in that they provide an abstraction that allows both the message source and message target to independantly determine whether they wish to run the message synchronously or asynchronously. 21:36

DragonFly messages also provide an immediate in-context synchronization abstraction that is hidden from the client, which is important for performance reasons since many messages can be resolved out of system caches. 21:37

What DragonFly does not attempt to do is abstract memory through its messages, which I think is where a lot of the confusion comes into play in Mach land.

next question. 21:38
NorthWay asks: have you done any statistics on what performance wins async will give you?
I am presuming 'async messages' here. I'm not sure one actually gets a performance win so much as one gets an abstraction that allows one to code-up complex systems more easily, by breaking their functionality down into independant entities. From a peformance standpoint you have to consider two forms of the message. DragonFly messages are actually semi-synchronous, which means that the source dispatching the message basically calls a function 21:40

stored in the target port. This function can decide to handle the message in context and return immediately, without even bothering to queue the message (extremely high performance, about the same as you would get with a direct procedure call), but if the message is too complex or cannot be handled instantly or easily the dispatch function can choose to queue. The idea is for the critical path to be met 'most of the time' by immediate returns

next question. 21:41
mbacarella asks: Any plans to replace ioctl()s with something less cumbersome?
Ioctl's have to be retained for compatibility with the vast majority of third party packages that exist out in the world. There are other mechanisms available, such as dynamic sysctls (remember, sysctls are actually hierarchical even though most people don't use them that way). I'm sure there are plenty of better ways but for now we have no plans to rip out ioctls. 21:42

next question.

I'm just too fast for weebl :-) 21:43
nobody481 asks: This may be way off base, but are there any plans in DragonFly BSD to make wi(4) work with tcpdump/ethereal/etc in *rfmon* mode? I haven't found anything on the webpage, but was still curious.
Well, that's a fairly driver-specific question. We do not really have the resources to do a huge amount of low level driver work and, at the same time, achieve all the goals we have already set out for ourselves. So the answer is basically no. But we do intend to synchronize driver updates, though perhaps not at light speed. 21:44

next question. 21:45
yodli asks: Are any C compilers close to being able to compete with gcc in a project like Dragonfly? Would the project consider another compiler?
DragonFly, like FreeBSD and Linux, relies heavily on GCC's __inline and __asm operators, as well as section directives to organize the boot and module init and uninit sequencing. Other compilers would have to support these contructs to be useable, at least in regards to compiling the DragonFly kernel. Userland is a different story... the compiler just has to be ABI compatible and produce ELF output. 21:46

next question.
ahze asks: what do you plan to do with packages? Use FreeBSD's ports? Go with something totally new? 21:47
This is something we've been batting around for a while. My desire is to implement a userland VFS capability that allows us to record compile time, install time, and run-time dependancies, and to verify (guarentee) that a port or package uses exactly those dependancies. We also need a system whereby multiple versions of any library or application can reside in the system in a manner that is guarenteed not to conflict with other versions. Such 21:49

systems exist, but we are really going for a moonshot here... I want something that can actually *guarentee* that everything is properly installed. This may involve a combination of Variant Symlinks and userland VFS 'environments', or other similar mechanisms.

Ultimately I want to have a ports/package system that requires minimal work by the developer to install, upgrade, and manage. We do not have a solution set in stone yet but that is the goal. 21:50

next question.
NorthWay asks: do you have any intentions to change the dynamic library naming and versioning system? That Simply Worked on the Amiga. installing linux sw is endless library conflict messages
What I would like to be able to do is build a ports/packaging system that, from its point of view, just compiles up the native third-party program and installs it in its native location, but have the install actually be redirected by the VFS environment into canned, versioned directories, which are specifically referenced by the package configuration for other ports but which (this is a long sentence), from the point of view of other ports, appea 21:53

rs to be where *they* expect it to be.

next question.
npmccallum asks: What do you really want to keep from FreeBSD (what have they done well that doesn't need to be reinvented)?
The VM system :-)

No, really... the VM system! 21:54

I think we have to look at subsystems on a case-by-case basis. We will adopt FreeBSDisms that have been put into 5.x where it makes sense to do so.

next question. 21:55
Floid asks: Somehow, I've managed to get and stay confused about the future of softupdates in DragonFly. Is there any plan to ditch them on philosophical grounds, and if not, where do they live in relation to things being touched by the Big Dig?
I do not plan on throwing away soft-updates but it is up in the air whether we will be able to backport things like snapshots into Dragonfly, because softupdates is *heavily* integrated into FreeBSD-5. What I would like to do is two things: First, I want a userland VFS capability to make the development and porting of filesystems far easier then it is now. Second, I want to port XFS from Linux. Third, I want to develop my own filesystem. I pe 21:57

rsonally believe that a log or log-hybrid filesystem is a better solution than softupdates simply because it is far easier to debug. Softupdates is powerful but finding and fixing bugs in softupdates is difficult.

next question. 21:58
yogsoth asks: I'm curious to know more about where FreeBSD-5 diverged from your idea of where it should've gone. I realize this might be a touchy subject, but might as well make it interesting, eh? So, could you elaborate a bit more?
Sure. I think it's a fine technical question, actually. I have major disagreements over FreeBSD-5's threading and mutex model. The threading model is complex... kernel thread preemption means that a thread can be moved to another cpu at any time, making it impossible to gain a stable pointer to the per-cpu structure without entering into a critical section and, even if you do, having to deal with possible cpu movement through any procedure cal 22:01

l that might block. FreeBSD-5 uses fine-grained mutexes to manage thread and process structures which are in the critical path for nearly every kernel syscall you will ever make. FreeBSD-5 uses mutexes to protect the scheduler and *still* integrates the userland priority scheduler with kernel-land threads.

DragonFly does things very differently. DragonFly has a fully independant light weight kernel thread scheduler running on EACH cpu. Threads do not migrate between cpus preemptively, so the per-cpu data structure can be accessed without any mutexes or locks, and the LWKT scheduler can operate without any mutexes or locks (just a critical section to protect from interrupts on that cpu). If a thread needs to manipulate state belonging to another 22:03

cpu (typically another thread, or process), then it sends an asynchronous IPI message to the other cpu.

DragonFly's userland scheduler is protected by the Giant lock at the moment, but the key point is that it is a *different* scheduler from the LWKT scheduler. The userland scheduler holds no sway for any thread that is in kernel space, it only holds sway for threads running in userland. So when a thread enters a syscall the userland schedule is out of it until the thread exits the syscall. 22:04

I could talk a lot more about this topic but that would take hours, if anyone has any questions about specific subsystems please ask away! 22:05

next question.
NorthWay asks: what is the time plan for non-x86 versions?
We need to stabilize the AI32 assembly for both the kernel and userland. The assembly used by the kernel is basically stable now, leaving only the userland threading code. We also have to reorganize the machine independant bits that are still in machine-dependant sections. This is an area where FreeBSD-5 has made great progress and I will certainly be looking at what they have done, but unfortunately these deep sections are already too diverge 22:07

nt to simply backport.

er. IA32, not AI32. I could tell you about AI32 but then I'd have to shoot you :-)

next question.
NorthWay asks: any plane for including a volume manager?
I would like to see the IBM volume manager in DragonFly but it is very low priority right now. The userland messaging abstractions we intend to implement will make it far easier to develop or port volume managers into DragonFly, but there are no specific plans for a volume manager right now. 22:08

next question.
[RaW] asks: What are or will be the main advantages of using DragonFlyBSD over any other type of BSD? 22:09
From a user perspective the new-feature advantages are going to start popping up fairly soon now as some of these abstractions start to effect userland. For example, we will likely have variant symlinks working in the next month or so. For system administrators DragonFly will hopefully provide a stable upgrade path from FreeBSD-4.x if FreeBSD-5 remains too unstable for large deployments. 22:11

I also believe quite strongly that once we start unwinding the giant lock and implement (for example) the network threading model, that we will be abel to demonstrate a major performance improvement over both FreeBSD-4 and FreeBSD-5. DragonFly uses inherently lighter-weight mechanisms and it should be possible to stay ahead of FreeBSD-5 as we come up to our first release in a little less then a year. 22:12

next question.
davo asks: will the proposed userland vfs layer allow separate filesystems to essentially appear as one device?
Theoretically you will be able to do anything. Preliminary work on turning VFS into a message-based system is already complete. The most difficult processing step for a VFS is with name lookups, which I am working on as we speak (with my left hand! :-)). The namecache changes will allow VFS layers to return underlying vnodes directly, without having to allocate a vnode alias, and still retain the path history. So the answer is, yes, you shoul 22:14

d be able to construct VFSs in userland that seemlessly gloms filesystems together without any adverse performance or memory issues.

next question.
mbacarella asks: Any plans for augmenting the POSIX security model with more fine grained access controls, like capabilities?
I think it could very well happen but my current intention vis-a-vie security is to implement it through VFS 'environments'. That is, instead of depending on the N terrabytes of disk space being properly secured through capabilities I would much prefer to run, say, apache or named in a VFS environment with a simple configuration file that says 'you can read this and write that and everything else is off limits'. 22:16

next question.
GeekGodOG asks: What are you feelings on having multiple firewall stacks in FreeBSD? Any plans on integrating PF from the ports system into the base system?
I a not familiar with PF. There has been some discussion on the lists in regards to implementing Cisco's duel-layer routing model, and being able to hang firewall rules off of that model as well as directly off of interfaces (again similar to how cisco rule sets work) would be a very powerful mechanism. 22:17

next question. 22:18
jstone asks: How usable is dragonfly right now? Is it self-hosting yet?
Our CD #1 is still primitive but, yes, it is self hosting. We haven't 'lost' any of the FreeBSD mechanisms so the build system hasn't really changed, at least not yet. Now, you do have to be aware that we are not planning a user release for a while, and the tree has and will occassionally break during development, but we have taken the position that DragonFly should remain stable throughout development and if anything does destabilize we will t 22:20

ake a step back and fix it before moving on.

I still recommend to Dragonfly developers with multiple machines to keep the development tree on a different machine then the one running the results.

But that is standard fare for any development effort. 22:21

next question.
Floid asks: As an armchair usability nut, it's easy for me to see how increased modularity and decreased maintenance headaches should free users and developers to Get Real Work Done. However, not everyone "gets it," to the point of blank stares and "That's not a usability project." Mind taking a stab at why Slashdotters should (or shouldn't) think about DragonFly on the desktop in the next five years?
People migrate to operating systems for a vast array of reasons. I expect that our feature set will be the primary attractor. For example, the variant symlinks that will be going in in the next few weeks. There is also a lot of interest in a kernel-supported checkmark/restore function for general userland programs and some preliminary work on that has already done. My goal is to eventually have an SSI model that works across a network and a c 22:23

luster capability that can arbitrarily migrate processes between hosts (SSI == single system image, which means full cache coherency across a cluster).

It will depend heavily on what we are able to accomplish in the next year. 22:24

next question.
mbacarella asks: Was your vision a result of a desire to make FreeBSD more competitive with Linux, or to head off in an entirely new direction altogether?
Well, I am a very competitive person but my vision is not really based on a desire to be better then another OSS project. Instead it is based on a desire to implement the best algorithms, topologies... the nitty gritty of the system because I consider the infrastructure to be the piece that determines a system's potential for growth into the future. 22:26

All systems have a shelf life, and this shelf life is based both on how well the guts have been implemented and how much effort new developers are willing to put in a system to bring it up to modern standards. To be long-lived, a system most both be implemented properly and implemented flexibly. This is true of any system, Linux, FreeBSD, whatever. Many open source projects die out over time not just because they might become obsolete, but also 22:28

because they wind up being so far afield from what is considered contemporary and modern that new developers are not interested in working on them.

next question.
yogsoth asks: Matt, could you describe your vision for where you see Dragonfly in three years? Five?
Ok, you all know about the seti project, right? Well, I want a system where I can create an internet-wide assocation that allows a portion of the resources under my control to be shared safely, internet wide, with others. I believe that large scale loosely connected clusters are the future of computing and I want DragonFly to fill that need. 22:30

We have short little flashes of what we can achieve now, just within our own home networks. We can do a lot better, and we can make it seemless. 22:31

next question.
mbacarella asks: It appears that some of your criticisms of Linux have effected positive change (for example, reverse page maps). What do you still believe is wrong with Linux, and how do you hope to address these issues in DFBSD?
I haven't looked at the Linux code recently enough to be able to comment on it from a technical perspective. My one critisism is that they appear to be going down the kitchen-sink path, but I think they have realized that themselves and have begun to address those issues. 22:32

next question. 22:33
davo asks: will the dragonflybsd project be committed to rock solid stability; ie, will it be a viable server OS?
Yes. That is the intent as of the first release (in a little less then a year), and the current development philosophy is to keep things solid on a commit by commit basis. At the moment with only 6 committers (and a hundred lurkers) that is very easy to accomplish. Down the line we will almost certainly have to implement a peer-review and testing mechanism. 22:35

next question.
kan asks: do you plan to stick to FreeBSD's stable/current development model?
No. I hope to implement a modular-enough environment that we can stick with a single-path tagged environment. There would still be stable and development releases, based on tags, but I would like to avoid branching the tree. Note that we want to extend the package environment into what is known as the 'base system' in FreeBSDland. I also have plans to address structural issues that have traditionally broken userland utilities between major Fr 22:37

eeBSD releases.

next question.
Jeffr asks: Why do you frown upon the fine grained mutex model of protecting against concurrent access? If it is the cost of a mutex, on UP x86, the cost is less than 16 cycles for an uncontested mutex. It seems to me that this provides for greater parallelization by not having to pick a cpu to bind a unit of work to. 22:38
My problem with using mutexes in areas where they should be unnecessary is that many cached operations take very little time anyway, so even if a mutex takes only 16 cycles uncontested you still wind up making a large number of mutex calls to accomplish an operation that might have otherwise only taken a few cycles anyway. Consider the codepath required to block a kernel thread... in DragonFly the codepath is very, very short. Ultra short, in f 22:41

act, because the low level scheduler needs no mutexes or locks at all so things like the BGL (which DragonFly still has) can be optimized at the scheduler level to the point where most BGL operations can be avoided on SMP boxes. In FreeBSD-5 the codepath is terribly long.

Another example would be the slab allocator. An allocation from cache is ultra short in DragonFly. I think it is less then 100 instructions though I haven't counted it. A 16 cycle mutex slows it down by 16%. 22:42

next question.
GeekGod asks: Do you plan on implementing any functionality that will ultimately help embeded device designers such as firewall appliances besides the Cisco CEF functionality previously discussed?
Well, that's another low level question. I certainly would like to see all sorts of functionality in the DragonFly kernel but the actual implementation depends on interest and time. I hope to make the process as easy as possible in DragonFly, because most of the time lost in any in-kernel development effort is lost due to crashing the kernel :-) 22:44

I will add that I believe there are a large number of programmers out there who can take the first step and get something 'almost working' or 'mostly working'... I want to nurture those efforts even when it means someone with more experience taking over for the last stage of development. 22:45

next question.
mbacarella asks: It seems like many of the BSD forks are caused by political factors and not so much technical ones, which may suggest that simply the structuring of the projects in general is at fault. Will DragonFly mirror the FreeBSD organizational structure or will it become something more like Linux's?
The primary difference between FreeBSD development and Linux (kernel) development is that FreeBSD development is now largely driven by people building things under grant, or for the companies they work for, and not just for personal interest. FreeBSD developers (including myself) tend to be older then a typical Linux developer, and have less time. The result is that FreeBSD developers tend to be more focused on their little corner of the world 22:47

which makes it difficult for multi-disciplinary programmers like myself to work in those environments. Linux's kernel development environment is still primarily multi-discplinary.

There are commercial interests, of course, so I don't consider the Linux development environment to be better or worse then BSD's, only to be a bit earlier on in its time track then BSD's. And now that they see where other development efforts are going perhaps they can avoid some of the mistake that have been made with the more established efforts. 22:48

I am trying to keep DragonFly as commercial-interest-agnostic as possible. It helps that I can dedicate the majority of my personal time on the project.

next question.
yogsoth asks: Any chance you might be convinced to enable another method for us to download the full cvs repository? (rsync for example?) Some of us who don't have native M3 compilers have trouble with cvsup. :-) I know I'd appreciate the ability to track exact changes semi-offline. 22:49
Heh. There are rsync mirrors already but you are right, I should run an rsync server on the main server as well. 22:50

next question.

Boy, I'm glad I ate before I started this!
yogsoth asks: Any suggestions for submitting patches or code to DragonFly? Perhaps a To-Do or help wanted list? If someone has a "great idea" and would prefer to contribute to DragonFly, are you open to changes elsewhere too? :-) 22:51
Anyone is welcome to put themselves on the mailing lists, or peruse them via the newsgroup. I don't have a mailinglist archive up yet. Discussions are always welcome but the work that gets done will primarily be based on submissions. There is a submission list for that purpose. Patch sets relative to the broken out source tree are best. I personally believe that submitting something is far more valuable then simply talking about it, even if 22:53

the submission is ultimately not acted upon, because it shows that the submitter has a real interest in the topic at hand.

We do sorta have a goals list and mostly people pick off areas of interest to them or suggest something new that they would be interested in persuing. 22:55

next question.
Floid asks: Can I force you to 'blue-sky' your answer to my previous some more? You gave yogsoth the universal view, but people can be rather petty when it comes to understanding the relevance of a project; want to reiterate (or define the laundry list) of things a run-of-the-mill admin/user won't have to be worrying about versus existing systems?
Hmm. Taken from the point of view of a 'completed' project (first user release), sysads and users won't have to worry about an installation or upgrade of a third party package breaking something else, or even breaking the older version of the package (which remains installed). This can be especially important when running a turnkey system or on systems with a lot of users... if a user is used to version X then upgrading to version Y might brea 22:59

k him. But you still want to ugprade to version Y for yourself. So, obviously, you want to retain both versions in that case. I think that sort of thing makes sysad work a whole lot easier. (2) Well, there is no (2) really. admins and users don't want the system to crash, so the system should not crash. admins and users want incremental backups (kernel supported even). etc. I'm not sure exactly how to answer your question :-)

Admins and users of clusters want to be able to take up and down hosts, and deal with unexpected failures, without having to restart the cluster. etc.

next question. 23:00
GeekGod asks: What is your opinion of the GPL? Are you trying to avoid using GPL code by rewriting code in question to conform to the BSD license similar to the approach OpenBSD has adopted?
I do not consider the GPL to be better or worse then the BSD license. Certainly the idea of proprietary interests stealing BSD licensed code is silly, since the whole idea of the BSD license is to give the prospective user of the code the ability to use it pretty much however he wants (with no political agenda). Keep in mind that many university and grant projects are designed not only to help open-source, but commercial interests as well, and 23:03

GPLing may not be appropriate in that case. Also remember that most commercial interests do not have the resources to proprietize BSD'd code anyway, so most modifications get fed back anyway. People use different licenses for different reasons. The GPL has certainly been advantagous in the SCO<->IBM spat, but the BSD license has also been advantagous.. it was so open AT&T polluted their own codebase with it, one of the major points in IBM's co

untersuit.

And, finally, remember that the GPL does not generally apply to non-integrated proprietary extensions to systems. That is, most of Linux is GPL'd but any commercial interest can still use the codebase verbatim and simply write a userland application to run on top of it that is still proprietary. 23:04

So, for those reasons, I don't make much of a distinction between the two. I personally prefer to use the BSD license simply because I am more interested in making my code available to all comers and less interested in making a political statement :-) 23:05

next qusetion.
wang asks: Will the SCO court case affect DragonFly BSD project?
Ha. I could go on forever about the SCO court case. The short answer is: The SCO case will not effect anything related to BSD at all because the USL settlement forbids them from interfering with us in any way, and if they try the result will likely be a reopening of that case and the likely result of THAT will be the entire SysV codebase being put into the public domain by court order. 23:06

So SCO is keeping far away from BSD. The bozo CEO made one comment a few months ago, but there has been total silence since them. I think they know they can't touch us. 23:07

But I don't think SCO has much of an effect on Linux either. It is glaringly obvious that SCO will never be able to win on any point related to the Linux codebase.

next question. 23:08
ok, this will be the last question, then we will open up for "free-for-all"
drdink asks: Where did you come up with "Dragonfly" for DragonFly BSD?
I went through a large number of names. For example, 'TurtleBSD'. Ugh. Firefly... Ugh (too short a life span), etc... finally through pure chance I decided on DragonFly, and then one decided to pose for me for a good 10 minutes in my garden which solidified the name. 23:09

whew. allright, that's it for the canned questions!