wumpus

Good question. We don't know how much surface soil was blown off. We might assume that any water blaster out might hit escape velocity, but the unobtanium that gives Kerbin its density rained back down. I wonder if this is the source for Kerbal materials... While most equipment meets Earth spec well, the fuel tanks are redonculously massive. It may have been a mixed blessing: killing much life while making valuable resources obtainable.

Oops. I kept saying "density" when all the things I talked about were "pressure". While increasing pressure should [usually] increase density (for gasses), as Snark points out you could simply introduce more dense gasses. Still, increasing the escape velocity allows to increase the pressure and thus the density [regardless of the gas] at equal surface gravity (increasing the surface gravity also allows for higher pressure, but appears less preferred). Could you make the fine print any finer? Also don't forget the winds of Venus: they go beyond "hurricane force" well into tornado speeds and probably off that chart as well (370kmh), although I don't know if they violently change direction.

Note that thanks to the Coriolis effect, the ball will be likely rolling down one side. This means that in addition to the kinetic energy of the ball falling through its yo-yo sequence it will also have the kinetic energy thanks to the angular momentum. So when it first pops out the far hole, it won't be re-entering the hole as fast as it did on the first time down. Assuming zero-friction everywhere (and no momentum lost banging against the walls), the height it pops out on subsequent trips will all be the same.

Also the trajectory of an ICBM is absurdly high, to make life difficult for any attempt to build an ABM, so simply aiming higher will work well. But solid motors can (and typically are in at least US ICBMs) be "turned off" by making the nozzle wildly less efficient (blowing the whole nozzle off would be my first guess, but I think they vent before that).

There is at least some point to having an extremely fast torpedo: to make it unavoidable. The only reason to build a superfast submarine is if it were easier than building an equally fast, equally large surface ship or airplane. The thing would stick out like a sore thumb (exactly the opposite of why most submarines are built/used) and still operate in a hazardous environment. Presumably the "air bubble" might help for defense: like horseshoes and hand grenades, close counts with depth charges. You might need a difficult shot with a VA-111 (or faster) torpedo to kill such a beast, but I doubt that is sufficient reason to build such a thing. You're essentially betting that a carrier (or ground, I expect Chinese doctrine will be based on overwhelming numerical advantage on the ground for quite some time) launched aircraft can't kill an underwater craft with a well known position. That is a bet I wouldn't take (at least not on the sub's side). An ultra-fast sub is as dumb as an ultra-large sub. The moment you give away its position it is useless. I'd also expect that the Shkval is close to the limit for submerged speed, any claims to "supersonic" are absurd as noted above.

Deflecting asteroids from damaging Earth appears to require time in addition to actually being able to spot them and send an intercept (we can't do either right now). A better question is just how long it would take to get Ceres (or similar) to either Mars/Sun or Earth/Sun Lagrange point 2 and then going wild (presumably getting Jupiter assists until finally hitting Earth with slightly above solar escape velocity). I'd assume centuries or even millenia (expect for comets to be your dwarf planet mover of choice, probably with large mirrors directly vaporizing bits of comet off to act as cheap delta-v). Such would be a lengthy project, no amount of launches from roughly the same time period could do it with modern technology, we'd have to build replacements over the centuries. I can't imagine a culture remaining that suicidal for that long. But given enough time, you'd be amazed at what tiny usages of delta-v can accomplish in a chaotic gravity system.

I know I've seen a Scott Manley video where he drives up a mountain with the return vessel. I'd hate to think how many hours that took. I'd much rather bring a large rocket than do a long drive in KSP.

My point was that high density/low gravity appeared possible, but I'm less sure how you could find/construct a planet that would have such an atmosphere (all the dense gasses in a gas giant will be "surface or below", probably leaving a hydrogen and other less dense gas "atmosphere"). But the limit on gas density should be the escape velocity of the planet which can be a lot higher than Earth's without increasing the surface acceleration (the "gravity" you feel on the surface). Perhaps a planet made of soapstone, talc or similar low density rock. - of course, that "surface acceleration" doesn't affect buoyancy at all. It just sounds like the OP would prefer a feeling of low gravity.

How do you float 100kg in a dense atmosphere? As long as object density > atmospheric density, if floats. Every [manned] hot air balloon ever made has had more mass than 100kg. So you don't need an atmosphere any more dense than Earth. A complementary question (that you appear to be asking, but it is lost in ignoring the basics of buoyancy is where you might find a high-density atmosphere with low gravity. Neptune and Uranus appear to qualify with near 1g gravity (at surface) but escape velocities twice Earth's (so gasses have a much harder time escaping). While I don't know much about either planet's atmosphere, it appears they could easily hold an atmosphere considerably more dense than Earth's [I'm equally unsure how the surface is defined in a gas giant]. So you presumably want a massive but low density planet (low g but high escape velocity) to hold a dense atmosphere.

