More bullets

I’ve got a number of little items, so more roundup:

  • How much disruption happened in DragonFly after introducing a dynamic device system?  Surprisingly, very little, as most of pkgsrc still builds.  Thanks are due to Hasso Tepper for the corrective work.
  • _why makes some very perceptive comments.
  • Jordan Gordeev’s been working on the very difficult AMD64 port as part of his Summer of Code work.  He says thanks for the help, and others reply in kind.  Speaking of which, it’s possible to boot 64-bit DragonFly now, though it’s not production-ready.
Messylaneous: books, lawsuits, git, more

Dear universe, including DragonFly people: stop doing so much stuff.  It’s hard to keep up.

BSD licensing, in a number of ways

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.

GCC 4.4. and NO_GCC44

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.

Pkgsrc parts explanation

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.

Donation time

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.

pkg_radd improvments

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.

Serial number details

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.