RKunze

You are literally breathing that nitrogen source :-)

The computer you read this on can probably do it in a grossly inefficient, interpreted language running within a space simulation game. For examples, see all those working kOS scripts out there that manage accurate boost back and landing...

If you mean the Novel by Arthur C. Clarke, make sure to also watch the movie. One of the best SF films ever (Clarke actually worked on both the novel and the movie script in parallel). And if you like classical SF, I can highly recommend The Fountains of Paradise, also by Clarke.

Because it has been "shivering" in the same direction (outwards) for as long as we can observe - which means for the last dozen billion years or so (thanks to the finite speed of light, we actually can look back in time). And there is absolutely no indication that this trend will stop (in fact, it seems to be speeding up).

What exactly do you mean with "tipping over"? Does the rocket go out of control and tumbles? or Does the tip of the rocket follow the (surface-)prograde marker, but that marker keeps falling down leading to an eventual crash? My guess would be 2, because 1 usually means your rocket is aerodynamically unstable, and your design looks OK in that regard (I'd have used a fairing for the payload, but you should probably be able to get to orbit without if you don't go too fast in atmosphere). If it is 2, then your rocket is actually following the ideal trajectory, a "gravity turn". The only problem is that you start that turn by tipping over too far. From the image, my guess is that your rocket has an initial TWR of well below 2 (which is actually realistic, real launch vehicles usually have a starting TWR of 1.2 to 1.5), which means you need to tip over just a very tiny bit (no more than 2° off vertical, usually less, but that depends on a lot of factors) after the launch, and then just leave the rocket alone. My usual launch procedure is: launch straight up until the rocket is clear of the launch tower and fast enough to be aerodynamically stable (for my designs, 20-30 m/s is usually fast enough) tip over very slightly (somewhere between 1° or 2° off vertical, depending on the rocket - as I use kOS to automate my launches, that's actually handled by a script, and the code that calculates how much to tip over is the most complicated bit of that launch script by far) keep the rocket pointing prograde (if your rocket is aerodynamically stable, this just means keep your hands off the controls, it will follow prograde automatically) If you reach apoapsis too soon, retry with a smaller initial tipover.

It's the type wheel from a type wheel printer. And I'm actually old enough to have used that kind of printer. And its close cousin, the type tape printer, which was much faster because it could print multiple types on a line at the same time. And much louder - especially if you fed it finely crafted input that caused it to fire all the types on the line at the same time (and no, the university compute center sysadmins where definitely not amused when we did that).

Should be around 2. Principles are well understood, engineering does not need any obvious unobtainium, but nobody built one yet. Could have something to do with the fact that its exhaust is the same kind of highly radioactive fission products that are carefully not let out of containment in terrestrial fission reactors

But the two sequels ("Fuzzy Sapiens" and"Fuzzies and other people") have never been published as an eBook - at least as far as I know. If I'm mistaken, please point me to a source - as @Vanamonde said, the sequels are almost impossible to get even on paper, let alone as eBook. I'd dearly love to read them. As for the original "Little Fuzzy", you don't have to go to Amazon. Copyright for that one lapsed, and it is available from Project Gutenberg at https://www.gutenberg.org/ebooks/18137 Edit: @Gargamel is the fellow Little Fuzzy fan - sorry for the mistaken ping...

In vacuum, at almost lightspeed. But where neutrons are generated deep within the sun is anything but vacuum, and most of those neutrons are considerable slower than c.

Small wonder. Neutrons are generated deep within the star, in the middle of a dense plasma. Which means they are either absorbed quickly by some other atom, or deflected often enough to decay while still deep within the star. Heck, the interior of a star is so dense that even the photons generated in the fusion zone don't normally get outside the star. They basically just heat up the plasma, and the photons we see from a star are generated at the "surface" (or more correctly, the "photosphere", because a ball of hot plasma does not really have a surface) of the star. That's why a stars' spectrum is very close to an ideal black body spectrum, which in turn means you can directly tell the stars' "surface" temperature from its spectrum.

Nope. Most fusion reactions (including those occurring in stars) also put out plenty of neutrons. And some events (supernovae and neutron star mergers) put out huge quantities of neutrons (if they did not, most heavy elements would not exist). The reason that there are almost no neutrons in cosmic radiation around earth is that free neutrons decay in about 10 minutes and thus don't reach us.

If you don’t mind that you lose the relative timestamps, you could pre-parse the page on scraping, strip out "data-short", replace the "16 hours ago" text with a formatted version of "datetime" (eg. "July 17 2024 21:59 UTC") and feed that edited version to the deduplication code. That should give you identical hashes even for new pages, and won't lose any relevant info for archiving.

Hmm. How do you get the power from the wire to the pantograph in this case? At the voltages involved, I'm pretty sure an electric arc will work technically (or rather, will be pretty much unavoidable), but I’m equally sure having a constant arc with enough current to drive a train will be quite hard on both the wire and the pantograph. Probably harder than having the pantograph scrape along the wire...

If the only problem left is patching the labels to show the correct resource, how about changing the labels with a standard MM patch to something generic like "extraction rate", "start harvesting" and "stop harvesting" and just leave them alone in the part switch config? Edit: Forget that, I didn't read your description correctly. As a wild guess for why patching the labels may fail: Could that be some interaction with the i18n system?

Because you need way more energy to go from aluminium ore to aluminium metal than to go from iron ore to steel. That is why Iceland's second most important export (after fish) is aluminium, even though both the ore needs to be shipped in and the finished product needs to be shipped out. But Iceland has lots of cheap electricity to run the smelters.