How many levels of plug-in can you find?

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.

HAMMER2 emergency space mode

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!

Colo upgrade for dragonflybsd.org, plus future

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.)

Disk encryption and non-QWERTY keyboard layouts

When you encrypt your DragonFly boot drive, initrd(7) is run to get your system online and able to accept a password to decrypt the drive.  So far, so good.  The initrd program is a minimal userland designed to be small, and it generally works.  However, it assumes a QWERTY keyboard.  If you’re Pierre-Alain TORET and normally use an AZERTY (in this case French) keyboard, that makes it difficult to type the decryption phrase.

It’s possible to patch a different keyboard layout into initrd, and he has documented just how to do that.

A new upgrade method

Remember my post about a new upgrade script?  tse, the author, has happily added in a bunch of suggestions.  I’m intermittently traveling and can’t do anything to test it for days yet – but I’d love to see others try it out.

The bugs issue tracking versions is here: #3197.  Can you, dear reader, try it out?  Do an in-place upgrade on your version, or even a test install with a VM?  I want to see what happens in the wild.