Having trouble with loading a splash screen? “beastie_disable=YES” in your /boot/loader.conf. Note: this may or may not work; it’s untested.
Running DragonFly under VMWare? Try GeekGod’s XF86Config, if you don’t have one set up.
This should be bugfix week; DragonFly BSD 1.0 should be ready for USENIX, starting on the 27th in Boston. This week may be rather quiet…
After several iterations, we now now a “offical” archive of discussions on the dragonflybsd lists. This pulls right from the news server. It’s currently updated every 2 hours. Credit’s due to Matt and Hiten for hitting me with ideas for it, and for adding the support applications.
There’s still some work to be done: Search functions, raw messages, and archive downloads. That’ll be the next version.
Other archives out there:
http://marc.theaimsgroup.com/
http://www.gmane.org/ (dragonflybsd.kernel only)
The DragonFly Live CD with installer now includes a web-based installer in addition to the existing ncurses installer.
Hiten Pandya posted that work for DragonFly 1.0 should be done by June 13th, which gives a week of testing before USENIX.
(flop sweat time!)
I had been thinking, “How big a market is there for BSD-based systems?” Netcraft’s very nice websurver-survey shows just how much, at least for FreeBSD and webhosting. It also shows something else – the Internet/computer market is definitely back into a growth cycle.
Matt Dillon noted that removing ‘device ehci’ from your kernel configuration will cause the USB 2.0 ports to switch down to USB 1.1. This may be needed to make certain USB chipsets work.
Munish Chopra pointed at this mailing list post as the possible reason you see -DTARGET_NAME=\”i386-undermydesk-freebsd\” when building GCC3.
A link getting passed around is this list of OSX optimizations. Joerg Sonnenberger commented on it in the GoBSD forums, listing what’s possible and what’s done already in DragonFly.
Since we’re still using the ports system, you can speed installs up significantly by using prebuilt packages. There’s package repositories at Fortunaty.net and GoBSD.com.
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.
‘GeekGod’ has also created a libdfui wiki. libdfui is the library being used to build the installer interface.
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“
‘GeekGod’ has placed Simon ‘corecode’ Schubert’s packaging plan into a wiki.
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)
Sascha Wildner’s preformatted DragonFly documentation has been cleaned up, and had title pages and content lists added.
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.