I suggest:

First offence: Have to watch CSPAN for 5 hours a day, for a week, without sleeping through it - evidence to be provided in court

Second offence: Have to sing Miley Cyrus songs and Baby Shark on TikTok - sober

Third offence: License to practice and all memberships of country clubs and golf courses revoked

They tried that with Apollo 13. And.... that actually did work, sorta.

You're confusing the importance of avoiding Kessler syndrome in LEO with the difficulty of causing Kessler syndrome. GEO debris can potentially remain there for millions of years before interactions between the gravitational pull of the Sun, Earth, and Moon sufficiently perturb it. LEO debris remains for weeks to months. You have to have many orders of magnitude more debris in LEO to trigger Kessler Syndrome, where the rate of collisions exceeds the rate of debris loss.

The fact that a LEO Kessler Syndrome would also be short is something that exists on top of that.

It's also worth nothing that not only are modern satellites not only vastly better at properly disposing of themselves than they were in the 1970s when Kessler Syndrome was proposed, but they're also vastly better at avoiding debris strikes. All of these factors are multiplicative together.

Lol, I was thinking of this instead ;)

People forget that the primary concerns about Kessler Syndrome were about geosynchronous orbit, which used to be where all the most important satellites went (many of course still go there, but not the megaconstellations). It takes a long, long time for debris to leave GEO. But LEO is a very different beast.

They said it's internal rather than a collision, so probably a failed COPV would be my guess.

Yeah. In particular:

with fragments likely to fall to Earth over the next few weeks

LEO FTW. Kessler Syndrome is primarily a risk if you put too much stuff with too poor of an end-of-life disposal rate in GEO. End-of-life without proper disposal rates have declined exponentially since Kessler Syndrome was first proposed (manufacturers both understand the importance more, and do a better job, of decreasing the rate of failures before deorbit - in the past, sometimes there wasn't even attempts to dispose of a craft at end-of-life). And now we're increasingly putting stuff in LEO, where debris falls out of orbit relatively quickly. It's not impossible in LEO, esp. with higher LEO orbits - but it's much more difficult.

Or to put it another way: fragments can't build up to hit other things if they're gone after just a couple weeks.

And this trend is likely to continue - a lower percentage of premature failures, and decreasing altitudes / reentry times. Concerning ever-decreasing altitudes, we've already been doing this via use of ion engines to provide more reboost (with mission lifespans designed for only several years before running out of propellant, instead of decades like the giant GEO ones), but there's an increasing interest in "sky skimming" satellites that function in a way somewhat reminiscent of a ramjet - instead of krypton or xenon as the propellant for an ion engine, the sparse atmospheric air itself is the propellant, so the craft can in effect fly indefinitely until it fails, wherein it quite rapidly enters the denser atmosphere and burns up.

That surprised me, too. TypeScript is a very poorly-congealed ("designed" seems a bit strong) language.

Of the two popular scripting languages - python and ruby - python probably makes more sense as you can compile into actual binaries if you want.

For speed and parallel processing, which I'd assume they'd want, they'd be better off with Tcl or Erlang, both of which are much much better suited to this sort of work.

Then they should have used Tcl.

ED: "But it doesn't work for gravity with linear curvature"

Relativity = gravity is represented by the curvature of spacetime. Curvature is linear, R. The formula treats curvature linearly. As things get closer and curvature spikes, the math just scales at a 1:1 rate

Quadratic gravity = Squares the curvature. Doesn't really change things much when everything is far apart, but heavily changes things when everything is close together.

Pros: prevents infinities and other problems when trying to reconcile quantum theory with relativity ("makes the theory renormalizable"). E.g. you don't want to calculate "if I add up the probabilities of all of these possible routes to some specific event, what are the odds that it happens?" -> "Infinity percent odds". That's... a problem. Renormalization is a trick for electromagnetism that prevents this by letting the infinities cancel out. But it doesn't work with linear curvature - gravitons carry energy, which creates gravity, which carries more energy... it explodes, and renormalization attempts just create new infinities. But it does work with quadratic curvature - it weakens high-energy interactions and allows for convergence.

Cons: Creates "ghosts" (particles with negative energies or negative probabilities, which create their own problems). There's various proposed solutions, but none that's really a "eureka!" moment. Generally along the lines of "they exist but are purely virtual and don't interact", "they exist but they're so massive that they decay before they can interact with the universe", "they don't exist, we're just using the math out of bounds and need a different representation of the same", "If we don't stop at R^2 but also add in R^3, R^4, ... on to infinity, then they go away". Etc.

The theory isn't new, BTW. The idea is from 1918 (just a few years after Einstein's theory of General Relativity was published), and the work that led to the "Pros" above is from 1977.

In short, Java was invented for a reason, and while it has become a victim of legacy cruft as well, the underlying concept of truly portable apps, with a minimum of fuss to jump from platform to platform, still ought to be the preferable path. The problem is that that true platform neutrality/ambiguity pretty much kills Microsoft in all but a few niches, like gaming, but only because hardware vendors put less effort into drivers for other operating systems.

Yes, Office is still king, although I think that crown is beginning to slip, and it may end up being Excel, with its large list of features, that may last the longest. But it isn't 1990, or even 2000 anymore. Developers have multiple ways of developing portable applications, and while MS may (for the nth time) update or swap out its toolchains, the real question is will developers really care?

A bit more about the latter. Beyond organophosphates, the main other alternative is pyrethroids. These are highly toxic to aquatic life, and they're contact poisons to pollinators just landing on the surface (some anti-insect clothing is soaked in pyrethrin for its effect). Also, neonicotinoids are often applied as seed coatings (which are taken up and spread through the plant), which primarily just affect the plant itself. Alternatives are commonly foliar sprays. This means drift to non-target impacts as well, such as in your shelterbelts, private gardens, neighbors' homes, etc. You also have to use far higher total pesticide quantities with foliar sprays instead of systematics, which not only drift, but also wash off, etc. Neonicotinoids can impact floral visitors, with adverse sublethal impacts but e.g. large pyrethroid sprayings can cause massive immediate fatal knockdown events of whole populations of pollinators.

Regrettable substitution is a real thing. We need to factor it in better. And that applies to nanoplastics as well.