Ctrl+E let's you save a running software session and restart later. Who had the idea? How does it work? Is this feature usable for clustering or virtualization?
MD: This was Kip Macy's idea. He saw that the core dump support was severely lacking in many areas. One thing led to another and we realized that we could walk the memory map, save modified anonymous memory, and record the inode numbers for open files, and thus actually save enough information to make simple programs checkpoint-able.
The checkpointing feature serves several purposes. It is in fact good enough to checkpoint simple programs (where the only open descriptors are associated with files, not counting stdin, stdout, and stderr). It can be used for debugging -- by checkpointing a program and then restoring it in a gdb environment. And we are using some of the checkpointing infrastructure APIs elsewhere in the kernel just to clean things up. Finally, by maintaining this relatively simple module we have a basis in place for the implementation of process migration in a future clustered environment.
It should be noted that DragonFly does not cluster (at the kernel level) yet. We are a few years away from achieving that goal. But it is our goal.
HP: We have plans to checkpoint network connections and the whole system, in the future. It was being discussed between Kip Macy and me.
The installation tool runs from a LiveCD. Are you considering creating a LiveCD with a complete system like FreeSBIE or KNOPPIX to promote DragonFly?
MD: I think at most we might pre-install an X environment. The problem with creating a "complete" system is that half the packages become obsolete the day after the release is burned. 99% of the people who would use such a release are also operating in a networked environment with Internet access, so my feeling is that whatever packaging system we come up should integrate network access and provide an incremental binary update facility.
JS: I'm planning to do that, yes. I was thinking about adding the important bits to the build-infrastructure, but it was decided to wait until our package system is ready. One important feature before this would happen is adding transparent decompression support either via a special userland lib or directly in the kernel. That's why KNOPPIX can support such an amount of software and what is currently lacking in DragonFly.
Do you plan to release binary updates?
JS: Later, yes. Having a binary package system and having a binary update system complements itself. Both are very useful for mass deployment and are a major part of any enterprise system.
HP: Yes, there are plans to release binary updates for security and upgrade. Quite a coincidence, because I, Joerg, and David Rhodus were discussing this just a few days ago. A lot of people just want to update their system and be done with, i.e., they don't care about source distribution but only in the quality of the update process (i.e., a smooth one).
Compiling ports and packages, world builds, take a very long time, they do not provide a marketable advantage. Most people do not have anything to do with the source code, so giving them the ability to update their packages using a binary system is a must; just think how long it takes to compile OpenOffice or any desktop system.
It is about time that someone in the BSD camp revolutionized system updates. One of goals focused on by the DragonFly Team is to implement (or at least organize) an update system that can be managed by just using PGP-signed binary updates; i.e., most of the base system packages do not require recompiling because they are seldom changed. The only part which the user would need to recompile is the kernel. Of course a few utilities which depends on kernel structures would be tagged specially for rebuild but the rest can just be updated using a binary update system.
Of course, nothing is set in stone, yet, but this sort of Binary Update system would become most helpful when DragonFly reaches its stability period (in a year and a half, I predict), in which ABI incompatible changes will be done once in a blue moon. The core project members (including David Rhodus) are discussing the issue.
DragonFly BSD is a young project and I'm sure you'll be happy to find new developers. What type of contributors are you looking for? Which area would you like to add manpower to?
MD: We are looking for a broad spectrum of developers and users/testers. Primarily we are looking for people who already have a good idea what they want to do rather then people looking for something to do, e.g., people who say, "I'd like to build an advanced checkpoint interface," versus people who say, "I'd like to help out with the project but I don't know where to start." Everyone is welcome, though.
JS: The userland development is currently pretty stalled. We could need additional manpower to cleanup the source tree, merge changes from the other BSDs, and start writing our threading library.
For the kernel, there is also a lot to do. One advantage of a small team is the reduced chance of conflicts :) If you want to contribute, send us a small note or come to our IRC channel, we don't want to waste your and our time by duplicating work.
HP: Sure, more people to help out is not a bad thing, but right now we need people who have some sort of a focus on what part to play in the big picture. Of course, we could use people who want to write documentation for DragonFly, pretty much like the FreeBSD Handbook or the NetBSD Guide. That does not mean we will be ignoring the "I need guidance" types; I for one do not mind educating more people about the DragonFly kernel or documentation framework or anywhere we could use help.
To summarize, most of the outstanding tasks require the developers to have some sort of expertise in the area or ability to pick up things quickly. That applies to the documentation as well.
Since the time I gave DragonFly a documentation framework, Justin Sherrill has done a lot of work on it like importing the FreeBSD Handbook and modifying it for us; but in order to add more DragonFly specific content, one would need to know it properly in order to produce precise and resourceful documentation; of course the Team members will try their best to help the volunteers.
Are you going to use a drastic solution to fight the new XFree license? For example, using only freedesktop XOrg?
MD: We consider X to be a third-party program, so it has no direct effect on the distribution. My personal feeling is that we would take a wait-and-see attitude to see what comes out of the XFree flap.
JS: We have an overwrite port for X.org floating around, but this doesn't affect us that much. I have read a lot of the license agreements in XFree86; the change is not that big, as long as you don't want to sell CDs like OpenBSD. Even then, you might have to do it anyway.
Do you have any idea to replace sendmail with something more modern?
MD: I'd like to integrate a second MTA into the base system and perhaps even default to it. Postfix maybe. Sendmail is fairly difficult to maintain.
JS: It's a question of time. Personally I strongly prefer Postfix over Sendmail, but I have neither the time nor the need to push any change.
HP: That might happen. See, once a package system is developed, we plan to compartmentalize the various parts of the base system so that we can provide packages like MTAs in a better way.
Can we expect to see a web server in the base system?
MD: Probably not, or if you do it will be a very simple one. Apache is too often updated to be a good candidate for base-system inclusion.
JS: I wouldn't count on it.
HP: I highly doubt if that will happen; if you see our answers to the Perl question, we are trying to reduce the amount of third-party items in the base system unless they are highly important, like a system compiler.
What is the status of IPv6 support?
MD: It should be working. We had some issues with connect failing but they should be worked out now. The IPv6 code needs to be rewritten from scratch; the original KAME code (I think I have the reference correct) was, and still is, a huge mess.
JS: There wasn't much effort to keep up with KAME development, partly because it's very difficult to merge changes when you only have lots of snapshots and have to sort out the important changes from the noise.
JH: We have the same IPv6 code that's in FreeBSD. I was in Tokyo last week at the Network World/Interop BSD BoF to reach out to the Japanese BSD user community and met with some of the KAME team members who expressed a readiness to cooperate with us in updating our IPv6 code to the latest KAME version, so our users can look forward to even better IPv6 support.
HP: IPv6 works fine, most issues were resolved. As from the development and update point of view, it needs thought and the whole thing is sitting at the very bottom of our list. The KAME work is hard to stay on par with, but some of the KAME developers are very nice and helpful.
What is the plan for IPSEC? Is there any problem with crypto import/export because Matthew lives in the USA?
MD: No, crypto doesn't seem to be a problem in the U.S. any more. IPSEC is being maintained but as with IPv6 it's a huge hack in the system. Currently we are doing no new work in the IPv6 arena but, certainly, any work the other BSDs do with IPv6 will be looked at closely.
HP: It is pretty much sitting in the same boat as IPv6. They are low priority right now because other things in the kernel need to be stabilized and cleaned up.
Are you going to remove Perl from the base system? If so, why?
MD: We are definitely removing build dependencies on Perl, so we don't need Perl to build the system. We haven't decided yet whether we are going to remove Perl from the base. It isn't that we don't like Perl. The real problem is that Perl goes through so many incompatible changes that the version in the base system inevitably winds up becoming obsolete and interfering with newer versions of Perl that people might want to install.
JS: Perl is a big system and still changing a lot in incompatible ways. Just look at the various ports in FreeBSD, which support either Perl 5.6 or 5.8. The same holds true for GCC, but having a compiler is a much integral part. Most dependencies on Perl are already gone. Both buildworld and buildkernel work without Perl. There still some Perl scripts in our source tree that have to be replaced first.
HP: Pretty much what Matt said. It is better to keep dependency on third-party applications down to a bare minimum. There are plans to improve upon our release framework so that we do not need to keep third-party applications such as Perl and Sendmail in the source repository, and they can be just fetched at release/ISO build time.
One can argue why we would keep a dependency on the Internet for a process such as release builds; but since 99% of the people who will do release builds have a decent connection to the Internet, that argument effectively becomes a moot point.
You have just imported GCC 3.4 in the tree and applied propolice patches. Don't you think that propolice should be included in GCC itself?
MD: I do. Propolice isn't useful unless people use it, and the GCC folks do not have anything remotely similar on offer. If they do not like the propolice patches then they should create APIs within the GCC framework to make it easier for the propolice people to hook in the features.
JS: Yes, I hope it will be part of it one day. It is difficult to maintain GCC, every additional patch increases that burden.
Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.
Return to the BSD DevCenter.