It is not my intention to ignite an EMACS/vim war; I will say that I find it baffling that Lower Decks is ending while Strange New Worlds is being continued. I like Strange New Worlds, despite disagreeing with some of the artistic licenses being taken. But if I had to choose between the two shows, it'd be no contest. Not only as a viewer do I prefer LD, but it has to be the cheaper show to produce. The fact that next season is the last (both by design, it only being contracted for 5 years; and announcement) is sad and incomprehensible in the same way the cancelation of Firefly was - except LD is popular and successful, whereas Firefly merely had a fanatical (🖐️) fan base.

I don't understand it. Yes, you want to end on a high note. Maybe the writers are running out of plot ideas. Perhaps, given an initial life span of 5 years, the actors have all made other arrangements and aren't available. But I just can't believe the One Big Plot Arc that's been building would necessitate ending the series by its resolution.

LD is a strong show. It's lighthearted. It's a breath of fresh air after the more decidedly darker, ethically challenging, and emotionally straining runs of TNG, Voyager, DS9. And Strange New Worlds... the Gorn are basically Xenomorphs from the Alien franchise.Who, despite being the existential threat of the show, somehow get entirely forgotten about by the time in TOS.

But I digress. I'm going to miss Lower Decks, badly. How can this happen? And why?

This is kind of a rant, but mostly a plea.

There are times when BusyBox is the only tool you can use. You've got some embedded device with 32k RAM or something; I get it. It's the right tool. But please, please, In begging you: don't use it just because you're lazy.

I find BusyBox used in places where it's not necessary. There's enough RAM, there's more than enough storage, and yet, it's got BusyBox.

BusyBox tooling is absolutely aenemic. Simple things, common things, like - oh, - capturing a regexp group from a simple match are practically impossible. But you can do this in bash; heck, it's built in! But BusyBox uses ash, which is barely a shell and certainly doesn't support regexp matching with group capture. Maybe awk? Well, gawk lets you, with -oP, but of course BusyBox doesn't use GNU awk, and so you can't get at the capture groups because it doesn't support perl REs. It'd be shocking if BusyBox provided any truly capable tools like ripgrep, in which this would be trivial. I haven't tried BB's sed yet, because sed's RE escaping is and has always been a bizarre nightmarish Frankenstein syntax, but I've got a dime riding on some restriction in BB's sed that prevents getting at capture groups there, too.

BusyBox serves a purpose; it is intentionally barely functional; size constraining trumps all other considerations. It achieves this well. My issue isn't with BusyBox, it's with people using it everywhere when they don't need to, making life hell for anyone who's trying to actually get any work done in it.

So please. For the sanity of your users: don't reach for BusyBox just because it's easy, or because you're tickled that you're going to save a megabyte or two; please spare a thought for your users on which you are inflicting these constraints. Use it when you have to, because otherwise it doesn't fit. Otherwise, chose a real shell, at least bash, and include some tools capable of more than less than the bare minimum.

I know it's tragically pedestrian; and I know there's supposed to be a 4 in 2025; and I also know there's many a slip twixt cup and lip, and the gaming industry is going through some pretty radical changes... but all I really want is another Borderlands.

There's not much they can do with it, not many places to go, and I'm sure everyone who's worked on the series over the years is thoroughly sick of it. But, damn. Every one of the main games (at least; I haven't loved every in-between spin-off) has his a sweet spot of mindless fun, funniness, and replay-ability. I've played 3 so many times through, and spent so many hours just running around in every location, even I can't work up much enthusiasm to fire it up anymore.

There's an occasional game that fills the same niche; Bullet Storm was pretty fun, but with low replay-ability. I just want a game where I can turn off the higher brain functions and run around killing stuff in interesting ways.

Thanks for attending my Ted Talk.

Rook provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass v2 kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless, and does not have a bespoke secrets database full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

Rook is in the AUR; binaries are available from the project page.

From the changelog, since the last Lemmy release announcement (v0.0.9):

[v0.1.3] Mon May 20 17:12:25 2024 -0500

Added

• status command, a more lightweight way of testing if a DB is open. Using this instead of info in e.g. statusbar scripts greatly reduces CPU load.
• case-insensitive search.

Changed

• removing some nil panics that could occur when DB is closed while a client call is being processed.

Fixed

• a hidden bug in the OTP pin code.
• some errors being ignored (and therefore not logged)
• TOTP attributes getting missed by otp generator check

