Best way to deflect any talk of sanctions is to say like this : "Mr Putin's foreign policy advisor Yury Ushakov said the situation was \"rather insignificant\" and should not influence relations with the US."
FTFY. Double quotes inside a double-quoted string must be escaped.
And where does the payload land on the 1-in-100 launches that the orbital insertion motor fails?
Pretty much the same place as the payload on a current launch if its insertion motor fails. Were you under the impression rocket-based launches don't use insertion motors?
Not quite. Current launch technology (read: rockets) are powered through much of the atmospheric flight. MECO occurs outside the atmosphere, and the craft's flight path takes it over uninhabited areas for the thousand KM until it is outside the atmosphere. Therefore, at no point is the vehicle on a trajectory such that if it looses power, it will intersect the Earth in an inhabited area. The balistic tragectory of the 'Slingatron', however, does bisect the Earth at roughly (due to atmospheric drag) the same place where it was launched from. Also, one needs to take into account the possibility that the payload will leave the muzzle at lower than expected velocity. Thus, an entire great circle of the Earth, several tens or hundreds of kilometers wide, potentially falls within the craft range.
The insertion motor isn't necessarily a single-purpose item; for example, the Shuttle used the same motors for insertion that it used for the rest of its on-orbit maneuvers...but one way or another, you either insert or you come back down.
Yes, I am aware of the functions of the OMS. And I believe that there was an abort mode for failure of the OMS, though it was not an OTA.
TFA points out that it will have to have an orbital insertion motor on board.
And where does the payload land on the 1-in-100 launches that the orbital insertion motor fails? At what speed, with how much kinetic energy, does it hit?
Note that current space vehicles, even man-rated ones, have about a 1-in-80 failure rate.
Or a PS/2 connector that the user tried to force in by twisting motion instead of just looking at the end to determine which way to put it.
I once watched in horror as a Post Office clerk did that to her keyboard (nice Cherry switches it looked like) while I was in line. She was forcing and twisting for a good ten seconds before I snapped and stopped her. The pins looked like my daughter's braided hair. I was able to straigten them out by sliding a mechanical pencil without the lead over each pin and carefully bend it back to place.
Troll of the week! Nice!
Running an SQL update statement without a where clause and seeing '47,982 rows updated'.......bonechilling
I've done this. Now I talk to the interpreter like this:
where ^a delete from table ^e name='bill';
Now my biggest fear is getting the ln and tar order of arguments correct, lest some huge directory get replaced with an empty tarball or going-nowhere link.
What could possibly go wrong?
Why didn't somebody tell me my ass was so big?
This is very misleading.
It is rather misleading when these scientists turn to their ladyfriends and say "Come on baby, give me a little head".
Then the only question remaining is whether we should trust you.
Maybe you can, maybe your can't, but there is nobody that you can trust _more_ than Eric Paris. If the NSA has gotten Eric's compliance, then there is no where else for you to turn: not to Microsoft, not to Apple, and not to any of the BSDs.
Hi Eric! As much has I appreciate your competence and your attention to detail, is it not possible (or even plausible) that insidious code such as that found in The Underhanded C Contest might have been passed in under your nose?
Of course, it is reasonable to assume that the SE Linux code would be especially vetted for backdoors, and thus other areas of the kernel might make for less-eyes-looking-for-issues cover for a backdoor. But considering how much code goes into the kernel, is it not possible that some innocuous-looking code may have gotten through?
Of course, if SELinux or any other component is compromised (or the hardware), then it is safe to assume that _no_ operating environment is any better off.
I just signed up with these guys about a year ago:
https://www.exascale.co.uk/
I'm stupid happy with them. If you want, I can set you up with my own reseller account with them. I won't even charge you for the month or so while you get stuff up and running. Once you're happy with the way things are going, I'll charge you cost for the server space, if it is a non-profit that I agree with. Who is the non-profit?
I'm also a developer by trade, so though I won't commit to doing 'free work' I will happily help with some technical issues or advice if need be.
Moon-LMO shuttle
LEO: Low Earth Orbit
That is a nice dream, but Low Moon Orbit does not exist. The moon's gravity is too lumpy for that. You either land on the moon or crash on the moon, you don't orbit it. At least, not for more than a few weeks and even that demands considerable fuel expenditure in the form of station-keeping.
If possible, I would try writing unit tests for the existing code. This tests your understanding of what you are reading and will come in handy later if you change the code. If unit tests already exist then I suggest that you read them since they will tell you the intention of each function.
Unit tests are a lot like documentation: they will tell you what the code is _expected_ to do. (Not what the code actually _will_ do, especially in corner cases). Thus, if you are already digging in to see what any section of code is doing, document what you've found: write a unit test.
And lo, yea though ye shifteth right 8 bits, counteth not thy sign as verily carried henceforth unto the int8_t.
16 bits is right out.
If you want to put yourself on the map, publish your own map.
