A running description of activity related to DragonFly BSD.
Some of the larger application sets on DragonFly have had trouble building, and inconsistent problems with that build. i.e. rust would fail, but in different parts of the build process, every time. It looks to be a problem with signal interaction, and there’s now much safer ways to do that on DragonFly.
That is going to require a full buildworld/buildkernel if you are on DragonFly-master, 5.7. Release/5.6 users are unaffected.
I link because they are good: 10% speedup. Or, because they made me laugh: “Basically, don’t use this.”
Remember how I said dsynth defaults to txz (tarred, XZipped) ? I was apparently wrong and it was using tgz (tarred, gnuzipped). Now it really truly defaults to txz, for space.
There’s a vulnerability in file(1), CVE-2019-18218. It’s fixed in current and release versions of DragonFly. Update when you get a chance.
As an example of how old design decisions have lasting effects, the POSIX standard still calls for terminal output to accommodate mechanical delay, as noted in this DragonFly commit – i.e. if output was still a line printer instead of a glass TTY, or, as it is 99.9% of the time today, xterm or puTTY or etc. etc.
I thought this would happen: the nrelease(7) process can use binary packages to build DragonFly. (For the dports packages, not the base system.) This is very interesting to me, but also useful for anyone who wants to build a custom DragonFly; something I think more people could do.
After 56k, I stopped paying attention, but apparently there’s stated baud rates of 460,800 and 921,600. And your DragonFly terminal can handle them, too.
This may be of most interest to me, since I’m usually the one building DragonFly releases. nrelease(7), which is used to build each release of DragonFly, now sticks to the default kernel config, and may use binary packages in the future. There’s some other changes but these are the ones I can describe most exactly; there might be more on the way.
Do you have a Coffee Lake Intel CPU? Cause corepower(4) in DragonFly now supports it.
If you were used to kldloading i915kms(4) and radeonkms(4)… they are now named i915 and radeon, respectively.
Pluggable Authentication Modules on DragonFly have gone through some changes. pam_ssh has been removed, along with pam_tacplus, and pam_radius, in favor of the more frequently updated versions in dports. ppp(8) still supports radius, though.
As anyone who has been running HAMMER1 or HAMMER2 has noticed, snapshots and copy on write and infinite history can eat a lot of disk space, even if the actual file volume isn’t changing much. There’s now an ‘emergency mode‘ for HAMMER2, where disk operations can happen even if there isn’t space for the normal history activity. It’s dangerous, in that the normal protections against data loss if power is cut go away, and snapshots created while in this mode will be mangled. So definitely don’t leave it on!
There’s now (well, for DragonFly 5.7 users) an /etc/os-release file to show the installed DragonFly version. This is similar to the de facto Linux standard, which of course evolved separately from the not-consistently implemented general standard. Evolved cross-platform standards are fine with me.
If you have a whole lot of I/O on a HAMMER2 system, this change will help. This is I assume an outgrowth of dsynth testing, cause that causes many, many threads to be reading and writing.
It’s now possible to pick which sort of compression you want to use for dsynth packages – xz is the default, but you can go gzip for speed.
Thanks to Erik Blomberg and the Vintage Computer Festival Midwest, I now know the Digest has reached a whole new operating system: CP/M. This entertains me.
(It’s the Digest being browsed in text mode on a TeleVideo TS-803, if you can’t see the screen well enough.)
Tomohiro Kusumi has been bringing in a large number of fixes to the msdos filesystem, mostly from FreeBSD, but from other sources. I’m not going to link to them all, cause there’s many over the last few weeks, but the good news is that there’s performance gains for this lowest-common-denominator filesystem.
You should set hostname in /etc/rc.conf. I am mentioning this now because not doing it kept me from running X apps from a DragonFly system on a Windows 10 system with vcxsrv, and I wasted half an hour of my life figuring that out. Apparently this is a lesson I need to keep relearning.