(That's not really that relevant to keep for vast majority of applications, though - and an AI knowledge base does not need to contain these for sure.)
C++ is the wrong language to compare Perl to. Python is what you need to align with it. And it is so much tougher to build a good case for Perl in that light. (Not impossible, but it probably won't be very convincing. Perl is the anarchocapitalism of programming languages - you have near-absolute freedom to choose your ways, which is delightful for the top 20% users, but unfortunately most people choose the most awful and dirty ways in the face of this freedom, typically just for lack of experience.)
(I love both Perl and Python. But in the past few years, I find myself writing vastly more Python that Perl code, except the oneliners of course.)
^ this. You have (i) existing modules in your project that are not python3 compatible, (ii) existing external modules that are not python3 compatible.
The situation is a lot better now than it used to be, but for example you still cannot use the deep learning theano-based libraries. This means people still produce python2 code at this point, which means issue (i) will be going to be an issue for even longer... (Even if you are starting a project from scratch, you often want to borrow some code from a different project you have access to - which may be python2.)
(Actually dealing with unicode was always painful for me in python2 and python3 typically results in less code therefore. Depends a bit on what you do.)
Still, the transition to Python3 is much smoother than it'd be to transition to Perl6. It seems to me kind of unfortunate that they chose "Perl 6" as a name for this newfangled language that has not that much to do with the current Perl. C++ is more "backwards" compatible to C than Perl 6 is to Perl 5, it seems to me. I think the idea of transition is not on the table at all for 80% Perl developers; you just go to Perl6 if you want to pick up a new language that seems fun. Whereas regarding Python I think even most 9-to-5 code-grinding guys recognize that migration makes sense (in a few more years).
Indeed, someone meanwhile made the point about loudness wars and difference in mastering above. That makes total sense and wasn't something I knew before. I wish the article was about that.:-)
Audio is just a crazy world of snake oil and placebo.
Really, the argument that's supposed to convince us is this?
> That warm vinyl sound: "I think this is what people like about it: it pins very closely to the way that human beings hear music organically," Gonsalves said. "It's very mid-range-y and very warm," a sound that flatters the fuzzy guitars of rock 'n' roll.
I'm sorry but I just don't buy it. There seems to be no obvious reason why you couldn't easily hack up a digital audio filter that makes stuff "sound like a vinyl". I'd even wager that it already exists?
Especially when you skip the compression and use FLACs. (But no, I'm not that kind of person who would claim to be able to distnguish 320kbps mp3 from a FLAC.)
I don't really use side-by-side windows but I still like portrait mode - because I get to have enough room for sideways tabs!
Seriously, I don't get it why by default the browsers still ship the tab bar at the top. As soon as you have more than 6-10 tabs open, tab bar on the side becomes incredibly more convenient to work with.
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.
"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.
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:
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.
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.
Slashdot Mirror
Ah, I see; thanks!
(That's not really that relevant to keep for vast majority of applications, though - and an AI knowledge base does not need to contain these for sure.)
enwiki is ~40GB expanded as of 20150112. Do you mean with images or all languages?
C++ is the wrong language to compare Perl to. Python is what you need to align with it. And it is so much tougher to build a good case for Perl in that light. (Not impossible, but it probably won't be very convincing. Perl is the anarchocapitalism of programming languages - you have near-absolute freedom to choose your ways, which is delightful for the top 20% users, but unfortunately most people choose the most awful and dirty ways in the face of this freedom, typically just for lack of experience.)
(I love both Perl and Python. But in the past few years, I find myself writing vastly more Python that Perl code, except the oneliners of course.)
^ this. You have (i) existing modules in your project that are not python3 compatible, (ii) existing external modules that are not python3 compatible.
The situation is a lot better now than it used to be, but for example you still cannot use the deep learning theano-based libraries. This means people still produce python2 code at this point, which means issue (i) will be going to be an issue for even longer... (Even if you are starting a project from scratch, you often want to borrow some code from a different project you have access to - which may be python2.)
(Actually dealing with unicode was always painful for me in python2 and python3 typically results in less code therefore. Depends a bit on what you do.)
Still, the transition to Python3 is much smoother than it'd be to transition to Perl6. It seems to me kind of unfortunate that they chose "Perl 6" as a name for this newfangled language that has not that much to do with the current Perl. C++ is more "backwards" compatible to C than Perl 6 is to Perl 5, it seems to me. I think the idea of transition is not on the table at all for 80% Perl developers; you just go to Perl6 if you want to pick up a new language that seems fun. Whereas regarding Python I think even most 9-to-5 code-grinding guys recognize that migration makes sense (in a few more years).
Indeed, someone meanwhile made the point about loudness wars and difference in mastering above. That makes total sense and wasn't something I knew before. I wish the article was about that. :-)
Audio is just a crazy world of snake oil and placebo.
Really, the argument that's supposed to convince us is this?
> That warm vinyl sound: "I think this is what people like about it: it pins very closely to the way that human beings hear music organically," Gonsalves said. "It's very mid-range-y and very warm," a sound that flatters the fuzzy guitars of rock 'n' roll.
I'm sorry but I just don't buy it. There seems to be no obvious reason why you couldn't easily hack up a digital audio filter that makes stuff "sound like a vinyl". I'd even wager that it already exists?
Especially when you skip the compression and use FLACs. (But no, I'm not that kind of person who would claim to be able to distnguish 320kbps mp3 from a FLAC.)
I don't really use side-by-side windows but I still like portrait mode - because I get to have enough room for sideways tabs!
Seriously, I don't get it why by default the browsers still ship the tab bar at the top. As soon as you have more than 6-10 tabs open, tab bar on the side becomes incredibly more convenient to work with.
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.
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.