sxan

Something like this? The heavy stagger is great, 42 keys is almost perfect, but the thumb placement is -- for me -- horrible. Having to move my thumb to practically under my palm is just terrible ergonomics.

This thumb layout reminds me more of the ErgoDox variants, and is far better placement. Is there a layout close to this?

tjot is a terminal djot renderer.

Features

• Covers 100% of the Djot spec
• Reasonably fast:
  • pandoc -f djot -t ansi: 10 runs, milliseconds per run: [266, σ 270, 274]
  • tjot: 105 runs, milliseconds per run: [24, σ 26, 28]
• ANSI glyphs & escape codes for nice tables, task lists, and coloring
• Renders images, including SVGs
• Detects the terminal size (usually) for accurate wrapping
• Langage-sensitive highlighting for code blocks, and language detection

tjot is alpha; this is the first version that is useful. That said, it's fairly complete.

What is this?

djot is a markup language related to Markdown created by John MacFarlane, the author of pandoc. For a detailed explanation of why he invented djot, see this essay, but my interpretative summary is that he was unsatisfied with the complexity and size of CommonMark -- a result of trying to maintain compatability with Markdown -- and thought they could do better from scratch. djot was the result.

I've been using djot since late 2022, but as there (until recently) was no terminal pager for djot, I finally decided to write one.

To render djot documents on the command line, install tjot and call it with the path to a file, or pipe the file into tjot on stdin. Pipe the output to a pager such as less.

If the document references images via URL, those will be downloaded and rendered.

Limitations

• There are known bugs; see the end of the CHANGELOG for a complete list
• Ultimately, I want a pager. The current version only renders output; paging has to be provided by an external program
• Customization is non-existent
• While images are supported, rendering is via asci; there's no sixel, kitty, or other high-res rendering. SVG rendering, in particular, is of particularly questionable quality.

As usual, feedback is welcome, as are any reports of failures. Although this is an early release, the nature of the project is such that getting exposure to a wide variety and complexity of documents will help me improve it.

What with lemmy.ee closing.

It's a tad surprising he's survived all this time. While I had him, i

• Went through a term of active duty in the army
• went through college
• lived oversees for a few years
• lived in 4 different states, and twice as many apartments and houses

He's one of the few possessions I've managed to keep ahold of despite a fairly nomadic life, but now he's pampered.

Anyway, with the recent cartoon about merch, I'm wondering what other people have. I never got a t-shirt, and it wouldn't have survived until today if I had.

Has anyone ported, or recreated, urob's timeless homerow configuration for ZMK to Vial, or to vial-qmk?

I have a Piantor Pro, built by BeeKeeb; it is a QMK keyboard, and specifically uses vial-qmk. Vial, or flashing directly from the vial-qmk repo, is the only way I've ever successfully flashed or configured it.

I've never been able to use the homerow for anything other than layer switches because they're the only things I can put a long enough delay on that I don't get unintended modifier hits. urob's Timeless Homerow mods for ZMK looks like just the thing, but given my failure to flash the board with anything other than vial-qmk (including vanilla qmk), I'm assuming ZMK is going to be a no-go.

Is anyone who's a fast touch-typer using homerow keys for MACS with Vial, or vial-qmk, and if so, what's your magic sauce for avoiding mis-keying?

Edit 2025-05-19

I was looking at Paul Getreuer's very nice page mechanical keyboards, where he discusses homerow mods on a variety of firmwares, and it mentions using the *_T Quantum keys for homerow mods as being better than tapdance. Maybe it is, but it doesn't completele solve the mis-strikes; they're what I used when I hacked together my version of Miryoku for Vial. They were better, but not foolproof, and from reading urob's description, the ZMK mods go a lot further than Vial's *_T mods. So I'm still looking.

Quick followup

I went back and reviewed Paul's notes, and I'd had Permissive Hold disabled, because it'd brought me nothing but grief in other configs. After enabling it, my 5th run of typioca came away slower than normal, but not unacceptable:

Having only to focus on the new shift location helps; I slow way down when I need layer shifts or in environments like Helix, with heavy ACS and arrow key use. That'll improve with practice. I'm also still getting a lot of accidental layer shifts with those thumb keys, but I think I can fix that with a layer shift delay. I also do not like the repeat delay on some thumb keys that having the layers introduces; backspace, in particular, is a PITA. Again, I hope that this is fixable by tweaking the layer switch mechanism -- I may have to resort back to tap-dance for layers. The key win is that the home row modifiers seem to be working well, and that was my main blocker.

The upshot is that I believe, for now, that my question is answered. Hopefully this post will help someone else on the same journey.

Here's my Vial config. It's basic (not "programmer") Dvorak for the Piantor Pro, with home row mods and heavy right-hand dominant. It attempts to preserve inverse-T movements (arrows) and layer shifts on the right hand; I use a track ball, and use keyboard mouse movement only rarely, so that's a layer relegated to the left hand. There's a layer dedicated to switching to QWERTY, for games, that's not currently bound to anything; I used to have it bound to LShift+RShift, but I'll need to find a new home for it since that's no longer possible. I'm attaching it mainly as an example that's working for me.

Rook provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 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 AUR and in Alpine community (a MR has been submitted for the new version); binaries are available from the project page.

There have been several releases since my last announcement for v0.2.0, 7 months ago. The major thing is that I've added built-in support for the Linux keyring, which makes it much easier to use; since it improves security, I'm hoping this will encourage users to use the feature.

Here are the rest of the changes, collapsed for brevity:

Added

