Make 2.0 notes now

Matthias Schmidt has set up (in CVS) a page for new items for the 2.0 release of DragonFly.  If you’re committing something big to DragonFly, write it down there.  Consistent use will give us a pre-prepared list for the actual release, which will probably be late summer.

Following up on ‘dolt’

I’m not technically qualified to answer the question Josh Triplett asked in comments on my ‘dolt’ article:

If you want to fix that, feel free to send me a patch, or just tell me that DragonFly uses the same -fPIC -DPIC that Linux and FreeBSD use.

Tell him at/send patch to, and if you do, thank you for helping.

Open Source development myths

This article, titled “Myths Open Source Developers Tell Ourselves“, dates back to 2003, but is surprisingly accurate. I suspect these myths will become even more prevalent; the number of open source projects out there has been increasing year after year, or at least that’s my impression. (Is there any person or organization that’s trying to track the number?) My favorite myth in the article: “End Users Love Tracking CVS”.


Not necessarily about me, but I read an article about the continuous stress of blogging, in the New York Times.  Entertainingly, the article says:

Blogging has been lucrative for some, but those on the lower rungs of the business can earn as little as $10 a post, and in some cases are paid on a sliding bonus scale that rewards success with a demand for even more work.

$10 a post?  Given that I’ve been doing this for near-free (the Google Ads buy me a sandwich every now and then) for years, that seems like a lot.  Not much to live on, though.

Another potential tool: dolt

Libtool is a very flexible but relatively slow tool used for a lot of software; it can impose a signicant time penalty during compilation. This post to names a new tool, dolt, which works as a drop-in replacement for libtool can significantly reduce build time. It’s not (yet) supported on DragonFly.  The name comes from “do ltcompile”.  (from Hasso on EFNet #dragonflybsd)

Solving underlying issues

This article, “Rethinking the interface to CPAN“, over at Perl Buzz, describes something there needs to be more of in the open source community.  CPAN, for those who don’t know, is a way to automatically add various libraries to a Perl installation, similar to BSD ports/pkgsrc or Ruby’s gems.

This is the message from the article: provide a solution to a real problem.  I bring this up because a reoccurring frustration people have with pkgsrc is how to upgrade packages.  Now, there’s no lack of ways to upgrade, but none of these solutions are a match for what people want: an upgrade method that works without frequent side effects or extra work.  This is why portupgrade is very popular for FreeBSD, or apt-get for Debian; it generally works as expected.  We need more of the thought process that leads to those solutions, in open source.

I’m not bring this up just to pick on pkgsrc; we need this sort of thinking for the DragonFly BSD website, too.  It (and the other BSD websites) take the role of a library shelf, with information only available by sifting through it until you find what you want.

Compare that to the Firefox website: most people are going to visit there to download Firefox.  A smaller contingent will already have it and want to upgrade it.  There’s a very clear visual path for 90% of the visitors to the site.  Now, go to any of the BSD operating system sites, and say “How do I install a working desktop system, with X and a window manager and so on?”  It’s going to take some digging.

BSDTalk 146: James Cornell

BSDTalk 146 is out, with James Cornell interviewed in a 20-minute podcast.  The host, Will Backman, asks “What are your favorite BSD-related websites?”, and  “Where can you buy BSD on disk?”  Leave a comment on his site if you’ve got an answer.