Skip to main content

A Chinese Rocket Breaks Apart Dangerously Close To the Starlink Constellation

3 weeks ago
A Chinese Zhuque-2E rocket's upper stage broke apart shortly after last week's June 9 launch, likely creating 100 to 150 pieces of debris in a busy region of low-Earth orbit crossed by the ISS and lower-altitude Starlink satellites. Most fragments should reenter within months because of atmospheric drag, but experts say the incident adds to a worsening trend as China leaves more large rocket bodies in orbit while expanding its launch rate. Ars Technica reports: The US Space Force confirmed the breakup event in a post on space-track.org, a website used by the military to distribute orbit data to the public. "The tracked pieces are being incorporated into routine conjunction assessment to support spaceflight safety," the Space Force wrote in an advisory. "There are currently no threats to human spaceflight. Analysis is ongoing." So far, the Space Force has not added any of the debris fragments to the official catalog of human-made space objects. [...] The bad news is that the Zhuque-2E's breakup is the latest chapter in China's growing contribution to the space junk problem. After decades of leaving spent rocket bodies in orbit, launch operators in most countries now reserve enough fuel to steer their upper stages back to Earth for controlled reentries. Rocket bodies attributed to Russia and the former Soviet Union account for the bulk of the launch-related debris in long-lived orbits, followed by China and the United States. But the Russian and American numbers are declining or holding steady, while the mass of Chinese rocket bodies in these long-lived orbits has grown by more than 150 percent in the past five years, according to a new analysis by Space Domain Awareness expert Jim Shell. The increase comes as China ramps up launches of its own megaconstellations designed to compete with SpaceX's Starlink. Rocket bodies are the most concerning sources of space debris because they are typically fairly large in size and mass, often with residual propellant and high-pressure gases that can trigger an explosion. There is no way to maneuver or dispose of them if left abandoned in orbit after releasing their payloads. McKnight characterized the recent breakup of the Zhuque-2E rocket as a "slight space safety issue," but the trend is not good. China's Long March 6A rocket has an especially bad track record, including two explosions that littered a higher-altitude low-Earth orbit with more than 1,000 debris fragments, where they will remain for decades or centuries. "Three of the top four breakup events in LEO are of Chinese origin, with two of these events being from Chinese (rocket body) explosions in the last four years," McKnight said.

Read more of this story at Slashdot.

BeauHD

CodeSOD: Required Fields

3 weeks ago

If you want to connect to another system, you need to supply credentials. That's a pretty obvious requirement. We can set aside the whole technical challenge of managing those credentials and the security problems various techniques create, and just focus in on: you must supply some credentials to authenticate.

Lisa has inherited a method which connects to another system. It, correctly, will complain if you don't supply parameters for credentials. It will, incorrectly, mislead you about their requirement:

public function connect(string $username = "", string $password = ""): void { if ($username === "") { throw new InvalidArgumentException("username is required."); } if ($password === "") { throw new InvalidArgumentException("username is required."); } // ... other stuff }

The $username and $password fields here are set to default values. Which means it is syntactically valid to invoke the function connect(). It won't work if you do that, as it will definitely throw an exception, but this is a bit of misleading ergonomics. If the parameters are required, they should probably, I don't know, be required?

What really draws our attention here, however, is not the misuse of default parameters, but the absolute disaster that debugging issues with this function could easily become. If you fail to enter a username, you'll get an exception telling you "username is required". And if you fail to enter a password, you'll also get an error message telling you "username is required".

Which is a factually true statement: username is required. But it's not the cause of my error, which is that I failed to supply the password. Theoretically, though, we could adopt this to make writing exception messages easier. I could make every exception message be "username is required", and it wouldn't be wrong. And clearly, that's what we truly mean when we say "not even wrong".

.comment { border: none; } [Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.
Remy Porter