[v0.1.2] Fri Apr 26 15:13:55 2024 -0500

Added

• one-time pin soft locking
• installation instructions for distributions that have rook in a repository
• more of the special autotype {} commands are supported (backspace, space, esc)

Changed

• getAttr adds a little delay before typing, allowing initiator tools (like rofi) to close windows before text is output
• cleans up code per golint/gochk

Fixed

• an autotype bug in outputting literals

[v0.1.1] Sun Mar 17 13:44:54 2024 -0500

Added

• the original source rook.svg
• ability to start the rook server passing in the password via stdin pipe.

Changed

• assets moved to directory
• documentation referenced Keepass v4; there's no such thing, it's v2.
• license, was missing (c) from original
• stop trying to remove the version number from build assets
• documentation to clarify when the master password exists as plain text, in response to questions from @[email protected]

[v0.1.0] Fri Mar 15 14:03:25 2024 -0500

Added

• nfpm file
• logo

Changed

• clears out the password so it's not being held in plain text by the flags library.
• some of the documentation, and fixes the duplicated v0.0.9 entry in the changelog.
• CI build targets are more limited, but also include some distro packages
• better README documentation

Removed

• the monitor attribute was taken out, as rook no longer busy-polls the DB

Rook is a lightweight, stand-alone, headless secret service tool backed by a Keepass v2 database. It provides client and server modes in a single executable, built from a reasonably small (auditable) code base with a small and shallow dependency tree - it should not be challenging to verify that it is not doing anything sketchy with your secrets.

Reasonable auditability, the desire to use KeePass files, and to do so through a headless tool that doesn't spawn off the better part of a DE through otherwise unused services, were the main motivations for Rook.

You might be interested in Rook if one or more of these are true:

