No. You'd store their DNA, ship that and "grow" people after it arrives. And after the robots have spent the time necessary building the infrastructure, making it habitable and amassing the minerals, water, gases and power generation needed to sustain the colony.

The only problem would be getting the robots to let go of control, once the humans arrive.

Let's take a step back.

What would provoke a battle in space? The simplest answer (at present) would be a dispute between two earthly powers vying for dominance. In that case I doubt that anyone in the general public would be aware of what was going on and the distances involved ( a few hundred km, up and down) means that ground based energy weapons and small projectiles that intercepted the opposition's orbits would be all that's needed.

But once you get into interplanetary conflict, it's a different matter, In that case (say for example: the Earth - Mars independence war - or Revolutionary War depending which side you're on), then for a Martian attack on an Earth-orbital facility, you'd need 2 things. First is an unmanned vehicle - simple because nothing else is sensible and the second thing would be a large mass. Orbital stations would be sitting ducks as they are in very predictable paths and while stations like the ISS *can* change altitude to avoid incoming threats, it's a slow process and again: fairly predictable.

So with an unmanned attacker, the vehicle IS the weapon - there's no point waiting for it to circle back round for a second shot. Just make it large enough and heavy enough that it could take any incoming "fire" from directed energy weapons and then have it disperse into many (thousands: millions) of small pieces as it nears the target. That would provide too many pieces to successfully destroy them all - you'd only need 1 to get through and whatever doesn't hit the orbital target would deny orbits to other "enemy" facilites due to the amount of debris the Earth's gravity would capture.

And if you want to get really nasty, there's always Footfall

Given what we can do with stealth technology today, imagine the problem of even discovering the presence (let alone position, velocity and acceleration) of something that doesn't want to be found.

The only two "giveaways" would be the heat signature from its power source (not just propulsion, but life-support) and whatever it accidentally occults as it moves across the background of stars. The heat can be drastically reduced by towing the power source a long way behind the main craft and having it very, very dispersed so the Watts per square metre of I.R. are very small. The occultation problem can be reduced by choosing a path that stays away from the galactic plane.

