Badabinski

For future reference, you should remove set -euo pipefail and then add manual error handling to all commands which could fail. set -euo pipefail is one of the biggest, most disgusting foot guns in bash (a shit language cursed with many horrible foot guns) and does nothing but mask your problems. If every command has a unique error message, then you can much more easily track down your problems.

To make things more ergonomic, remove the foot gun and add a die function that accepts an error message and optional exit code and calls it like this:

echoerr() { echo "$@" 1>&2; }

die() {
  message="$1"; shift
  exit_code="${1:-1}"
  echoerr "$message"
  exit "$exit_code"
}

fallible_command || die 'shit is so fucked yo'

source: bash was my first language and I’ve been dealing with its bullshit personally and professionally for over 13 years now.

I’ve got a Brocade ICX6610 that’s been quite nice.

well that’s no fun!

Only possible AI thing I see is .zed in the .gitignore, but that’s not an indicator of LLM usage. Plenty of people use zed with all AI features disabled.

In the context of “upping the ante”, it’s been used since at least 1870: https://nosweatshakespeare.com/quotes/famous/up-the-ante/

I’m guessing that people took the phrase “ante up” and switched it around.

EDIT: I did check the source out a bit and they seem to be legitimate, not just LLM slop. They could still be wrong, but they do at least cite sources.

Senior software dev here at a company you know of. I was forced to use Claude for a week at my job and it was absolutely miserable. I hate LLMs and don’t use them in any way, shape, or form. I do spend a lot of time cleaning up the fucking slop written by some of my colleagues who have no qualms about unleashing them on our codebase which is already bursting with tech debt.

Like, it’s gotten to the point where I check potential new dependencies for AGENTS.md/CLAUDE.md/Claude as a commit co-author/.cursor in .gitignore before I use them. It’s obviously not possible to avoid using code written with LLMs, but I’ve had too many fucking problems at this point, so I’m going to try.

That’s the route I took. I still pray for a nice Home Assistant helm chart because I’d really like to be able to quickly bounce a Home Assistant container around between nodes and also have easier monitoring and alerting, but all the k8s options just seemed too jank.

If the benchmarks are to be believed, it’s much, much faster than juicefs.

One kinda scary thing is that for use with NFS, all writes are basically unsafe. The server says it has committed everything to disk immediately.

I love my XL. It’s been the best printer I’ve ever owned.

Nah, it’s really not necessary. I’m senior dev at a large software company you’ve absolutely heard of and I’m just as productive as my colleagues who use LLMs. My tasks usually take fewer PRs as well, since there are fewer bugs that need to be fixed.

I still don’t understand why people are foaming at the mouth about LLMs. They’re fucking awful at writing software.

Is your container using BusyBox? if so, then it’s not even real wget, it’s just the disgusting awful busybox version.

God I hate BusyBox.

I have one of these too. I believe the model is the Cuisinart PerfecTemp. I’m very fond of mine, it’s pretty fast and the keep-warm feature is great for ADHD ass people like me.

The segmented caching request thing is… weird. I worked for a company that developed a caching proxy and it very much did not work that way. Like, random access in a caching system is usually kinda bad and you should try to avoid it. Like, our proxy manually controlled the disk (it wasn’t a mounted filesystem) so it could constantly sweep the head across the disk and cue up reads and writes optimally. This gets much harder when things are fragmented as fuck.

If the concern was about what would happen with multiple connections for the same cache miss, then the caching proxy should just combine the client-side connections into a single upstream one. You can still cache the first part of the response if your upstream connection gets terminated and then restart it from that point.

ASA can still warp, but an enclosed and warm build chamber should do a lot to squelch that. Are you printing on an open bed slinger? Or do you already have a build chamber?

Where’s the CVE? Was there an attempt at responsible disclosure? Was confidentiality breached? Did they coordinate this release with the devs like the dirtyfrag people did? This “announcement” doesn’t answer any of these questions and I am frustrated by it.

EDIT: Ok, there IS a CVE: https://security-tracker.debian.org/tracker/CVE-2026-46300

There are far more bountiful resources to be found, including GitHub issues with concrete examples. I picked that one because I know that all four of the companies listed are problematic. I do not currently have the time to find more detailed links, but they’re out there.

Here’s just one sample that came up when I searched for “3d printer GPL violation”

https://www.th3dstudio.com/2018/04/05/gpl-violations-in-the-3d-printer-community-creality-anet-tronxy-zonestar-and-others/

If you get some PETG V0 or ABS V0, that will be perfectly safe and probably up to code. That shit can self extinguish when it catches on fire.

I’m here for it.

These other responses are annoying. This looks really cool, and I hope that it works well for you and your friends! We definitely need good discord alternatives ASAP, and more options are better imo.

One cool feature would be some sort of official support for interop/bridging to other services. That might help to boost adoption and would make the “why not just contribute to Y” people be quiet.