The norm for big software companies seems to be: you have some number of open reqs for your team, and you're eager to fill them (both to get the work done, and because the might vanish). So you work your pipeline as best you can, interview anyone who passes a phone screen, and hire anyone who passes the interview. At most places I've worked, we end making an offer to about 1 in 20 people we phone screen (about 1 in 3 who we bring in); where I am now we make an offer to about 1 in 5 we bring in, and they don't always accept of course, so that's maybe 50 people who look good enough to phone screen to hire 1. You're much more likely to have too few qualified candidates than too many. Normally, if you end up with an extra guy you'd like to make an offer to, another team will be delighted to take him.

None of my games that came on floppies are still playable. About half the games I have bought on CD/DVD over the years are gone or don't work now (I seem to move every few years, and long-distance moves don't always go well).

Heck, I've bought MOO2 three times now, once on physical media, once from some now-gone download, and once from GOG. Now that it's on GOG I'm very happy. (The games I'm most frustrated with are Fantasy General and Space general, as my media doesn't seem to work and no one has them for download - GOG has some of the Panzer General games, but not these sequels).

Meanwhile, I've bought hundreds of games on Steam, and all but a handful still work (some depended too heavily on GameSpy). Maybe Steam will itself vanish one day, but the risk of that seems lower than the risk of a box being lost the next time I move, or simply no longer having an OS or emulator that I can get to work with older games.

That's certainly true, on both counts. Has nothing o do with physical media though - if the game is written to need a server even in single player mode it's crap no matter how you buy it. But fuck EA in any case.

Just imagine what happens if you lose or damage your physical media. That's happened to me about 20x as often as the download servers being unavailable - and the servers came back. Especially for older games, where I'm happy to pay again for someone to port it to a modern platform (GOG FTW).

Buying anything with "always on DRM" is foolish of course, but you get that with physical media as well.

I'm pretty skeptical of that concept (for geopolitical reasons if nothing else), but yeah, it at least seems possible. Space elevators don't just require the unobtanium cable, but a counterweight made of pure handwavium to avoid energy stored as oscillations in the cable from building up to catastrophic levels over time.

But I do take the idea of robotic asteroid mining in high orbit seriously (at least for fuel, a nickel-iron asteroid is something else), as there's so much ongoing, related, high-budget research happening today for military, industrial, and commercial robotics.

And this doesn't happen by accident. Every component self-identifies in some way during POST, or during Windows plug-and-play scan. Driver INF files list the ID strings to match against. Building a knock-off that identifies itself as the "real" product to avoid driver certification is an old trick, but at least it's understandable why someone would do it. Deliberately building a component that identifies as an existing product, but needs your own drivers? The mind boggles.

That's a bizarre way of looking at the problem.

Sure, the fuel cost is a pretty trivial part of rocketry today, though it's more for high orbit. I believe LOX/Hydorgen fuel is about $10K/ton. That may be a NASA markup cost, I suspect it's rather cheaper for the Russians and Chinese, but still this stuff isn't like jet fuel - it's takes a considerable multiple of the energy of the fuel to make the fuel. It'll never be the sub-$1000/ton price of jet fuel.

You need about 60 tons of fuel to get 1 ton of payload into high orbit IIRC (if we're building anything interplanetary, you're paying that fuel cost one way or the other), so just the fuel costs alone (of lifting the "payload fuel") are about $600K/ton conservatively, but maybe half that cost on the cheap.

Current high orbit payload costs are about $18-36M/ton. SpaceX is shooting for 10% of that, and that certainly seems technically possible, but far into the land of diminishing returns. It seems quite fair to call $1M/ton "dirt cheap" (even if we somehow one day reach half that, it's not changing the game much).

So you're still looking at around $1B for each 1000 tons of fuel in high orbit.

Who said "colony"? Are a bunch of robots a "colony" now? Have we already "colonized" mars? The tech development from current vehicle automation and manufacturing automation to fully automated mining is of course non-trivial, but it's probably on the order of the several billion it would take to capture an asteroid and lift many tons of robots to high orbit, and there's certainly a market for fully automated mining here on Earth (and better autonomous vehicle programming, and better industrial automation in general).

Sorry, it's just never going to be "cheap" to lift thousands of tons of fuel into orbit. Lifting bulk raw materials into high orbit is just silly - the bulk raw materials are already up there, and landing a payload on an asteroid isn't science fiction any more. The robotics would break new ground, but that's a 1-time research costs with immediate commercial benefits.

I don't think that's really the fastest way - the blocking problem seems to be radiation killing you on the journey. There are risks of the form "20% of the ships won't make it" that people might be willing to take, but barriers of the form "no one can make it alive, or at least not healthy enough to do anything once there" aren't about risk taking.

We need cheap fuel in orbit more than anything else. The ability to send very heavy payloads to Mars would go a long way towards the current blocking issues. I'm not sure "dirt cheap" rocket launches to orbit will ever be cheap enough for this scale. However, dragging a CHON asteroid into orbit and building a robotic fuel processor on it would make fuel quite cheap (and if we can solve the latter problem, the problem of how to move a CHON asteroid is solved too).

This is a low-tech "bigger hammer" solution for everything but the robotics aspect. Viewed as simply a robotics engineering problem, it doesn't seem that far-fetched: automatic mining of a soft surface, and repairs on a refinery that can make usable fuel from messy inputs (doesn't have to be great, high-purity fuel, as we'll have a remarkable quantity of it already in orbit).

"Precedent" implies this is the first time something like this happened. The trend is quite clear: don't depend on anything offered by Google for your business, as Google will just take it away at a whim. It's one thing to use their service opportunistically: this week they're the best choice, but we could use someone else next week. But to build your business around a Google service shows you're really not paying attention.

Complicated how? It's the simplest way to manage lightweight containers at scale. It's not about what happens on any one machine (that's a well-solved problem), it's about fleet management in a way that decouples the hardware from the needs or the software, without the overhead of a full OS per container. I don't think it adds much value at the scale of a few machines, maybe not even at a few dozen machines.

It's designed to solve a deployment problem, not a security problem. People really like VMs for managing deployments - everything together in one image, no conflicts to resolve, very easy. Images can be shared internally or in an open-source way. Docker gives you that with far less overhead, so if you have a lot of very small "servers", you can cram them together in a VM (just like with jails), but without the security of VMs or jails.

For a single server, jails just seem better, but for managing a fleet, especially in the cloud, Docker has the infrastructure built.

Sites where you can buy the special green markers for the edges of CDs? And directional speaker cables? Are your interconnects "danceable"? Maybe you didn't pay enough.

Oh, I agree, if you're just doing simple stuff where you just have some web form that "looks like" the backend storage, without complex logic in between, and no scale concerns, there's little enough difference. You're barely writing any business logic in the first place, so any tool will do, and Java has better frameworks.

In a sense, Java frameworks are a great programming language where they make sense, but they're only tangentially related to Java. Solving complex problems with the raw language, however, is where Java is constantly irritating compared to C#.