Do you have any links discussing this more in depth? I took a look at http://en.wikipedia.org/wiki/P... and that one is pretty brief and it's not remotely clear if it succeeded at these or not.

I don't know why are people looking at it as failure. We got plenty of data, we even got the very important chemical analysis data in the last session. It would have been great if it worked further, just as it was awesome that the Mars rover worked much longer than their projected mission lifetime was. But if that did not work out, we still got a lot of value out of this, so I don't follow why should it be a failure.

Vojtech brought me to SUSE Labs where I then worked on git and glibc for several years; since I did home office, we didn't meet that often but whenever we did, even because of something banal, it was a little awe inspiring for me. SUSE Labs is packed with brilliant people, but I always got the feel he's the smartest guy around. *And* at the same time it's a place that feels as un-corporate as possible in a corporation, I'm sure mostly thanks to his managing role.

So, I'm generally a bit sceptical about revering articles. But this one is spot on. When I think about it, I guess I still consider him one of my role models. :)

P.S.: Don't you guys feel kind of bored by the systemd spam under every Linux article too?

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.