More or less any industry on the moon would need a "cheap" way of getting mass to Earth. Without that, there's no point in putting the industry on the moon.
So when the BigBadBallBearing company builds their factory on the moon, they will include the means to get their products back to Earth, and those means, like many other tools, can be used for good or bad purposes.
Somewhere, there's a computer that's "Preparing to configure Windows" after it rebooted in the middle of a flight scheduling run.
Or stuck at a BIOS prompt saying "No keyboard found, press F1 to continue."
If you can't handle the distinction between murder and killing, then, again, just stop.
How do you define the difference between murder and killing?
There are many possible differentiators, here are a couple that come to mind:
Murder is killing for no reason.
Murder is killing for no *good* reason.
I'm just curious as to how you might distinguish between the two without resorting to something like "I know it when I see it".
I used to flip through SkyMall just so I could laugh (or cry) at all the stupid things people invented. I couldn't fathom how someone could invent a speaker in the shape of a rock, and then sell it for 3x the price of a normal outdoor speaker. Then there were the pet accessories, tie racks, and a host of other useless crap.
I guess I wasn't alone - people didn't buy enough of it to keep the company alive.
Now I feel better as an inventor of things that can actually be useful.
Good code must work, but looking nice is optional. Additionally, when debugging code (sometimes code you wrote an hour ago), you need to see not only the code, but what is happening in the hardware. At that point, it's irrelevant whether the code looks nice or not. It's also not always true that good looking code will work. There are errata for microcontrollers (and microprocessors, though those are usually handled at the OS/driver level), so the obvious and beautiful solution may not work at all.
Debugging is what you do when something doesn't work the way you expected. This means that, by definition, the code isn't understandable. If it were understandable, there wouldn't be a problem, right?
The Core i7 CPU the OP has should be able to do MD5 or SHA256/512 sums at a rate of at least 100 MBytes/second. (See here and here.) Any reasonably modern storage system should be able to feed data that quickly.
At 100 MBytes/sec, 1GB takes 10 seconds, 1TB takes 10,000 seconds. 10,000 seconds is somewhat under 3 hours (800 seconds less), so let's assume 3 hours per TB. With 5TB to hash, it should take around 15 hours, or one overnight plus a little bit.
Surprisingly, it's not that big a problem for a modern PC.
I would make a series of tables as you suggested, split by size. Maybe have separate tables by order of magnitude, FS<1k, 1K<FS<10K, 10K<FS<100k
After the first run, this will also provide a mechanism for determining if files have changed.
Gases occupy 22.4 liters of volume per mole of material at STP (standard temperature and pressure, which is 300 K, 1 atmosphere pressure). One mole of material weighs as many grams as the sum of the atomic numbers of the atoms in each molecule. Air is mostly Nitrogen, which is atomic number 7 and has an atomic weight of ~14. Since Nitrogen gas has two atoms per molecule, one mole (22.4 liters) of nitrogen weighs about 28 grams.
So if you take a 1000 liter (257 gallon) tank, and get it down to perfect vacuum inside, you will offset about 1250 grams of mass. (28 g/mol * 0.0446 mol/liter * 1000 liters)
There isn't much point in using vacuum as a "flotation ballast".
First, airlocks used in space are used a few dozen times at most before being completely overhauled. The docking connector on a train like this would get more than that much use in a single day, probably in a single morning.
That doesn't seem likely, since you would only use a vacuum-tunnel/4000MPH train for long hauls. Like NY <-> LA. That trip would take about 40 minutes at 0.1G constant acceleration, IIRC.
The locks would be used at most once per hour or so.
If you're thinking of airlocks, then you'd have to depressurise and repressurise the train at every station. If you actually mean a tube connected to equal pressures outside of the tube and inside the train, then you're assuming that the seal of something that can be attached and detached, can handle one side moving as the train bounces up and down slightly as people step on and off, and still will have zero leakage.
You're assuming that the vacuum tunnel goes straight into the station. If I were designing the system, I would have the train go through a big airlock or two before getting to the station, so the last mile or so would be at full pressure, and the doors could be just like airplane doors (ie, they seal, but they don't have to attach to anything on the outside).
I hope Google *does* do something to standardize hardware. Specifically, they need to define a standard connector similar in functionality to what every iOS device has.
The fact that you can make a set of speakers or a stereo dock with one connector, and have it work for basically every device out there, is a big win. I know there have been some issues with device thickness which required mechanical adjustments on dock devices, but the electrical connection is the same.
It's hard to overstate just how useful that is. Imagine how great it would be if you could get a charger / speaker set / remote control / keyboard / USB adapter (ever wanted a host port on your device
To make this work, it has to be done right. The connector spec has to include anything and everything that is likely to be useful, including some generic interfaces (like USB, HDMI, audio, charging, maybe even SATA
I can't even tell you how annoying it was to walk around at CES and see thousands of devices meant to work with iCrap, and basically nothing that was meant to work with Android devices (that wasn't made by the manufacturer of the Android device). It's even more annoying to go to an electronics store looking for something like portable speakers - about 95% of them have iPod docks, but less than half have a miniphone connector to plug into a headphone port.
Get with it, Google. The software is about equal, but there will never be a "peripheral ecosystem" unless there are hardware connection standards.
Um. This has nothing to do with the path separator and everything to do with the C language.
In C, the character '\' is the escape character. That's how you can print newlines ('\n'), tabs ('\t'), and other things. SInce the backslash has a special meaning sometimes, you have to escape it with a backslash if you want one in your string.
To get the string literal "C:\command.com" in your program, you have to declare it as "C:\\command.com" in the C source.
The reflective part of a mirror is behind the glass, so the thickness is realy irrelevant. There is a point in the fact the mirrors are not curved so some misalignment would result. It seems to work well enough though.
Actually, if he's using rear surface mirrors, then the thickness is more important.
Most glass reflects about 5% off each surface, so the energy from the front surface of the glass is not being directed at the same point as that from the read surface - it's off by the thickness of the glass. (actually, it'll be the thickness of the glass times the sine of the angle of incidence, I think)
Additionally, some of the energy gets absorbed by the glass, and the thicker it is, the more energy is absorbed.
Neither of those effects is particularly huge, but they are dependent on the thickness of the glass. Both effects are eliminated by using front surface mirrors instead.
My sister opened a computer store in Hawaii. She sells C shells down by the seashore.