Starman4308

That is blatantly misleading. The actual statement: "Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect" They're not saying it's not a problem, they're saying it's not unique to Intel. By chopping off the last half of the statement, you are effectively lying about what they said.

They are almost certainly trying to correct it. I would not be surprised to see them offer free replacements... When those replacements actually exist. Which might not be for years, because of how very difficult it is to design and manufacture machines with transistors mere nanometers in size. This kind of error did happen, and it went undetected for decades under the eyes of thousands of experts. Fundamentally, modern high-performance computing hardware has gotten so incredibly complicated that it's hard to account for everything.

CPUs have been faulty for decades. This isn't a new problem, this is literally a decades-old problem that is only now coming to light. They could recall the chips but have nothing to replace them with. Again, this issue is present in Intel CPUs dating back from 1995. There is nothing to replace them with. On AMD vulnerable vs. not vulnerable, I would refer you, once again, to AMD's website, where they state: Problem 1 (which I think is Meltdown): Mostly fixed by OS patches, exactly the same as Intel's chips. Problem 2: Theoretically vulnerable, but most of the work has been done on Intel chips, and an attack on AMD chips has not yet been demonstrated. Problem 3: Not vulnerable. This is a fairly unprecedented event, where a near-ubiquitous class of products has been faulty for decades, there is no stock with which to replace those products, and there will be no stock for at least a year because of how long it takes to design a new microarchitecture and get it into production.

Well superheated plasma is a fluid, so it would be splashed down, not landed. I thought that one would be obvious!

Part of it is that, as I understand, dealing with these flaws is a nontrivial issue. They need to figure out how to stop these flaws at the hardware level, design a new microarchitecture with these paradigms in place, test it, make the masks, do a test production run, test again, and then get started on making new CPUs. I'm pretty sure the ordinary pipeline for designing new microarchitectures is years long, and they've apparently had half a year, tops There's a reason Spectre will "be with us for a long while to come"; the only fix is a fundamental change to how CPUs are designed.

A, citation needed. B, the same chips that the NSA uses? C, I have finally thought of a good analogy for this. Intel engineers in 1995: "We've made a good chip; this out-of-order execution is going to significantly speed up processing." Death Star engineers in 0 BBY: "We've made a good battle station that will finally crush this Rebellion." No Intel engineer in 1995: "What if some hacker* creates a branch statement into some kernel code and flushes the cache into main memory?" *1995 probably had much less concern about computer security; you didn't have a situation where everybody had a smartphone and tablet where they did all their banking, communication, etc. No Death Star engineer: "What if some pilot flew at high speed down a trench littered with defensive firepower and protected by TIE fighters and dropped a photon torpedo into a 1-meter-diameter thermal exhaust vent?" Which says nothing of the sort; Intel's news release mostly just clarifies that it is not unique to Intel hardware.

Part of it, I suspect, was simply that this was a vector of attack nobody would likely think about. It is a side effect that never touches main memory unless directly exploited, reliant on out of order execution (which returns the same result with purely temporary side effects), and is based on hardware, not software. The hardware guys said "we get the same result as sequential", and security analysts trusted that, with nobody looking at this tiny little detail of an ephemeral side effect. Until now.

Incorrect, even according to AMD. Bound check bypassing hits almost all modern CPUs, but can be patched in software by very strict isolation of kernel functions, which is where the performance hit comes in. Branch target injection is theoretically possible on AMD hardware, but has not yet been demonstrated due to hardware differences. Rogue data cache load is the only one thought to be purely an Intel thing. These two cannot, to my knowledge, be resolved by software patches, except in specific known cases. EDIT: Either I'm mis-remembering things, or there's conflicting information on what's "Meltdown" and what's "Spectre".

My understanding is that performance drop for KSP will not be significant. It's an issue with needing to secure kernel calls, something that usually happens during file I/O, not intensive physics calculations like the Unity rigid-body-physics engine. Regardless, I'm under the impression it has to deal with fiddly details of how speculative execution is done, an unanticipated method of accessing secure information. What's interesting to me is that Google claims AMD chips are vulnerable, while AMD claims they're secure from it... despite using the same x86-64 instruction set as Intel, with many of the same hardware mechanisms.

To expand on this a bit: The Enterprise's engines are badly off-center, inducing a torque that must be corrected for. In reality, this would mean a constant hard gimbal or a lot of attitude thrusters, though KSP's reaction wheels/magic torque machines would also work. The Enterprise has fixed engines and fuel tankage. To combat the tyranny of the rocket equation, real space vehicles must stage off empty fuel tanks and now-overweight engines every so often to achieve high delta-V. My guess is that the Enterprise accelerates incredibly fast compared to real space vehicles. While the launch vehicle must have TWR > 1 (or wings for lift), once you get to space, TWR goes way down because engine mass is just dead mass in the rocket equation. While players tend to be less patient than NASA, you'll still see vehicles that accelerate at less than 1 m/sec^2.

