I'm also curious if it stopped after that goal or if it kept playing.

In a different vein, another thing TLA+ isn't great at is modeling atomics and in particular weak-memory semantics or anything that's not sequentially consistent. If you translate your algorithm to pcal, it will run as if it was sequentially consistent. If you need to model non-sequential-consistency, then that needs to be spelled out with explicit logic to TLA+, which is probably too complicated and error-prone to do by hand. The C/C++/Rust memory models permit a lot of wacky stuff. I imagine you need to add read caches and writeback buffers for each variable with cache-flushing instructions at appropriate points, but maybe there is a more elegant way to do it.

If you use rust, miri and loom both have analyzers that can check some non-sequentially-consistent behavior (and loom doesn't actually implement sequential-consistency at all).

https://www.cnbc.com/2026/09/29/trump-ai-gemini-grok.html

The other line items are probably similarly unrealistic since they include their own launch costs as well.

They also spec 300 racks of 500kg each, which is <40% of the weight of the comparable land rack. I doubt the full weight reduction since the racks still need to survive launch force/vibration in addition to fluid/pressure enclosures that land racks don't require. I think it's likely that just about every part of this report has a similarly cooked numbers, and we can just throw the whole thing out.

These conversations get frustrating since one group is saying the dancing is bad, a second group is saying it's good (for a bear), and a third group is saying we are a few years from a bear-only dancing industry.

Bilbo's house is actually described in The Hobbit and the exterior isn't really described at all in Fellowship. The prologue of Fellowship (Concerning Hobbits) mentions hobbits like round doors and windows and the fact some hobbit homes are underground, but the turf-dome design here is not mentioned. It actually mentions hobbit homes typically have bulging walls, so unless you've read the The Hobbit, you might not picture this entirely-underground style.

In The Hobbit, his home is described as a (nice) hole in "The Hill" with a perfectly round front door and round windows, which could imply the design here.

Are there any projects on codeberg that are getting banned and actually have significant human interest?

If codeberg decided to kick out spammers, nobody would decry the loss, so what's being lost here? Is it strictly slippery slope?

The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.

A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.

    static JsonObject of(Map map);

    static JsonObject of(Map map);

It does seem like any serious application is going to use another library, and this will be useful for very simple json usage or single-file hello-world type programs (e.g. to go along with Implicitly Defined Classes and the Flexible Launch Protocol).

All the surrounding systems still run at full speed. You can travel large distances and still arrive soon enough to matter in the fight. You can also die, respawn in another system, rejoin the fight, and barely miss anything. The positions in the fight therefore move even slower than time-dilation since ships on both sides are replaced so quickly.

Large groups have a massive advantage over small groups, so alliances are very large and join various alliances-of-alliances. The playerbase is often organized into only 2-3 major coalitions. At some points in history, nearly all the alliances have joined the same coalition, which leads to a strange pax-Romana called the "blue donut" (referring to all the ownable outer-systems being "blue" or allied with each other).

Also, nearly every player in a large fight just follows simple orders. Orbit A and shoot B. There are just a few people calling the shots.

Fights sometimes end just because people are bored, need to sleep, or go to work.

If you use ordinary READ COMMITTED transactions, they will advance their xmin horizons on each query (and allow old version cleanups) up until their own transaction id but unfortunately not beyond that. For a given table, this is important since that transaction is uncommitted and it might modify the table. If you could make long-running transactions readonly on those specific tables, then you could use a different xmin horizon specifically for those tables. It would require a lot of duplicative bookkeeping in shared memory though. You could probably fake this today by using 2 databases on the same machine and using two-phase-commit+dblink/fdw for cross-database transactions/queries (fdw uses repeatable read in transactions, so it won't allow the xmin to advance).

It seems like most customers are returning the oven, which would normally be an extremely strong signal that there is a quality problem. In the SaaS world, the equivalent would be churn, but it's not always as straightforward since if users quit before they sign up (e.g. by reading a review or using a free trial), then they don't show up in that metric.

This could all be optics as well to try to give the appearance of a defensible moat. E.g. they can claim to investors that they are able to protect a significant chunk of their intellectual property this way. I'm not sure if anyone has a study about how significant the summarization is to distillation.

1. No overlay networks. 1 IP per machine. pods use dynamically allocated ports, and the kubelet enforces pods listen only on their assigned ports using seccomp.

2. No kube-proxy or equivalent Layer-4 "load-balancer". It's not good, but it's often used. You should use some kind of Layer-7 load balancing instead. Also you need to look up the port number from (1). This also greatly lessens the need for DNS.

3. A better config language. YAML and helm templates are terrible. kustomize is built into kubectl, but it's frustratingly limiting and also still very complicated. Something like nix would have been great. This can make it easier to upgrade third party configs since you can have more logic to validate and merge your settings with upstream defaults or templates.

4. Maybe an EBF-like for the api server? If the built-in k8s objects don't have a setting for something, then you need to write an operator or control loop yourself and then run that too, which is a big lift. Over time, k8s just keeps adding more and more built-in things and then revising them, which creates a ton of churn. If you could easily script simple operations, then they wouldn't have to build in every permutation ahead of time. E.g. the HorizontalPodAutoscaler has 24 config object types with several fields each, but all it does is set replicas based on data read from the api-server, so it could be replaced by some kind of flexible script that runs in the control plane.