Somehow spaces in file names have not been a problem for my command line use on Unix for many years now, and I don't pay much attention to them. Perhaps, just perhaps, whoever grumbles about that doesn't know any better?
I don't have many grudges with CP/M, but I remember using PIP, CP/M's file copying utility, and thinking that its command line syntax was utterly stupid. I was a 6 year old kid back then. That's one of the few opinions I've carried for most of my life. Sure, once you tried out the various incantations it'd accept (or read the fine manual), it was something you could learn, and I quickly became proficient, but it was needlessly counterintuitive for no good reason at all. When I first tried using it, I expected something that later tuned out to be the syntax that Unix cp and DOS copy would accept: cp source destination. Somehow that seemed like a natural syntax, even though I used CP/M before I even knew that PC/DOS existed, and I'd have my hands on a Unix machine almost a decade later. I've used CP/M, PC/DOS and MS/DOS, VAX VMS and IBM CP/CMS before Unix in fact
Cha-ching. This also means that it can't be true, and it can't be anything in between. It's utterly useless in that sense.
It's hard to claim whether something is possible or not if you don't even know what the text means in the first place. Taken at face value it reads like patent nonsense. So you have to "interpret" the text. Once you do that, all bets are off.
To me, the question of whether anything in the bible is accurate (scientifically, historically, etc.) is essentially moot. The text, as-is, is not usable in answering any such questions. It's almost meaningless in this respect.
The so-called big data can replicate the "data" to each node, thus alleviating the interconnect requirements - most "big data" analytics is highly parallelizable with no interconnect. When you're doing big matrix inversions, the communications needs scale with the number of matrix elements...
The crypto is for the spacecraft control and for the vehicle mission termination systems. All subject to export controls and possibly using classified protocols.
It's not even about who controls what - it's simply that all the risk is on OSC. They have to pay for the engines whether they blow up or not, but they will eventually go out of business if their launch vehicle keeps blowing up. The subcontractors have very little risk passed onto them.
Given that the fuel "pumps" on rockets are rather highly stressed turbopump units, there's no way to discount a mechanical failure there. It's awfully easy for a compressor or turbine disc spinning at 10k+ RPMs to rip everything nearby to shreds when it decides to shed a blade. Of course it could just as easily be a failure in the combustion chamber or the piping, but yeah, it was clearly a mechanical failure. I just don't understand why you so offhandedly discount a turbopump unit failing.
Everything depends on whether you can estimate mission failure probability from the engine failure alone. Other things can go wrong too. I'm always worried about the software destroying their mechanically perfectly functional rocket in the style of Ariane 5's maiden flight.
The fuel "delivery" system is basically pipes and tank pressurization, if any. The fuel and oxidizer pumps and turbines that power them are an essential part of the engine. We're not talking about cars with their puny ICEs that can run with a gravity-fed carburetor. For reference, the F9 v1.1 1st stage pumps have combined flow rate of 1500 L/second.
Everyone expects things to go bang eventually, no matter how careful you are, Musk is no fool here. I'm sure that SpaceX fully realizes that their number will come up, sooner or later. That doesn't make Musk a fool. Their success rate is still an order of magnitude better than Orbital's.
Again, for the last time, it's not NASA's business to build stuff, and it never was. NASA is there to fund contractors that build stuff, and to design, plan, oversee and execute various space missions and research. NASA's problem isn't bureaucracy, it's the lack of flexibility in spending the money the way it'd wish to spend it. NASA is highly limited in how it can spend the money, so much so that it isn't funny. The reason for this is known as pork. That's all there's to it.
The pumps are almost by definition a part of the engine. It's not like a fuel pump in a car, with its rather puny flow rate. Those engines are fed literally tons of fuel and oxidizer per second, and there's no stand-alone power source to deliver the megawatts needed for the pump. Both the turbine and the pump are an integral part of the engine design.
Sure they could do that, but there's simply no cloud provider out there who has sufficient connectivity for the needs of a supercomputing system. The stuff one runs on a supercomputer would completely saturate the normal "cloud" datacenter interconnect, while leaving the nodes hopelessly underutilized. Serving web apps and doing large-scale computations have very different scalability requirements. That's why it's easy to scale a big cloud storage/app serving facility, while it's really hard to scale a supercomputer.
The grid that NASA used for those Neptune weather predictions probably had a cell the size of a large Earth country, or a small Earth continent. Neptune is fucking big.