• built-in support for the kernel keyring on Linux.
• Go 1.24 landed in Alpine, so off we go!

Changed

• autotype and getAttr now detect if keyctl is available and in use, and automatically uses it to get the pin. (which should be superceded by ---keyring)
• the kernel keychain instructions are now independent of external environment variable management, such as herbstluftwm
• Use Go 1.24's go tool for manpage generation, via go:generate.

Fixed

• --keyring may not be used with open; this is now prevented, and documented. It never worked, but it would be seen by the server as on open failure.
• --detach and -P didn't play nicely; now they do
• URLs in the README (thank, mlc-man!)
• getPassword() was prompting on STDOUT, which is bad for piping the pin
• --detach never worked
• logging was going to stdout
• some log messages were not being logged, but just printed out
• PIN authorization had a lot of bugs
• build assets now contain man pages & other documentation, and arch image CI is fixed

Is T-Mobile Fiber (in the US) friendly to Wireguard, or am I going to have blocking issues?

T-Mobile is installing fiber throughout our neighborhood. While I'm not a huge fan of T-Mobile, I actively loath Comcast, and that (or DSL) are currently our only options. At less cost for guaranteed Gb up/down, it's a no-brainer switch.

Except that we're always on VPN. I've got a perma-connection through Mullvad on the router, and a bypass for VPN the company my wife works for uses; there's no unencrypted anything going through the network provider. Comcast has never been an issue, but before I go through switching to T-Mobile it'd be nice to confirm that they aren't going to try to block VPN traffic.

As in the title, it's Wireguard; does anyone use anything else anymore? Don't answer that; it's rhetorical.

Can anyone in the US confirm they're successfully using Wireguard on T-Mobile Fiber?

cross-posted from: https://lemmy.world/post/29327391

I liked the "vintage" comment, so going back even further to Bakshi's inspiration for Avatar.

I've read that Bakshi tried to get Bodé to collaborate on Wizards but it didn't happen so he just did his own version. I can't find that source again; I'm pretty sure it was in a biography of Bodé, though.

In any case, the homage is clearly evident.

So I have been trying to beat shattered planet, trying various things. One thing I've tried is throttling by cutting off engine fuel to engines based on damage taken, on the theory that the slower the platform goes, the fewer asteroids it has to deal with. I have a big, 6 ending platform that runs between a max of around 190, and can throttle down to about half that by shutting down all but two engines.

To my eye, it doesn't seem to make any difference in asteroid density. It just takes longer, with the end effect of using more ammo to go less distance. Coming to a complete stop, of course nearly shuts off the flow.

So now I have it in my head that controlling velocity doesn't affect asteroid speed or volume, which would suck.

I also can't get interrupts to work properly, and nearly stranded my platform before I noticed :-/ But that's a different post.

Anyway, is velocity affecting asteroid density, or not?

Update, 2025-04-22

Thanks to everyone who had suggestions; I used most of them:

• Use foundries. This had the single biggest impact. I always forget about foundries except on Vulcan.
• Use lasers for little asteroids. Foundries are only an option if you have fusion, and if you have fusion lasers start to make sense. I'd given up on them when I tried to build a nuclear + accumulator platform, and was quickly annihilated, but they become useful later.
• Rail for huge, rockets for large, guns for medium, lasers for small. This is the magic formula for me, although I also have some logic that switches rails to include medium if rockets get low; rockets seem to be the bottleneck for me.
• Quality lasers are really effective for small asteroids -- even just quality 2.
• 1 fusion reactor is not enough. I was a little surprised that fusion is so wimpy compared to nuclear, but with lasers and foundries, I was getting into spots where I didn't have enough energy to keep the fusion reactor running.
• I have a bunch of logic controlling speed. This is a critical factor in success.
• I'm processing Promethium on the ship, rather than trying to use it as a cargo. This is much more effective, but requires all that logic.
• I'm not using interrupts. I don't know why I didn't notice before, but the Shattered Planet has "turn around when" logistics instead of the normal planet logistics.

So, now I load up on everything, hitting Nauvis last for one load of eggs. Then I make a speed run (175km/s max) for the shattered planet. As soon as I detect that I have shards, I cut speed to about 60km/s and cruise for shards, processing eggs to Promethium packs. As soon as I'm down to about 50 eggs, I turn around. I still have a couple hundred shards by the time I cycle around to Nauvis again, which gets me a few extra packs. This gives me about 300 packs, per run.

There's a bunch of extra logic to throttle based on damage and/or ammo levels, and where I am in the system -- I run at 50% on my way back to the edge, because otherwise I inevitably take damage running full speed at the turn-around point. With this set-up, it's fully automated, I can make the run with no damage, and I am able to process all of the eggs before any spoil. At this point, I think most of the ammo management -- designed before I converted to foundries -- is unnecessary. I just need to hang out a bit before heading to Nauvis to let missiles stockpile, and I don't think ammo has throttled speed lately.

Egg management is a pain, and there's more logic to make sure there are no unprocessed eggs in the cryo factory or on the belt; I used to toss them overboard, but found it was faster to run them through a recycler until they're gone -- there are never more than 9 left over, anyway, and that's really just in case I get a late batch from Nauvis and a few spoil on the way such that I end up with an odd number at the end.

Ok, Lemmy, let's play a game!

Post how many languages in which you can count to ten, including your native language. If you like, provide which languages. I'm going to make a guess; after you've replied, come back and open the spoiler. If I'm right: upvote; if I'm wrong: downvote!

Bonus question: do you ever do your counting in a non-native language, just to make it more interesting?