I just deployed my own forgejo instance on my private tailnet this week. I've had a ton of fun mirroring up to or down from github, I set up a devpi proxy for my python packages, and just generally "cleaned house" in my personal infrastructure. Delightful! Forgejo was an absolute breeze to install. I chose homebrew for installation and service management because I'm running on macos and I'm trying to avoid containers for key services (for no particular reason other than "it's my homelab and I'm gonna do what I want"). A few short lines in an app.ini and `brew services start forgejo` and it all just unfolded from there. Great job, forgejo team!

A quick search for "Audi recall" shows several recalls this year. Here's the first official link I found: https://www.audiusa.com/en/compliance/takata/

Not stupid at all. Definitely yes. Don't have the numbers on hand but it's orders of magnitude more CO2-equivalent released per kg-mile, especially when you factor in the fact that they are using methane.

Of course the reality is that this tech won't ever see adoption used that widely, but where is the break-even point?

Rocket launches emit less CO2 than a trans-pacific airline flight.

> CO2-equivalent

I think what they were trying to get at is GHG emissions in general which there are more of than just CO2.

Full flow staged combustion engines like Starships do not have significant un-burnt methane. They run slightly fuel-rich, but that results in extra CO emissions rather than CH4 due to the temperatures involve -- methane cracks at 1200C, Starship engine temperature is 3000C.

Starship's operations in Boca Chica do emit methane during ground operations. The mitigation for that is to use a pipeline rather than trucks for delivery.

Solid rocket motors emit all sorts of nasty stuff, like aluminum particles.

That's my thought as well. I predict we'll be seeing SDK's for generating github workflows by mid-2026. Maybe pulumi will get an extension for it. (I'm well aware that codegen yaml has been a thing for a long time, but I'm thinking about something targeting github workflows _specifically_.)

TBH it's getting a bit exhausting watching us go through this hamster wheel again and again and again.

Software is written with a context, and the context degrades. It must be renewed. It rots, sorry.

You said it's the context that rots.

It's a matter of perspective, I guess...

When you look from the program's perspective, the context changes and becomes unrecognizable, IOW, it rots.

When you look from the context's perspective, the program changes by not evolving and keeping up with the context, IOW, it rots.

Maybe we anthropomorphize both and say "they grow apart". :)

We say the context has breaking changes.

We say the context is not backwards compatible.

Can you see how this comes off as a pedantic difference? If I ran a program 10 years ago and it worked, then run it today and it doesn't work, we say the program is broken and needs to be updated. We don't say the world around it is broken and needs to revert back to its original state.

We do revert back to a previous context if that seems practical: revert back to a previous compiler or library version.

Definitely more of a fish vs zsh situation, in my opinion.

tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!

Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.

Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.

I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.

0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.

> Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things.

That’s been a pretty standard feature of tmux since forever.

In fact the reason I first discovered tmux was because some Irssi (terminal IRC client) plugins used tmux to create additional panes for Irssi.

tmux is one of those tools that does a lot more than most people realise but the learning curve is steep and features aren’t easy to discover.

Zellij looks interesting but these days I mostly use tmux as a control plane rather than a terminal UI. So the enhancements of Zellij are wasted on me.

As I understand it, these constellations are all low enough in orbit that stuff deorbits from atmospheric drag relatively quickly. I think you get a few years at most for these sorts of satellites.

The "Kessler syndrome" worst case scenario - I'm just recalling stuff from Scott Manley videos here - I think is a 'really bad decade' where a cascade of collisions makes launching in to LEO impossible until everything settles down in 10ish years. Bad, yeah, terrible even, but possibly worth it in some sense? I mean, it makes about as much sense to me as growing subsidized corn for ethanol gas, I suppose. I'm sure someone is making money.

Starlink: Yes. Kuiper: Not so much.

Well you have to have another core free to run your sick winamp skin, otherwise how will you keep up your K/D?

Your link says that A(r) still requires posting the jobs officially, though. It certainly seems like they skipped that. Also, the director lied.

The article implies they lied about having disabilities which is not true.

This carries more weight than failure to post a job properly.

I'm saying that they may still have done exactly that. If they were using A(r), they would have posted the job.

They either need to lie about posting the job officially or lie about having a disability. Why do you think one lie is more reasonable than the other?

In truth, I think getting an unscrupulous doctor to declare they all have ADHD or autism is probably their simplest option, if they’re at all trying to keep up appearances of doing things by the book (and they are, otherwise why bother with this Schedule A stuff at all?)

The point here, I believe, is that 1Password will only prompt you to enter the 2FA code if the domains match, same with the password. Your point that if you've already decided to enter your password then entering the 2FA code isn't much of a hurdle is sound, but from the perspective of a user of 1Password, it is indeed very surprising (and rare!) when I try to log in to a page and find that 1Password won't show my log in because the domains don't match. It happens, usually due to some cross-origin login flow, but it's rare. So I think the claim isn't false, it's just based on a premise that might not factor in for different people.

If domain doesn't match, password manager of choice will not suggest to populate credentials. In that case it doesn't matter if 2FA is saved by the password manager, or is managed on another device, because you won't have the chance to use the 2FA.

If domain doesn't match, and you manually copy the password, and login, you can as well manually copy the 2FA code.

> The point here, I believe, is that 1Password will only prompt you to enter the 2FA code if the domains match, same with the password.

Yes, same with the password.

So it is not an advantage of 2FA.