Remember it's not just about pornography. It's anything deemed "harmful to minors" including platforms like Reddit, Bluesky or stuff conservative lawmakers think is harmful like discussion forums for LGBTQ people, sexual health information or dissident political opinions.

They also examine how these laws, which are often backed by the religious Right, are getting support more broadly from people who see it as a way to rein in Big Tech who are creating "social media addiction" and so forth.

And even within our industry there is a lot of money to be made by creating and selling compliance products, so even on forums like this you will find people advocating for them.

"Another Internet Law That Punishes Everyone" - Power User Podcast 1/9/26: https://www.youtube.com/watch?v=8bnp3nmpK9g

They said their /v1/prefixes endpoint has this snippet:

  if v := req.URL.Query().Get("pending_delete"); v != "" {
      // ignore other behavior and fetch pending objects from the ip_prefixes_deleted table
      prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
      
      [..snip..]
  }

The immediate problem of course is this block will never execute if pending_delete has no value:

  /v1/prefixes?pending_delete   <-- doesn't execute block

  /v1/prefixes?pending_delete=true   <--- executes block

  /v1/prefixes?pending_delete=false   <-- wrongly executes block

So, while there's plenty to criticize on the testing front, that's first and foremost a basic failure to clearly define an API contract and implement unit tests for it.

But there's a third problem, in my view the biggest one, at the design level. For a critical delete path they chose to overload an existing endpoint that defaults to returning everything. This was a dangerous move. When high stakes data loss bugs are a potential outcome, it's worth considering more restrictive API that is harder to use incorrectly. If they had implemented a dedicated endpoint for pending deletes they would have likely omitted this default behavior meant for non-destructive read paths.

In my experience, these sorts of decisions can stem from team ownership differences. If you owned the prefixes service and were writing an automated agent that could blow away everything, you might write a dedicated endpoint for it. But if you submitted a request to a separate team to enhance their service to returns a subset of X, without explaining the context or use case very much, they may be more inclined to modify the existing endpoint for getting X. The lack of context and communication can end up missing the risks involved.

Final note: It's a little odd that the implementation uses Go's "if with short statement" syntax when v is only ever used once. This isn't wrong per se but it's strange and makes me wonder to what extent an LLM was involved.

"This guy was able to vibe code a major thing" is exactly the reason they hired him. Like it or not, so-called vibe coding is the new norm for productive software development and probably what got their attention is that this guy is more or less in the top tier of vibe coders. And laser focused on helpful agents.

The open source project, which will supposedly remain open source and able to be "easily done" by anyone else in any case, isn't the play here. The whole premise of the comment about "squashing" open source is misplaced and logically inconsistent. Per its own logic, anyone can pick up this project and continue to vibe out on it. If it falls into obscurity it's precisely because the guy doing the vibe coding was doing something personally unique.

* SCREEN Act age verification with huge implications for all online privacy: https://www.youtube.com/watch?v=8bnp3nmpK9g&list=PLu4srHCWJr...

* Abolishing Section 230, the law that protects platforms like this from being sued for user content (just published today): https://www.youtube.com/watch?v=_eqt8vrtP-U&list=PLu4srHCWJr...

