cpast

There is no "best in general." Some cargo is time-sensitive. Some cargo actually has to go to a destination in the middle of cities. Last mile delivery is best served by small vehicles with lots of flexibility (i.e. trucks), unless there's a *lot* of cargo going to one place, in which case a better facility makes sense. Most cargo is not time-sensitive, so you can have huge advantages by making most of the trip happen over highly efficient bulk modes (trains, ships) using intermodal containers. Any attempt to make a "balanced" one will be worse at just about every task compared to a more specialized thing. The aeroscraft is utterly awful at last-mile delivery, because you need to land it somewhere (and good luck doing fast loading/unloading without infrastructure; it's simply not possible with any mode of transportation). With a 250t load, it's not *for* that, it's for use in the middle of the transportation pipeline. It might be great at heavy cargo delivery with less infrastructure than other means. Large aircraft are a decent balance of speed (way over 120 kts) and capacity, but need an airport plus freight handling capabilities (and aren't suitable for direct delivery of goods). Smaller aircraft can handle small quantities of goods extremely quickly, but can't do capacity. Ships reign supreme for capacity per dollar. Freight rail (which can handle *thousands* of tons per train) is great for getting lots of not-time-sensitive cargo to a place near its destination, or (with heavy infrastructure, but lighter than an airport) to its destination. Trucks are flexible and suitable for last-mile, but have low capacity (need one driver per container). Aeroscraft would at best find a niche of its own.

Not really. A car thief firing beams at a helicopter to avoid capture is more like someone tossing caltrops on the road behind them -- it causes risk (and unlike airliners, a helicopter chasing a car has a *much* more increased risk to dazzle, because helicopters are less stable and they're flying lower), it's not like shooting a gun at pursuers (classing it as attempted murder would be rather excessive), and it's for the purpose of escaping the cops (doing things to stop the cops from chasing you is illegal). A stupid kid isn't trying to interfere with a pilot by shining a laser at them; if you're *trying* to interfere with a pilot, that's a much more serious crime (and rightly so), because you can't claim "I didn't think it would cause any harm." It is not safe to shine a laser at a police helicopter pilot flying at low altitudes. It is not innocuous. It should be punished reasonably severely.

Does hiring cost also depend on rep? It seems like it *should*, because a program with a great reputation has an easier time convincing people to work for them. But that might also be a strategies thing (like the spending-rep-for-cheap-parts strategy).

If reports here are anything like other forums I've seen, all a report inherently does is notify moderators that something might be a problem; the actions taken are decided independently by the moderation team just like if they'd seen the issue themselves (aside from reports like "this is my thread, can you please close it").

Personally, I'm more interested in the hand-drawn avatars.

Even assault doesn't really fit. In most cases of lasering aircraft, the person lasering the plane doesn't know it's an issue. That's exactly why the US added the specific section for "pointing a laser at a plane" -- it turns out it was hard to get other charges to stick in US court in many cases, because you had to first show that they knew that the beam could even *reach* the plane with enough power to affect anything, and then that you knew (or should have known) that it could cause harm to the aircraft. Thus, Congress passed a law to make it illegal to aim at a plane or at a flight path, without requiring that you know that your laser pointer can affect the aircraft at all (because it's a lot easier to show you intentionally aimed it at a plane or a flight path than it is to show that you tried to *hit* a plane). This is possibly US-specific, though; other countries may differ on how easy or hard it is to prove this sort of thing.

Highly depends. You can't make attempted murder stick for it in any but the most extreme cases, because you need to show intent to kill (and most people don't know that pointing a laser at an aircraft *can* kill, let alone do it with the intent to kill). The actual crime in the US is the aptly-named "Aiming a laser pointer at an aircraft," which is a felony (max 5 years). Anything more requires showing intent to hurt someone or interfere with a flight, which normally isn't there -- most people who do this are just having fun, and don't know it causes any problem at all (it's hard to convict someone of assault or attempted murder if they don't think their laser beam will even reach the plane, let alone cause any harm). At the federal level, it has the same max sentence as grand theft (5 years), but I'm not sure how actual sentences stack up between the two. If someone's *intentionally* interfering with a flight, it becomes much more serious, and has a much longer max term -- intentional interference with flight crew has a 20 year max.

Are you sure it's showing airspeed? Ground speed depends on winds aloft, which can be very fast (and so have a huge impact on ground speed).

Not really. The Dreamliner is maybe a *bit* faster optimum cruise than the 777, but it isn't way faster. Most widebodies like to cruise between 0.80 and 0.85 Mach.

The specific date is a combination of budgeting, age, and intergovernmental relations; it's set by agreement between ISS partners. There's never a firm predictable cutoff date; it's just that as the years go by, maintenance becomes harder, things get less reliable, and it starts becoming a better idea to just start over. And I do think they'd start over, rather than do module-by-module replacements, not least because the oldest modules are at the center of everything. With all these programs, there has to be *some* cutoff after which you don't send more crew (unmanned craft get away with running till failure, manned craft do not). You can't really do a full overhaul in orbit for a sane price (this is one of the issues with reusing modules for a Mars mission); at some point you decide to replace instead of repairing. This takes a lot of planning and prep work, so you want a good deal of advance warning (hence the extension to 2024 coming 5 years before it was planned to end in 2020). It might get extended more as budget permits and NASA and Roscosmos feel like continuing it, but I don't think it's likely to get extended much beyond -- maintenance and operations are a big chunk of the cost, and a new station allows starting over with lessons learned from ISS (like ISS started over from Mir).

You're underestimating the cost and difficulty of converting an ISS module for a Mars mission. Like, by several orders of magnitude, based on the "tool box" comment. I'm not sure where you get $50b from or why it has any relevance to this discussion: most of the ISS simply could not be used, the parts that could would need modification to support it (because the mission they're designed for is not the mission of a Mars transfer stage), and unless you can extensively inspect the modules (which is rather difficult in space) you will still have serious trouble meeting safety requirements. What's cheaper than using the things already in orbit? Having the parts down on Earth where assembling stuff is relatively easy, and where the parts are actually designed for the job. You don't seem to understand this: The ISS is not capable of independent operation. It needs resupply. It needs evacuation procedures. Much of it has spent over 10 years in orbit; parts of it are approaching 20 years. Its component pieces are not designed for, and are not capable of, the reliability needed on a Mars mission. They never needed to be, because there was always an abort option. They routinely require spare parts to be sent up, because the entire station was designed for a mission in LEO where resupply is possible. Its component parts might be considered reliable enough to continue operating in LEO past the design date. Operation in LEO is easy -- there is an easy abort option. A Mars mission cannot rely on that, nor can it rely on the ability to send up replacement parts. Space hardware is expensive. Part of the reason is that it has to be designed within very tight parameters, and is highly specialized. The ISS is specialized to be a LEO laboratory. Its modules are designed to support a crew and science in LEO. Trying to turn them into something suitable for a Mars transfer, while they're in space? That's the sort of thing that, while it might initially sound frugal, ends up being a massive budget-sink.

Yep. When the ISS is decommisioned (2024, not 2020), it's because its getting too old. That is the *worst* time to fly it on a manned mission with no evacuation possible and no resupply possible. Component reuse on the older components is not practical because of age; IIRC, most of USOS isn't designed to be able to operate separately from the ISS. Spacecraft are not Legos. You can't just pop something out of the ISS and pop it onto a different mission for which it was not designed; integration is difficult and expensive when two things *are* designed to go together, let alone when they're not. Bringing things into orbit isn't *that* expensive compared to the cost of retrofitting an aging module to work with new systems reliably enough that it can be used on a manned mission with no abort modes.

Yes, too complicated. One of the most important things in engineering is knowing when something isn't worth sinking more effort into. The ISS would cost more for worse results compared to building Mars transfer equipment from scratch. To answer your acceleration question: Acceleration is absolutely relevant; it controls what kinds of maneuvers you can pull off. The ISS can't take much acceleration; if you can't do much acceleration, you can't pull off the trajectory used on most Mars trips. This is particularly a problem on ejection and capture burns. The ISS can't aerocapture and can't pull off a Hohmann capture burn, so it has to follow a different trajectory than other Mars missions (the way Dawn did capture was to approach at low relative velocity, which required a different trajectory than you're used to seeing). In contrast, something that could pull off aerocapture would have a huge dV savings. This is, of course, leaving aside that the ISS isn't designed to operate without resupply; it's getting fairly old, which you don't really want on your interplanetary spacecraft; it's not designed or allowed to operate without the ability to rapidly evacuate all crew to safety (and while they haven't had to do that yet, they have had emergencies that required preparing for an evacuation if needed); it's a highly specialized orbital lab with the ability to receive new experiments from resupply ships, and is designed with the assumption that it'll be doing that (swapping experiments in and out, rather than having just long-term experiments), which is not what you want or need in a one-shot Mars trip; and it's currently performing lots of good science in Earth orbit, which we'd lose if we sent it off to Mars. I really can't think of any reason why it would be a good idea to take a highly specialized (and aging) LEO laboratory and send it off as a transfer vessel for a Mars mission, which has different requirements. The ISS was designed for a job. It does that job fairly well. Said job is more valuable than anything it could do in Mars orbit (because there's not all that much difference between LEO and LMO, and scanning-type experiments can be done at least as well with a probe, but in LEO it's way more accessible). There's no such thing as a "little rearranging and adding some fuel" in real life; real rockets aren't Legos. A Mars transfer ship should be built as a Mars transfer ship, not retrofitted at great expense from something doing a useful job.

That may or may not work, depending on the SOI change code. How does the code know you should have changed SOI? Does it detect that you *did* change SOI (and so step back through the full trajectory), or is there some more complicated way? If the former, you can't use it for planets, and it won't stop you from timewarping through a tiny bit of an SOI without a forced slowdown (if you would enter and leave it in the course of a single tick, I think it wouldn't notice that you should have changed SOIs). The issue with the planet isn't that the player will smack into it; it's that the player *won't*. I have had missions where I was approaching Kerbin at high speed and max warp, on a trajectory that intersected the ground, in which I passed from the altitude with no timewarp restrictions *through* Kerbin within the span of a tick. I should have smacked into Kerbin, but I was apparently flying fast enough to go through a planet without stopping. To expand on what 5thHorseman said: When you're in a closed orbit that's above the atmosphere and doesn't enter any other SOIs, there is a closed-form expression for your location and velocity at any given time. The orbital parameters need not change (and I don't think they do); there's no need to even bother storing the calculated location for use in future calculations, because you can throw it out and recalculate position from the orbital elements (which didn't change) and time at the next tick. Rails orbits, if they're implemented decently, cannot go unstable.

I have that model throttle, pedals, and a CH Fighterstick. I don't fly lots of KSP planes, but what I did find it excellent for was controlling an orbital tug's RCS: I used the stick for roll and pitch, the mini-stick on the throttle (the throttle there has a small analog stick that you can control with your thumb) for left/right and up/down translation, the pedals sliding for yaw, and the toe brakes for forward/backward translation. It made things *much* easier to control, using it as essentially a six-axis control unit. One of the nice things about CH is that they have a pretty decent control manager, letting you set up your logical controls however you want regardless of the physical controls (e.g. I had all of those axes on one joystick as far as KSP was concerned, which included combining the two toe brakes into one axis via a script). If you have all CH sticks, then you can have this mapping include all of your sticks and the like, and can use different modes that you can switch between on the fly that change how real axes and buttons map to logical ones (the green light in Ten Key's picture is the mode indicator, which works if you have one device and use three modes, but can be inaccurate and useless if you have a more complex layout, in which case you need to remember the mode). That means that even though KSP doesn't let you easily remap controls in the middle of a flight, you can have several preprogrammed control layouts that you switch between.

I actually did look them up, and both of them trace back to Akamai, not the FBI or NSA (www.nsa.gov uses one of them in my location, but it's an Akamai system that's acting as a CDN).

I hadn't played Simcity 2013 (I am, however, apparently the one person in the world who kind of liked Societies, although I didn't consider it to be a "real" Simcity game), but I so far love Skylines. Still basically in the grid mindset, and a bit frustrated on how annoying it can be to zone new areas, but overall it's quite fun. Favorite bit: setting up public transit routes, with bus stops that don't require demolishing houses or building anything but a depot (if we could only get on-road subway, that'd be even better, but I can see why it's good to have metro need to build the stop). One of the main annoyances I had with IV was that I couldn't channel sims into multiple modes of transit (e.g. bus to the subway stop, subway to a rail station, rail across the city). The one thing I'd most like to see is a way to not start from scratch each time. In 4, there was the big city tutorial (medium-sized but unpleasant city, which you could follow the instructions for but which you could also build on to improve), and there was regional demand (i.e. instant mega-demand that let me take a city to like 500k in 40 minutes or so). Managing and improving a big city is different from growing a small town, and I'd like to be able to do the former without really needing to do the latter first. I know Workshop has premade cities, but something officially endorsed would be nice. Alternatively: Anyone have Workshop stuff to recommend? Particularly something like a medium-sized city that needs to build up and be improved, not built out? - - - Updated - - - The one issue with that is that it can be hard to initially build the grid -- you need to build a road the *exact* right length to be able to make a corner with another road, and it's hard to get the zones to have high efficiency. OTOH, it is making it easier for me to build parks and trees and such, so not all bad.

Eh, that also happens for every other holiday.

What do you mean by a robotic colony? Like, full man-rated equipment, but running entirely on automatic? Or like a few robots landed at the same point (e.g. one is a heavy powerplant, one a battery-powered rover that goes there to recharge)?

Replace biometrics with "passwords." Add that in practice, passwords are routinely reused; that passwords, unlike biometrics, are actually passed on to sites you use them for (a properly-made biometric system doesn't ever send biometric data to the site), which means you rely on every site to be properly storing passwords; that passwords are very low-entropy; that plenty of people will gladly send their password to a site that looks kinda legit that they clicked a link to in an email; and you come to the conclusion that passwords being secure against attack doesn't mesh with humans being human. Training does not help, because people don't actually change how they use passwords according to training (more often, they learn rules having no idea why those rules exist, and so they work around those rules while completely subverting the purpose). Furthermore, it's questionable whether stealing biometrics helps at all, because biometrics have to be presented to the physical scanner. You know how password managers work, with separate high-entropy passwords for each site, unlocked by a master password that is memorized? That's the way to do biometrics; with things like the iPhone, that's how they're done. Biometrics are meaningless outside the tight loop between scanner and processor; you cannot present a biometric login remotely. Biometrics instead replace the master password, in a way that actually is getting people to adopt them. Remotely cracking someone's DNA doesn't work if the only thing that accepts that DNA is their laptop, which is stored far away. And this can be done in general with technical means; you can't force people to use good passwords with technical means. Remember: The alternative to biometrics isn't long random passwords, different for each site, and all either memorized or stored in a password manager with a strong memorized master password. It's people using "GoRed$ox2004" on all the sites they use.

"Public agency" is a synonym of "government agency." NASA is, and always has been, government-run. So is every organization referred to as a "public agency." In fact, the fact that it's government run is the reason FOIA applies, and you can generally get NASA information (except when limited by arms-control regulation). NASA was created by the National Aeronautics and Space Act of 1958 (PDF), specifically section 202 ("There is hereby established the National Aeronautics and Space Administration.") From its beginning, it has been a government agency. It is the successor to NACA (National Advisory Committee for Aeronautics), which was also a government agency (created by the Naval Appropriations Act of 1916, "An Advisory Committee for Aeronautics is hereby established.") There has been no point in NASA's history in which it was not an agency of the United States government. Being referred to as a "public agency" doesn't contradict that, because the terms are synonymous.

Biometric indicators on properly designed systems never leave the system in question. They're stored in tamper-resistant chips, which will not reveal them even with physical access (they check that a submitted thing is or isn't equal to the stored data, but don't reveal their stored data). They never leave the trusted system. Passwords *must* leave a controlled system, because they're sent in some form over the Internet and because users know them. Biometrics are not known to the users, and never have to leave the controlled system. This makes them just about immune from remote theft. In your response to "just use a password, don't use both:" Passwords are terrible security devices for humans. Seriously. They have some things they're good at, but many things they're bad at. Biometrics are poor security devices. Their weaknesses largely do not overlap. Password+biometric is far, far better than either alone. Biometric is better than password for an average user, because an average user's password is really awful and they've shared it with a half-dozen places (if even one of those places has poor password management, you're in trouble at all of them). Passwords, well-used, are pretty good. Biometrics, well-used, are decent. Users do not properly use passwords. Users are more likely to properly use biometrics.

Nothing; you cannot use biometrics with an untrusted scanner, or it changes from "something you are" to "something you know". That's why biometrics don't generally send a thumb pattern to the server; the way this is generally implemented is that a key is stored on the local device, and only unlocked upon successful authentication with biometrics. Basically, the way this would likely be implemented (and is implemented on iOS, AFAIK) is essentially a local keychain. Protection over the wire is done just like it's done with passwords, with the addition of high-entropy secrets instead of low-entropy ones (alternatively, you could likely get away with using certificates to do authentication to the server). Before you sing the praises of passwords, note that they are a very, very flawed form of authentication: most people have atrocious password management, ranging from putting passwords on sticky notes on the computer (or in plaintext files), to choosing very low-entropy passwords, to giving their passwords out to people who ask. Biometrics are likely going to end up harder to steal than passwords in practice; it's really, really easy to steal passwords by getting people to tell them to you, while stealing a biometric indicator can't be done remotely.

For many years, a simple pattern has been insufficient to fool sensors. Just about every fingerprint scanner on the market has things to detect whether there's an actual human finger there, or if it's a bit of plastic. It can be fooled, but it's not trivial to do so.

The Shuttle was also, from a numbers standpoint, the most successful manned launch vehicle in history. It had more launches than any other system, in around 60% of the time it took the closest competitor to *approach* the same number of flights. This is leaving out that the Shuttle's crew capacity was over twice that of any other launch vehicle ever made, which is even more significant when you realize that having a crew of 7 opens up 5 slots for people who don't need to be fully qualified to handle emergencies in the spacecraft, which means the Shuttle could fly more mission specialists than any other spacecraft in history could fly total people. If you're complaining about spaceflight being in low Earth orbit, that has nothing to do with any particular technology; it's a factor of no one wanting to spend money on manned missions beyond Earth orbit, because there's honestly serious question about how much it'd be worth the money (Apollo got funding in large part because of PR value; it had significant scientific value, but it wasn't funded because Congress thought the science was worth that much money). Meanwhile, Shuttle was rather successful at station assembly, was also rather successful at satellite repair (see: Hubble), and complaining that it was a manned space truck overlooks that that was the entire point of the program.