If you don't actually care about having friends, just having an income for work, a possible alternative is to be damn technically excellent, spend a few months getting creds for working on high profile open source projects, and make your money via remote work on Elance or such. (Especially at the beginning, it helps a lot if your living cost isn't high, but with well groomed profile, you can get high above $50/hour after a few months.)

Well, but now I realize that at least 50% of the success as a contractor is again great communication (well, especially being open+regular about it even when things are looking down and always being polite). And getting your work included in open source projects requires the same. Unless you are physically repulsive, maybe bad communication was the cause everyone is blowing you off. In that case, see the sibling posters.

But it's not actually clear why is it critical that PID 1 is simple (and if situation is so much worse with systemd).

Xorg, which on desktop is as critical as init to keep running, is not really simple.

kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.

And one common myth is that systemd has these so many features and systemd is pid 1 therefore pid 1 is this huge bloated monster that does udev, logging and NTP, right? Wrong; actually, just the core bits of systemd run in pid 1 and the rest is compartmentalized in a bunch of separate daemon processes.

So, this "increased complexity" issue is not really as bad as it sounds, realistically.

So in case of JVM, you'd think it's flaky for the JIT to happen on the same CPU as the one that is executing the code?

Bear in mind that nowadays, the CPUs don't anymore need to be designed to run even closed source, boxed version operating systems with top performance. The bootloader and kernel can be custom-compiled for the very specific CPU version and won't *necessarily* need the helper.

Okay, but *eventually* I think they are bound to figure out that a better alternative to this situation is going back to a site-local webmail service instead of a third-party black-box cloud (even if they promise the data stays in your server room).

In this sense, I think it's not a risk but a good thing - people start to realize that giving data to third parties may not be smart.

...abandoning it in favor of what? What real (or trending) alternatives do you think they'll pick? Phones and fax?

CRISPR is a tool that allows you to cut the DNA in two disjoint pieces at a specific point (specification of this point is a parameter of a particular CRISPR instance). What happens then depends on your setup; bacteria will just insert some junk at that break point, or you can pack your custom DNA sequences along the CRISPRs and they will be spliced in, connecting to each of the two disjoint pieces by one end. Thanks to this, at that specific point, you can disable a gene or modify or add an extra sequence.

We had tools to do this before - restriction enzymes or TALENs. They weren't really usable for therapeutic purposes, though, due to much less reliable targetting, more laborous engineering (parametrizing your instance for a specific sequence) and low effectivity (the break happens only in a a few percents of cases). CRISPRs are easily parametrized, can be precisely taretted, and have effectivity in tens of percents (in general; can vary organism by organism). It's still a work in progress, but looks pretty promising!

+1 Insightful. :-) Now, this is something I completely agree on - we need a better test than the original immitation game, with some restrictions and incentives. Hmm, that actually almost sounds like a TV show!

Your proposal sounds fairly reasonable, though I think "exposing chatbots" is way too aggressive - we don't need Blade Runner style interrogations, that just doesn't seem like that sensible a goal. We just want to push the conversations to a higher, intellectual level to test the computers' ability to deduce and relate like a human; pick people accordingly and also offer incentives for winning against the computer.

I don't think pretending to be a person who isn't fluent in English is cheating in the immitation game, as long as the conversation still happens in English; remember, they are still talking to the human too! This result does say a lot about computer capabilities, and may have implications in spam, but also e.g. call center automation etc.

I agree that based on this experience, we can add some extra restrictions to the immitation game to make it a much more useful benchmark for progress in AI.

I'm developing an open source IBM Watson analog and I don't really care *how* my brain works when solving this task, because I am dealing with a different computation platform. What my point was is, on the high level, what *function* does the brain perform. And my brain, in this task, acts like a search engine on the facts I have learnt - no matter how it does it.

...and your brain, during a game of Jeopardy, is what if not a search engine?

Of course, (at least) advanced deductive capabilities are also important for general intelligence. That's the next goal now. (Watson had some deductive capabilities, but fairly simple and somewhat specialized.) We gotta take it piece by piece, give us another few years. :-)

What has been conducted precisely matches Turing's proposed immitation game. I don't know what do you mean by a "full-blown Turing test", the immitiation game is what it has always meant, including the 30% bar (because the human has three options - human, machine, don't know). Of coure, it is nowadays not considered a final goal, but it is still a useful landmark even if we have a long way to go.

That's the trouble with AI, the expectation are perpetuouly shifting. A few years in the past, a hard task is considered impossible for computers to achieve, or at least many years away. Then it's pased and the verdict prompty shifts to "well, it wasn't that hard anyway and doesn't mean much", and a year from now we take the new capability of machines as a given.

The reaon is simple - the human is also allowed to answer "don't know" in Turing' immitation game. So with purely random anwers, the probability of each is 1/3.

(I think forcing the judges to pick one would make the results more clear-cut, I'm not sure about Turing's reasons here.)

Anyway, the 30% bar has been proposed in the original paper and this is what "Turing's test" was _always_ meaning.

Make a game. Or contribute to an existing open source game. You can easily set and adjust the scope and depth of the project so that it's fun and challenging. Chances are, you already play some games you like, and chances are you can get inspired for your own game project there. And perhaps others will even find it fun to play.

Somehow, when I get playing a game for any period of time, sooner or later I slowly switch to hacking the codebase as it ends up being even more fun. :-) If you're interested in building a non-trivial game, you may find it interesting to take a look at the code of existing open source games and start hacking them. You will find fun and rewarding low-hanging fruit features lying all around. In strategies - Freeciv, OpenTTD, Wesnoth, Widelands..., arcades like Supertux or Stepmania or even FPS like Xonotic. Or UI or computer player for a board game.

Games are also nice because they are very multi-faceted - you can start by adding simple features, but also work on optimization and better core algorithms, graphics programming, network programming, improve the user interface, porting it to a new platform or have a go at building an AI computer opponent. Hey, try building an AI for OpenTTD, none of them is perfect and they have a nice plugin system. And if you get more involved, imho they look pretty cool on a CV of any programmer.

I actually think it's not really possible to do it fool-proof. You may eventually get right as in mathematically right in some formal system, but then the problem is in quality of your formal system.

10 years ago, people often wouldn't account for timing attacks (though I admit they were proposed ~20 years ago) and things like that. It's still well possible that there are attacks noone concieved of yet and implementations may or may not be vulnerable. Heck, it's possible a specific sequence of instructions your single true implementation compiles to on some future architecture triggers a subtle bug.

I still believe that even for the most basic plumbing, diversity is a good thing and it's not possible to get any slightly complex software 100% right, 100% foolproof in the real world, even if you manage to do it in an abstract formal system.

In some cases, fragmentation is bad. In case of critical infrastructure, fragmentation is great!

Having multiple interoperating implementations has been always one of the basic requirements for internet standards, it ensures future growth and leaving out the worst warts, dependency on undocumented behavior etc. But most importantly, if a bug is found in one of the implementations, it cannot take out the complete internet infrastructure because large parts of it are running a different implementation. Even if a bug is found on a protocol level, some implementations may not implement that feature or implement it slightly differently and aren't involved. Fragmentation is essential to the robustness of internet.