How would you do the review? This "thing" that was our payload continued on a ballistic trajectory. We can show it was installed per all instructions. While I'm sure plenty of people knew a lot about Zuna, most of the people needed for a "full review" certainly don't otherwise have the "need to know". I once had a coworker who did "work" "upriver" (as a contractor). That was all we were supposed to know. Then we were told to forget about the "up river" part (presumably it meant NRO instead of CIA, but with the amount of contractors all over VA I doubt anyone could say for sure).

Note that this will still likely take a few billion years. Humans have managed to develop tech and side effects sufficient for self-extinction, but taking the big ball of rock out with us is another thing. My solution is to really wait a few billion years (unless that is what you are saying). Accelerate to epsilon-less-than-the-speed-of-light (with "navagation shields" that could stop nuclear weapons, natch) and return in several billion years. The Sun will go red giant and consume the Earth, done.

Orbit is at least 3k delta-v (typically more), escape takes about 4k (including orbital). While theoretically "not going into orbit" is more efficient, most high-efficiency rockets don't provide sufficient TWR to hit escape before orbit. In practice, it makes more sense to get into orbit to at least try to correct any inclination errors that might have crept in, and also to use the maneuver planner to choose your exit burn time (I'd love to be able to use the maneuver planner on the launchpad).

I think the point here is that you will need a probe core for each ship/lander (regardless of control, KSP has a tendency to delete such rockets without cores). You will also need to provide communications so you can direct them from KSC (don't worry, we don't have speed-of-light issues in KSP) which means being careful of relay and non-relay communication.

