Matthew Dillon has committed two changes, both to DragonFly 5.4 and to DragonFly-current. His note to users@ explains the details. I don’t have a date for 5.4.2 being rolled out, but I expect soon.
This is the commit I should have linked to yesterday, and was reminded by an anonymous commenter: git: sys/vfs/fuse: Add initial FUSE support. It’s not complete, and so isn’t built by default; check the commit for details.
Remember my Wyse terminal experiment with a DragonFly VM? I mentioned an odd output pause where the screen would stop updating until there was keyboard activity – or occasionally just die. That was an artifact of Virtualbox; running this now in Qemu has no such problem.
I now have a very overcomplicated clock! I’m running GRDC on this Wyse-185 connected as a vt100 to the virtual machine running DragonFly 5.4 in Qemu on my Windows 10 work laptop. It’s at 9600 baud so I can see the numbers morph. I find this aesthetically satisfying.
Tomohiro Kusumi has committed more work on FUSE support in DragonFly. I am not sure if this is more foundational work or if it makes a user-level difference. At least the commit notes are nice.
Sepherosa Ziehau has an update for em(4)/igb(4) network cards, for you to test if you have the matching hardware. It looks like this is an update from the vendor, Intel, going by the version numbers.
DragonFly now has ministat(1), imported from FreeBSD thanks to Aaron LI. Use it on the output from your next run of benchmarking tools.
time_t in DragonFly is now 48-bit. This won’t affect anything you do day-to-day, probably, but it’s neat to see the 9 million year timeframe.
DragonFly 5.4.2 is out. My users@ post describes upgrading, as do the 5.4 release notes. This release has the HAMMER2 fix mentioned here recently. There’s a number of additional small changes listed in the tag commit.
Images are available for download at various mirrors, too. If you’ve recently upgraded to 5.4, it’s the normal build process.
It’s always helpful to see other people’s questions and answers; in this case it’s a conversation about HAMMER2 snapshots and how to manage them. (Follow the thread)
I managed to find an ancient Wyse-185 terminal at my workplace today, left in the corner of the server room. For entertainment purposes only, I booted DragonFly in VirtualBox and attached the physical terminal to the physical serial port on my Windows laptop docking station, mapped through to that virtual machine.
I have already discovered that the character output will often pause until the keyboard is used, which may be a settings issue. Mash the keyboard enough and VirtualBox dies. I’d use different emulation but Hyper-V doesn’t support serial and Qemu I haven’t figured out.
It’s entertaining, though I am not sure what I will do, other than maybe run GRDC once I figure out the reason for output pausing.
The aforementioned HAMMER2 fix is now in 5.4. You can update using the normal make buildworld/make buildkernel process to get it in place. I plan to roll a 5.4.2 release this weekend.
If you want to hear nothing at all from ACPI, no matter what, set debug.acpi.silence_all to 1. In related news, DragonFly has just updated to Intel’s ACPICA version 20190329.
It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
top(1) is no longer in DragonFly contrib/ directory, for a number of reasons. It’s still present in the system, of course, and I think needs to have someone re-add as a vendor branch – a relatively easy project for a volunteer, hint hint.
There’s some code changes for callout, where the actual lines of code that trigger it are stored in the callout structure. It’s a little thing, but it’s a big thing if you need it.
Lots of BUG news this week; thank you all for the leads on groups to watch.
- Talking Jails at Semibug, 9 April 2019. Note the meeting has been moved up a week.
- “FreeBSD Mastery: Jails” and a new novella.
- April 9th Meetup. ChiBUG.
- Rusted ravens: Ravenports march 2019 status update. There’s some DragonFly stuff in there I haven’t had a chance to link to.
- How to use NetBSD on a Raspberry Pi. (via)
- Serenity: x86 Unix-like operating system for IBM PC-compatibles. Almost UNIX, almost BSD. (via)
- Before Unix: An Early History of Timesharing Systems. Influences on BSD.(via)
- OpenRA imported – game engine recreation for RTS games of the Command & Conquer family. (via)
- Project Trident 18.12-U8 Available. (via)
- Removing PF. (via)
- Silent Fanless FreeBSD Server – Redundant Backup. (via)
- LLDB/LLVM report for March 2019. NetBSD.
- Continuation of signal semantics improvements. NetBSD.
- iked curve25519 group number change. OpenBSD.
- Valuable News – 2019/04/01.
- Sega Dreamcast Running NetBSD. (via)
- UNIX and BSD Discord/Matrix Servers.
- BSD Router Project 1.92 is now available. (via)
The show subcommand for gpt(8) has had some improvements including a way to connect it to the device UUID; I link to it cause depending on the age of your machine, you may have never even needed to use gpt yet.
If you are so lucky as to have an ixgbe(4) card, the version 3.3.6 driver (from Intel) are in DragonFly.
Note that I’ve managed to catch up to March commits! There’s been a lot.
GCC 5.0 is no longer needed in DragonFly, so it’s not being built, and can be removed on your next ‘make upgrade’. As a bonus, buildworld is a little faster.
On DragonFly, booting from a USB stick means your boot volume is usually /dev/da8. That’s a rather arbitrary distinction. As a bonus from the recent part-by-label device change, you can now find the boot disk in /dev/part-by-label/, named by the booted kernel rather than a device number. The commit message has a slightly better explanation.