offbyone

"jobs that are long-running might get rescued even if the producer is still alive" indicates otherwise. It suggests that jobs that are in progress may be double-scheduled. That's a feature that I think shouldn't be gated behind a monthly pro subscription; my unpaid OSS projects don't justify it.

Ooof. I don't mind the OSS/pro feature gate for the most part, but I really don't love that "Pro version uses smarter heartbeats to track producer liveness."

There's a difference between QoL features and reliability functions; to me, at least, that means that I can't justify trying to adopt it in my OSS projects. It's too bad, too, because this looks otherwise fantastic.

If you happen to nominate or vote on the Hugo Awards, you may have seen this turn up.

Self-hosting breezewiki -- even on the same machine that you browse from -- gets neatly around the way fandom wikis block the breezewiki public nodes. I've got it self-hosted and now I never see that damn fandom interface.

Well, this is delightful; the links that this tool finds now 403, and looking at the network inspector, it seems that the URLs are now signed in some way.

I was your opposite number at AWS for many years. Like you say, it was one of the best jobs I've ever had, but over there it was a career dead end. I wasn't laid off, but I had to leave it to have any hope of growing myself.

I feel for ya, zem; if you ever turn up at a PyCon in person, lemme buy you a drink.

I had the distinct pleasure (?) of owning the C++, Python, and Java implementations of that config for a while and ... yeah, it had some positives, but the fact that it had two orthogonal hierarchies of configuration in addition to implementation-specific feature gaps and nuances made it something of a nightmare in practice.

The article is interesting in general, but this line really needs more than "works like a charm": `usb_modeswitch -W -v 12d1 -p 14fe -K -P 14ac -M "55534243000000000000000000000011060000000000000000000000000000"`

I mean, I believe you, but ... what on earth IS all of that?

I have been fortunate enough to land in a part of my employer's technical culture governed -- roughly -- by this sort of idea, albeit not one that's written down anywhere. The people in the Slack channels (IRC, back in the day, but time marches on...) that I frequent are the ones who provide some of the backchannel cross-team communication and technical analysis that make our company work.

I like this article a lot; if I were trying to replicate the community I've got now, I'd probably start with this.

Probably just delete.

Especially if it's the one I'm thinking of, too. It's a damn solid architecture.

I love build tools, and work with them professionally, and this tool seems to be getting one thing quite right: it is not injecting itself into the dependency resolution process. Where I see build tooling fall down is where they try to replace the idiomatic dependency modeling tools that exist in each language.

The build logic and CLI experience looks to be well thought out. I really like the native sandboxing support and the intentional exclusion of the calling environment. There's a lot of polish here.