• you use KeePass v2-compatible tools to store secrets already
• you are not running a DE like KDE or Gnome (although Rook may still be interesting because of secret consolidation)
• you prefer to minimize background GUI applications (KeePassXC is excellent and provides a secret service, but doesn't run headless)
• you run background applications such as vdirsyncer, mbsync (isync), offlineimap, or restic, or applications such as aerc that can be configured to fetch credentials from a secret service rather than hard-coded in a config file.

Pre-built binaries for limited OS/archs are built by the CI, and Rook if available in AUR. There's an nfpm config in the repos that will build RPMs and Debs, among others. I consider Rook to be essentially free of any major bugs and fit-for-purpose, although I welcome hearing otherwise.

Utility scripts in zsh and bash are available for providing autotyping and entry/attribute selection using xdotool, rofi, xprop, and so on; these are YMMV-quality.

Changes from v0.1.1 are:

Added

• one-time pin soft locking
• installation instructions for distributions that have rook in a repository
• more of the special autotype {} commands are supported (backspace, space, esc)

Changed

• getAttr adds a little delay before typing, allowing initiator tools (like rofi) to close windows before text is output
• cleans up code per golint/gochk

Fixed

• an autotype bug in outputting literals

Update

On a whim, I tried searching YouTube instead of search engines and found a short video which led me to this shop in Etsy. It looks quite promising, so I'm going to update the title as "solved."

Original post

I've had an Elektra Micro Casa Leva for a number of years, and a while ago I bought a naked portafilter for it. It was (and still is, on the product site) as "for the Micro Casa." It is, without a doubt, one of the poorest quality things I've ever bought. The wood appears painted, not stained; it's been resistant to oiling, and lately the paint has been flaking off leaving what I assume is cheap pine. The wood itself has been cracking and splitting. The portafilter itself is painted to look like brass; I can tell this because that paint has started chipping and peeling. It looks as if it's some type of steel underneath -- I'd suspect aluminum, except for the weight and I assume the maker would be concerned about having one literally melt on a user. In any case, it's horrible. The handle is not screwed in, or else it's screwed & glued; if the metal weren't so obviously crap, I'd consider routing out the handle and replacing it myself; as is, it's so poorly made it hardly seems worth the effort. Regardless, I've been using it for a few years and it hasn't outright broken yet, but with all the paint chipping and peeling, it's looking really rough, and you don't own a Micro Casa Leva for the convenience.

The Elektra takes a non-standard 49mm portafilter, which can make finding parts challenging. Is there a company that makes decent portafilters that fit the Leva? It's possible I simply haven't delved the depths of the web deeply enough. Or, is there a craftsman in the community who does this sort of work -- making nice handles, sourcing appropriate baskets, etc? Failing all of that, is there a place I can buy a naked portafilter of good quality for the Leva, and is there anyone making good handles for portafilters? I'm no craftsman, but I can manage sanding wood to fit a hole, and I can mix epoxy.

What I'd really like to end up with is a brass portafilter with a beautiful wood handle with a nice grain and stain. I'd settle for a naked portafilter for the Leva that isn't a cheap piece of garbage.

cross-posted from: https://midwest.social/post/9890016

Rook, a secret service backed by Keepass 4.x kdbx

Howdy Lemmy,

I'm announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless and does not have a bespoke secrets database, full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there's no malicious code is a critical trait for a tool with which you're trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn't yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I've been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.

Howdy Lemmy,

I'm announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless and does not have a bespoke secrets database, full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there's no malicious code is a critical trait for a tool with which you're trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn't yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I've been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.

I assume this is QMK, because changing the settings clears or introduces the issue. I'm using Vial for the programming/configuration.

I have a key configured tap-dance, like many others: - on tap, and ctrl on hold. The issue is that most of the time when I type something like -p, I get only the -. Then, the next time I type p, I get 2 of them. So something like this will happen:

I type foo -p bar baz, but don't notice the p is missing until after baz, cursor left and type p again, and end up with -pp

Most of my keys are tap-dance of some pattern: on tap, layer shift in hold, on tap-hold. I've noticed this buffered character after - on other characters; it isn't just p. Changing the timeout does affect the frequency, but doesn't entirely eliminate it. I haven't noticed it on any other combo, although they're all of the same pattern; it seems to be only happening with the -/ctrl tap-dance. Removing the multitap on - eliminates the issue.

This is my first QMK. I'd been using an Ergodox for years, and kmonad on my laptop for a year or so, although I recently switched to kanata (fantastic piece of software, incidentally), so I'm more or less familiar with the world of layers, multi-tap/tap-dance, combos, and so on. This one has me stumped, though.

I've checked and there's no combo defined that involves dash. I've never created a QMK macro, but it occurs to me that I didn't check if there are any defined.

Does anyone have a suggestion of how I can debug this? Could there be some bug, some bit that I accidentally set, that's causing this? Is there some QMK feature that does exactly this thing, and I've somehow enabled it? I've power cycled the keyboard, although I haven't yet tried a hard or factory reset.

Any ideas would be appreciated!

Edit corrected "multi-tap" to "tap-dance", as QMK calls it the one thing and not t'other

I've been looking around for one; search (in my Lemmy client) doesn't find one, and while there seems to be at least one in Reddit, the only communities listed on qmk.fm are Reddit and Discord.

Is there a good place to ask questions in the Fediverse?

I have been using a piantor built for me by beekeeb.com, and am enjoying the more agressive stagger than my previous Ergodox. However, my typing experience is being spoiled by how tight the key spacing is. I have large hands, and can span an octave on a full-size piano; the Piantor is downright cramped.

In looking for a possible replacement (the Kyria was my primary option, but I guess splitkb.com has entirely given up on selling pre-builts, and I don't solder), what should I be looking at for specs to get some wider spacing on the keys? Is it simply "key spacing?"

Most commercial keyboards are fine; my prior was an Ergodox and the spacing was fine. The Piantor supplies that - it might even be a touch too much, but it's still better than the tepid stagger on the Ergos.

What are the terms for language anachronisms?

I had a conversation about a year ago with someone about anachronisms in language. We both felt that there were terms for these things, but could neither recall nor find (via web search) satisfying answers. This came up again recently in a different discussion in a Lemmy community, and it's driving me a little nuts. Help me Linguistics-Wan Kenobi; you're my only hope.

So we have the term "skeumorphism," which refers to oramental anachronism. I may be using "anachronism" incorrectly, but it's the hammer I have. Skeumorphisms, in computers, refer to the graphical representations of things, but not the underlying concepts. There are similar linguistic anachronisms that I feel also have specific labels:

• "disks" which are still in use, but are largely being replaced by solid-state, rectangular SSDs; but most people still call all persistent storage devices "disks."
• "film" to refer to movies, regardless of the media (increasingly digital and having nothing to do with film).
• "rice" to refer to the process of fancifying something, like computer desktops
• "desktops" to refer to computer GUI window managing interfaces
• "files" and "folders" in computers

Are these all the same category of things? Is there a term for them?