DragonFly BSD Digest

Matt Dillon posted more ideas on how the DragonFly releases were to go. Specifically, different versions would be coded by slip tags instead of the branches that go on with FreeBSD:

“releaseX_Y: Specific official release, build and regression tested, including security fixes. A sub-sub version (Z) would be embedded in the uname to differentiate between updates to a release, but not be incorporated into the tag name.

release: Current official release.

developer: Developers who want to be cutting edge but still be ‘reasonably’ stable, with occassional glitches.

HEAD: Absolute latest work, might have build and other issues.

Not being branches, slip tags are limited in scope. It might not be possible to incorporate a security fix into a particular release tag, for example, all we would be able to do is tell people to upgrade to a later release. When we are able to stabilize the system interfaces (about a year and a half from now) this won’t be a big deal.”

David Rhodus announced a new BSD-oriented info site – gobsd.com. Most interestingly, it appears that it will host packages that can be added via pkg_add.

His announcement is pasted below:
Continue reading “gobsd.com created”

Matt Dillon has updated the ‘known stable’ ISO on the download page. He mentioned he plans to create a ‘stable’ tag in cvs (not a branch, but a slip tag) so that people who don’t care for experimentation can track that target.

R. E. Ceiver posted his DragonFly install experience. It follows the same form as the regular from-CD install, but a little more verbosely.

Matt Dillon has found the solution to the wierd MMX problem; it’s now safe to try kern.mmxopt=1 again. The problem turned out to be (quoting Matt) “related to the PIPE code, but only when the sysctl’s were set up for legacy algorithms. By default the PIPE code uses SFBUFs which are not effected[sic] by the bug.”

Matt Dillon’s placed a new “known stable” ISO at ftp://ftp.dragonflybsd.org/iso-images/dfly-20040502.iso.gz.
Devon H. O’Dell has mirrored this image in San Jose, California, US, and Amsterdam, Holland. Only one month until June, and 1.0! (Though it probably won’t released this early in June.)

Matt Dillon’s updated his diary page.

If you have an Athlon or Xeon processor, go into usr/src/test/sysperf, do make, and the resulting /tmp/mem1 program will probably give interesting results, which you can then post to the kernel mailing list. A caveat from Matt Dillon:

“Note however that you have to manually edit which copy tests it does since it bus fault if you try to run the XMM (SSE2) test on a machine without SSE2 :-)”

It’s been very quiet, but that’s because people are really, really busy working on DragonFly features. Here’s a roundup:

– Devon H. O’Dell and others are still working on the installer, promtped by Hiten Pandya. The code for this is available via cvsweb, including the very interesting design notes. (It has diagrams, so it must be good.)

– Hiten Pandya and Joerg Sonnenberger are updating the device subsystem to match FreeBSD 5.x. (I don’t have a lot of details on this; they’re busy!)

– Matt Dillon is writing a paper with FreeBSD’s Alan Cox detailing the performance improvements of certain pipe optimizations; he’s been doing various benchmarks for data. He’s also been working on AMD64-specific code, which he’s planning to commit soon.

– I may as well toss this in too: Jeffrey Hsu has been quietly and steadily changing the networking system. I don’t often mention his patches because he’s working at a level that’s quite beyond my ability to summarize.

Devon already noted this in comments on the last post, but a screenshot (not a prototype) of his installer work is at http://sitetronics.com/current.png.

Devon H. O’Dell has been working on an installer. This is a prototype, not a screenshot.

The libcaps interprocess communication is now functional, though not implemented. Matt Dillon wrote how this could be worked up, which I am reporting wholesale:
Continue reading “libcaps complete”

Sascha Wildner submitted a whole bunch of changes to vidcontrol(1); among other things, the colors/modes you can set in your terminal are more flexible, and it handles problems a lot better. This hasn’t been committed yet, and I usually don’t mention code until it’s in, but Sascha posted some nice photos of some of the possible modes:

C64-style
640×200, 8×8 font
320×200, 16px font