sxan

Picture unrelated to question; built for style, not functionality. I've learned that the most efficient (and boring) platform design is a spear.

I think of all the planets, I like Fulgora the least. I have tried two or three approaches to dealing with the sushi belts of parts; my biggest issue is the monomanical logic of inserters, which -- given a storage chest of a dozen different items, seem to get stuck on one item for extended periods. For instance, unloading a train of random stuff, I'll get 15 inserters all pulling out gears for several minutes, ignoring everything else in the chests. It's frustrating beyond belief, so I think I'm not looking at this the right way.

The biggest issue is buffering. I'll get nothing but gears for a few hours, but then they'll dry up and I'll get nothing but low density structure for a few hours and almost no gears. If I were paranoid, I'd think the devs did this on purpose to maximize jamming.

What I'm going to try next is building a train system with per-item trains, or maybe cars, and see if that helps. Transport raw to an island, recycle it, and load up trains with product and send them to a big factory island. I suspect it's simply going to get jammed up at the recycling center and I won't be any further ahead, but maybe I can mitigate that by just having one, really long train that stops every 12 cars and every series of 12 cars has each car containing a single item.

I don't know. Fulgora just feels stupid, or makes me feel stupid. How do you folks handle Fulgora?

Update edit

I completely redesigned everything on Fulgora, and it doesn't get jammed, and I'm only having to "throw away" steel (the plate, not the girders; I'm not sure why the game calls "girders" "plate", but whatever).

My solution, as it is, is based on the suggestion of having a recycling plant rather than recycling at the miners. I'm using trains: I mine ore into trains and ship it to a recycling island, where the output is filtered into train cars - one type per car. I run the trains full of product to wherever I have factories set up, and pull specific items needed there. I avoid sushi belts and sushi boxcars; my production islands are consequently much simpler, and as yet I'm not having to waste product.

I will point out that I initially used recyclers to reduce the amounts out items, but found I had to keep changing what I was recycling because what was overflowing kept changing, and by recycling I was regularly running out of items; this, again, is related to whatever the RNG is doing to me. Honestly, I have a mind to actually keep a counter, because it appears as if I'll get a run of copper coil, where it's the dominant item mined for dozens of minutes, then it'll be blue chips, and so on, cycling through each of the items. It swamps me with one thing that I can't even manage with belt weaving, then suddenly that'll dry up and I'll get only a trickle of that thing for the next couple of hours. I've frequently had launches completely stop because I had to recycle one component to built rocket parts, and then it dries up and I have to built an assembler to produce the product until the RNG deems me worthy to have it start being a mined item again. If the cycle happened over a period of less than hours, I'd record it. Although, the fact that the inserters (almost) all get stuck on the same item pulling from sushi boxes, I could easily show. If I, of anyone else, cared enough.

In any case, with trains and enough storage boxes I have it set up to weather the droughts and floods of specific items, and am assuming either it's coded this way on purpose, or only doing it on my machine because I don't hear anyone else complaining about it.

This might be a client thing, but... I'm subscribed to several overlapping communities: !linux on one server, !linux on another, !linux on two others. Same with !lemmy, !commandline, and a couple other communities with the same topic and slightly different membership and/or focus.

Crossposting is a valid and useful tool, but I'm noticing an increase of crossposting where the submitter automatically crossposts to 4 similar communities at the same time. Seems reasonable, and yet... I'm starting to get annoyed by seeing the same post 4 or 5 times in a row. I sort by New and since the posting happens concurrently, they just spam my feed with a page of identical posts.

I could unsubscribe from some similar communities, but the content doesn't exactly overlap and I feel like this is solving the wrong problem. I could decide that automatic crossposting by the same author is "bad behavior" and downvote crossposts, but I feel like this solves the wrong problem and violates a valid use case.

What I think a solution might look like involves a unique ID that persists between crossposts, and a corresponding way to filter s.t. only one post is shown. Some communities are more active than others, and comments on a filtered crosspost would be invisible, so it would be necessary to aggregation crosspost comments, interleaving them under the single, unique, unfiltered post. All comments on all subscribed communities where the post was crossposted would be aggregated; replies to any specific comment would reference the comment in its source community and therefore show up in the right community, for folks who aren't subscribed to multiple duplicate communities.

It requires a more complex solution than it might initially seem. Whatever the solution, I feel as if something should be done, because there's an increasing noise-to-signal ratio resulting from increased crossposting.

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.

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?

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?