The amount of swap space usable under DragonFly has gone to a theoretical max of 4 terabytes. The practical limit is probably around 512 gigabytes. As Matthew Dillon writes, this could be interesting when paired with SSDs.
Well, technically, the title is “Twenty questions about the GPL“, but I read it more as reasons for using the BSD license. (via)
Also, I was going to link to this article about increased BSD(ish) license adoption, and then I wasn’t, and then I found that Dru Lavigne had managed to pull out the quote that summarized the idea perfectly.
While I’m on this theme, this Coding Horror “Digital Sharecropping” article complains that people are effectively doing free labor for companies that plan to profit from that labor. There’s a parallel between free software and the activity he’s worried about. Not that he’s wrong, mind you, but there’s more to the story.
Subscribe to BSD Magazine, get all the previous issues. (via)
As Hasso Tepper pointed out, having GCC 4.4 in DragonFly is unique to DragonFly. Systems like pkgsrc don’t work due to the changes in headers and etc. between gcc 4.2 and 4.4, and since no other BSD uses gcc 4.4, the fixes would all have to come from DragonFly (and be backward compatible). This is unlikely to change in the near term, since this newer version of gcc is being refused due to the V3 GNU Public License, not a technical issue. It’ll stay in DragonFly for now.
However, you can specifically exclude it and speed up buildworlds with the new NO_GCC44 option. It’s also possible to use NO_GCC34 in make.conf to keep the old version of gcc from building, for those who don’t like to wait.
I totally missed this, but Sascha Wildner reminded me: Alex Hornung now has commit access to DragonFly, due to all the devfs work he’s done.
Matthew Dillon provided a summary of the state of the dynamic device filesystem work, plus a note about the preliminary iSCSI work. He also brings up the notion that iSCSI would eventally allow booting off a drive no matter where it’s physically connected.
This isn’t breaking news, but it provides definition for pkgsrc: there’s ‘stable’ branches of pkgsrc that aren’t called ‘stable’; they’re tagged as quarterly releases. You may have already inferred this from my postings. Alan Barrett went into detail on the pkgsrc-users@netbsd.org mailing list.
Any commits to DragonFly go to the commits@dragonflybsd.org mailing list. The subject format has been reduced to “git: “, branchname, and the first line of the commit message. Keep that in mind when constructing your commit messages, and if you have any filters based on subject line for your mail.
The FreeBSD Foundation is seeking donations – not that they aren’t always open to it, but they’re asking now instead of at the end of year rush. The Foundation does excellent work getting developers to conferences and sponsoring projects, all of which increases the amount of free code in the world. If you’ve got some spare cash, please donate. It doesn’t have to be a lot, as having a large pool of donors is almost as valuable as total donation size.
If you’re on DragonFly 2.3.1 or 2.3.2: I’ve uploaded a full pkgsrc build to avalon.dragonflybsd.org based on pkgsrc-2009Q2. It’s possible to use pkg_radd to automatically download and install packages for those systems. (and pkg_search will search the remote repository for you.)
If you’re on DragonFly 2.2.x, I’ve modified the pkg_radd target for that release so that when pkg_radd makes a request, it is redirected to the appropriate place on avalon.dragonflybsd.org instead of attempting (and potentially failing) to find a matching mirror.
I said close to the same thing as the above text on users@; the short form of all this is that pkg_radd should generally work for everyone. Tell me if that’s not your experience.
Are you going to (already sold out) HAR2009? Matthias Schmidt is, and he’s like to meet up with any other DragonFly users there.
There’s some more explanations of how disk serial number support is working from Matthew Dillon, plus a warning that a full kernel/world rebuild is needed because of these changes.
If I’m reading it right, serial number support, combined with a dynamic /dev, makes it possible to identify a disk by serial number, assign a name to it, and then refer to that disk directly by name in places like /etc/fstab. Much, much easier than remembering /dev/ad0c or /dev/ad1a, and so on.
DevFS breaks vinum. Will it be fixed? Yes, hopefully very soon.
Preliminary serial number support for drive identification has been added to DragonFly, with /dev/serno listing the appropriate devices and numbers.
Dru Lavigne needs someone for the BSD booth at the Ohio Linuxfest, in late September. Please help out if you’ll be near; it’s a good way to meet people and a way to spread BSD.
I picked this up from the bsdevents Twitter feed – possibly the most comprehensive list of events out there. It’s surprising how many conventions and speaking events and etc. are out there!
DevFS has been added. There’s some issues, each with a workaround. Please test, as it’s certain that a major change like this will cause new problems around video and sound. Once those are fixed, however, device management will be a lot easier.
I published a retention policy for pkgsrc packages. It works out to “current release and last release” for what will be kept as pkgsrc binaries that you can add with pkg_radd. If you need longer-term support, speak up, but I don’t think this will be a problem for anyone.
Want to bring Hammer to Slackware Linux? People want it, and there’s some work already in progress.
Simon ‘corecode’ Schubert has been working on an import of gcc 4.4 to DragonFly; it’s not usable yet, but when it is, it means the 3.x gcc code can be dropped.
This machine, shiningsilence.com, is having some issues. I had to power down because of unrelated problems, and the system couldn’t find the kernel on the next boot, though the issue disappeared on the next boot. That’s enough of an excuse to build new…
Any hardware recommendations? I’m interested in hearing what chipsets/disks/RAID setups/etc. and/or hardware suppliers worked well for people.