A running description of activity related to DragonFly BSD.
That’s a pretty cryptic headline, isn’t it? John Marino has ‘privatized’ several libraries in DragonFly, so that they can’t get included involuntarily as part of a port build. That may mean you will need to perform a full rebuild of your system if you are tracking DragonFly-current.
(This is the way to fix ‘system’ languages like Perl was in FreeBSD 4.x – keep them clearly separate from the port version. It’s about a decade too late for that idea to work out, though.)
This has no effect on the actual operation of DragonFly, but it makes me feel better that it’s done: Rimvydas Jasinskas has gone through DragonFly source and removed the unnecessary 3rd BSD license clause, which is no longer needed.
For those of you with i915 video on your DragonFly system, there’s another update bringing DragonFly support to match what’s in the Linux 4.1 kernel. ValleyView and Skylake processor owners will benefit, along with a slew of other bugfixes and improvements.
Are you using a i915 video chipset? Are you using the DisplayPort? Imre Vadasz has added a tunable that may make it work better.
DMA, the DragonFly Mail Agent, is available in dports and FreeBSD ports, and is now available for NetBSD through pkgsrc-wip. (Thanks, Christian Koch)
Sepherosa Ziehau has an update to the em/emx(4) (or other Intel NICs) driver, for testing. Hey, remember what I said the other day about Skylake support?
There’s two important security updates for SSH. DragonFly release and development have been updated for it, and you can correct for it on your running system using the one-liner at Undeadly.
Note: keep in mind this is a client bug – it’s an information leak when you as a client connect out to somewhere else. A server, as an endpoint, is not affected.
New CPU support in DragonFly is continuing, and Matthew Dillon will be testing one of the newer Intel ‘Skylake‘ processors soon. That may mean even more accelerated graphics support at some point, too.
I’ve never heard of ‘McCabe Complexity‘ before now. It’s a description of how complicated software can be, measured by the number of possible paths through it. Pierre Abbat used that measure on Hammer code and not surprisingly, got a high number.
John Marino has opened up his new utility for testing: Synth. It’s made for building custom package repositories, similar to poudriere, but much less setup work. If you’ve ever said “I like binary installs, but I want my own build options”, this is for you. The README includes screenshots to show all the things it can do.
This is a little thing, but so useful: the Wi-Fi indicator light on your iwm(4)-using device will now show its status under DragonFly.
Please welcome DragonFly’s newest committer: Rimvydas Jasinskas. He’s already done some adding and removing, and he’s been making a ton of dports changes for some time.
Francois Tigeot has updated DragonFly to match the video support found in the Linux 4.0 kernel. This will benefit you most if you are running Skylake, Cherryview, or Valleyview chipsets. Don’t ask me how to tell; the improvement has been so rapid I’ve lost track of which model codename is which.
There’s some DragonFly links I snuck in here because why not?
A number of people have reported problems with qemu and DragonFly, both running locally and on a host. It turns out to be a problem with the getcontext(), setcontext(), and swapcontext() functions, but Matthew Dillon fixed it in a way that doesn’t affect performance very much.
That apparently wasn’t good enough, so he added _quick versions of those same functions, so it became not just a fix, but an improvement.
In related qemu news: qemu-devel can use vknetd similar to a vkernel, now.
I was going to point at a new igb(4) update for testing, but Sepherosa Ziehau has already merged it. Try it if you have the right Intel networking hardware.
For those of you that are very bandwidth-constrained, or just impatient, there are xz-compressed images of DragonFly 4.4 available. (see ‘download live image’ area) The mirrors should have them too.
The DragonFly installer has been modified to produce disk arrangements that will generally match between UFS and Hammer installs, plus directories where you usually don’t want Hammer history or backups (like /tmp or /usr/obj) are now under /build and null-mounted to where you’d expect, since null-mounting works transparently well on DragonFly. Matthew Dillon has a note explaining the whole thing.