Matt Dillon summarized what he's been thinking so far for the system installation process: (Quoted directly from his post)
* Make CDRom #1 a fully live image, allowing the system to boot into a complete environment. Include various additional tools on the CDRom, including X. * Split a normal installation into two stages. Stage 1 is responsible for FDISK and basic partitioning (/, swap, and /usr), and simply copies the CDRom to the hard drive and reboots. Stage 2 is responsible for the more sophisticated aspects of the installation. Both stages will use the same scripts, languages, & utilities and such to do their work since both the CDRom boot and the HD boot will have a full environment to play in. * Choose a set of tools to build the installation GUI. Desired features are to be able to run the installation from a character terminal, from a graphical environment, from a serial port, from a remote character terminal or graphical environment via the network, or totally automated. What I am currently proposing: * Place Apache, PHP4, lynx, and some sort of browser (if we can get it to fit) on the live CD. * Use Apache and PHP4 as the backend to the installer, lynx as the character terminal frontend, or a browser as the graphical frontend. The installation code would be written primarily in PHP4. * The PHP4 code could make use of a simple database and the existing RCNG scripts to hold onto persistent data and execute its various functions.
(end quote)
The daily snapshots mentioned earlier at http://chlamydia.fs.ei.tum.de/ were garbled if you downloaded them via the web before today. (FTP downloads worked dandy.) It's now fixed. Robert Garret is working on a new system installation method. The consensus so far seems to be that the installation CD should be a "live CD", meaning that it boots and runs a full system, whether or not it can see the installation system's hard drive. He's also decoupling the start of installation - booting, partitioning, base system, etc. - from the third-party software installation, which will be nice for anyone who's endured complete reinstallations because something in the XFree86 setup process got all mangled. My personal record is 4 reinstalls.
leaf.dragonflybsd.org is now available for developers via SSH. Also, a number of folks have reported success running DragonFly BSD under VMWare, Bochs, and qemu (with modifications). Following is a list of the shell access requirements from Matt Dillon. (more…)
Simon 'corecode' Schubert has a machine set up to build snapshots on a daily basis, at: http://chlamydia.fs.ei.tum.de/ ( pub/DragonFlyBSD/snapshots/i386/ is where you'll want to go, probably.) What a euphonious name... New builds will probably finish around 11 AM (GMT+2), which is 4 AM for me in New York, and 1 AM if you are on the Left Coast of the US.
There's a new documentation newsgroup/mailing list (each posts to the other) for documentation. Check the Forums page for information on all the lists. Hiten Pandya appears to be the instigator. Matt Dillon's work diary is updated, too.
Apparently all the old-style prototypes using __P are now gone. Robert Garret is the one to thank for removing the thousands of entries. Matt Dillon has brought in his slab allocator. This handles memory allocation, and is almost nearly multiprocessor-safe, meaning no fancy locking will (eventually) be required for memory allocation. I may be wrong, but this sounds like a partial fix to the issue of the "Giant Lock" from FreeBSD 4. Matt Dillon's description follows... (more…)
The inital installation process for DragonFly BSD was to install FreeBSD 4.8, import the DragonFly BSD code from CVS, and then build over that system. Relatively time-consuming, especially when hitting the mergemaster step. Now, thanks to the efforts of David Rhodus, you can nab the first installation image. http://dbsd.catpa.com/drhodus/dbsd.iso It's just over 150M.
I've always thought that one of the problems for the various BSD programs is that there's a lot of good information that can only be found by digging through the various mailing lists. Nobody in their right mind wants to have to sort through the last 3 months of questions@freebsd.org just for a 5-second answer. So, blog software used to provide a 'newsfeed' may be useful. I'm not a clever enough programmer to contribute code to DragonFly BSD, but I do read the main newsgroups for it. The DragonFly BSD project is small enough that a rolling readout of events may work. So, I've got this blog here to do just that. You too can watch me fumble technical terms! My first goal is to read up and post. This layout just doesn't work without an article history, or at least more long-winded articles.