If you're either very lucky in timing or the target is very distant, gravitational assists might save time. In this case, though, I doubt it; Duna and Dres are too small for a good gravitational assist when you're going by at several kilometers per second, and you'd lose too much time swinging by Eve*. He's ejecting from LKO with an absurd amount of energy, enough to basically say "screw orbital mechanics, I have delta-V!" *The OP's question is when you have a favorable alignment of Jool, not an arbitrary one where Eve might just be close to the straight line path.

You should also avoid target retrograde, even if the target is close. That's how my first rescue vessel tipped! What is useful advice is not to obsess about a perfect, maximally efficient landing, and don't be afraid to use some upwards thrust to avoid terrain, even terrain you haven't seen yet. Perfect is the enemy of good and good Kerbals.

Approximately twice the chance of a single engine failure, yes, but not total engine failure. My understanding is that most 2-engine birds can fly on one, at the cost of being difficult to fly and running the other engine close to its limits, which can cause that one to fail too. Still, you reduce the risk of your plane becoming a glider significantly, making an engine-out event much less likely to cause a total failure. There is an increase in some risks such as "lol, engine exploded and now you have no left wing", but I suspect multi engine birds are generally safer than single engine. Maybe not as efficient or effective in some cases, but multiple engines are probably in general safer than one. I heard this one story about an Air Force F-16 pilot getting impatient at traffic control because they prioritized a B-52 running the dreaded 7-engine-landing over his single engine that was acting "peaky".

As originally stated, it was dangerously misleading. While downscaling might make courts more likely to agree it's fair use, it is not a get-out-of-jail-free card. You are still preparing a derivative work, a right given to the original copyright holder, and hoping courts would agree it's fair use. I also find it improbable that a court would call it "entertainment". That was a qualitative judgement on your part, not related to the actual intent of the blog. Overall, you seem to be applying standards based on your personal experience to a quite different type of media from a quite different type of author not used to your field's standards, and being incredibly high-handed and arrogant about it. He is not somebody submitting to your journal. He is an enthusiast making a blog post. This is not a professional context where there are clearly established guidelines on content, where you could say "please re-read these guidelines and resubmit based on these guidelines"; it's an amateur blog post. Even in a professional context, your original "rewrite everything" posts would have been arrogant and uninformative; for an enthusiast blog post, they were simply unhelpful and insulting. In an informal context such as this, it is crucial to give specific feedback, preferably couched in a constructive tone. Otherwise, you mostly just wind up insulting the author. Even in professional contexts, it's best to maintain a constructive tone, treating the submitter as a colleague instead of a misbehaving student. And speaking of "treating him as a misbehaving student", you have failed to grasp the difference between privately telling a student "please resubmit" and publicly telling the world "I think your article is terrible and needs to be completely rewritten".

For downsizing, my interpretation of PB666's post was that he claimed downscaling an image made it fair use, which is incorrect. When it comes to fair use, be careful, cite whenever possible the original work, and try to use public domain or permissive license images to avoid dealing with fair use in the first place. Still, it's a blog post, not a manuscript that needs to be very careful about plagiarism issues. My understanding is that plagiarism is not a crime (though copyright infringement is), so private works don't strictly need to cite... though it's polite to cite anyways.

You... kind of did repeat yourself, giving no additional information. In this case, you weren't telling him nicely, you were saying "everything is terrible, rewrite" without the slightest indication of what was wrong. The failure in communication here is not on MatterBeam's part, it is quite squarely on you. Ironically, usually you seem to go for large, incomprehensible, rambling walls of text, whereas here you went for a single-sentence dismissal of everything he wrote. I'm also pretty sure downscaling images is not "fair use"; downscaled, upscaled, or edited, you still have to attribute the original source according to its license when you use it.

Use the staging button to fire off one of the stack separators? If neither staging a separator nor running a test completes the contract, and you have the correct part in the correct situation, then you have a bug, and I'd just use the alt-F12 debug menu to complete it.

The easiest thing to do would be to add a ModuleResourceConverter to ISRU units, with only ElectricCharge as an input resource. However, I will warn you that this would break conservation of mass hard, unless you used a truly staggering amount of EC per unit of liquid fuel. Assuming 1 EC = 1 kJ: E=mc^2 m = 5 kg (1 unit of LF) c = 3*10^8 m/sec E = 4.5*10^17 J Thus, to avoid completely breaking conservation of mass/energy, you would need to input at least 450 trillion EC per unit of liquid fuel generated... assuming perfect energy-to-mass conversion.

Graphics will use both. You need the CPU to send rendering instructions to the GPU. While increasing settings usually doesn't hit the CPU much, because you're saying "render a bigger screen with these high-res texture files instead of these low-res textures", adding effects can be a non-negligible impact on the CPU, because you need to send a bigger package of instructions to the GPU. I suspect FAR can be another CPU-heavy culprit due to a lot of custom aerodynamics code.