* UK online safety act (it's not just the U.S.) - interview with the lawyer defending 4chan: https://www.youtube.com/watch?v=DD3PGp9RhTw&list=PLu4srHCWJr...

Repeating unsupported claims and declaring yourself the winner does not, it turns out, actually help you win an argument.

That you point to the Mars rover, a mission with extremely budgeted power requirements, as proof of how soiling doesn’t pose an impediment to mega scale desert solar farms, only underscores the flaw in your reasoning.

[1] https://www.sciencedirect.com/science/article/abs/pii/S22131...

That's incorrect. Lasers can suffer from atmospheric interference and fogging on earth.

Here is a post from NASA explaining why they like laser communications better than RF in space.[1]

[1] https://solc.gsfc.nasa.gov/modules/kidszone7/mainMenu_textOn...

You claimed it was already a solved problem thanks to wind, which is false. You are unable to provide any source at all, not even a controversial one.

And that's just generation. Desert solar, energy storage and data center cooling at scale all remain massive engineering challenges that have not yet been generally solved. This is crucial to understand properly when comparing it to the engineering challenges of orbital computing.

And you still haven’t provided a source for your claim.

[1] https://www.nlr.gov/news/detail/features/2021/scientists-stu...

Space changes this. Laser based optical links offer bandwidth of 100 - 1000 Gbps with much lower power consumption than radio based links. They are more feasible in orbit due to the lack of interference and fogging.

> Building data centres in the middle of the sahara desert is still much better in pretty much every metric

This is not true for the power generation aspect (which is the main motivation for orbital TPUs). Desert solar is a hard problem due to the need for a water supply to keep the panels clear of dust. Also the cooling problem is greatly exacerbated.

Deserts have good sun exposure and land availability but extremely poor water resources, which is necessary for washing the sand off the panels. There are many challenges with scaling both terrestrial and orbital solar.

What (literally) on earth makes you say this? The arctic has excellent cooling and extremely poor sun exposure. Where would the energy come from?

A satellite in sun-synchronous orbit would have approximately 3-5X more energy generation than a terrestrial solar panel in the arctic. Additionally anything terrestrial needs maintenance for e.g. clearing dust and snow off of the panels (a major concern in deserts which would otherwise seem to be ideal locations).

There are so many more considerations that go into terrestrial generation. This is not to deny the criticism of orbital panels, but rather to encourage a real and apolitical engineering discussion.

However one flaw in this critique is that is only looks at the cost of ground-based solar panels and not their overall scalability. That is, manufacturing cost is far from the only factor. There is also the need for real estate in areas with good sun exposure that also have sufficient fresh water supply for cleaning.

When we really consider the challenges of deploying orders of magnitude more terrestrial solar, it really requires a more detailed and specific critique of the orbital vision. Positive includes near continuous solar exposure (in certain orbits) and no water requirements.

Much has been said of cooling but remember, there is a lot of literal space between the satellites for radiative cooling fins. It is envisioned they would network via optical links, and each mini satellite would be roughly on the order of a desktop GPU (not a whole data center rack). The vision is predicated on leveraging a ton of space for lots of mini satellites on the order of a Dell desktop tower. The terrestrial areas that are really cold are also not that great for solar exposure.

Personally I don't know how it will play out but the core concern I have about making these kinds of absolutist predictions is they make weak assumptions about the sustainable scalability of terrestrial power. And that is definitely the case here in that it only looks at the manufacturing cost of solar.

Not great, but to be clear this is different from fabricating the whole paper or the authors inventing the citations. (In this case at least.)

[1] https://openreview.net/forum?id=IiEtQPGVyV

I clicked through on the first news item I saw, "Security forces open fire on woman filming them."

This led to a post on X captioned 'Yasuj; "Firing a shotgun at a lady who was filming."'

The attached video[1] did not show a weapon. It appeared to show uniformed forces on motorbikes and some kind of muted firing sound.

A subsequent comment said: "Don't write the wrong text, it's marking with paintball so the operations team can arrest him. The sound of a shotgun is like this, don't give wrong information."

To be clear, this is not meant to defend security forces firing paintballs at or arresting people recording them, just calling into question the integrity of this particular claim suggesting lethal force, and the overall lack of support for the figures claimed.

[1] https://x.com/ManotoNews/status/2008440556867702830

It cites the ISS's centralized 16kW cooling system which is for a big space station that needs to collect and shunt heat over a relatively large area. The Suncatcher prototype is puny in comparison: just 4 TPUs and a total power budget of ballpark 2kW.

Suncatcher imagines a large cluster of small satellites separated by optical links, not little datacenter space stations in the sky. They would not be pulling heat from multiple systems tens of meters away like on the ISS, which bodes well for simpler passive cooling systems. And while the combined panel surface area of a large satellite cluster would be substantial, the footprint of any individual satellite, the more important metric, would likely be reasonable.

Personally I am more concerned with the climate impact of launches and the relatively short envisioned mission life of 5 years. If the whole point is better sustainability, you can't just look at the dollar cost of launches that don't internalize the environmental externalities of stuff like polluting the stratosphere.