That's why I said "or a replacement". At the least, the ISS can serve as a construction shack while assembling that replacement, and as a source of parts and refined/processed raw materials to expand it's replacement. It's replacement may not even ever be truly separate, it may start as new modules attached to the ISS and once those new modules have enough space the original ISS modules would be disconnected and cannibalized.

And the ISS will help how, exactly? The entire ISS came from the Earth's surface. Unless you have a really fancy plan to do asteroid/lunar mining, that's where all future materials will ultimately come from too.

Yep, it did. And yep, we will need asteroid or lunar mining of some sort to get raw materials. Like I said, we can't sustain orbital manufacturing and construction while lifting the majority of the materials and supplies from the surface, which means we'd better stop dismissing lunar and asteroid mining and such as sci-fi dreams and start figuring out how to make them work. As far as the ISS, it helps because it's there. A city doesn't just appear full-blown, and neither does orbital infrastructure. The ISS is a structure already in orbit you can expand to house more people, so that your workforce for the next step can have a place to stay in orbit rather than commuting to and from the surface all the time. It may be in low orbit, but the biggest fuel cost and the biggest constraints on weight and size aren't in getting from low orbit to high orbit, they're in getting from the surface to low orbit. And ultimately it'll end up being recycled into raw materials or basic parts for something else once it's no longer needed (for instance if the solar panels are still in working order they can be disconnected and attached to something else that needs more power capacity).

No, it's not going to be easy or simple. Colonizing North America wasn't easy or simple either, but we did it. And as for Star Trek having ruined a generation's sanity, all it did was encourage them to set a goal and then figure out how to go about getting there. Though I'll admit that attitude does seem kind of insane to the couch potatoes. Not really my problem though, my entire career my motto's been "They don't pay me to not get the job done." and the older I get the less reason I see to change it.

If the US wants to go to Mars for more than a single short mission, it's going to need the ISS or a replacement. We'll need to be able to build ships in orbit so they aren't limited by the constraints of the first hundred or so miles of the trip (lifting the ship up from the surface to Earth orbit), that's the only way we'll be able to build them large enough for the crew, supplies and equipment needed for a mission of more than a week or two. And if we want this to be a sustained thing, sending more than a couple-three missions, we're going to need to be able to build ships without shipping the majority of their components up from surface.

We can already see the parallels from large historical construction projects in the US. For Hoover Dam they didn't ship the concrete in from the nearest cities and they didn't have the workers commuting between the dam site and those cities. They set up the cement plant on-site to make the concrete from local materials and a town sprang up at the site to house and supply the workforce. For resources (silver, gold, timber, cattle, oil, etc.) it's worked the same way, people moved to where they were needed and the facilities and infrastructure to house, support and feed those people grew with the population. Because frankly you just can't run an oil field in Texas with all your workers and suppliers back in New Orleans.

The major problem with C++ is that it's popularity means there's more crap code written in it by bad programmers than any other language. But, to borrow from a quote, a bad programmer can write bad C++ in any language. I've had plenty of experience with bad programmers and bad code, and the problems rarely stemmed from the language used. They usually stem from the programmer not understanding the language or the environment and from an all-too-common mule-headed desire to design their part of the software the way they want it to work rather than in a way that fits with the rest of the software. Languages where this isn't a problem are typically new enough that there's only been one "right way" to do things taught. C++ is old enough that there's a variety of approaches built up over time, leading to the problem.

As for C++ being so popular, that's because well-written C++ can beat most other languages in performance. I've learned one thing over the decades: good engineering in software is a great priority as a developer, but from the business side it's irrelevant. Business cares that it gets the correct results and it runs fast enough. It could be the worst Rube-Goldbergesque contraption under the hood, but as long as it gave the right results and performed like a Formula 1 car they'd be ecstatic. C++ makes it easy to achieve that in the complex software common in commercial environments.

All but the first are standard items that should be covered by normal testing (they would be where I worked, at least). The first is a build-environment issue, and I'd expect Ubuntu to audit the build options for every single package they bring into the distro to make sure they're correct for what Ubuntu wants to support by way of CPUs, hardware and so on.

