Based on Kant's imperative, I don't want to do myself what I wouldn't want others to do. I wouldn't want others to eat me (at least if it involved killing me first), so I wouldn't eat others either.

The question is, who are the "others" - in this context, clearly those that are also capable of guiding themselves by the Kant's imperative. Is any animal intelligent enough to make a choice based on this imperative? (I.e. it would willingly choose not to eat me based on observing me not eating its kindred.) I'm no expert on animal intelligence but I really doubt so.

Let's feast!

"Clearly not concerned about the AI's performance?"

It uses Python, indeed. And for the computationally intensive tasks, it uses numpy and theano. Theano is general symbolic computation framework that will automatically accelerate your vector computations on a nearby GPU, etc.

I don't know how it compares with (likely Lua, torch-based) deepmind's implementation. But assuming that scientific python programs actually do their expensive computations in the Python VM is really rather silly.

I'm sorry, I've meant to link to http://seclists.org/oss-sec/20... (you may want to walk the thread up a bit) and https://bugzilla.redhat.com/sh...

And now it turns out that even patched bash still carries some related security bugs. (Not really a surprise since the parser is complex and bound to, seems like running it on arbitrary environment variables really isn't the best idea...)

So, if you think you are safe,

export X='() { (a)=>\'
bash -c 'brm date'
cat brm

(N.B. the backslash is not inhibiting the apostrophe in shell syntax.)

That is, by crafter environment variables you can still overwrite files and run commands that were supposed to be parameters instead. This is still very dangerous, but thankfully the attack surface is smaller than before, for example $SSH_ORIGINAL_COMMAND is frequently not an issue anymore (at least in case of gitolite I couldn't *quickly* figure out a way to exploit this), etc.

No patch for this available yet.

Today is a fun day for linux! Think about switching your /bin/sh to dash and maybe login shell of non-interactive users too!

On repo.or.cz, as login shell for all git user accounts we use a shell script that does some verifications, shows nice error messages etc. Thankfully, #!/bin/sh is at the top of the script and that's dash on the Debian server; otherwise, we would have been vulnerable. (Only getting into a chroot as non-root, but still...)

You can get shell on git@ accounts set up with gitolite and gitosis, at least some of their versions will use /bin/bash as the login shell (and only use ~/.ssh/authorized_keys to restrict the commands). One easy way to check whether your git server account is vulnerable:

ssh git@yourgitserver '() { echo $1; }; /usr/bin/id'

Because a desktop environment ties into a lot of the rest of the system infrastructure - from volume controls to disk mounting to power management - and the system infrastructure keeps moving forward. Therefore, you need to maintain the desktop environment in order for it to keep working well. A typical case is that xfce + new upower tends to suspend twice when you close the lid (i.e. when you open the notebook lid, it re-suspends right away). This is because noone updated xfce's power manager to a new upower API that was announced >6 months before it appeared in a release. (AFAIK xfce update finally happenned and is now fighting its way into Debian unstable.)

Desktop environment is not maintenance free. The rest of the infrastructure evolves (for real reasons - better hardware support, security fixes, usability, ...) and the DEs need to keep pace.

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.