No, I'm merely pointing out reality. You live in fantasy land.
This comment is meaningless. Plenty of people have told you how to solve your problems; books have been written about how to solve your problems.
I don't know why you refuse to try to fix your problems, but that does explain why you have so many problems in the first place. Your problems keep piling up because you don't fix them.
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
I've spent a long time reading through Dijkstra's works, trying to understand what he meant. I'm fairly confident my explanation is accurate.
You got modded troll, but the closer it gets to being a "trusted" OS, the closer it gets to being malware. Remember "trusted" means they don't trust you, and that they control the platform.
The story that really drove this point home for me was about a text editor that worked perfectly.......except if you tried to save when your file was exactly 2^16 bytes long. Any longer, it was fine. Any shorter, it was also fine.
The book that related this story then went on to calculate how many combinations of tests you would need to run before testing every possibility in a reasonable sized program. A ridiculous amount.....
You know that Dijkstra wrote that as part of a joke paper where he trashed every single one of the major programming languages available at the time, right?
It wasn't a joke paper. It was a serious paper that had jokes in it. Apparently you didn't realize that.
If you even start thinking about it, your code will be improved automatically, without even taking extra time. Too many programmers don't even give a first thought to security. Hack and slash and get it done.
I messed up on the link in that previous comment sorry, this book will help you do defensive programming within your schedule (and once you get the hang of it, probably faster than schedule because you'll have fewer bugs).
There is no excuse for not using defensive programming.....
"It's not a business goal that will drive sales." - Manager
You're stubborn holding on to your negative misconceptions of the world, but this book will teach you how to do defensive programming within your schedule.
And then the programmer wakes up into the reality of the fact that their manager demands that the product be done yesterday and far under budget leaving them next to no time to worry about such issues.
Next time you are standing in line at the checkout, start yelling and screaming, demanding that you be checked-out immediately, and you be given a 30% discount on everything.
The reason your manager does that to you is because you are a pushover. Read this book and it will tell you how to do better..
You act as if the developer has a choice in 99.9% of the cases.
If you think you don't have a choice, you need to read this book. It will teach you how to act professional and do the right thing, while keeping your job. There is no excuse for not using defensive programming.....those programmers should be fired.
We hire "hackers" in the literal sense of the term - people who hack and slash with crude brute force to just "Git 'R Dun!" as fast and as cheap as we can
These are the people Edsgar Dijkstra was talking about when he said, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Because BASIC is a hack-and-slash language. It takes a while to get out of that mindset.
There's definitely time to purge your inputs. We're not talking about something that's going to take weeks here, or even days in most cases. We're talking about something that takes seconds or minutes.
How many non-embedded, non-life critical developers here check every mathematical operation for under or over flows?
You don't need to check every operation for over/underflow. You do need to properly purge any data input comes from the user (or other untrusted source), including sizes and numbers.
It'll never happen. Consumers don't care about buggy software and non-buggy software is too difficult to code. Perfect code can fail on bad hardware too.
It doesn't have to be perfect. The sad reality is our software could be drastically more secure without coming anywhere close to perfection.
If a programmer is even thinking a little about security, or is even informed what typical security problems are, then they start writing better code. But most programmers don't think about security at all.
OPEC is hoping fracking will stop, inventories will dwindle and the oil price will go back up.
It won't. Oil prices are going to drop even more.
Saudi Arabia is betting electric cars and renewables will make oil demand drop like a rock, so they are selling as much as they can as fast as they can, while the price is still as high as it is. Iran is planning on increasing production to regain market share, now that sanctions have been lifted.
Slashdot Mirror
No plug-in, no exploit. In fact, 99% of the CVEs are related to the browser plugins. But don't let that stop you.
That's true, but I figured by this point everyone realized that already.
No, I'm merely pointing out reality. You live in fantasy land.
This comment is meaningless. Plenty of people have told you how to solve your problems; books have been written about how to solve your problems.
I don't know why you refuse to try to fix your problems, but that does explain why you have so many problems in the first place. Your problems keep piling up because you don't fix them.
No, my girlfriend wrote this one. Don't judge.
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
I've spent a long time reading through Dijkstra's works, trying to understand what he meant. I'm fairly confident my explanation is accurate.
You got modded troll, but the closer it gets to being a "trusted" OS, the closer it gets to being malware. Remember "trusted" means they don't trust you, and that they control the platform.
Hello, Mr Nadella, thanks for visiting Slashdot. Might I suggest creating an account?
The story that really drove this point home for me was about a text editor that worked perfectly.......except if you tried to save when your file was exactly 2^16 bytes long. Any longer, it was fine. Any shorter, it was also fine.
The book that related this story then went on to calculate how many combinations of tests you would need to run before testing every possibility in a reasonable sized program. A ridiculous amount.....
Nah, they're too busy singing to put anybody down.
You know that Dijkstra wrote that as part of a joke paper where he trashed every single one of the major programming languages available at the time, right?
It wasn't a joke paper. It was a serious paper that had jokes in it. Apparently you didn't realize that.
Yah. All You Have To Do Is...
If you even start thinking about it, your code will be improved automatically, without even taking extra time. Too many programmers don't even give a first thought to security. Hack and slash and get it done.
Not likely.
If the code is not readable, it's probably not going to be flexible.
If it is readable, then any bugs will be fixed quickly.
All these massive security holes in Java are actually in the C++ code.
If you read the article, you'll see that the bug described is actually in the Java code. But carry on.
I messed up on the link in that previous comment sorry, this book will help you do defensive programming within your schedule (and once you get the hang of it, probably faster than schedule because you'll have fewer bugs).
There is no excuse for not using defensive programming.....
"It's not a business goal that will drive sales."
- Manager
You're stubborn holding on to your negative misconceptions of the world, but this book will teach you how to do defensive programming within your schedule.
And then the programmer wakes up into the reality of the fact that their manager demands that the product be done yesterday and far under budget leaving them next to no time to worry about such issues.
Next time you are standing in line at the checkout, start yelling and screaming, demanding that you be checked-out immediately, and you be given a 30% discount on everything.
The reason your manager does that to you is because you are a pushover. Read this book and it will tell you how to do better..
You act as if the developer has a choice in 99.9% of the cases.
If you think you don't have a choice, you need to read this book. It will teach you how to act professional and do the right thing, while keeping your job. There is no excuse for not using defensive programming.....those programmers should be fired.
We hire "hackers" in the literal sense of the term - people who hack and slash with crude brute force to just "Git 'R Dun!" as fast and as cheap as we can
These are the people Edsgar Dijkstra was talking about when he said, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Because BASIC is a hack-and-slash language. It takes a while to get out of that mindset.
oh, interesting, I remember a clock very similar to that one.....
There's definitely time to purge your inputs. We're not talking about something that's going to take weeks here, or even days in most cases. We're talking about something that takes seconds or minutes.
How many non-embedded, non-life critical developers here check every mathematical operation for under or over flows?
You don't need to check every operation for over/underflow. You do need to properly purge any data input comes from the user (or other untrusted source), including sizes and numbers.
I wonder how many of these security flaw bugs would happen if we made companies actually legal responsible for the flaws in them?
A lot fewer. Oracle fixed 154 security issues here, which means they are going through their code looking for them.
They should have done that a long time ago.
It'll never happen. Consumers don't care about buggy software and non-buggy software is too difficult to code. Perfect code can fail on bad hardware too.
It doesn't have to be perfect. The sad reality is our software could be drastically more secure without coming anywhere close to perfection.
If a programmer is even thinking a little about security, or is even informed what typical security problems are, then they start writing better code. But most programmers don't think about security at all.
My library has nice lounges set up so I can go there to read, surrounded by wisdom.
OPEC is hoping fracking will stop, inventories will dwindle and the oil price will go back up.
It won't. Oil prices are going to drop even more.
Saudi Arabia is betting electric cars and renewables will make oil demand drop like a rock, so they are selling as much as they can as fast as they can, while the price is still as high as it is. Iran is planning on increasing production to regain market share, now that sanctions have been lifted.
(Strangest part of it all? I still have the damned thing...)
Do you have a picture? That sounds really cool.