Yes, you can always miss problems. However, by the time we got done with QA and final testing (trial installation into a replica of production and a set of acceptance tests to make sure it was really running correctly), we were pretty confident we'd caught everything we could think of. We had a rollback plan and were prepared to use it, but we weren't expecting to need it and we rarely did need it. It was a big thing if we did, resulting in a lot of "What was the problem, how did we miss it in testing and what do we need to do to make sure we don't miss that kind of thing again?" and modification of the test plans so we wouldn't have a repeat in the future.

This kind of thing is what a beta release is for, and everything I'm hearing from the systemd team and supporters says it ought to be in beta right now getting exposure to real-world environments to nail down any incompatibilities and fix them before release.

I run servers on Linux. My attitude: if testing of a new component is so incomplete that there's still a concern for significant bugs and regressions when it goes into production, it's not ready to go into production. If I told my managers "Throw it into production and if it breaks things too badly we'll roll it back.", they'd tell me to get a proper test plan written like I should have the first time (assuming they didn't fire me for incompetence, since decent testing is both best practice and a company standard). And this is for mere application software, not a critical part of the boot process where a failure has the potential to render servers in the data center not remotely accessible.

It always amazed me that tech companies would contract this work out in the first place. Security has virtually unrestricted access to every area of the building (if they don't actually have it, they control the equipment that grants it). Janitorial has similar access, in fact probably more since people might find it odd that a Security badge was accessing an area at night but Janitorial is practically expected to be in there every night to empty the trash. With as easy as it is to gather up loose papers, plug keyloggers or hacking devices into computers (If you epoxy closed all the USB ports, where are you going to plug the keyboard and mouse in? And if the ports for the keyboard and mouse are usable what's to stop someone from plugging a dongle with a built-in hub in and plugging the keyboard/mouse into that?) and photograph whiteboards, why would any company that values intellectual property allow contract employees (who they can't control and can't screen) access? I'd have all that stuff in-house first thing, and pay the people well enough that if approached about espionage their first reaction will be to smile and nod and make all the right noises and then immediately report the details to the company because the offer isn't worth losing their paycheck and benefits over.

Kinda-sorta. They can use Google's services and pick and choose which services. That doesn't require Google Play Services or Google's apps. Google publishes the APIs for all their services, and anyone's free to get a developer account, generate API keys and create their own apps that access Google's services (as long as they don't abuse the services, of course). What they can't do is preload Play Services and/or Google's apps (which are copyrighted and not open-source) without an agreement with Google which is likely to require Google's core apps be the defaults. And frankly any suit by the OEMs like you suggest would die on the first motion to dismiss, since the locked bootloaders and locks apps are the OEM's and carrier's choice, not Google's. Google's quite happy with unlocked bootloaders and apps that the end-user can uninstall at will, it's usually the carriers who don't want their profitable deals disrupted by users removing the relevant apps. As far as forced bundling, they'd have to restrict the suit to just the all-or-nothing bundling of the apps without regard to Android itself and that's likely to fail on the grounds that none of the apps have monopolies (there's far too many alternatives to GMail, for instance). If they try to use Android as the underlying monopoly, the suit will fail on a motion to dismiss since the OEMs aren't required to bundle any of the apps as a condition of getting the ability to use Android.

The main issue is that the OEMs and carriers want to be able to sell access to the very lucrative search box on the phone to the highest bidder while still using Google's apps for all the other things that users expect access to like their contacts and e-mail, but Google's set terms that force them to do all their own work if they want to do that.

"I'm not a rockstar. I'm a professional. My job isn't to write the greatest code ever. My job is to turn out software that works, that does what you need done, on time and without bugs or maintenance nightmares down the road."

Certainly having those services included increased the price of the handset. But the same could be said for any of the software the carriers include on their phones (and usually prevent you from removing). Ditto even for hardware, having a camera or WiFi on the phone increases the price of the handset.