I'll have to wait until I get home to see how to disable boiloff completely, but: There are storable propellants such as MMH, UDMH, Aerozine 50, hydrazine, NTO, IRFNA/nitric acid in general, HTP (High Test Peroxide), kerosene, etc. Cryogenic tanks gain heat and lose propellant slower than normal; command module tanks are extremely well insulated and lose propellant very slowly at the cost of being very heavy. Realism Overhaul has ZBO (Zero Boil Off) tanks somewhere, and for RF-Stockalike, there is this mod, which can eliminate boiloff completely from cryo tanks. EDIT: The cryogenic propellants I know of offhand: liquid hydrogen, oxygen, fluorine, ammonia, and methane. They tend to be reserved for launch vehicles, which are used up within an hour or two of launch, after which the lower performance and higher cost storables take over.

He wasn't asking for how to achieve a polar orbit. As point of fact, the stock game doesn't even give the orbital parameter of interest, longitude of the ascending node.

To elaborate a bit, there are five orbital elements to specify the shape and size of an orbit, with two more to specify where you are in that orbit, for a total of seven orbital elements. For something to be coplanar, you not only have to match inclination, but also LAN (Longitude of the Ascending Node). This is, by the way, very much related to specifying x,y,z coordinates, velocities in x,y,z, and a time of observation. For an elliptical (non-escape) orbit: First, one defines a plane of reference (usually the equator), and a direction of reference (in the real world, usually the First Point of Aries, in KSP, a random point in the skybox). Semi-major axis defines the size of your orbit. Eccentricity defines how oval vs. circular the orbit is; for elliptical orbits, the range is 0 <= e < 1. If e=0, it is perfectly circular, with higher values indicating a greater difference between apoapsis and periapsis. Inclination is how tilted your orbit is with respect to the equator, with values from 0 to 180 degrees. Longitude of the ascending node (LAN), AKA the argument of right ascension, is the eastwards angle from the reference direction to the ascending node. This is the primary difference between your two orbits, and represents where the tilt (inclination) is, on the equatorial plane, with respect to the reference direction. Argument of periapsis (AOP) is the angle (along the orbit) from the ascending node to periapsis. This represents the relative positioning of the semi-major axis (eccentricity) with respect to the equator. As promised, these five elements represent the shape, size, and orientation of an orbit. If SMAs are equal, they are isoperiodic (same orbital period). If inclination and LAN are equal, they are coplanar. If all five of the above are equal, they follow the same orbital track... but might be at different points on that track. Mean anomaly at epoch (MAE) defines how far along the orbital track the object was at an arbitrary point in time called "epoch". In KSP, this ranges from 0 to 2*pi. Divide your orbital period by 2*pi, multiply it by MAE, and you get the number of seconds it would take to travel from periapsis to the vessel's position at that arbitrary epoch. Effectively, it's an offset from periapsis at an arbitrary time. Epoch is that arbitrary point in time; in the real world, there are some common epochs such as J2000.

Not even remotely helpful critique. There is precisely no indication of what he might improve on, what he's done well, etc. Impressive. I suspect it's an optimistic estimate, but it's still a quite significant improvement over PV cells. A few figures for PV panels that I've found: Juno solar panels: About 0.04 kW/kg Wikipedia's estimate for current state-of-the-art: About 0.077 kW/kg SLASR (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.474.2067&rep=rep1&type=pdf) : ~ 0.36 kW/kg Ultrathin perovskite (without ancillary equipment such as the support structure: https://www.nature.com/articles/nmat4388): 23 kW/kg (PV cells only) It may also be possible to extract additional energy via thermocouples attached to the back of the panel, extracting electricity from the heat rejection system. Overall, based on the SLASR results, I think it would be realistic to hit 0.5 kW/kg for PV cells, possibly in a hybrid PV/TEG arrangement. The relatively conservative 1.8 kW/kg figure is still significantly higher than this, and I'm given to understand the final 96 kW/kg figure is based on a fair number of technologies that are nowhere near production ready... and while I could be mistaken, there's a couple things I'm not sure of for that*. *First, 10 micrometer channels for gas could produce significant flow issues, and might not work as expected. Second, I'm not sure you actually accounted for the mass of the mercury vapor used in the system. What the analysis suggests to me is that a solar-powered turbine could produce more power per kilogram than PV cells, at the cost of far more moving parts, and possibly being more sensitive to reduced solar insolation. There's a few scenarios where this could be useful. First, if the solar turbine is less sensitive to the van Allen belts than PV cells, one could imagine using those instead of PV cells to power ion engines out of LEO. Second, it could be used for power-intensive applications such as driving ion engines, with PV cells used during coast phases to reduce wear on the moving parts of a turbine.

Are you playing with mods? For example, with Real Fuels installed, tanks are empty by default.

Would never happen. First, the planetary protection officer would have the launch cancelled. Second, it'd need a heatshield and Earth communication equipment and basically need to become an expensive probe, not an amusing mass simulator.