You forget all the people employed to keep the "non-profit" prisons running. And all the suppliers. And all the judges, police, prosecutors, etc. They all want profits or job-security. The mere fact that the US has a lot of people behind bars (the only thing were the US is a real world-leader) creates huge incentives for keeping that going. Utterly perverted incentives.
It is clearly part of what is going on. The other part is that religious fuckups deeply desire to control what others can do with their bodies. No fun except in prayer. Some even say this openly. It is really a coalition of evil.
Indeed. The base-problem is that we have these fuckups in society that want to control what other people do, no matter what. And they think the only thing fun in live should be prayer.
In actual reality, anybody that wants drugs can get them. None of the deterrents work. The deterrents waste an extreme amount of money though and cause massive secondary damage. So legalizing drugs would have a number of advantages.
First, the cost goes down massively and the quality goes massively up and becomes reliable. That means anybody that has their habit under control stops suffering the insane side-effects of the enforcement of stupid laws and the risks of buying variable quality and the need to generate oodles of money to buy the stuff. That already solves a large part of the problem. Also, anybody that does not have it under control can get help much easier and far better information on how things actually work will become generally available.
Second, legalizing it opens the door for less addictive, less harmful drugs. I am sure the large pharma companies already have a few of these ready and research would certainly be intense. Of course, evil corporate monsters being what they are, you would still need laws limiting addictiveness so that they do not try to make and sell more dangerous stuff. We saw that happen with Big Tobacco in the past. These laws and their enforcement will be tricky and they should certainly not be done by the fuckups currently in charge of "fighting" drugs.
And third, all those insane and destructive efforts to fight drugs will stop being a burden on society. A wave of new additions is very unlikely to happen. The current opioid problem in the US was caused by the doctors and some really evil people in the pharma industry, not the patients. That is why some regulation and enforcement will still be required, but none of it should be targeted at the users.
Side note to the most dumb counterargument somebody will surely bring up ("You just want to use drugs!"): I do use drugs: Sugar (psycho-active and pretty destructive for the metabolism long-term if abused), caffeine (pretty benign, comes with mild withdrawal symptoms) and alcohol (probably the No 1 killer drug on the planet), all in moderation. No, what a "drug" is is not defined by law. It is defined by its medical effects. Anything else is just disconnected from reality.
Indeed. Drivers are trusted. That means they can break your security and there is nothing that can be done about it. As to malice, that seems highly unlikely, as this issue would have been better hidden. In particular, the attacker would have made sure these "sensors" do not detect it. A placed backdoor loses most of its worth after it has been found. No, this is just a regular screw-up that stems from the fact that the world still has not learned that software is hard and that people doing it well need talent, expensive and intense education and experience and that nothing else will serve. Getting more cheaper coders will just allow you to produce more errors in less time.
The max-age of zero is nice! "Zero-insight coding" is what I call that. I have seen such things as well.
I do strongly recommend against the code monkeys from India though. They will make things even worse. All the competent people from India are not cheaper than western devs. The others are really, really bad. The made the all-time worst implementation of a feature (that still worked, somewhat) that I have seen: A piece of code that was used to remove duplicated from an SQL-query result. They used a manually coded bubble-sort, i.e. O(n^2) for that. In Java. In a situation where you could have a lot of results. The code was too slow (500ms mainframe limit) even with test data that was nowhere near production-sized. Of course, Java has better sorting in O(n log n). Of course Java has hash-tables which give you close to O(n) for this task. Of course, they could just have told the DB engine to remove the duplicates. Oh, and variable names were > 80 characters with sometimes only 1 char difference. And some other things. If found this while doing an interface review and I was not even looking at the code. But that double-loop just looked immediately wrong.
Needless to say, the project failed. But here it comes: This was the second time this failed and the project "leader" that screwed the outsourcing up had already killed the first attempt by the same mistake. India both times. Each time this took something like 3 years. And he did not get fired the second time either. It is absolutely no surprise that with corporate culture being this bad (i.e. it matters who you are in bed with, not what you can and cannot do) things are completely messed up.
Larry Wall has won the obfuscated C contest several times by now. Not an accident. You can write well readable code in Perl though, I have give Perl code to students for years and for them to modify and base their own work on and there never were any problems. Requires insight and discipline, just like any quality coding, really.
In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?
Everything *MUST* *BE* unit-tested for type-correctness
While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.
I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.
Static type-safety has its advantages and its disadvantages. For newbies it can be pretty helpful, but they often think this is something that is expected to be there. A huge disadvantage in most languages (except Eiffel) is that static type-safety usually enforces that child classes can always be used instead of their parent. That massively limits code-reuse and is not a good model in general. It just makes compiler-creation easier. In Eiffel, this is solved with a global translation scope. The compiler will, for example, accept children that have methods removed if these are never called when the child is used for the parent or the child is never used in place of the parent type. In Python, you have the same power, but you do it dynamically. That means type errors will be found at run-time only, but any reasonable test-coverage will find problems caused bu this and you need that test-coverage anyways. Also, if you use this feature with understanding and care, it will not drive debugging and testing efforts up at all.
It is a great way for the incompetent to mess things up though. Although the incompetent have no business writing production code anyways. In all tech fields (except coding, because it is too new), we require an engineering degree for full-custom design (which basically all coding is). In coding, we need to to the same. The driver in other tech is that the harm done and the cost increased from bad implementations just make it economically non-viable to do custom designs with less than an engineer. This is even more true in coding, but somehow the "managers" still think they can do this with cheaper people and get better value. This is _known_ to be untrue. Admittedly, other engineering disciplines needed reference catastrophes and quite a bit of time to get it and to establish these rules. Coding is not there yet, but there are huge financial advantages to be had by making sure all your coders really know what they are doing and know what their limits are. Requires planning a bit longer than just for the next quarter though, and that seems to be something the "managers" cannot manage either these days.
Indeed. This only hits you if you incompetently assume the rules are the same as for some other language. Scope is one of the things anybody competent looks at when learning a new language.
Because "managers" cannot do simple math. They do not understand that people who are cheaper per hour but produce a lot of problems are much more expensive than people who are more expensive per hour but produce far less problems. They also have no clue that writing software is anything but easy.
I am also in IT security and I cannot say I disagree. Although as part of my job I do security coding at full consulting rates. That is about 3 times what our customers pay for regular coders and it is eminently worth it for them. I mean, "senior web developers" with > 5 years of experience that do not even know what a HTTP request looks like? These people are worth worse than nothing. They would be very expensive if they were free. It is utterly pathetic. And this is from a Fortune-500 company that critically depends on its IT.
There are software engineers. There are people that are well trained as engineers in the real of producing software and have been selected for talent and insight. There are also gifted amateurs that are almost as good. But these people are a small, small minority in the coder population.
It is time to require that engineering degree and have the self-taught people come in and prove they can do as well. (Little known fact: You can get almost any academic degree without going to university by proving equivalent skills and a few years real-world experience in the field. At least in Europe you can.) And then degrade the rest to technicians and prevent them from designing anything and from working on software unsupervised by engineers. Have any company that does produce software and does not follow this be liable for any and all damage caused to an unlimited degree.
Fuckushima with the wind blowing differently. Fuckushima with the cooling pool catching fire (which was a very close thing). No more Tokyo. That is unacceptable, even if it was narrowly avoided by pure dumb luck.
Indeed. And since a lot of people mindlessly cheered for nuclear and saw it as a sign of prosperity and power (via the bomb), there was a lot of money to be made. The best part is that the follow-up costs of nuclear is extreme (in a non-catastrophe scenario), but nobody that profited is going to pay.
This person has not even the decency to be minimally ashamed for his hugely negative contribution to the human endeavor. That is the face of tomorrow, if we do not stop it. That is the kind of person that would have done really well in the 3rd Reich. That is, if he had made it past the race laws.
Possibly. At the very least we know that the nuclear industry has screwed up badly in the last half century and still is neither cost-effective nor safe and has extreme follow-up costs that nobody has yet paid for. And the alternatives are getting better every day or are already significantly superior with much lower risks.
Scope in Python is complex. However, it is absolutely nothing that will surprise anybody competent. Because if you have a variable twice, with different scope, anybody competent will read up how scope works before. Also, "accidentally" reversing an assignment is a code bug and nobody with the least bit of understanding would ever blame the language for the effects.
Slashdot Mirror
You forget all the people employed to keep the "non-profit" prisons running. And all the suppliers. And all the judges, police, prosecutors, etc. They all want profits or job-security. The mere fact that the US has a lot of people behind bars (the only thing were the US is a real world-leader) creates huge incentives for keeping that going. Utterly perverted incentives.
It is clearly part of what is going on. The other part is that religious fuckups deeply desire to control what others can do with their bodies. No fun except in prayer. Some even say this openly. It is really a coalition of evil.
Indeed. You may also find this research pretty much proves this: https://www.theauthoritarians....
Indeed. The base-problem is that we have these fuckups in society that want to control what other people do, no matter what. And they think the only thing fun in live should be prayer.
In actual reality, anybody that wants drugs can get them. None of the deterrents work. The deterrents waste an extreme amount of money though and cause massive secondary damage. So legalizing drugs would have a number of advantages.
First, the cost goes down massively and the quality goes massively up and becomes reliable. That means anybody that has their habit under control stops suffering the insane side-effects of the enforcement of stupid laws and the risks of buying variable quality and the need to generate oodles of money to buy the stuff. That already solves a large part of the problem. Also, anybody that does not have it under control can get help much easier and far better information on how things actually work will become generally available.
Second, legalizing it opens the door for less addictive, less harmful drugs. I am sure the large pharma companies already have a few of these ready and research would certainly be intense. Of course, evil corporate monsters being what they are, you would still need laws limiting addictiveness so that they do not try to make and sell more dangerous stuff. We saw that happen with Big Tobacco in the past. These laws and their enforcement will be tricky and they should certainly not be done by the fuckups currently in charge of "fighting" drugs.
And third, all those insane and destructive efforts to fight drugs will stop being a burden on society. A wave of new additions is very unlikely to happen. The current opioid problem in the US was caused by the doctors and some really evil people in the pharma industry, not the patients. That is why some regulation and enforcement will still be required, but none of it should be targeted at the users.
Side note to the most dumb counterargument somebody will surely bring up ("You just want to use drugs!"): I do use drugs: Sugar (psycho-active and pretty destructive for the metabolism long-term if abused), caffeine (pretty benign, comes with mild withdrawal symptoms) and alcohol (probably the No 1 killer drug on the planet), all in moderation. No, what a "drug" is is not defined by law. It is defined by its medical effects. Anything else is just disconnected from reality.
It has some reduced and basically compromised nebulous idea of security. Nothing like what much older systems offer.
Indeed. Drivers are trusted. That means they can break your security and there is nothing that can be done about it. As to malice, that seems highly unlikely, as this issue would have been better hidden. In particular, the attacker would have made sure these "sensors" do not detect it. A placed backdoor loses most of its worth after it has been found. No, this is just a regular screw-up that stems from the fact that the world still has not learned that software is hard and that people doing it well need talent, expensive and intense education and experience and that nothing else will serve. Getting more cheaper coders will just allow you to produce more errors in less time.
Indeed. I call that "assault"...
The max-age of zero is nice! "Zero-insight coding" is what I call that. I have seen such things as well.
I do strongly recommend against the code monkeys from India though. They will make things even worse. All the competent people from India are not cheaper than western devs. The others are really, really bad. The made the all-time worst implementation of a feature (that still worked, somewhat) that I have seen: A piece of code that was used to remove duplicated from an SQL-query result. They used a manually coded bubble-sort, i.e. O(n^2) for that. In Java. In a situation where you could have a lot of results. The code was too slow (500ms mainframe limit) even with test data that was nowhere near production-sized. Of course, Java has better sorting in O(n log n). Of course Java has hash-tables which give you close to O(n) for this task. Of course, they could just have told the DB engine to remove the duplicates. Oh, and variable names were > 80 characters with sometimes only 1 char difference. And some other things. If found this while doing an interface review and I was not even looking at the code. But that double-loop just looked immediately wrong.
Needless to say, the project failed. But here it comes: This was the second time this failed and the project "leader" that screwed the outsourcing up had already killed the first attempt by the same mistake. India both times. Each time this took something like 3 years. And he did not get fired the second time either. It is absolutely no surprise that with corporate culture being this bad (i.e. it matters who you are in bed with, not what you can and cannot do) things are completely messed up.
Larry Wall has won the obfuscated C contest several times by now. Not an accident. You can write well readable code in Perl though, I have give Perl code to students for years and for them to modify and base their own work on and there never were any problems. Requires insight and discipline, just like any quality coding, really.
In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?
Everything *MUST* *BE* unit-tested for type-correctness
While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.
I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.
Static type-safety has its advantages and its disadvantages. For newbies it can be pretty helpful, but they often think this is something that is expected to be there. A huge disadvantage in most languages (except Eiffel) is that static type-safety usually enforces that child classes can always be used instead of their parent. That massively limits code-reuse and is not a good model in general. It just makes compiler-creation easier. In Eiffel, this is solved with a global translation scope. The compiler will, for example, accept children that have methods removed if these are never called when the child is used for the parent or the child is never used in place of the parent type. In Python, you have the same power, but you do it dynamically. That means type errors will be found at run-time only, but any reasonable test-coverage will find problems caused bu this and you need that test-coverage anyways. Also, if you use this feature with understanding and care, it will not drive debugging and testing efforts up at all.
It is a great way for the incompetent to mess things up though. Although the incompetent have no business writing production code anyways. In all tech fields (except coding, because it is too new), we require an engineering degree for full-custom design (which basically all coding is). In coding, we need to to the same. The driver in other tech is that the harm done and the cost increased from bad implementations just make it economically non-viable to do custom designs with less than an engineer. This is even more true in coding, but somehow the "managers" still think they can do this with cheaper people and get better value. This is _known_ to be untrue. Admittedly, other engineering disciplines needed reference catastrophes and quite a bit of time to get it and to establish these rules. Coding is not there yet, but there are huge financial advantages to be had by making sure all your coders really know what they are doing and know what their limits are. Requires planning a bit longer than just for the next quarter though, and that seems to be something the "managers" cannot manage either these days.
Indeed. This only hits you if you incompetently assume the rules are the same as for some other language. Scope is one of the things anybody competent looks at when learning a new language.
I have seen the graves. It happened. Go away Nazi scum.
Yes! Blut und Boden! Because that works so well...
Anybody with a camera is not impressed. This is not "nuclear", except in the sense that it is tiny and meaningless.
YubiKey does not sell HSMs. If you go with a cheap real HSM, you are paying at least $50'000.
Because "managers" cannot do simple math. They do not understand that people who are cheaper per hour but produce a lot of problems are much more expensive than people who are more expensive per hour but produce far less problems. They also have no clue that writing software is anything but easy.
I am also in IT security and I cannot say I disagree. Although as part of my job I do security coding at full consulting rates. That is about 3 times what our customers pay for regular coders and it is eminently worth it for them. I mean, "senior web developers" with > 5 years of experience that do not even know what a HTTP request looks like? These people are worth worse than nothing. They would be very expensive if they were free. It is utterly pathetic. And this is from a Fortune-500 company that critically depends on its IT.
There are software engineers. There are people that are well trained as engineers in the real of producing software and have been selected for talent and insight. There are also gifted amateurs that are almost as good. But these people are a small, small minority in the coder population.
It is time to require that engineering degree and have the self-taught people come in and prove they can do as well. (Little known fact: You can get almost any academic degree without going to university by proving equivalent skills and a few years real-world experience in the field. At least in Europe you can.) And then degrade the rest to technicians and prevent them from designing anything and from working on software unsupervised by engineers. Have any company that does produce software and does not follow this be liable for any and all damage caused to an unlimited degree.
Fuckushima with the wind blowing differently. Fuckushima with the cooling pool catching fire (which was a very close thing). No more Tokyo. That is unacceptable, even if it was narrowly avoided by pure dumb luck.
You were saying?
Indeed. And since a lot of people mindlessly cheered for nuclear and saw it as a sign of prosperity and power (via the bomb), there was a lot of money to be made. The best part is that the follow-up costs of nuclear is extreme (in a non-catastrophe scenario), but nobody that profited is going to pay.
This person has not even the decency to be minimally ashamed for his hugely negative contribution to the human endeavor. That is the face of tomorrow, if we do not stop it. That is the kind of person that would have done really well in the 3rd Reich. That is, if he had made it past the race laws.
Possibly. At the very least we know that the nuclear industry has screwed up badly in the last half century and still is neither cost-effective nor safe and has extreme follow-up costs that nobody has yet paid for. And the alternatives are getting better every day or are already significantly superior with much lower risks.
None of which I was talking about. You are not only functionally illiterate, you are an idiot. Non-idiots can recognize context, you cannot.
I am no use to idiots, and ipso facto no use to you. A fact I can live with very well.
Scope in Python is complex. However, it is absolutely nothing that will surprise anybody competent. Because if you have a variable twice, with different scope, anybody competent will read up how scope works before. Also, "accidentally" reversing an assignment is a code bug and nobody with the least bit of understanding would ever blame the language for the effects.