Then Hyrule Hostoria came out as a collectable. I would put good money on a conversation during its writing that went like this "What else can we put in here?" "Maybe a timeline of the games?" "Yeah, sure. What's the official one?" "There isn't one. The fans have a fun split timeline one." "Oh neat. Yeah work out the details. Now has anyone found that Wind Waker concept art yet?"

A common flaw I see in media literacy is operating like the author has pulled a completely coherent story from a different universe and simply written it down, as opposed to a creative process. Nintendo has never cared about the timeline, nor developing a single coherent story across all of the Zelda games. Some games are sequals, prequels, or have direct references. The timeline itself is purely from non-game sources, and is obviously not a factor when they design a new game.

* There are many useful ways to handle it properly, and your choice depends on your program's constraints. The very small amount of friction (once you're used to it) encourages you to consider what ways to handle it are viable, such as allocating all memory at startup.

* If your strategy is to crash immediately, there is very little additional friction but you get the benefit of it being obvious in your code that this is the case.

* There are environments where memory allocation fails immediately, including if you turn off over-commit on Linux. If your hardware is dedicated to running a high reliability system, configuring it in this way is reasonable.

* Memory is not the only resource. Indeed, removing the special call out is what changed here. That different resources are handled with the same mechanism (errors, instead of eg returning null from malloc) is good.

Roughly put, the rocket equation is: change in speed = (engine efficiency) * log(mass of the rocket with fuel / mass of the rocket without fuel). So there's limited parameters to play with:

- The speed you need to reach is fixed.

- You can change the weight of the payload. Payload (eg, satellite) designers try to make things as light as possible, rocket designers try to give as much capacity as possible, and everyone prays they can meet in the middle.

- You want as little propellant as possible for cost and practicality, but mostly the other parameters fix how much you need. If the other parameters aren't good enough, you can easily get results like needing a rocket the size of Central Park. [1]

- You can make the engine more efficient. This means running it hotter with higher pressure, pushing the limits of material science. [2]

- You can make the non-payload static parts of the rocket lighter. This means removing structural integrity. It also means making the lightest parts to complete hard tasks like being a valve for cryogenically cooled, literally the smallest element, hydrogen.

Both the engine and non-payload static mass are essentially asking the question "How far can I push this without it breaking". Get your answer to that question even slightly wrong on any of the thousands parts in a rocket, and suddenly all of the fuel that you're using to go in one direction fast decide that you should instead go in every direction fast.

[1] https://what-if.xkcd.com/24/

[2] Or not using chemical propulsion. However things like ion engines don't have enough thrust to get through the atmosphere and into orbit, and things like nuclear propulsion spew fallout everywhere.

- Launch roughly on time, after a scrub yesterday. (Sounds like the scrub was due to ground equipment, most notably the water system.)

- Initial ascent was good, but then one engine on the booster went out.

- Relight of the booster's engines after stage separation for the boost back burn failed. Engines did light again for a landing burn, but seems to have hit the water harder than expected and was very off target.

- Starship lost one engine shortly after stage sep. Turned into an unintentional test of engine out capability. It made it to space.

- Some weird motion and lots of off-gassing after engine cut-off, with uncertainty about if it actually got a good orbital(ish) insertion. Seems to have been benign, with the motion being a weird slow flip to the orientation for payload deployment.

- Test deployment of dummy payloads was successful, including a couple with cameras to look back at Starship.

- An in space engine relight test was skipped, presumably due to the issues during launch.

- Re-entry to over the Indian Ocean seemed to go really well. Nothing obviously burning or falling off. The amazing views of the plasma during re-entry, something never seen live before starship, are now routine.

- Starship did a maneuver to simulate how they'll have to go out over the gulf and back to the landing site.

- Nailed the target, evidenced by views from drones and buoys. Soft landing before falling over and giving us a big (expected) boom.

As far as overall progress from previous test flights goes, they're at least treading water while making many large changes. I think they were hoping to try for a tower catch and actually going orbital for next flight, but I highly doubt that now. The boostback burn failing was the largest failure, with the engine failure on Starship being a close second. Good performance despite engine out seems to be an unintentional success.

Comments URL: https://news.ycombinator.com/item?id=46878880

Points: 10

# Comments: 0

However, I do understand why some consider it a slog. There are many puzzles in the game that people will dislike, indeed many puzzles that I disliked. It seems Jon prioritized finding all of the interesting things that they could say about the puzzles in the game over making sure that all of the puzzles were actually enjoyable to a majority of people. My advice is if you don't like an area, just go somewhere else. You don't need to complete every area to roll credits.

It also may be a matter of expectations. Puzzle games tend to be on the shorter side, but The Witness is lengthy. So jumping in expecting to finish in an afternoon is a way to set yourself up for frustration.

On a funnier note, the 9 in Falcon 9 is the number of engines. So blue origin is somewhat picking up on their naming scheme. Or, by BO's scheme, it'd be the Falcon 9x1, or the Starship 33x6.

The practicalities of their illegality then comes down to enforcement. Given the current executive branch's behavior related to enforcement of laws, that can mean anything from "melt them all down", to "don't do it", to "if our friends start doing it, it'll be legal, if our enemies start doing it, we'll enforce".

People seem to have surprisingly different internal experiences. I don't know how common 4d visualization is, and I suspect even those capable require exposure to the concepts and practice. However I do think it possible.

2. The institutional knowledge of working directly on the Apollo program has largely been lost in the US, and certainly isn't present in China.

Those are the unimportant pieces. The real reason is:

3. The US was actively at war with Russia. While it was a cold war (except for the proxy wars), the Apollo program had a wartime budget (spent nearly half a trillion in today's dollars), and a wartime risk tolerance (Neil Armstrong thought they had a 10% chance of not making it back).

SLS Block 1: >27,000 kg (59,500 lb)

SLS Block 1B: 42,000 kg (92,500 lb)

SlS Block 2: >46,000 kg (101,400 lb)

Vulcan Centaur: 12,100 kg (26,700 lb)

New Glenn: 7,000 kg (15,000 lb)

Orion crew module by itself weighs 10,400 kg (22,900 lb), the service module is 15,461 kg (34,085 lb).

Orion is a heavy spacecraft. SLS, like or not (I don't), it has a lot of lift. Unless you're sticking an Orion inside of a Starship (lol), Orion basically dies with SLS.

It's not unheard of. Eg, Blender earns $261,360/month. (https://fund.blender.org/) Companies should more eagerly support open source projects they rely on with funding. It keeps their dependencies competitive with much more expensive commercial products, and a broad base of donations prevents a project from being dominated by specific large corporate interests which might run counter to their average user.