Let me start by saying I did not RTFA... the summary was too full of shit for me to follow the link.
Science fiction, other than pulp, has never been about a clear cut division between good and evil. Interesting stories come from complex situations. Read any old Niven, most Heinlein, modern GRR Martin, Robert J Sawyer, Bruce Sterling, John C Wright, Greg Egan, Stephen Gould,... basically any author I would call good. While there may be a clear good and evil side, it is not a requirement. And when there is a clear good & evil, the interesting part and the focus of the story is the characters in between and their struggle. Flash Gordon and the Lensmen are not the sum total of science fiction.
*Of course* science fiction is based on current culture - people can't relate to anything too alien, and thus it doesn't sell. The same is true for every other kind of fiction. You never see fantasy books trying to get us to relate to people who kill peasants for talking back to them as good guys, but I'm pretty sure virtually every knight would have considered that appropriate. We are never given a culture of good guys in which the firstborn child is drowned if it's a girl, but certainly major cultures that considered themselves good, and were good in many ways, did so.
The thesis that science fiction is dying is a load of crap. I've found several good new authors over the past several years (Stephenson, Egan, Gould, etc), a few within the last few months (Sawyer, Wright) and many of the oldies but goodies are still producing (Niven, Sterling).
I don't care what the federal government thinks its reasons are. I wouldn't care even if the number of people killed by terrorism in the US showed up as a blip on the charts in US deaths.
I believe in rule of law. Without rule of law you have a priviledged class that gets away with pretty much anything, a middle class that can muddle through, and a minority of people who just get fucked because no one cares and the executive branch can do whatever they want. And if we're going to have rule of law, the first thing the feds have to do is follow the constitution.
I quote some pretty smart people:
Article [IV.]
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
No gov't official in the US has the right to stop me and search me without a good reason to believe I'm doing something wrong. No matter what. They don't even have the right to dictate that someone else search me before they can provide me some service. It's against the constitution, and if they want to change that there is a process for making constitutional amendments.
We don't have to argue philosophically if Wikipedia can possibly be accurate. Pick an esoteric subject (or 20) you know a lot about, and check the entries. If there's anything there, you are almost guaranteed to learn more than you knew before and I defy you to find four factual errors, or two important factual errors, in your arbitrary selection of 20 articles.
You guys argue as long as you like about whether or not it's good - I've seen it, and it's good.
When you're ready to start arguing about how to make it better, let me know.
The Triple Filter Experiment. Try googling on that or "polarization photons 90 45 quantum". I had a great big explanation of what's going on written up for you, but slashdot went 500 on the submission and then my browser ate it:-(
My apologies; the excerpt didn't make it completely clear that, in fact, it was varying by hertz per second, not varying by so many hertz.
That said, I stand by my assertion that New Science is full of unsubstantiated and poorly reported crap - the more recent slashdot article about this topic being my vindication.
Further, most of the people who corrected me sorely need a lesson in manners.
Do feel free to mod down my (incorrect) parent post.
I'll reply to this even though the other two posts are accurate, because I don't think they're clear:)
Quantum cryptography lets you recognize when you have the same bit (sent via the phase of an entangled photon) that the sender has. You don't get to pick what the bit is; you can just tell when it's the same. So it lets you have a one time pad that you didn't have to establish ahead of time. The pad is the bits sent via the photons. Then the sender sends his message XORed with the one time pad (turning it into random noise for anyone who doesn't have the pad), and the receiver XORs the message with the one time pad to get the original message.
The reason this is so secure is firstly that the message is indistinguishable from noise if you don't have the pad and secondly that it's not physically possible to intercept the pad without letting the real message recipient know. This second part is because detecting the phase of the photon eliminates the wave nature of the photon.
That's exactly why Patrick Henry, among others, was *opposed* to the Bill of Rights - because people like you would say it was a complete list of rights, rather than a list of minimal guaranteed rights among many other rights.
What it boils down to is that you have whatever rights you have the ability and willingness to demand. What _that_ generally boils down to is that you have whatever rights your culture grants you. It is a bad, bad move as a culture for us to decide people have some minimal set of rights that can be enumerated somewhere - instead, keep pushing the envelope of your rights until it includes everything that doesn't hurt someone else.
That said, I don't believe we have a right to force Google to make it easy for 3rd party mail notifiers to work. It did miff me until someone pointed out how their notifier could be much more efficient. I wouldn't be surprised to see them solidify the notifier API and make it a public release after they have tested it for a while.
I think frantic defensive articles regarding Java aren't helping anyone.
I don't care what the topic is, *this* I disagree with completely and utterly. It is really pretty silly to assert that when someone expresses an opinion with which you strongly disagree, it's "frantic" and "defensive" to show why you think they're wrong.
The only thing they have to solve is f(X+S) = S, where f is the algorithm for calculating the signature, X is the exe code, and S is the signature. Depending on f, it can either be completely trivial to calculate S or impossible.
Ages ago, my first x86 type computer was a 286. My father works for the county government, and had gotten his hands on some old MFM hard drives that were being thrown out. They were 40 meg hard drives but I only had a 20 meg controller, so I installed it and was ready to go at 20 megs:(
Well, eventually the hard drive stopped working. It would spin up and then spin right back down. I was way too poor to just go buy another hard drive, so I took the HD case off and screwed around inside it for a while. I found two leads I could short across during the spin-up, and if I released them at the right time the HD stayed up!
Being poor and generally slovenly about such things, I just soldered wires to those two leads and hung the loose stripped ends of the wires out of the case. When I turned on the PC, I had to hold the wires together to get the HD to spin up properly. Then when it was up, I just let 'em go. It worked fine for as long as I used that machine.
I also had crammed the motherboard into the wrong kind of case (AT vs ATX? I don't remember for sure now) and I had to mutilate the mainboard power cable to get it to have the right pinout.
When did I talk about writing perfect program? What part of "to some acceptable degree of error" did you not understand? Why am I replying to an obvious troll?
*I* said that validating the quality of a program is easier than writing a program to that same degree of quality. Apparently you were too dense to realize that when I originally said writing a program is harder than validating a program, I meant that the two programs had the same purpose and degree of quality, as opposed to writing "hello world" versus validating ssh.
From the original post:
I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.
And what the original post appeared to be arguing, which I took issue with, is that writing + validating is easier than validating, which is obvious bullshit.
That's what I've been arguing all along (writing + validating is lots harder than just validating). Provide an example of where I've misunderstood my own argument or even misunderstood the text of someone else's.
Damn, I have been trolled. Your post is off in too many ways (I misunderstood *my* argument? I was arguing against comments you made before you made them?) for it to possibly be accidental.
No, I was *describing* design as being an NP hard kind of problem. I was saying, the solution is relatively easily verifiable, but hard to come up with. That's what I meant when I said it was NP hard. I think that stands as self evident - I wasn't trying to say that design = NP hard, therefore it's easy to verify. By saying it was NP hard, I was attempting to describe it. I wasn't being circular, I was being redundant:)
And I disagree with your comment that it's untrue. Verifying a design is immensely easier than coming up with a good design. I would say in most cases the difference in difficulty is on the order of factoring a large number vs verifying that a list of terms multiply out to the right answer. You're right - it may be really hard to verify that a program is correct. But it will always be easier to verify that a program is correct to some acceptable degree of error than it is to *come up with* a program that is correct to that degree of error.
Spend some time thinking about how to solve some simple software problem, e.g. logging. Then go look at how log4j does it. Log4j is simple to use and performs its task well. It is immensely easier to see that log4j does a good job than it is to come up with a way to do the job well.
You can pull that trick with almost any popular software that solves one simple problem. Think for a day how you would do it, then verify for yourself in 20 minutes that they do it much better than you would - usually by being both simpler to use and solving problems you never even realized existed.
Think about it - why the hell would you buy a book on design if it weren't much easier to see that they're giving you a good way to do it than it is to come up with a good way on your own?
Sorry, you're right - technically an NP hard algorithm requires more than polynomial time to solve.
I still stand by my bastardization of the meaning. NP is used to indicate problems for which verification of a solution is easy, but finding the solution is hard. It is a useful term to have in plain english as well as mathematical language, because lots of problems that are difficult to formulate mathematically fall into that category, and they require a similar special way of thinking to solve.
We were talking about *rewriting the software from scratch*. That *does* require a design, and a good design *does* jump out at you (after you spend some time examining it). It is IMMENSELY easier to see that a design is good than it is to come up with a good design.
The examples you're talking about are not design issues, they are implementation issues. Yes, they require code inspection. They don't jump out at you, generally, they require looking in depth. That does nothing to invalidate my point that it will take much, much more time to rewrite a system and validate that it's good than it will to take a written system that's seen use and validate that it's good.
Anyone who claims that they can rewrite software and validate it faster than they can validate software that has already seen production use either isn't a professional developer or isn't thinking clearly. Making that claim doesn't indicate you're stupid, or not a professional developer, it just indicates you made a mistake. Are you really trying to defend that claim after having the error pointed out?
Just to anticipate another straw man, I'm also not saying that you shouldn't rewrite parts of the software that are insecure. I'm not even saying that it never makes sense to rewrite something that wasn't written with security in mind. I'm just saying that it's crazy to claim offhand that you are going to write from scratch software that's better than something proven to work, or that you will have fewer security holes writing from scratch than you will get from something that some magical guy who has built a reputation in the community to the point he can submit patches and then introduces subtle enough bugs that review doesn't find them.
And I'll say it one more time: a secure design *sure as hell does* jump out at you much more readily when it's in front of you than when you have to figure one out from scratch.
An NP problem is one for which you can verify if a particular solution is correct in an amount of time that is a polynomial function of the size of the input (i.e. you can verify it fairly easily) but for which it is not known how hard it is to find the solution from scratch. Factoring arbitrary large numbers and IMO software design (for non-trivial requirements) and solving riddles basically fall into this category. Many other things that fall into the NP category, too, of course.
This also ignores the fact that the infiltrator has to spend time building up a reputation to get himself able to submit patches to the source, then if you catch him submiting bad code you just block that guy. It's much cheaper for you to stop him than it is for him to try to screw you up.
Well, I've been developing C++ and Java servers professionally for EDS, Nations Bank, Southwest Airlines, etc. for 10 years, so yes, I've developed a vast amount of software on a large scale. I've conducted or sat in on many code reviews, although most places I've been had far fewer than they should have.
Bug identification, testing, and fixing takes forever - if you don't do code reviews up front. If you wait for the bug to whack you, then you go dig around for the code that's the problem, it is a very time consuming process. However, a code review for the material that one person develops in a week (starting from analysis through implementation) shouldn't take more than 5 people * 2 hours = just over 1 day to review. Even if you spend twice that time to do an intensive review, you're still taking half as long to review the code as it would have just to write it yourself. And that's assuming you're not going to review it if you write it yourself!!
If you think that it's as hard to check code for correctness as it is to write the code in the first place, you can't be a developer, or you're not thinking clearly.
Writing code is one of the classic "genius" kind of activities - it's generally an NP problem. Figuring out the right answer is *immensely* harder than recognizing the right answer when you see it. A good design jumps out at you when you see it, but finding it starting from scratch can take a long time. It's like finding the answer to a riddle, or factoring a large number. When you have the answer, it's obvious. If you don't, it can seem impossible.
So even if they have to evaluate the whole body of the code initially, then all diffs with every revision after that, they've made an immense gain to use open source versus building it over again themselves.
Slashdot Mirror
Sounds like time to strace Firefox and search for calls to gdk-pixbuf functions. I am on a shitty winders machine right now or I would do it myself.
Let me start by saying I did not RTFA... the summary was too full of shit for me to follow the link.
... basically any author I would call good. While there may be a clear good and evil side, it is not a requirement. And when there is a clear good & evil, the interesting part and the focus of the story is the characters in between and their struggle. Flash Gordon and the Lensmen are not the sum total of science fiction.
Science fiction, other than pulp, has never been about a clear cut division between good and evil. Interesting stories come from complex situations. Read any old Niven, most Heinlein, modern GRR Martin, Robert J Sawyer, Bruce Sterling, John C Wright, Greg Egan, Stephen Gould,
*Of course* science fiction is based on current culture - people can't relate to anything too alien, and thus it doesn't sell. The same is true for every other kind of fiction. You never see fantasy books trying to get us to relate to people who kill peasants for talking back to them as good guys, but I'm pretty sure virtually every knight would have considered that appropriate. We are never given a culture of good guys in which the firstborn child is drowned if it's a girl, but certainly major cultures that considered themselves good, and were good in many ways, did so.
The thesis that science fiction is dying is a load of crap. I've found several good new authors over the past several years (Stephenson, Egan, Gould, etc), a few within the last few months (Sawyer, Wright) and many of the oldies but goodies are still producing (Niven, Sterling).
This looks like a big troll. I guess I bit.
I would think not - you have probable cause to check someone's age if it looks as if they're an underage person attempting to buy alcohol.
/. so IANAL.
Of course, this is
I believe in rule of law. Without rule of law you have a priviledged class that gets away with pretty much anything, a middle class that can muddle through, and a minority of people who just get fucked because no one cares and the executive branch can do whatever they want. And if we're going to have rule of law, the first thing the feds have to do is follow the constitution.
I quote some pretty smart people:
No gov't official in the US has the right to stop me and search me without a good reason to believe I'm doing something wrong. No matter what. They don't even have the right to dictate that someone else search me before they can provide me some service. It's against the constitution, and if they want to change that there is a process for making constitutional amendments.
er, *It would* be very easy to generate electricity without steam. Try a Peltier system (alternating plates of two different metal).
Oh, you mean difficult to do as efficiently as it's done with steam? That's a different story.
We don't have to argue philosophically if Wikipedia can possibly be accurate. Pick an esoteric subject (or 20) you know a lot about, and check the entries. If there's anything there, you are almost guaranteed to learn more than you knew before and I defy you to find four factual errors, or two important factual errors, in your arbitrary selection of 20 articles.
You guys argue as long as you like about whether or not it's good - I've seen it, and it's good.
When you're ready to start arguing about how to make it better, let me know.
The Triple Filter Experiment. Try googling on that or "polarization photons 90 45 quantum". I had a great big explanation of what's going on written up for you, but slashdot went 500 on the submission and then my browser ate it :-(
My apologies; the excerpt didn't make it completely clear that, in fact, it was varying by hertz per second, not varying by so many hertz.
That said, I stand by my assertion that New Science is full of unsubstantiated and poorly reported crap - the more recent slashdot article about this topic being my vindication.
Further, most of the people who corrected me sorely need a lesson in manners.
Do feel free to mod down my (incorrect) parent post.
I'll reply to this even though the other two posts are accurate, because I don't think they're clear :)
Quantum cryptography lets you recognize when you have the same bit (sent via the phase of an entangled photon) that the sender has. You don't get to pick what the bit is; you can just tell when it's the same. So it lets you have a one time pad that you didn't have to establish ahead of time. The pad is the bits sent via the photons. Then the sender sends his message XORed with the one time pad (turning it into random noise for anyone who doesn't have the pad), and the receiver XORs the message with the one time pad to get the original message.
The reason this is so secure is firstly that the message is indistinguishable from noise if you don't have the pad and secondly that it's not physically possible to intercept the pad without letting the real message recipient know. This second part is because detecting the phase of the photon eliminates the wave nature of the photon.
Who the hell writes this stuff, and how did they get to be a science writer if they don't know herz *means* per second?
This is one of the many reasons why I ignore things in New Science until I've seen them somewhere else.
That's exactly why Patrick Henry, among others, was *opposed* to the Bill of Rights - because people like you would say it was a complete list of rights, rather than a list of minimal guaranteed rights among many other rights.
What it boils down to is that you have whatever rights you have the ability and willingness to demand. What _that_ generally boils down to is that you have whatever rights your culture grants you. It is a bad, bad move as a culture for us to decide people have some minimal set of rights that can be enumerated somewhere - instead, keep pushing the envelope of your rights until it includes everything that doesn't hurt someone else.
That said, I don't believe we have a right to force Google to make it easy for 3rd party mail notifiers to work. It did miff me until someone pointed out how their notifier could be much more efficient. I wouldn't be surprised to see them solidify the notifier API and make it a public release after they have tested it for a while.
I think frantic defensive articles regarding Java aren't helping anyone.
I don't care what the topic is, *this* I disagree with completely and utterly. It is really pretty silly to assert that when someone expresses an opinion with which you strongly disagree, it's "frantic" and "defensive" to show why you think they're wrong.
Can you say college algebra?
The only thing they have to solve is f(X+S) = S, where f is the algorithm for calculating the signature, X is the exe code, and S is the signature. Depending on f, it can either be completely trivial to calculate S or impossible.
Ages ago, my first x86 type computer was a 286. My father works for the county government, and had gotten his hands on some old MFM hard drives that were being thrown out. They were 40 meg hard drives but I only had a 20 meg controller, so I installed it and was ready to go at 20 megs :(
Well, eventually the hard drive stopped working. It would spin up and then spin right back down. I was way too poor to just go buy another hard drive, so I took the HD case off and screwed around inside it for a while. I found two leads I could short across during the spin-up, and if I released them at the right time the HD stayed up!
Being poor and generally slovenly about such things, I just soldered wires to those two leads and hung the loose stripped ends of the wires out of the case. When I turned on the PC, I had to hold the wires together to get the HD to spin up properly. Then when it was up, I just let 'em go. It worked fine for as long as I used that machine.
I also had crammed the motherboard into the wrong kind of case (AT vs ATX? I don't remember for sure now) and I had to mutilate the mainboard power cable to get it to have the right pinout.
*I* said that validating the quality of a program is easier than writing a program to that same degree of quality. Apparently you were too dense to realize that when I originally said writing a program is harder than validating a program, I meant that the two programs had the same purpose and degree of quality, as opposed to writing "hello world" versus validating ssh.
From the original post:
And what the original post appeared to be arguing, which I took issue with, is that writing + validating is easier than validating, which is obvious bullshit.
That's what I've been arguing all along (writing + validating is lots harder than just validating). Provide an example of where I've misunderstood my own argument or even misunderstood the text of someone else's.
Damn, I have been trolled. Your post is off in too many ways (I misunderstood *my* argument? I was arguing against comments you made before you made them?) for it to possibly be accidental.
No, I was *describing* design as being an NP hard kind of problem. I was saying, the solution is relatively easily verifiable, but hard to come up with. That's what I meant when I said it was NP hard. I think that stands as self evident - I wasn't trying to say that design = NP hard, therefore it's easy to verify. By saying it was NP hard, I was attempting to describe it. I wasn't being circular, I was being redundant :)
And I disagree with your comment that it's untrue. Verifying a design is immensely easier than coming up with a good design. I would say in most cases the difference in difficulty is on the order of factoring a large number vs verifying that a list of terms multiply out to the right answer. You're right - it may be really hard to verify that a program is correct. But it will always be easier to verify that a program is correct to some acceptable degree of error than it is to *come up with* a program that is correct to that degree of error.
Spend some time thinking about how to solve some simple software problem, e.g. logging. Then go look at how log4j does it. Log4j is simple to use and performs its task well. It is immensely easier to see that log4j does a good job than it is to come up with a way to do the job well.
You can pull that trick with almost any popular software that solves one simple problem. Think for a day how you would do it, then verify for yourself in 20 minutes that they do it much better than you would - usually by being both simpler to use and solving problems you never even realized existed.
Think about it - why the hell would you buy a book on design if it weren't much easier to see that they're giving you a good way to do it than it is to come up with a good way on your own?
Sorry, you're right - technically an NP hard algorithm requires more than polynomial time to solve.
I still stand by my bastardization of the meaning. NP is used to indicate problems for which verification of a solution is easy, but finding the solution is hard. It is a useful term to have in plain english as well as mathematical language, because lots of problems that are difficult to formulate mathematically fall into that category, and they require a similar special way of thinking to solve.
We were talking about *rewriting the software from scratch*. That *does* require a design, and a good design *does* jump out at you (after you spend some time examining it). It is IMMENSELY easier to see that a design is good than it is to come up with a good design.
The examples you're talking about are not design issues, they are implementation issues. Yes, they require code inspection. They don't jump out at you, generally, they require looking in depth. That does nothing to invalidate my point that it will take much, much more time to rewrite a system and validate that it's good than it will to take a written system that's seen use and validate that it's good.
Anyone who claims that they can rewrite software and validate it faster than they can validate software that has already seen production use either isn't a professional developer or isn't thinking clearly. Making that claim doesn't indicate you're stupid, or not a professional developer, it just indicates you made a mistake. Are you really trying to defend that claim after having the error pointed out?
Just to anticipate another straw man, I'm also not saying that you shouldn't rewrite parts of the software that are insecure. I'm not even saying that it never makes sense to rewrite something that wasn't written with security in mind. I'm just saying that it's crazy to claim offhand that you are going to write from scratch software that's better than something proven to work, or that you will have fewer security holes writing from scratch than you will get from something that some magical guy who has built a reputation in the community to the point he can submit patches and then introduces subtle enough bugs that review doesn't find them.
And I'll say it one more time: a secure design *sure as hell does* jump out at you much more readily when it's in front of you than when you have to figure one out from scratch.
An NP problem is one for which you can verify if a particular solution is correct in an amount of time that is a polynomial function of the size of the input (i.e. you can verify it fairly easily) but for which it is not known how hard it is to find the solution from scratch. Factoring arbitrary large numbers and IMO software design (for non-trivial requirements) and solving riddles basically fall into this category. Many other things that fall into the NP category, too, of course.
This also ignores the fact that the infiltrator has to spend time building up a reputation to get himself able to submit patches to the source, then if you catch him submiting bad code you just block that guy. It's much cheaper for you to stop him than it is for him to try to screw you up.
Well, I've been developing C++ and Java servers professionally for EDS, Nations Bank, Southwest Airlines, etc. for 10 years, so yes, I've developed a vast amount of software on a large scale. I've conducted or sat in on many code reviews, although most places I've been had far fewer than they should have.
Bug identification, testing, and fixing takes forever - if you don't do code reviews up front. If you wait for the bug to whack you, then you go dig around for the code that's the problem, it is a very time consuming process. However, a code review for the material that one person develops in a week (starting from analysis through implementation) shouldn't take more than 5 people * 2 hours = just over 1 day to review. Even if you spend twice that time to do an intensive review, you're still taking half as long to review the code as it would have just to write it yourself. And that's assuming you're not going to review it if you write it yourself!!
If you think that it's as hard to check code for correctness as it is to write the code in the first place, you can't be a developer, or you're not thinking clearly.
Writing code is one of the classic "genius" kind of activities - it's generally an NP problem. Figuring out the right answer is *immensely* harder than recognizing the right answer when you see it. A good design jumps out at you when you see it, but finding it starting from scratch can take a long time. It's like finding the answer to a riddle, or factoring a large number. When you have the answer, it's obvious. If you don't, it can seem impossible.
So even if they have to evaluate the whole body of the code initially, then all diffs with every revision after that, they've made an immense gain to use open source versus building it over again themselves.
I did read the article, I just misread the funny looking E as the funny looking F.
:-(
Good catch
Somebody hire that guy!