A running description of activity related to DragonFly BSD.
If you are on DragonFly-current, the ABI changes of the past few days are complete and new dports packages are built, so now is a good time to do a complete build and install of world and kernel, and then a pkg update.
5.6 users can keep on keeping on; no breakage there.
ABI breakage continues, so continue the full buildworld/buildkernel cycle, if you are on DragonFly-current, and continue to ignore it, if you are on 5.6.
Update: yeah aim for next week.
There’s commits being made in DragonFly that will break binary compatibility. If you are running DragonFly-master, that means you will need to do a full buildworld/buildkernel when updating, and you will either have to rebuild packages or wait some days until a new set are built.
If you are running the 5.6 release, you are unaffected.
Roy Marples has imported openresolv 3.9.2 to DragonFly. This is a replacement for the old-style /etc/resolv.conf file. The more complicated your network, the more you will appreciate this tool.
Roy Marples has brought in version 8.0.4 of dhcpcd(8); it’s definitely up to date since he’s the author. It does DHCP, DHCPv6, and IPv4LL/ZeroConf, the last of which I’ve only seen on Apple machines before. Someone want to try Network Configurator with it?
I’ve seen a similar config other places, but it never hurts to note: scrolling in X requires just a few xorg config lines.
Jails on DragonFly now have their own sysctl tree, inherited from defaults. And are no longer MPLOCKed.
The radeon driver support on DragonFly now matches Linux 4.7.10. Update and test, especially if you have one of the chipsets mentioned.
First, history: DragonFly has had binaries of dports available for download for quite some time. These were originally built using poudriere, and then using the synth tool put together by John Marino. Synth worked both to build all software in dports, and as a way to test DragonFly’s SMP capability under extreme load.
Matthew Dillon is working on a new version, called dsynth. It is available now but not yet part of the build. He’s been working quickly on it and there’s plenty more commits than what I have linked here. It’s already led to finding more high-load fixes.
Following up on an earlier post, the new servers for DragonFly are in place. The old 40-core machine used for bulk build, monster, is being retired. The power efficiency of the new machines is startling. Incidentally, this is where donations go – infrastructure.
Incidentally, my employer, REDCOM, uses FreeBSD as a base for its main product, is deployed in rough areas and in high-security government locations, and is one of the few electronics manufacturers still working entirely in the U.S.. REDCOM also has jobs to fill in New York, where I work. Please, apply if you see a job that interests you – and tell me.
Taken from IRC: “DFBEADM(1) A Boot Environment Manager for HAMMER2“. This could be fun! Here’s the users@ post to match.
Here’s something I haven’t see before: at the time of me typing this, there are commits in DragonFly, FreeBSD, and I assume NetBSD (haven’t found the commit), but the 2019-5612 CVE entry is still shown as reserved and not public. This may change by the time you read this article, of course.
Update: the original source, found by an intrepid reader.
If you have an AM4 motherboard and also can’t EFI boot DragonFly on it, this recent change may fix that for you.
Also, if you are using a Corsair keyboard, this commit may be useful to you.
Matthew Dillon posted an extensive writeup about the hardware changes for dragonflybsd.org; price to performance ratio has been improving so much for multiprocessor machines that we can jump forward both for hosting hardware and for a testbed.
He also mentions his immediate thoughts on what to tackle next, since SMP has been so relentless improved in DragonFly. It resulted in a very long conversational chain as people weighed in with opinions, so I’ve held off posting it until the conversation finished. (I chimed in too.)
Roy Marples, the ‘upstream‘ for dhcpcd(8), noticed that DragonFly was working with it as a dhclient/rtsold replacement, but the process wasn’t complete. So … welcome new committer!
DragonFly’s tap(4)/tun(4) devices have been historically precreated – tap0, tap1, tap2, tap3. They are now auto-cloned, which might surprise any software counting on the prior behavior. I don’t know of any specific packages that are affected by this, though. DragonFly version 5.6 is unaffected by this; it’s in -current only.