Java rumors

Sun is reportedly thinking about open-sourcing Java. There’s no timeline or specific commitment, so it all could be rumors. While Java for FreeBSD works on DragonFly (or so I’ve heard), it’d be nice to have it work officially, without jumping through license hoops.

Doc to do

Thomas Belian made a post to dragonfly.docs asking if a translation of the documentation to German would help. I made a reply that is probably worth repeating:

“It would be nice to have; you may want to wait until the documentation is more “settled”, probably after the 1.0 release. If you’d like to write original documentation, that would help too, and that can be done right
now.

We could use an extended section on networking setup, and a section on ports. If you check out the cvs target ‘doc‘, you can base it off the files there. Specifically, copy one of the chapter.sgml files in a directory under /doc/en/books/userguide/ and start working. If you are unfamiliar with the markup, you can read up on it at http://www.docbook.org/tdg/en/html/docbook.html

Ports link, refreshed

Discussion of an improved/replaced ‘ports’ system ran on for a bit on dragonfly.kernel, and Eirik Nygaard reposted an important link: Simon ‘corecode’ Schubert’s extensive writeup.

(Watch for subtle hint!) It’s good enough to serve as a task outline for anyone contemplating ports work. (end hint)

Why not apt-get?

Matt Dillon mentioned that he’s considering using apt-get combined with VFS to create a sort of ‘per-user’ port visibility. Quoting his examples:

“So the ‘apache user’ might only have 10 ports installed (and only access to those 10) while a GUI user might have 50 ports installed (and only access to those 50). Overlaps would be allowed… the environments would be considered independant.

Such environments would also enforce basic isolation/separation/security features such as “/usr is read-only except for /usr/local”, and would be stackable, but instead of trying to use them on a per-package basis we would use them on a per-user basis (or something like that).

This gives us the best of both worlds in my view.

This would mean a new ‘port’ system would have to wait until VFS is finished, though using apt-get without the per-user separation would be achieveable almost immediately.

Switch now or pain later

David Rhodus mentioned in his GoBSD journal that DragonFly is a better choice right now than FreeBSD 4.10, highlighting a FreeBSD-4 unfixed bug in his journal. He also let slip that he’s working on a commercial operating system based on DragonFly, with the first release candidate coming very soon.

Improvements in the future

Rahul Siddharthan pointed at this post as evidence of softupdates not working as quickly as it used to, for FreeBSD and by extension DragonFly. Matt Dillon replied that:

“FreeBSD-5 has a lot overhead, especially when it comes to the buffer manipulation that softupdates does. DFly should be nearly the same as 4.x in regards to FS performance.

There isn’t much I can do about softupdates but the (slowly progressing) namecache work will eventually allow us to release the exclusive lock on the directory vnode during directory searches and this will bring up our lots-of-little-file benchmark numbers considerably.

Another issue that slows down filesystem operations is the busy-page lockout that occurs when the system is writing data to disk and some other operation wants to modify the page undergoing I/O. That is ”on the table’ as well.”

Kernel Krap

The kernel mailing list is getting hit with a Windows mail virus in a big way; be careful when viewing it through your mail client/news interface if you use Windows.

Update: fixed now.

BIND9 updated

Matt Dillon has added bind-9.2.4rc4 to contrib. This replaces bind8 that was being used for DragonFly (and I assume FreeBSD-4) by default. Things may be somwhat unstable for a few days; if that is trouble for you, don’t update your system this week.