This is a slow road to irrelevancy though: Because all the good STEM workers will leave, and only those that have no other prospects will stay. IBM is in that fix at the moment for example, they do not have many good engineers left. Same with HP or Yeahoo. Sure, giants die slowly, but once they are moribund, nothing can safe them.
I completely agree. One condition of getting me to work for you is that every minute I work is on the clock and gets paid for. Otherwise, overtime (which in a sane environment is reserved for emergencies only) becomes a tool management uses to compensate for their mistakes.
Bullshit. Good STEM workers are not primarily interested in money, or they would have chosen a different field. Of course, it has to be still enough to make a decent living, but otherwise other things are more important. Not all people are like the modern "manager" species that does not understand anything except money, and that only with a short-term view.
The level of stupidity in that is staggering. I do remote management, testing, development etc. all the time (currently Linux and Solaris) and the only thing (with very rare exceptions) I use is ssh without X-forwarding. As to window-manager, I mostly need it to arrange xterms (and one web-browser window). Fvwm with its pager is perfect for that and I have not had to adjust anything in about 10 years.
This also shows one fundamental problem the whole IT industry has today: Recruiters are utterly clueless. That is why so many bad coders get jobs.
Yes, _those_. The people that think security can be created by bureaucratic process. These are really the worst. I am constantly amazed how many people need to be told that "compliance" does not ensure security at all and vice versa. It is the same mind-set that thinks forbidding something makes it vanish.
The difference here is that you wanted to have a successful business, and did. The ones criticizing you have big egos and small actual business skills. They think that "running a business" means imposing your personal preferences on the people that work for you, just like a business was a little authoritarian state where everything must be controlled from the top. That is a recipe for failure, even if it takes a long time to manifest.
Quite plausible. And just look at Germany where a PM that asked critical questions about the conduct of the National Police was eliminated in exactly this fashion with timing that is more than just highly suspicious. Obviously the spiritual successors to the GeStaPo have material about everybody they potentially may be threatened by, but they only use it when these people move against them. This is a hidden, slow coup, nothing else.
Can you offer a reason to prefer it over a better algorithm with better properties that takes less compute power and has been subject to a rigorous standardization process? E.G. Shake128. I can't.
Obviously you have no experience in the real world, or you would have found the glaringly obvious scenario. It really is quite simple: Applications that already use it, but in a task were it is secure. Replacing it is effort, causes problems and may even introduce security problems. Claiming it is generally insecure is problematic and unprofessional.
Incidentally, "takes less compute power" is undesirable in password hashing.
Indeed. Unfortunately, it is much, much worse: If they have material about an MP before that person became an MP (and they will have that), they can already blackmail that MP.
The biggest issues are actually that it is immature and that it is yet another language attempting to fix bad coders, which is something a language cannot do. Hence it was created for all the wrong reasons and it shows.
There is this large number of younger coders that got into IT not because they love it, but because they thought it was a sure meal-ticket. These people are scared by things like pointer-handling or memory management, because they do not actually understand it. Then they jump on every new thing that comes around just because they hope it will make them appear less incompetent.
The rabid pro-Rust crowd is an excellent example, because the benefits of Rust are not actually that remarkable and, in addition, both language and libraries are immature and hence should never be used in any production project at this time. Yes, they _can_ be used, but that would be hugely unprofessional and bring more problems with it than the language can solve. The one exception is the Rust developers themselves as they have to accept that drawback in order to get experience with their language. Nobody else has to and nobody else should.
Sounds very much like Rust is a huge pain for those of us that actually know what we are doing. Suddenly we need to work around an authoritarian compiler that thinks we are children and it knows best. Not desirable unless your coders are monkeys because you pay peanuts.
This seems very likely. Of course the Rust fanatics (in themselves a valid reason to stay away from that language) will claim differently on all points, but that is just propaganda.
Becoming a language expert is a huge wast of time. If a language is so difficult that you have to become an expert in it to use it efficiently, stay away from it. If it does not, then picking it up is quite enough. Sure, you have to understand things like algorithms and datastructures (a thing most coders already fail at), the machine, etc. But these do not really change from language to language. You also have to understand the main language paradigms. But a need to "get nuances" just means you are using a bad tool.
There's really no reason ever to use C over C++ if you have a C++ compiler available.
You must be one of these "modern" coders that never have heard of simplicity or all the problems still C++ has. I do not think taking advice from you is wise.
On the minus side, a poor engineer will not even be able to do Rust at this time, so Rust benefits form that you likely get better people as you either have to get one of the very few people that can do Rust or get one that can learn it fast.
That said, do not mix languages on a large project unless you have to. And of you really go Rust, make sure you have more than one engineer who can work with it. Also counting against Rust is that it is too new.
I would also say that the person insisting on Rust is acting hugely unprofessional and trying to push his personal agenda on the project. That alone would be a valid reason to "bulldoze" him.
SHA1 does not need to go into the bin for all applications. For password-hashing it is still fine, if iterated and salted appropriately. Please stop spreading FUD.
Slashdot Mirror
Ah, yes. Supervisors that think _they_ are doing the important work....
This is a slow road to irrelevancy though: Because all the good STEM workers will leave, and only those that have no other prospects will stay. IBM is in that fix at the moment for example, they do not have many good engineers left. Same with HP or Yeahoo. Sure, giants die slowly, but once they are moribund, nothing can safe them.
I completely agree. One condition of getting me to work for you is that every minute I work is on the clock and gets paid for. Otherwise, overtime (which in a sane environment is reserved for emergencies only) becomes a tool management uses to compensate for their mistakes.
Bullshit. Good STEM workers are not primarily interested in money, or they would have chosen a different field. Of course, it has to be still enough to make a decent living, but otherwise other things are more important. Not all people are like the modern "manager" species that does not understand anything except money, and that only with a short-term view.
Loyalty is priceless. Unfortunately, the MBA scum that swims to the top these days does not understand that.
The level of stupidity in that is staggering. I do remote management, testing, development etc. all the time (currently Linux and Solaris) and the only thing (with very rare exceptions) I use is ssh without X-forwarding. As to window-manager, I mostly need it to arrange xterms (and one web-browser window). Fvwm with its pager is perfect for that and I have not had to adjust anything in about 10 years.
This also shows one fundamental problem the whole IT industry has today: Recruiters are utterly clueless. That is why so many bad coders get jobs.
Yes, _those_. The people that think security can be created by bureaucratic process. These are really the worst. I am constantly amazed how many people need to be told that "compliance" does not ensure security at all and vice versa. It is the same mind-set that thinks forbidding something makes it vanish.
The difference here is that you wanted to have a successful business, and did. The ones criticizing you have big egos and small actual business skills. They think that "running a business" means imposing your personal preferences on the people that work for you, just like a business was a little authoritarian state where everything must be controlled from the top. That is a recipe for failure, even if it takes a long time to manifest.
The worst threat to freedom are happy (and dumb) slaves. You qualify.
Quite plausible. And just look at Germany where a PM that asked critical questions about the conduct of the National Police was eliminated in exactly this fashion with timing that is more than just highly suspicious. Obviously the spiritual successors to the GeStaPo have material about everybody they potentially may be threatened by, but they only use it when these people move against them. This is a hidden, slow coup, nothing else.
Can you offer a reason to prefer it over a better algorithm with better properties that takes less compute power and has been subject to a rigorous standardization process? E.G. Shake128. I can't.
Obviously you have no experience in the real world, or you would have found the glaringly obvious scenario. It really is quite simple: Applications that already use it, but in a task were it is secure. Replacing it is effort, causes problems and may even introduce security problems. Claiming it is generally insecure is problematic and unprofessional.
Incidentally, "takes less compute power" is undesirable in password hashing.
Could not agree more. Using Red Hat Linux is becoming more and more professional misconduct.
The feeling is mutual. Unfortunately, working with nil-whits can usually not be avoided, there are just too many of them.
Indeed. Unfortunately, it is much, much worse: If they have material about an MP before that person became an MP (and they will have that), they can already blackmail that MP.
I have both a gaming-box and a long-running Linux server on the FX8350. Absolutely no problems.
You must not have gotten Intel's payment from the "honesty in journalism" fund. After you have, of course everything Intel is much faster!
The biggest issues are actually that it is immature and that it is yet another language attempting to fix bad coders, which is something a language cannot do. Hence it was created for all the wrong reasons and it shows.
There is this large number of younger coders that got into IT not because they love it, but because they thought it was a sure meal-ticket. These people are scared by things like pointer-handling or memory management, because they do not actually understand it. Then they jump on every new thing that comes around just because they hope it will make them appear less incompetent.
The rabid pro-Rust crowd is an excellent example, because the benefits of Rust are not actually that remarkable and, in addition, both language and libraries are immature and hence should never be used in any production project at this time. Yes, they _can_ be used, but that would be hugely unprofessional and bring more problems with it than the language can solve. The one exception is the Rust developers themselves as they have to accept that drawback in order to get experience with their language. Nobody else has to and nobody else should.
Sounds very much like Rust is a huge pain for those of us that actually know what we are doing. Suddenly we need to work around an authoritarian compiler that thinks we are children and it knows best. Not desirable unless your coders are monkeys because you pay peanuts.
This seems very likely. Of course the Rust fanatics (in themselves a valid reason to stay away from that language) will claim differently on all points, but that is just propaganda.
Becoming a language expert is a huge wast of time. If a language is so difficult that you have to become an expert in it to use it efficiently, stay away from it. If it does not, then picking it up is quite enough. Sure, you have to understand things like algorithms and datastructures (a thing most coders already fail at), the machine, etc. But these do not really change from language to language. You also have to understand the main language paradigms. But a need to "get nuances" just means you are using a bad tool.
There's really no reason ever to use C over C++ if you have a C++ compiler available.
You must be one of these "modern" coders that never have heard of simplicity or all the problems still C++ has. I do not think taking advice from you is wise.
On the minus side, a poor engineer will not even be able to do Rust at this time, so Rust benefits form that you likely get better people as you either have to get one of the very few people that can do Rust or get one that can learn it fast.
That said, do not mix languages on a large project unless you have to. And of you really go Rust, make sure you have more than one engineer who can work with it. Also counting against Rust is that it is too new.
I would also say that the person insisting on Rust is acting hugely unprofessional and trying to push his personal agenda on the project. That alone would be a valid reason to "bulldoze" him.
SHA1 does not need to go into the bin for all applications. For password-hashing it is still fine, if iterated and salted appropriately. Please stop spreading FUD.
Hehehehehehe....
Yes, I had that too.