It’s on, again! Not that there was any doubt. I need to collect potential mentor names before DragonFly can be involved, so you can guess what I’ll say next…
Edward Berger found that using a LG/Hitachi DVD drive kept him from successfully booting a DragonFly install CD. Using other manufacturers worked out fine. What causes the problem? I don’t know, but it’s worth mentioning it out loud in case someone else gets bit by it.
There’s a NetBSD Hackathon going on February 10th through 12th, mostly online. I mention this because it may have some effect on pkgsrc, used by both NetBSD and DragonFly. Hackathons for pkgsrc usually happen separately, but no harm in keeping an eye out for any positive benefits.
ISDN support has been removed from DragonFly. It was not useful at this point, because it’s rarely used any more. It does make me feel a little sad; this was the technology everyone said was the future before cable modems and DSL were figured out.
They are located in the normal place, in .img (USB) and .iso (CD/DVD) formats. I haven’t made the desktop DVD yet; let’s see how these untested versions do…
A bit of symmetry in that title, there. Old ATA, which was replaced years ago, is finally gone. This should affect nobody…
If you need to use ISDN with DragonFly, speak up now. I think it may get tossed otherwise.
Note that it’s branched, not released. I’m building and uploading binary pkgsrc packages for it now, and hope to have a ‘release candidate’ very soon. This is the prep work before the release, really. There’s a catchall ticket for tracking remaining work.
There’s a whopping 250 euro bounty up now on the DragonFly Code Bounties page. It’s for supporting the newer Intel video chipsets, and there’s already examples in FreeBSD to start with.
(David Shao, where are you? If you’re reading this, hop into #dragonflybsd and tell us how things are going with your GEM/KMS work)
‘Live dedup’, where a DragonFly system makes a deduplicative reference to copied data instead of actually copying the data, is now off by default. There’s no definite issue linked to it yet that I know of, but it never hurts to be careful just before a release.
John Marino has added support for RELRO in DragonFly, which makes it the first BSD to have it. That’s great news! What is it? Apparently a guard against memory corruption or overflow in the linker. His commit message gives better details.
Matthias Schmidt found a discussion about DragonFly’s password encryption. The result, if I am reading it correctly, is that brute-forcing the password from available hashes is quicker than it should be. Matthias also found a contributed fix. Samuel Greear updated to match the reference SHA implementation also in Linux, with this very pertinent warning.
If you liked KDE3, you may like Trinity. Matthias Drochner would like you to help get it in pkgsrc.
Matthew Dillon has a very detailed commit message with changes to make sure Hammer will run overnight cleanups in situations as low as 256M of RAM. I think you can find that much RAM in breakfast cereal boxes these days.
The answer is “not very”. As I wrote in a post to kernel@, DragonFly 3.0 will be tagged soon, and released when there’s pkgsrc-2011Q4 packages to go with it. Probably a week if everything goes to plan.
Chris Turner reports success building JDK 1.6 on DragonFly x86_64, though it requires a bit of fiddling. Building 1.7 on x86_64 is getting closer but not yet, as far as I can tell.
If you install CUPS, or know that you will never print using lpr(1), you can make sure thatyour DragonFly system never builds lpr again by putting NO_LPR=true in /etc/make.conf.
What if you have a DragonFly system that you want to use for an wireless access point? Andrey N. Oktyabrski did, and he helpfully listed his solution.