Singularitarians don't think that only the people who believe in a Singularity will be saved or any nonsense like that.
Probably because no one yet realized the income possibilities from such a claim.
In the singularity (which will happen in your lifetime) the self-replicating computers will destroy all humans they don't consider valuable (since they are not bound by human ethics). For just one million dollars I'll teach you how to become valuable to the future self-replicating computers.:-)
A brain simulation would not predict the output of a specific brain, that would be plain silly. The brain simulation would model an independent brain, just as a cloud simulation models an independent cloud. You would not need to know every single connection of the brain. What you need to know is the rules according to which the brain works. We don't know the complete rules yet, and probably they are quite complex, but the complexity of the rules is largely independent from the number of possible connections between neurons.
Kurzweil's ideas about *how* complex the brain is are nuts - as postings in TFA point out, the genome isn't the program, it's the data
No, the genome is the program. It's just that the processor which processes that data is so complex that the code needed to emulate that would be a few orders of magnitude larger than the program which is processed. And of course, even if we had a simulator which calculated every single protein interaction, we wouldn't get a functional brain, because the development of the brain depends very much on interaction with the environment.
To make a more apt analogy: Ray Kurzweil is like an assembler programmer who looks at the size of the PHP code in MediaWiki and believes that you can write Wikipedia in the same amount of assembler code. The first mistake is to ignore that there's a whole Web server as well as a language interpreter and a standard library involved, all of which cannot be found in the PHP code. The second mistake is to ignore that Wikipedia is not just MediaWiki, but much of what it is, including a lot of the functionality, depends on the input from the users. Of course all that doesn't mean that the PHP code is "just the data".
Moreover, from what I've heard when doing cross licensing agreements, people don't look at the individual patents, but only on the number of patents the company holds in a given field. So you may make some real money even from bullshit patents if you can weight them in on cross-licensing deals (of course you also have to have in addition some patents the other party would like to use).
Actually, if you sign an oath, I actually consider it quite positive that luminaries are now admitting their crime (a false oath is a crime, right?). That allows them to be prosecuted, and thus set a precedent which might cause future applicants to think twice whether they file a bogus patent (on the downside, maybe the only conclusion they would draw is "don't be so stupid and admit it").
That's wrong. You can easily see that from the units: The first term has the unit kg^2 m^8/s^8, while the other terms have the unit kg^2 m^6/s^6. You can most easily see it by comparing the first term with the last. What you probably meant is:
(E*v)^2 + (m*c^3)^2 = (E*c)^2
Which, using the fact that in relativity E*v = p*c^2, is equivalent to the normal relativistic energy-momentum relation.
Me too. Developers are not good designers, designers are not good developers. While there is always the exception to the rule, generally as a developer you so intimately understand how your creation works and is supposed to, you really cannot consider the position of someone who has never seen your product before and has to decode how it works and what it is capable without reading the source code and only what information you choose to present.
Well, you can consider that position to a large extent, by writing user documentation. If you write user documentation, you'll quickly see where you have troubles to explain something. Of course, the user documentation cannot refer to the source code. Also don't fall into the trap to write a reference manual instead (a reference manual is useful in addition to user documentation, but it cannot replace it).
Not in the same way. Your end users will not care about if you indented your code with two spaces, eight spaces, a tab, or whatever. As long as your code works well and is maintainable (so bugs don't creep in in future versions), everything is OK. Users do care about things like where exactly your OK button is placed (and if it is labeled OK or by the action to perform), or what background color you used.
Maybe you should arrange that changing the test cases causes enough work to offset that urge. For example, if you are working on a machine where you have root, you could add a second account for yourself as tester, and use an extremely tedious password for that. Then, when the test cases are ready, log out of that account before using the (readonly from your developer account) test cases. Since it's tedious to change a test case (log in to the test case account, type tedious password), you'll avoid it if it's not necessary (it also is an incentive to get your test cases right before applying them).
Think this way: do you prefer testing or writing documentation?
For me: Clearly writing documentation (not comments, mind you, those are tedious, I'm speaking of actual documentation, of the type that's usually missing from those projects which use automated "documentation" tools: documentation that actually tells you how to use the damn thing, instead of just documenting what functions are there to use). Of course, writing the actual code still beats writing the documentation.
However, how do you test your tests? I think you should write tests for your tests first, so that you know your tests are bug free. Of course, don't forget to test those test tests.
If I understand the web site correctly, it only works with Ruby. Which is great if you happen to develop Ruby programs, but doesn't help you a bit if you develop in any other language.
Well, with "most people" you probably refer to hobbyist programmers, because if you are at a company, you usually are told what to work on. No hobbyist programmers of course tend to focus on interesting stuff. After all, you don't want to pass your time doing boring stuff.
However, I think the solution to testing is to take enough pride in your code. If you are ashamed of any bug that gets true, then you are very motivated to test your code so that as few bugs as possible remain. If you don't care enough about bugs in your code, the motivation of testing goes down.
Generally, if it's some code I really care about, I'm also usually sure that it's more or less bug free (of course you never have a guarantee that it's completely bug free). Buggy code is usually caused by one of two cases: (1) It's some code I don't care enough about, or (2) I need to use the code now and cannot afford the time to test a code path which possibly never will be taken anyway (in that case, I write an explicit output "warning: untested code path entered" or similar into that path, so I know if I trigger this code). Of course, for the code I write, generally I'm also the user, and I know that if I put a bug in there, I'm the one getting wrong results. That's certainly a motivation to get it right.
I shall use a web site to generate my password? How do I know I can trust them? And why is this better than just base64-encoding 48 bytes from/dev/random?
So you're required to be nerdy enough to want to enter this this contest and create a demo of your idea, but noob enough to still be running 32-bit?
If you are running Windows, you're not a true nerd anyway.:-)
"To reserve a place in the contest and to receive an Adaptive keyboard for development, contestants must submit an entry email to the contest chair no later than August 17th, 2010."
Not much notice/.!
Slashdot readers are expected to be able to invent and code something innovative in a single night.;-)
What _is_ surprising to me is that a linux based infotainment system would _ever_ hamper any system outside itself. Why would my audio system glitching cause my car to not start? Ok, if it somehow drains the battery, I get that, but otherwise it should be an offering on the "LAN" and simply not used if not accessible.
I mean, are these systems so horridly setup that one specific glitch in the DVD playback software can do _anything_ to the basic functions of the car (brakes, engine, etc)? Or was that just sensationalism in the article merely to illustrate how much software really is "under the hood"?
I certainly hope the latter. Especially given the car this is about is not exactly a cheap one, so they should be able to afford to do it right. As you say, the only connection (apart from the battery) it should have to the rest of the system is a common data bus, and I'd add that this data bus should be separate from the data bus for essential car functions, so that even if it congests the network due to a bug, it cannot block any important internal data communication.
Given that in capitalism it's always the scarce good which is paid for, shouldn't we get paid by the information providers for giving them part of our attention?:-)
Slashdot Mirror
Probably because no one yet realized the income possibilities from such a claim.
In the singularity (which will happen in your lifetime) the self-replicating computers will destroy all humans they don't consider valuable (since they are not bound by human ethics). For just one million dollars I'll teach you how to become valuable to the future self-replicating computers. :-)
A brain simulation would not predict the output of a specific brain, that would be plain silly. The brain simulation would model an independent brain, just as a cloud simulation models an independent cloud. You would not need to know every single connection of the brain. What you need to know is the rules according to which the brain works. We don't know the complete rules yet, and probably they are quite complex, but the complexity of the rules is largely independent from the number of possible connections between neurons.
And from where do you know that the computer circuits in 200 years will still look the same as the computer circuits now?
No, the genome is the program. It's just that the processor which processes that data is so complex that the code needed to emulate that would be a few orders of magnitude larger than the program which is processed. And of course, even if we had a simulator which calculated every single protein interaction, we wouldn't get a functional brain, because the development of the brain depends very much on interaction with the environment.
To make a more apt analogy: Ray Kurzweil is like an assembler programmer who looks at the size of the PHP code in MediaWiki and believes that you can write Wikipedia in the same amount of assembler code. The first mistake is to ignore that there's a whole Web server as well as a language interpreter and a standard library involved, all of which cannot be found in the PHP code. The second mistake is to ignore that Wikipedia is not just MediaWiki, but much of what it is, including a lot of the functionality, depends on the input from the users. Of course all that doesn't mean that the PHP code is "just the data".
I think what he really wanted to say is that Mathematica is more bloated than the human genome. :-)
And on Linux.
Indeed, I'm just typing this in a textbox in Firefox running on Linux.
Moreover, from what I've heard when doing cross licensing agreements, people don't look at the individual patents, but only on the number of patents the company holds in a given field. So you may make some real money even from bullshit patents if you can weight them in on cross-licensing deals (of course you also have to have in addition some patents the other party would like to use).
Actually, if you sign an oath, I actually consider it quite positive that luminaries are now admitting their crime (a false oath is a crime, right?). That allows them to be prosecuted, and thus set a precedent which might cause future applicants to think twice whether they file a bogus patent (on the downside, maybe the only conclusion they would draw is "don't be so stupid and admit it").
About your signature:
That's wrong. You can easily see that from the units: The first term has the unit kg^2 m^8/s^8, while the other terms have the unit kg^2 m^6/s^6. You can most easily see it by comparing the first term with the last. What you probably meant is:
(E*v)^2 + (m*c^3)^2 = (E*c)^2
Which, using the fact that in relativity E*v = p*c^2, is equivalent to the normal relativistic energy-momentum relation.
Well, you can consider that position to a large extent, by writing user documentation. If you write user documentation, you'll quickly see where you have troubles to explain something. Of course, the user documentation cannot refer to the source code. Also don't fall into the trap to write a reference manual instead (a reference manual is useful in addition to user documentation, but it cannot replace it).
Not in the same way. Your end users will not care about if you indented your code with two spaces, eight spaces, a tab, or whatever. As long as your code works well and is maintainable (so bugs don't creep in in future versions), everything is OK. Users do care about things like where exactly your OK button is placed (and if it is labeled OK or by the action to perform), or what background color you used.
Maybe you should arrange that changing the test cases causes enough work to offset that urge. For example, if you are working on a machine where you have root, you could add a second account for yourself as tester, and use an extremely tedious password for that. Then, when the test cases are ready, log out of that account before using the (readonly from your developer account) test cases. Since it's tedious to change a test case (log in to the test case account, type tedious password), you'll avoid it if it's not necessary (it also is an incentive to get your test cases right before applying them).
For me: Clearly writing documentation (not comments, mind you, those are tedious, I'm speaking of actual documentation, of the type that's usually missing from those projects which use automated "documentation" tools: documentation that actually tells you how to use the damn thing, instead of just documenting what functions are there to use). Of course, writing the actual code still beats writing the documentation.
However, how do you test your tests? I think you should write tests for your tests first, so that you know your tests are bug free. Of course, don't forget to test those test tests.
If I understand the web site correctly, it only works with Ruby. Which is great if you happen to develop Ruby programs, but doesn't help you a bit if you develop in any other language.
Well, if you only masturbate each time you find a bug, it may even improve your testing.
However, it may degrade the quality of programming.
Well, with "most people" you probably refer to hobbyist programmers, because if you are at a company, you usually are told what to work on. No hobbyist programmers of course tend to focus on interesting stuff. After all, you don't want to pass your time doing boring stuff.
However, I think the solution to testing is to take enough pride in your code. If you are ashamed of any bug that gets true, then you are very motivated to test your code so that as few bugs as possible remain. If you don't care enough about bugs in your code, the motivation of testing goes down.
Generally, if it's some code I really care about, I'm also usually sure that it's more or less bug free (of course you never have a guarantee that it's completely bug free). Buggy code is usually caused by one of two cases: (1) It's some code I don't care enough about, or (2) I need to use the code now and cannot afford the time to test a code path which possibly never will be taken anyway (in that case, I write an explicit output "warning: untested code path entered" or similar into that path, so I know if I trigger this code). Of course, for the code I write, generally I'm also the user, and I know that if I put a bug in there, I'm the one getting wrong results. That's certainly a motivation to get it right.
I shall use a web site to generate my password? How do I know I can trust them? And why is this better than just base64-encoding 48 bytes from /dev/random?
There are no kangaroos in Austria.
Patents were intended for temporary monopolies on inventions in exchange for publishing the design.
You con not patent a slogan. That's a trademark.
The town is where it is and they are not inventing anything.
And as another post points out, a trademark is exactly what they got.
You'll also find Tux in Austria. You should also go there if you like Gaming.
Given that IIRC plate tectonics is moving Italy towards the alps, the center of Europe should be slowly moving in north direction.
So you're required to be nerdy enough to want to enter this this contest and create a demo of your idea, but noob enough to still be running 32-bit?
If you are running Windows, you're not a true nerd anyway. :-)
Slashdot readers are expected to be able to invent and code something innovative in a single night. ;-)
What _is_ surprising to me is that a linux based infotainment system would _ever_ hamper any system outside itself. Why would my audio system glitching cause my car to not start? Ok, if it somehow drains the battery, I get that, but otherwise it should be an offering on the "LAN" and simply not used if not accessible.
I mean, are these systems so horridly setup that one specific glitch in the DVD playback software can do _anything_ to the basic functions of the car (brakes, engine, etc)? Or was that just sensationalism in the article merely to illustrate how much software really is "under the hood"?
I certainly hope the latter. Especially given the car this is about is not exactly a cheap one, so they should be able to afford to do it right. As you say, the only connection (apart from the battery) it should have to the rest of the system is a common data bus, and I'd add that this data bus should be separate from the data bus for essential car functions, so that even if it congests the network due to a bug, it cannot block any important internal data communication.
Given that in capitalism it's always the scarce good which is paid for, shouldn't we get paid by the information providers for giving them part of our attention? :-)