If you’re running DragonFly in a virtual machine – specifically in VirtualBox, on Windows – there’s a recent thread on users@ that may have some tips, including a link from John Marino to tunnelier.
Two tips for working with pkgsrc, derived in part from this mailing list post on users@ (follow the thread) and from my own experience. If you put WRKOBJDIR=/usr/obj/pkgsrc into /usr/pkg/etc/mk.conf :
- You can clean up any leftover package building files by deleting the files in that directory and leave your pkgsrc files untouched.
- You can have a read-only /usr/pkgsrc, which means it can be shared over NFS (or SMB?) between multiple machines, DragonFly or otherwise.
Siju George asked about how he could figure out which serial number (in /dev/serno) maps to which disk. Tim Darby posted a script he used for it, or you can just use devattr(8). There’s also a linking trick described by Chris Turner to remember how the names map.
Happy (post) Turkey Day for the U.S. readers! A light link week this week.
- Facebook is bad for the Internet. ‘Gaslighting’ is a new term to me. As that article points out, I can’t even put my posts to the Digest onto Facebook in any sort of automated way. Facebook suggests that of course I’d love to retype them all by hand. That’s not realistic. Facebook doesn’t want any sort of useful external link to be visible to their customers. Customers isn’t actually the right word; the customers are the advertisers. What would be a better word for the users? Crop?
- “the internet is above and beyond all else a resentment machine.” It’s a very long essay that points out people are confusing brand identity with personal identity. (via)
- You know what would be good? More conversations about games on BSD, cause it could use some attention. Oh hey there you go.
- A Dragonfly lamp (via Julian Gehtdichgarnichtsan)
Your unrelated link of the week: Animals Talking In All Caps. It is what it says it is.
Francois Tigeot has updated his PDF of Postgres benchmarks with some OpenIndiana results. They’re crazy high, though he reported some freezes too, as with Linux.
When building world and kernel on DragonFly, /usr/obj is where the work files get placed. This can eat a bit of space, but it can be safely deleted. If you keep the files around, subsequent rebuilds can be done faster with a quickwork/quickkernel, but this may not matter to you.
(This was answered on the mailing lists by Max Herrgaard, but I don’t have a link to his reply – sorry!)
Remember the Postgres benchmark I described here a few days ago? Francois Tigeot has updated it with numbers from Scientific Linux running the same pgbench procedure. (see page 2) If you’re too lazy to look at the PDF, his summary is this: Linux is fastest of all, and also crashes the most.
DragonFly now uses Redmine for bugs.dragonflybsd.org. This means that the bugs@ and submit@ lists have can still be read by anyone, but to post a new bug or patch, or reply, you need to be registered on the bug tracker itself. You don’t have to be subscribed to the mailing list to use the web interface. See the bugs@ and submit@ announcements for other details.
Juan Francisco Cantero Hurtado has been working with clang and DragonFly, along with Sascha Wildner. DragonFly mostly compiles using clang, with lib/citrus being (the only? one of?) the last holdouts. Juan Francisco Cantero Hurtado detailed how to test it out using clang 3.0 in case someone else wants to help solve this.
The two things that make my day! The work on DragonFly-current has led to some significant speed improvements. So good, that Samuel Greear’s post on OSNews.org links to graphed results from him and from Francois Tigeot (multi-page PDF) showing the results from pgbench.
The results show a jump in multi-core/processor numbers that vastly exceeds DragonFly 2.10’s performance, and is comparable to FreeBSD 9/10. Here’s some of what did it.
The host leaf.dragonflybsd.org has been upgraded to new hardware. This is the machine used for anyone who wants to develop on DragonFly, so there’s a good performance boost there for developers. It also hosts bugs.dragonflybsd.org, which should be working again soon.
There’s a new page up on the DragonFly website, about using rpkgmanager to manage your pkgsrc-installed packages.
In DragonFly, there’s only a few places C++ is used. If you wanted to make sure DragonFly was pure C, Samuel Greear lists those remaining nooks and crannies.
Almost all the packages in pkgsrc support non-root installation now… except these last 31. I recall something about their removal by the next quarterly release if they still don’t work, or maybe just after. Jump in if one of these packages is useful to you.
Some cleanup in the CVS -> git process wasn’t happening, so if you have been using pkgsrc 2011Q3 from git (i.e. via make in /usr), re-pull to make sure you have everything.
(The post noting this seems to have been eaten by the mailarchive… that’ll be replaced.)
There’ll be some brief outages this week as a few of the dragonflybsd.org machines are upgraded. The new machines will be 64-bit DragonFly, and have 16G of RAM. RAM is crazy cheap these days. I’m continually dumbfounded by it.
This recent structure change (are there others like this? Maybe?) means that existing binaries may need to be recompiled for anyone tracking DragonFly master. This probably means that an upgrade from 2.10 to 2.12 will require rebuilds of all binary pkgsrc packages.
Well, they’re still available, but you don’t want them in your config any more because they can slow you down. This will only affect you if you are running binary files from DragonFly 1.2 or earlier, or… I guess a 4.3 BSD binary? From 1986? I’m sure there’s some other reason for it to be there.
Samuel Greear, Jan Lentfer, and others are looking at Postgres scaling on DragonFly. The work they are doing isn’t in the tree yet, but here’s a graph showing some of the performance differences.
Francois Tigeot does something very useful: he monitors the resource usage on his systems, and tracks how it changes over time. Because of that, he noticed that the recent VM changes in DragonFly have made quite a difference in memory usage. (See the green area in the attached chart, around week 42.)