None of which matters. The question in an antitrust case isn't whether it increased the price, it's whether Google used it's control of the Android OS to force vendors to include other Google services as a condition of using Android at all. And the answer to that question is no, Google doesn't do that. Amazon's phone runs Android without having Google services pre-installed (although you can install them yourself). The Kindles are a really good example, they run Android without any of the Google stuff at all and there isn't even any way of installing the Google services. Several Chinese companies make Android phones without Google services. I even have that with my Galaxy S4: I flashed it with CyanogenMod, so I start out without any of the Google apps or services and have to bootstrap an installation of them myself if I want them. The only downside is that if you don't accept Google's terms for officially using Google Play Services and their apps, you can't use the related trademarks for much except referring to those apps. So no, on antitrust grounds Google's OK because they simply aren't using their monopoly on Android (although technically they don't even have a monopoly, see CyanogenMod and AOSP) to force other Google services on manufacturers, carriers or users. In fact Google isn't even being as strict as they could be legally. They'd be within their rights to deny any use of the Google services and apps except where the vendor had the full license, but Google doesn't go that far because they realize it'd be a) stupid because it would annoy users who'd then shy away from Google completely and b) not in their best interests because it'd prevent Google customers from using Google services which would reduce Google's revenue. So all they do is say "You want to use our logos and brands and have access to all the official tools? You need to take our package. Otherwise, you'll have to install things by hand like anybody else." (well, not completely by hand since once they've done it once they can just clone the firmware image and flash it straight into the phones).

The people making that decision don't own and operate my servers, so they're not qualified to make that decision for me. I depend on those servers. I do not want them dependent on software that hasn't been in production service for long enough to have all the issues wrung out (and there are always issues when new software goes into production, I don't care how much the dev team may wish otherwise). I'll look at systemd late this summer and see how it's shaking out, and make any decision about adopting it next fall at the earliest.

Seriously, check how HR or your agency is screening applicants. I've found too many of them that do keyword-based screening, and they're throwing out any applicant who doesn't have exactly the keywords on their resume that you put in the job description. That can filter out the good candidates with broad backgrounds in favor of job-hopping contract people with the canonical "1 year of experience repeated 10 times" who know how to put the right keywords in to pass the screening. Have HR give you all the resumes they received and have one of your guys sort them to remove the ones who clearly don't have any relevant experience, then compare what's left to what HR thought passed screening.

That result's because programmers got the ideas in "Goto Considered Harmful" pounded through their skulls while they were learning, and handled it like they would dynamite: it's very effective and the best tool for certain jobs, but it's also very dangerous and capable of causing a ton of damage so you should handle it with an abundance of caution. tl;dr: "Use it to crack huge boulders and tree-stumps, not to loosen bolts."

Equations and theories that not only explain current observations but bundle up and deal with things our other theories say we should observe that we don't are attractive from a neatness standpoint. I'm skeptical when they make exotic and complex predictions which we haven't seen any evidence of yet, but when they tie up all the loose ends without creating more I usually take that as a sign there's something fundamentally right about that path. Only time and accumulated evidence will add certainty to it, but I like the ideas in this one.

And as far as a universe with no beginning or end is concerned, what's the problem? I was dealing with infinite open shapes (lines, planes) in grade school, unending closed shapes are trivial (a circle, a sphere), and if you assume our universe is a 4-dimensional "slice" of an n-dimensional space it's not that hard to construct an arrangement where you can travel forever in any "direction" (since the time axis counts as a direction here) inside our universe without either encountering an edge or returning to your starting point. The math's brain-bending when you start, but it's like differential equations: migraine-inducing and you hate it with the burning fire of a thousand suns right up until they describe the General Method, at which point you blink and go "Oh. That's easy. Why didn't you mention this in the FIRST PLACE?!

The next thing along those lines will be Google Glass. Probably not in the exact form of Google's device, but a box in your pocket with all the electronics of a modern smartphone but using a Bluetooth-connected set of glasses (with a mic/headphone incorporated) for display. Not just a small prism, the breakthrough will be when it can use the entirety of both lenses for coordinated display overlaying the wearer's field of vision and using pupil-tracking to identify exactly where the wearer's looking. Text input would be via voice recognition. We're fairly close to that, the display's the part of the tech where we still need work.