If you don’t have an Intel CPU, but still want to perform microcode updates, cpucontrol(8) now supports more recent AMD CPUs.
The default kernel config for DragonFly has changed: Sascha Wildner has added the acpi, gpio_acpi, gpio_intel, smbus and smbacp devices. If you are using a custom kernel, you’ll probably want to add these. If you aren’t using a custom kernel – you should have no negative effect.
The title really says it all – if you have a Coffee Lake series Intel chipset, your video is accelerated on DragonFly.
Rimvydas Jasinskas created a loader.conf(5) hint that keeps various nata(4) devices from attaching during boot. This is super useful if it’s a device that screws up your boot process. and I think it’s also great if you get irritated having something in your dmesg every time about the device you never use, like a CDROM.
DragonFly now has support for the Adaptec 1420. “Now” means since last month, cause I am working through my link backlog.
The ls(1) command has a lot of options (Look at the man page synopsis!). So much so, that the most recent option added in DragonFly is “_”. That’s to show nanotime as part of the -l output. This will be most useful when you have multiple files being created within the same second of time, and you want to see which came first.
I’m still catching up with the pre-2018, pre-Meltdown commits, so here’s one: Changing the staged packet count in DragonFly changes forwarding rate, for the better – up to a point. There’s probably some specific ratio in the change that makes sense, though I don’t know it.
The commands rcp(1), rlogin(1), rlogind(1), rsh(1) and rshd(1) have been removed from DragonFly. There’s a net/bsdrcmds port if you still need them… though I imagine/hope ssh is filling the void for everyone.
I’m sure this was needed by someone: morse(6) can now encode and decode Morse code, signified by . and – of course.
I say “one more” like I know when this saga will end. If you are using the devcpu-data port to update your processors, you’ll need to add
microcode_update_enable="YES"
to your /etc/rc.conf, as Sepherosa Ziehau points out.
The regular maintenance scripts for HAMMER1 assume that it’s mounted at the time of cleanup. If you have them unmounted, they won’t go through that regular maintenance, but it’s easy enough to fix.
Matthew Dillon posted a summary of IBRS and IBPB support in DragonFly, and some numbers showing its impact in various configurations of options and CPUs.
Are you tired of hearing about Meltdown/Spectre yet? Doesn’t matter! The two sysctls for controlling mitigation in DragonFly have been renamed:
machdep.meltdown_mitigation machdep.spectre_mitigation
They go to hopefully sensible defaults, but Matthew Dillon has done some testing to show the effects of each in various combinations. (Update: more changes and tests.) Note that this is not the final mitigation work; compilers (i.e. gcc) are being updated to include workarounds for this, so new gcc -> new compiler in DragonFly -> new defenses. No silver bullet there, though.
One side effect of Meltdown/Spectre are CPU microcode (firmware) updates. For future needs: sysutils/devcpu-data is the port that has the updates for Intel, and cpucontrol(8) is the program you run on DragonFly to add them.
I haven’t used this myself, yet, so I can’t tell you how necessary an immediate update could be – but you will probably want to use it soon.
Update: Newer CPUs might require this sizing change.
Update update: a better explanation of applying microcode updates. There’s new ones out, too. (via)
If you’re on the bleeding edge of DragonFly and already updated for Meltdown fixes, there’s a few more commits you’ll want to get.
Matthew Dillon wrote a summary of the current status, noting there’s not much you can do for Spectre beyond new hardware. There is an update to the “defensive browser setup” plan for DragonFly (using –site-per-process) that can help at least with Javascript versions of Spectre.
Update: step-by-step microcode fixes from Intel if you really want to trash your performance.
By now you’ve probably heard of the Meltdown/Spectre attacks. (background rumors, technical note) Matthew Dillon’s put together a Meltdown mitigation in DragonFly, done in four commits.
It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs. Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.
Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.
Update: Matthew Dillon posted a summary to users@.
Update 2: He told us so.
DragonFly has a donation page and a Paypal account. There’s no 501c3 benefit for U.S. residents to donate; DragonFly doesn’t exist as a non-profit. People have still been donating in smaller sums over time. It’s not enough to offset the colocation fees ($4k/year) plus the hardware there, but the money does get used for specific tasks. Matthew Dillon wrote a description of his upcoming plans: more storage, plus some interesting details on how much wear the existing SSD disks have sustained.
the md5(1) utility on DragonFly now does SHA512 checksums, thanks to Rimvydas Jasinskas. You can see it as a separate ‘sha512’ binary in /sbin, but it’s a hard link back to the original md5, if I’m reading the commit right.
There’s been a number of commits lately from Sascha Wildner with mentions of “Tianocore EDK II” a term that’s new to me. Googling for it tells me it’s a development environment for UEFI programs, useful for anyone booting on modern hardware.