You missed the whole point of the answer: you use a buffer much like a victim cache (presumably caching while entering *and* leaving, while a true victim cache only caches while leaving). This likely has to be fully associative (to avoid the same issues as hashing) but doesn't have to be big. Since you would look up both simultaneously, you don't lose performance (well, some speed thanks to the extra capacitance on the lines, but nothing major. Victim caches are a thing, and don't kill performance). I suspect that AMD will at least look at this type of thing for Zen 3, but don't count on seeing anything beyond what they've already done. Presumably Intel has to do a bit more (but luckily did most of what was needed *years* ago with the PTI data).

What would be the issue with an NTR? It doesn't explode, it is in no way a weapon, nor could it be seen as militarization. It is just a rocket, only a potentially awesome one. I think you are assuming that since an Orion (which would violate the treaty) isn't allowed, no nukes are allowed. Wasn't there a Soviet reactor in space? I doubt they could have done that before the treaty/treaties.

As far as I can tell, the ideal KSP processor before 1.1 was the highest clocked Intel pentium you could find (technically the big boys with the much larger caches would show an improvement, but it would be pretty small). Even after 1.1, I'm guessing that the ~$75 Pentium G4560 is easily the best value for KSP (unless you decide to stream it). As far as "everything else", things are finally interesting after roughly a decade of Intel dictating what the market should be. AMD pulled out ahead for everything between the extreme lows and highs of performance (and still hit high performance if you have enough threads). Recently Intel bumped up the number of threads (look carefully at #of cores and hyperthreading, Intel hasn't been consistent with what i3, i5, and i7 really mean (especially for notebook CPUs)) so between the higher overclocking and matching cores, Intel is back competitive with AMD (of course, check your applications *after* patching meltdown). Hopefully before spring we should see AMD's answer in the form of higher clocking Ryzen processors. But for [just] KSP you probably want the Pentium (but check prices on motherboards, you might find an AMD+motherboard bundle more valuable, especially if you live near a microcenter). PS: does Unity use SSE/AVX/other vector systems for floating point calculation? Judging by core2 performance, it doesn't appear that they ever go beyond SSE (and might only be filling a single position: you wouldn't want to use x87 past a Pentium4). This should make a big difference (and would show a difference between a Pentium and a i3, and give a big advantage to an i5 over an AMD if you could use AVX256 instead of SSE/2).

As far as I know, the AMD systems either delay the checks or delay throwing the segfaults. Unreading the cacheline is certainly possible (simply marking it invalid), but replacing the old values is the real problem and likely just as visible to the attacker. Using some form of slew (or hashed) cache may make it difficult for the attacker to measure the performance of the old cache line (this was brought up in the realworldtech forums, but nobody commented on it. It might take a secure hash [absolutely performance killing] to make this work. There are a few defenses against an attack on the cache: don't depend on privileged code. This seems to be the current strategy (and patches). Don't let memory access the stuff or branch to unavailable areas. Wait for the branch predictor to "catch up" before filling the cache line. While this appears performance killing, I don't think any cache fills starts until 8 cycles (probably more) after the initial attempt to execute the load/store. In practice, this would likely use something that looks a lot like a victim cache to buffer the cacheline until the load/store instruction is retired. With a more or less associative victim/buffer cache, it should hide which lines are effected. There are all kinds of nasty holes in CPUs. My favorite is that you can construct a Turing Machine out of the MMU page replacement scheme: this isn't a flaw in any implementation, it is exactly what the architectural spec demands. But nobody is all that worried of somebody taking over the page replacement data. It almost always makes more sense to attack the software than the hardware, and nobody is protecting the software to quite the same rigor.

The raspberry pi uses a processor sufficiently weak to not use branch prediction and is not affected at all by this attack. It gives you a good idea of how weak such a processor would be. The problem isn't "using speculation is bad", but "allowing the effects of the paths that were incorrectly predicted [and thus should have all their effects rolled back] leak into the user-visible state". This comes down to at least 2 paths: Allowing the branch predictor to access memory it shouldn't. It seems Intel [and ARM] "checks their privilege*" a wee bit late and allows operations that have been predicted to use privileged data that they shouldn't to fiddle with branch prediction. Once this data has been cleared out, the effects of which branch predictions succeeded and failed are still visible. Allowing the branch predictor to update with data that "shouldn't exist". Rolling back all speculated operations after mispredicting branches is a real pain, and rolling back the branch prediction updates not only suffers that pain but also loses data (and thus makes branch prediction miss more often). But it turns out that it may be possible to use the data leaned from the mispredictions to determine what happened on data that shouldn't be accessed. You should be able to fix these with a limited performance hit. It will take plenty of engineer-hours to get it done (for Intel and ARM, AMD may have already done most of it). A few notes on conspiracy and Intel: This looks more like a cost-cutting scandal than anything else. AMD presumably noticed a similar potential flaw, patented a fix, and shipped processors immune to much of this issue. The catch for Intel (unlike ARM) is that they have a patent cross-licensing deal with AMD and presumably some Intel intern tasked with grepping the list of new patents for "AMD" would have noticed the patent and spread it around to the appropriate engineers. As far as we know, Intel has only themselves to blame (for at least being not as resistant to this as AMD). Intel has been known to act in ways that appear indistinguishable from conspiratorial acts. The hardware RNG in Intel processors has the peculiar property that it appears designed to produce 64 bit random numbers when "correctly" manufactured but via simple process changes can produce only 16 bits of true randomness. This is a problem as it is fundamentally impossible to determine from the output just how much "randomness" you have (unless you know the process changes made to produce the chip). After this was discovered, pretty much all users of random numbers stopped using Intel's RDRAND instructions. Note that it must be far easier to discover vulnerabilities in Windows/iOS/Android/browsers than to bake weird faults into hardware: this is almost certainly a cost cutting measure (getting privilege escalations is easy, the RDRAND is an amazingly useful target and might actually be a threat). And speaking of conspiracies, the infamous DUAL_EC_PRNG random number generator (basically used by the NSA as a backdoor to listen into anybody foolish enough to use software based on that algorithm) manged to cause a printer driver bug: https://blog.cryptographyengineering.com/2017/12/19/the-strange-story-of-extended-random/ * the user is trying to see root's (the administer) code/data. They aren't supposed to have that privilege and the "check" should fail. Sorry about the bad joke.

A favorite story of mine is that of HGS-1 (also called Asiasat-3 and PAS-22, but was called HGS-1 during this story). A proton launch failure left the satellite in the wrong orbit (highly elliptical, presumably something like geosynch-intercept). To save the bird, launch control looped it around the moon. This used up about half the delta-v for stationkeeping and left the inclination about 11 degrees off, but left Hughes with a workable satellite. After another sale, the it was moved yet again (no inclination change). There was another plan to fix all the inclination with a much slower route, but since they couldn't track such progress it was never used. I'm not sure what the design lifetime of the bird was, but it only lasted 4 years before removal to the graveyard orbit. It also suffered loss of a solar panel, presumably dealing with different heating/cooling cycles than expected (well, according to wiki. I don't think GSO birds get much shade from the Earth, although it may have suffered from being behind the Moon. Presumably the "slow route" would have been harder on the bird).

I'd expect to try all three myself (presumably including buying at least "Making History" assuming it is remotely mod friendly and can be completed without additional purchases). I bought KSP back in the .2x days (apparently just after the DLC cutoff, but I have no way to tell as I bought it from Valve) and bought on the assumption that the game had to be worth whatever Squad was charging (it was on sale) without additional development (while Squad had been steadily improving, plenty of other early access games have been busts). Even so, after KSP hit 1.0 they are hardly required to do any additional development (those of us who remember cartridges and other pre-internet games certainly expected "what they originally ship is what you bought"). Anything since that is gravy, and I'm amazed at how far they have come. The only real action this might have on my part is a slightly greater interest in archiving older versions (and compatible mods). I recently noticed a copy of the beta edition lurking in an obscure directory and was pretty happy about it (I had thought that the entire souposphere+stable pancake rocket experience was lost). As long as you have a version you like and the mods you want/need, you have an amazing KSP experience forever (well, that might require the Linux edition, don't expect Windows to maintain that type of backward compatibility).

Orion (no, not the current NASA project of the same name, the *real* Orion). Send a battleship-sized spaceship into space by setting off nuclear weapons underneath it. Theoretical top speed: 10% of lightspeed. Not just kerbal, but straight out of E.E. doc Smith. Scott Manley has a small playlist of these (4 videos): https://www.youtube.com/playlist?list=PLYu7z3I8tdEmmUlCpcj-7BUt0X-sdjmtt

Except that it isn't Squad's game anymore and they aren't calling the shots, so any previous actions of Squad are pretty moot. The game now belongs to Take 2, who has stated an absolute insistence for including such ways to pry money out of players. I'm equally befuddled by people complaining about lack of purchases of DLC that aren't even scheduled for release.

Does it obey the rocket equation? Is it spitting out mass&velocity in one direction and getting momentum in the other? If so it is a rocket. Note that this gets rather fuzzy where the line has to be drawn between: High bypass turbofans [almost certainly not rockets] Classic turbojets (what is typically used for supersonic flight) [not quite rockets] Ramjets/Scramjets [getting to being a rocket] SABRE [probably a rocket, but maybe not for models that can't fire in vacuum] Air-augmented rocket [almost always considered a rocket] Classical rockets (supply their own oxidizer) [always considered a rocket]

Just ran across a job for somebody to integrate an electric propulsion system into a spacecraft (plenty of experience in both required). $90-$100/hr [6 month contract]. Washington DC area. Anybody do this for reals? The job hasn't been filled for 30 days, so I'm guessing there isn't anybody in the area with the right skillset (or the contract hasn't been awarded and the job doesn't exist - a more likely story for this type of thing).

I think many of the posters are venting at the wrong people. It took a bit of googling to even find the most recent (9 months ago) announcement on KSP DLC and then clicking around on it to get a current blog (at http://kerbaldevteam.tumblr.com/ )to see that the DLC was still being developed. If you want us to buy the DLC, convince Squad to get it out the door. That said, I have at least two views on DLC (at least as far as KSP is concerned): Four years ago (when it was originally announced) releasing DLC would have been a mistake. The game was in early access and needed to be completed (without cost) to those of us who bought the game. Once it achieved 1.0 status (maybe 1.0.5 thanks to various bugs) this was no longer an issue. Selling the planned DLC (now, or at least once it is released) makes all kinds of sense. While theoretically there may exist more KSP buyers who would happily buy the game if only it had the polish of an AAA game, most gamers aren't willing to learn rocket science to play a game. The current batch of KSP players are needed to finance this game and DLC is an ideal way to increase sales (hopefully including a bundle of KSP+DLC at a savings for players who haven't discovered KSP). But you can't complain about people not buying a game that isn't for sale.