So most battles would be ones of sneak attacks and defensive fire. It might be possible to devise some sort of A.I. mines, or even simply fire a cloud of sand in the general direction (assuming the relative velocites of target + sand are high enough, that could be all that's needed).

However, I have a feeling that most "wars" in the future, whether in space on on Earth, will be economic in nature and "fought" over decades rather than wham-bam shooting battles.

So the authors are considering a future where we have to replace all our domestic appliances every 2 years, simply because someone somewhere has decided that the control software *must* have this new feature (that nobody asked for) and that it will only run on version X. You now have 3 months to toss the old fridge / cooker / vacuum cleaner / lightbulb before it gets automatically bricked. Even though it performs its primary function perfectly.

No thank you.

An american website?I think you'll find the other 95% of the world disagrees with you.

There are more reasons.

Reports are consistent: they report the same data, in the same format thus making for easy comparisons
Reports are easily filed. Why would a manager want to waste their time learning how to retrieve past data and then learn how to compare it with stuff form other dates/times when they can simply print it and highlight what they want. Paper and disk space are cheap - their time is not.
Reports are portable. You can take them away with you, you can show them to other people.
Reports are secure. You can print them and be sure that whoever you show them to cannot access anything else. ANYTHING
Reports can be easily incorporated into a manager's "product" (presentations, summaries, proposals and archives) without them having to learn any new methods. Again: it's a trade-off between cheap IT resources and their expensive time.

And probably most important of all: reports are familiar. Never forget that IT is providing a service to the business. It's not the place of IT to dictate to the business how they do their work - it should always be the other way round.

Exactly right. Whenever I post on Linux related topics I see responses like this that are both arrogant and foul-mouthed - where neither position is necessary, nor adds credibility to the poster (or to the subject they are writing about).

The other thing these individuals seem to do is drag MS into the subject - as if they are still fighting their own little wars over some 1990's idealogical differences. But they never put forward any actual rational arguments or facts to back up their bile: just hate posts.

So sad.

Since you already have a full life, something would have to give. The amount of time you estimate to be available would get to hobby level: the same as the other thousands of amateur astronomers in the country. But it's not enough to do any serious studying, get qualified or do research to a publishable quality.

A difference between badly documented code and well documented code? Sure. The badly documented (or not documented at all) is far more likely to be buggy, fragile and inefficient. People who create software professionally take pride in their work and a big part of that is letting other people know just how good they are. They do that by explaining what the code does and by implication telling the world how experienced and smart they are.

Poorly documented stuff is written by people who think it's all "fun" and have no real clue about professionalism. They probably haven't even spent any time thinking about the structure of the problem before diving in and bashing out a couple of thousand lines of code. These people tend to be trying to prove to themselves how good they are and mistakenly associate "good" with code size or how many overly complex and inexplicable constructs they can use - in the false assumption that others will be impressed by this.

We aren't. But I've never seen an Arts or Humanities coder produce this kind of shambolic mess (mostly because I've hardly ever seen any code from non-technical programmers) and I don't believe it's something any self-respective tech. graduate would be prepared to put their name to, either.

While the two CEOs who are promoting this view both have non-technical qualifications (so: no surprise there) the article is written more as a "preaching to the choir" piece than as serious career advice.

For example: the liberal arts train students to thrive in subjectivity and ambiguity, a necessary skill in the tech world where few things are black and white I don't see that as being particularly helpful when trying to compile code - it either does or it doesn't. There is no alternative to having an executable pop out of the slot when you "win". It also avoids any notion that technical problems require technical solutions - and the only way to arrive at the best (if not "the") solution is to have a deep understanding of the technical issues and the technical advantages and flaws with each alternative. No matter how good you are at history or philosophy, you won't be helping in this arena.

So while it is quite possible for technically unqualified individuals to work at technology companies, that does not mean they will be working with (or creating) the technology the firm is based on. But it could mean that one day, they'll be your boss.

Nope. I've never even heard of it - and having read that announcement I'm still no clearer what it is, what it does or whether I should be interested in it.

However, it's not alone. There is a huge amount of FOSS that has an entire "front" web page that tells people in exquisite detail what changes have been made, who contributed, how others can get involved and what bugs are outstanding without ever mentioning what the hell the project does, or what benefits it brings the world. This just adds one more to the tally.

It may be the best thing since sliced bread, but until these projects extract their collective heads and start addressing the billions of people outside their closed, little development communities, no-one will ever know,

There are already dozens of boards available that are better than the RPi for this sort of use. Many at less than the $49 this thing is up for grabs at.

No. Learning to code is like learning the alphabet and some basic words.

Learning to be a programmer is being able to use a word-processor, having the rules of grammar, the 4 modes of discourse, a huge vocabulary and a storytelling ability fluently available to you.

"Coding" tells you the structure of a for loop. Being a programmer tells you when to use it and how to deal with the exceptions it could throw up. Sadly there are no job interviews I have ever encountered that are deep enough to split the one from the other.

Why do people rave about it? Because it's cheap.

Forget all the principled arguments: free software, "for the children", pretty coloured boxes, or hackability. The only reason people buy Pis is the price. The only thing that most of them do is them load XBMC and then brag to their friends how they got a $99 media player for fifty bucks.

We're all tarts: chasing after the cheapest price and free-est stuff. Nobody really cares whether the software is FOSS, the hardware is open source or if the PCB is made out of panda skin. If it low on the $$$$'s it's top of every geek's wishlist.

It takes as long as it does, because that is the amount of time (or money: same principle applies) than is allotted to the project. Finishing sooner makes no sense as you'd just be working yourself out of a job earlier. There is also no pressing need to have such a vehicle. It's not as if there was a killer asteroid heading this way that would spell doom - and worse: upset NASA's carefully crafted timetables.

In that situation, where there was a deadline to be met (and not a vacuous political one), then yes: I daresay the prototype would be on the pad in a matter of months. With 2 or 3 more following close behind.