DragonFly BSD Digest

Pedro Giffuni noted that there is an effort in NetBSD to protect the stack that may be useful for DragonFly BSD; several others noted that the x86 platform, where DragonFly is currently focused, does not explicitly support this behavior, so it is more hassle than use at this time.

You may say to yourself, “Gosh, I hope the recent SSH and Sendmail holes are fixed in DragonFly BSD, too!” And you’d be right.

Miguel Mendez brought up the idea of using NetBSD’s Veriexec for more secure prebinding (which will also be committed, but not used by default); David Rhodus reports he has Veriexec working and will commit it soon.

David P. Reese, Jr. has separated out the sendto/sendmesg/recvfrom/recvmsg calls and created kernel versions. 4.3BSD syscalls have been separated out, too, to src/sys/emulation/43bsd. (Patch pending)

Matt Dillon pointed out that GEOM in FreeBSD may be something DragonFly can present a compatible API for, but it requires the messaging work for VFS and DEV first. Incidentally, Matt will be working on namecache, VOP_LOOKUP, Simon ‘corecode’ Schubert’s prebinding, and Jeffrey Hsu’s changes to ifq.

If, like me, you are clueless on what prebinding and ifq are, here an explanation of prebinding for OS X (should apply here) and ifq… appears to be the queue in which chunks of network information are held/passed? I haven’t found a good explanation. (Comments welcome, if you know)

asmodai pointed out xenofarm during a discussion of the tinderbox builds of DragonFly.

Kip Macy noted that he is working on a checkpoint/restart project, where an application can be ‘saved’ in a running state and later restored. This can be useful with programs that have a long runtime, or when debugging.

Diego Calleja brought up this paper in reference to discussion of a devfs-style /dev system.

Simon ‘corecode’ Schubert linked to a patch he made to allow prebinding.

(added later)
Matt Dillon pointed out http://apollo.backplane.com/BSDCON2003/ now has pictures from the FreeBSD DevSummit.

Not too much visibly occurring on the mailing lists, but a few people have posted links to pictures they took at the recent BSDCon.

http://apollo.backplane.com/BSDCON2003/
http://machdep.com/drhodus/bsdcon03/

(Second link now fixed)

‘dports’ is now ‘dfports’, because of a name conflict with Darwinports. It’s cvs-dfports in CVS now.

Matt Dillon has created dports, a DragonFly-local override of /usr/ports from FreeBSD. This way, DragonFly can continue to use the FreeBSD ports system and changes/overrides can be placed in /usr/dports to handle changes. This is not permanent; it’s supposed to last until a new package system is devised, which should be after things like the VFS work is done.

Complete text of his post follows, as there’s some notes on how to check this out of cvs:
Continue reading “dports created”

I’ll try to run through all the events that came through in the past few days.

– David Rhodus reports over 1000 iso downloads on dbsd.catpa.com, while Simon ‘corecode’ Schubert reports (since logging started) 129 unique downloads.

– David P. Reese Jr. has set up various split syscalls and set the linuxulator to use them.

– Matt Dillon pointed out the right name for this new OS is ‘DragonFly’, with the F capitalized. He also suggested starting a new ports (/usr/dports) system that would work as an ‘override’ to the carried-over FreeBSD ports system.

– There was some discussion of slogans for DragonFly, of which my favorite was David Leimbach’s “DragonFlyBSD: We’ve raised our standards… so up yours!”

– Robert Garrett brought rsync into the base system. Also, David Rhodus set up a cvsync server that carries both FreeBSD and DragonFly. (his config continued below.)
Continue reading “Catch-up”

Matt Dillon posted a longer explanation of his namecache work; I’m quoting it here because I’m not knowledgeable enough to summarize.

Quoted text follows:
Continue reading “namecache work description”

From the discussions going on, it looks like the installation interface will be http based, using Apache, PHP, probably Python, and a text (links or elinks)/graphical browser depending on install environment.

A new topic coming up is: should cvsup be included, or something like it?

Matt Dillon is starting work on cache_lookup(), for at least the next week or so. When implemented, it should lead to some very interesting changes in the filesystem. This may be backportable to FreeBSD, too. Quoted text follows:
Continue reading “namecache work”

DragonFly BSD must be a legitimate operating system now. Tobias Florek has come up with a way to purchase a plush Fred mascot. No sales info yet…

Pictures here: http://ibotty.net/fred

Joerg Sonnenberger posted a long writeup of possible directions for a packaging system. I’m repasting it verbatim, as there’s no need to sum up yet.
Continue reading “Package system”

No major events, but a few small items over the weekend and U.S. holiday:

– Hiten Pandya suggested creating downloadable patchsets for unstable items like ACPI that come from other operating systems, so that people can try them without placing unstable code into the default Dragonfly setup.

– Lots and lots of talk about sysinstall; nothing was really resolved other than that language preferences polarize discussion. Matt Dillon pointed out he was more interested in figuring out RCNG integration, in any case.

– If you, like me, aren’t familiar with RCNG, Jeremy Messenger posted these links (all about the NetBSD version, but that’s close) for more info:

http://www.netbsd.org/Documentation/rc/
http://www.cs.rmit.edu.au/~lukem/papers/rc.d.pdf
http://www.daemonnews.org/200108/rcdsystem.html
(Google cache if Daemonnews is unavailable.)

– Serial console support doesn’t seem to be working, though the settings should be the same as with FreeBSD-stable.

– I “announced” this web page, and nobody said anything bad. Yay!

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.