And by any sane standards of safety-engineering, we will start to have data of actual worth for the task at hand.
I am not opposed to nuclear energy. I am opposed to the greedy and insane people that operate and build the respective installations and that continuously lie to the public about their safety. Nuclear could be made safe, but not by these people. It cannot, at this time, be made both cost-efficient and safe. That will require more research.
You need to read up on how that fallacy works. Here is a hint: It requires a disconnect between the group-characteristic and the excluded examples. That disconnect is missing in my statement and hence the fallacy does not apply.
I have done stuff in both and I do not agree in the least. PHP is a dangerous mess. You need to understand its specific defects to code safely in it. Python is pretty well-designed but _not_ a language for beginners in OO concepts, functional coding, etc. It requires experience with the general concepts used, but not with the specific implementation in Python. As such, it does not violate the principle of least surprise.
Invalid inversion of the burden of proof is invalid. You make grande claims and fail to support them adequately. And then you claim that the situation is the reverse one. Are you by any chance a Trump supporter?
You seem to be functionally illiterate. Because what you criticize is very clearly not what I said. I did, in fact, not make any claim as to Linux security vs. other products. But that seems to have completely escaped you. Which is hilarious, because you even quote the line that you were unable to comprehend.
Show me an actual, scientifically sound study first that backs your claim. Because your reference does not do that. Instead if regurgitates the ages-old fallacy that because specific vulnerabilities are removed from the possible things you can code, the same coders will write better code. That is not the case and nobody has ever been able to prove otherwise.
This whole "make everybody a coder" bullshit is just a stunt by the tech industry to make coders cheaper. It's not like they care about actual coder quality anyway. The more the merrier.
The funny thing is that the industry is massively hurting itself by this and does not understand that at all. Bad coders (and cheap coders are bad coders) are always more expensive in the TCO than good coders, frequently extremely so. And to make matters worse, making coders even cheaper will prevent a lot of talented and capable people from ever going into that profession, so when the industry finally realize they are doing it to themselves, there will not be many good coders left and they will be stuck with the expensive bad ones.
As soon as you documented this very carefully and very hard to miss in the code and in the written documentation, I have absolutely no problem with this approach. Competent risk management is not about perfection, it is about balancing cost and risk-costs and avoiding catastrophe-level events.
I agree. PHP has traps by surprising behavior. One of the corner-stones of secure coding is the Principle of Least Surprise and PHP violates it repeatedly. Still a good coder will find these and just not trust the language anymore and be extra careful. This makes coding slow and not fun and expensive, but it can be done. An average or worse coder (the majority of them) will just fall in the traps and create insecure code. However, an average or worse coder will still screw up more than acceptable in a well-designed language.
Well, either quantum mechanics or gravity (likely both) are known to be wrong, because they are inconsistent. Hence you cannot make reliable predictions with either. Not possible. I do know they are both exceptionally well verified experimentally, but that just means their flaws are either subtle or surprising or both and they will be fundamental. There are a lot of morons that cannot see that though. You seem to be one of them.
But to be fair. some languages are more prone to security holes (like PHP, especially the older versions).
No. The only thing PHP does is to make it easier for bad coders to create really simple to exploit vulnerabilities. Anybody competent will write code just as secure. It may take them longer because PHP is a really, really bad design that no good coders would use given a choice. (If you think different, then you are not a good coder. Sorry. It is completely clear and you are deluding yourself. PHP ignore fundamental principles of good engineering in many places.)
And that is the only aspect that matters. Anything else is a red herring or a minor issue. But too many people that think they are competent to voice their opinion on the matter cannot see that and hence the mess continues. Will probably take a few really large disasters to change anything here.
No. You cannot force people to think. The avoidance of thinking is one of the most refined skills in the human race. No tools can help here. This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect. Of course, the motivation behind this is to avoid addressing the continued management failure in both hiring cheap, incompetent coders and in making tech decisions.
Very true. Also, a bad C coder will just create other vulnerabilities in Java, for example. The problem is with coders that a) have no clue how to do it and b) do not know their limits or are forced to not respect them by stupid management. It comes all down to the coder, not the language. A bad coder will produce insecure code in any language, there is _no_ way to avoid that even if many bad coders continue to believe in the existence of the One True Language (TM) that will finally make them good coders. This quasi-religious belief is built on a futile hope and hot air used by vendors and interest groups to keep it alive.
So, let me state again: There is no silver bullet. Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders. These coders are rare, expensive and expect to be treated well. Not having them and trying to do it on the cheap will always be a lot more expensive in the longer run and is a severe management failure. As in any engineering project, in coding, the architects, designers and coders are the most important people, the managers merely serve to deal with management obstacles. They have zero business making tech decisions and if they do that they sabotage the success chances and result quality of the overall project.
We, as the human race, generally have this figured out in engineering, with some notable exceptions, e.g. the current mass-murder committed by Boeing management, the Brazilian dam certified to be secure by TÜV Süd, Fuckupshima, etc. But in software engineering, management is not just incompetent (as usual), it is outright demented and completely disconnected from reality. That has to change.
Slashdot Mirror
It does. You seem to be mentally deficient though.
Indeed. Tech problems need to be solved by engineers. Anything else is pure insanity.
And by any sane standards of safety-engineering, we will start to have data of actual worth for the task at hand.
I am not opposed to nuclear energy. I am opposed to the greedy and insane people that operate and build the respective installations and that continuously lie to the public about their safety. Nuclear could be made safe, but not by these people. It cannot, at this time, be made both cost-efficient and safe. That will require more research.
You need to read up on how that fallacy works. Here is a hint: It requires a disconnect between the group-characteristic and the excluded examples. That disconnect is missing in my statement and hence the fallacy does not apply.
I have done stuff in both and I do not agree in the least. PHP is a dangerous mess. You need to understand its specific defects to code safely in it. Python is pretty well-designed but _not_ a language for beginners in OO concepts, functional coding, etc. It requires experience with the general concepts used, but not with the specific implementation in Python. As such, it does not violate the principle of least surprise.
Indeed. Nice to see that there are people that can think here. Even if you are an AC.
Invalid inversion of the burden of proof is invalid. You make grande claims and fail to support them adequately. And then you claim that the situation is the reverse one. Are you by any chance a Trump supporter?
You continue to be clueless. I did not claim C was a good or bad language either. I just used it to explain a deep flaw in the comparison made.
You seem to be functionally illiterate. Because what you criticize is very clearly not what I said. I did, in fact, not make any claim as to Linux security vs. other products. But that seems to have completely escaped you. Which is hilarious, because you even quote the line that you were unable to comprehend.
Show me an actual, scientifically sound study first that backs your claim. Because your reference does not do that. Instead if regurgitates the ages-old fallacy that because specific vulnerabilities are removed from the possible things you can code, the same coders will write better code. That is not the case and nobody has ever been able to prove otherwise.
What is the relation between your statement and what I wrote? Can you explain?
I agree that this is a strong component in this mess.
Python is not nearly in the same class here.
This whole "make everybody a coder" bullshit is just a stunt by the tech industry to make coders cheaper. It's not like they care about actual coder quality anyway. The more the merrier.
The funny thing is that the industry is massively hurting itself by this and does not understand that at all. Bad coders (and cheap coders are bad coders) are always more expensive in the TCO than good coders, frequently extremely so. And to make matters worse, making coders even cheaper will prevent a lot of talented and capable people from ever going into that profession, so when the industry finally realize they are doing it to themselves, there will not be many good coders left and they will be stuck with the expensive bad ones.
As soon as you documented this very carefully and very hard to miss in the code and in the written documentation, I have absolutely no problem with this approach. Competent risk management is not about perfection, it is about balancing cost and risk-costs and avoiding catastrophe-level events.
I agree. PHP has traps by surprising behavior. One of the corner-stones of secure coding is the Principle of Least Surprise and PHP violates it repeatedly. Still a good coder will find these and just not trust the language anymore and be extra careful. This makes coding slow and not fun and expensive, but it can be done. An average or worse coder (the majority of them) will just fall in the traps and create insecure code. However, an average or worse coder will still screw up more than acceptable in a well-designed language.
Well, either quantum mechanics or gravity (likely both) are known to be wrong, because they are inconsistent. Hence you cannot make reliable predictions with either. Not possible. I do know they are both exceptionally well verified experimentally, but that just means their flaws are either subtle or surprising or both and they will be fundamental. There are a lot of morons that cannot see that though. You seem to be one of them.
Unfortunately, that makes perfect sense. The whole complex mess we have in Quantum Physics theory may primarily server to keep some people employed.
Are you functionally illiterate?
Read my .sig
But to be fair. some languages are more prone to security holes (like PHP, especially the older versions).
No. The only thing PHP does is to make it easier for bad coders to create really simple to exploit vulnerabilities. Anybody competent will write code just as secure. It may take them longer because PHP is a really, really bad design that no good coders would use given a choice. (If you think different, then you are not a good coder. Sorry. It is completely clear and you are deluding yourself. PHP ignore fundamental principles of good engineering in many places.)
but the programmer that uses it.
And that is the only aspect that matters. Anything else is a red herring or a minor issue. But too many people that think they are competent to voice their opinion on the matter cannot see that and hence the mess continues. Will probably take a few really large disasters to change anything here.
No. You cannot force people to think. The avoidance of thinking is one of the most refined skills in the human race. No tools can help here. This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect. Of course, the motivation behind this is to avoid addressing the continued management failure in both hiring cheap, incompetent coders and in making tech decisions.
The vast majority of security vulnerabilities in the wild are running AMD64 assembly. It's by far the least secure programming language.
Especially if run on the inferior "Intel" implementation.
Very true. Also, a bad C coder will just create other vulnerabilities in Java, for example. The problem is with coders that a) have no clue how to do it and b) do not know their limits or are forced to not respect them by stupid management. It comes all down to the coder, not the language. A bad coder will produce insecure code in any language, there is _no_ way to avoid that even if many bad coders continue to believe in the existence of the One True Language (TM) that will finally make them good coders. This quasi-religious belief is built on a futile hope and hot air used by vendors and interest groups to keep it alive.
So, let me state again: There is no silver bullet. Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders. These coders are rare, expensive and expect to be treated well. Not having them and trying to do it on the cheap will always be a lot more expensive in the longer run and is a severe management failure. As in any engineering project, in coding, the architects, designers and coders are the most important people, the managers merely serve to deal with management obstacles. They have zero business making tech decisions and if they do that they sabotage the success chances and result quality of the overall project.
We, as the human race, generally have this figured out in engineering, with some notable exceptions, e.g. the current mass-murder committed by Boeing management, the Brazilian dam certified to be secure by TÜV Süd, Fuckupshima, etc. But in software engineering, management is not just incompetent (as usual), it is outright demented and completely disconnected from reality. That has to change.