The Environment Quickstart document for DragonFly now has a HAMMER2 section.
Do you still reflexively type “shutdown -p now” to power down your computer? I haven’t been able to break that habit. A recent documentation commit reminded me that “poweroff” exists, even though I posted about it 7 years ago.
I’m posting now because it’s happening Wednesday and waiting for In Other BSDs on Saturday will be too late: the next FreeBSD Office Hours (livestream with Q&A) is happening on the 16th.
I tagged DragonFly 5.6.3, and built images. You should run 5.8, cause it’s the most recent, but this means there’s an image that captures all the last bugfixes in the 5.6 series. You can see them in the tag message if you are curious.
I moved the 4.x ISO/IMG release files for DragonFly out to an existing “older” directory. If you’re looking for a old release image, it’s available via the web.
Note that it’ll be a few hours until this change filters through to the mirrored directories. The 4.x images are all older than 2 years, so this is of most benefit to mirror sites.
If you follow the upgrade instructions in my 5.8 update post, there is one ‘gotcha’. If your copy of /usr/src was downloaded using “make src-create-shallow”, you will not have any git history – or any branches other than 5.6.
The easy, cheesy way to fix it is to remove /usr/src, then type “make src-create” in /usr, and proceed from there. There’s probably a way to edit in the other branches, but I haven’t tried it yet. I’m counseling the brute force method for now.
DragonFly 5.8.0 has been released. This version brings dsynth, with matching optimizations to fit dsynth running many parallel builds of ports.
My users@ post has the usual details on upgrading, as do the release notes.
Note that you will get some noise in dmesg until you remove opie from where it’s mentioned in /etc/pam.d/ files. It’s cosmetic unless you use opie, and you probably don’t. I mention it because I noticed it. Check /usr/src/UPDATING after pulling in the 5.8 source to see details of this and other changes.
Linked cause I always forget the right shell command for UTF-8, to reduce the amount of ???? ??? ??? ??????? ??.
daemon(8) has been updated, cause there’s ports that expect daemon to have some specific flags – especially -T.
There is a certain correlation between this utility and certain BSD logos.
If you’ve been following HAMMER2 for some time, these questions and answers will not be new to you – but they are useful notes all the same.
I imagine this may work for any BSD, really. Aaron Li has the instructions, which may be especially useful for non-English readers.
SEMIBUG’s next meeting is tonight, with Michael Lucas talking about SNMP. Go, if you are near.
I for some reason set line height properties in the style sheet for dragonflybsd.org years ago, and it made scroll bars appear around all <pre> text. It’s taken me years, but I finally removed it. Anyone notice other effects than the lack of those odd scrollbars?
It’s probably going to be quiet for at least a few days because of the Christmas holiday, though I’ll of course have the normal weekend features up.
In the meantime, here’s something to ponder: this post about tmux and plugins for it led me to thinking about plugins in general. The pkg system is sort of a plugin scheme for BSDs, much like apt for Debian, yum, etc. Each language has its own libraries to load and plugins to manage past that, like Perl’s CPAN. Nowadays, applications have their own plugins. For instance, a system with WordPress installed with PHP installed with PHP plugins required with WordPress plugins that also require given PHP libraries. WordPress manages keeping itself and its plugins up to date, but not the underlying PHP installation. You can get something similar with Perl along with the Perl-specific package updates, through cpanm. Or, npm, which seems to be its own world of constant flux.
How many levels could this go? Like running multiple emulators within each other, how many levels of plugin could you achieve? There’s probably a series of levels proceeding from tedious to barely maintainable to ridiculous.
The BSD.nrw Dusseldorf-Wersten BSD user’s group next meeting is on the 20th. Go, if you are near.
Synth logs for dports are now located here on a new machine:
https://sting.dragonflybsd.org/dports/logs/Report/
If there’s only a short list, it’s because the most recent build was probably focused on retrying a broken-but-now-possibly-fixed package. I link both because of the utility and also because the interface is pretty.
I sorta like seeing these things ricochet back and forth.
There’s been a fresh binary build of dports – and then some more updates to cover a variety of security issues in some of those ports. Now is a good time for a ‘pkg upgrade’.
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!
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.