And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.
Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.
It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.
On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.
My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find out how to deal with a new technology that may not even be around for a longer time.
It does. And it is glaringly obvious that it does: The decrypted data has entropy lower by at least the entropy in the encryption key and that entropy was distributed over the bits of the encrypted data. As such, it is fundamentally different. Some basic understanding of what encryption does is required to see this though.
You cannot keep an economy going with laws. The only thing this would cause is companies leaving the US altogether. While I am unsure how this problem can be fixed and whether it can be fixed at all, this is certainly not the way.
Funny how they say "might even help bring manufacturing back to the U.S.", but it does not mean "bring jobs back to the US". I wonder how many people missed that little problem.
The problem with that is that you are far above average. The average IT person learns slowly and has trouble learning new things in the first place. They still need to eat and be able to live decently, same as everybody else or society breaks down. Sure, one problem is too many mediocre people in IT in the first place, but that is what they have learned and now somehow need to be able to do.
I see your problem: You are unable to generalize and think one specific highly untypical example is representative. No use arguing with you, you do not have what it takes.
A good programmer learns assembly to better understand how to write simpler, smaller, and faster code. A shitty programmer makes excuses for why they don't understand assembly.
And that is just the point. Most of the excuses here have stayed the same for the last few decades and are just as invalid today as they where back then.
Well, there is something to your stance, but I think a language that has bit-shift should also have carry-bit access. Of course, it should also have rotate with and without carry, and maybe the real issue here is that CPUs were not standardized enough in that area when C was defined. Although the carry-bit has been very standard for a long time. On the other hand, one primary design criteria for C was that writing a compiler should be very easy (and writing a non-optimizing C compiler is pretty easy), and things like carry, rotate, etc. may just have been cut to keep the language small.
I do fully agree that anybody that does not know what a carry-bit is is not a low-level coder at all and that many people that fancy themselves low-level coders do not qualify as such.
I have a set of tools, and I use the one I think is best for the job. Sometimes I will evaluate something new or less used, but only if I think it is still a good fit. People that have a default tool and use it for everything may "switch" after a time, but having a default tool that is not a good approach in the first place.
Very much so. I lost some passwords some time ago (dead disk and I had not included these in the backups by accident) and was very surprised how easy it was to get my accesses back.
That is tragic. While rarely used, it gives you a far better understanding of how things work. Seems most engineering students these days aim for being mediocre.
Slashdot Mirror
And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.
Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.
It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.
On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.
My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find out how to deal with a new technology that may not even be around for a longer time.
There is no reason to assume that Rust would be any better. But the egos of the Rust-people are much bigger, so they make bolder claims.
It does. And it is glaringly obvious that it does: The decrypted data has entropy lower by at least the entropy in the encryption key and that entropy was distributed over the bits of the encrypted data. As such, it is fundamentally different. Some basic understanding of what encryption does is required to see this though.
At least that is the best possible explanation so far.
You cannot keep an economy going with laws. The only thing this would cause is companies leaving the US altogether. While I am unsure how this problem can be fixed and whether it can be fixed at all, this is certainly not the way.
Funny how they say "might even help bring manufacturing back to the U.S.", but it does not mean "bring jobs back to the US". I wonder how many people missed that little problem.
The problem with that is that you are far above average. The average IT person learns slowly and has trouble learning new things in the first place. They still need to eat and be able to live decently, same as everybody else or society breaks down. Sure, one problem is too many mediocre people in IT in the first place, but that is what they have learned and now somehow need to be able to do.
Like any self-respecting con-person would.
At this time, the choice of candidates for president in the US is "very bad" and "somewhat worse" (your choice which is which).
I highly doubt that. From that kind of "qualification" you will get 0% good ones, as they are already in better jobs.
Indeed. More bad code from bad coders. We already have more than enough of both.
My guess is some people in the media have either bought put-options or want to buy Tesla stock cheap. There is no rationality to their reporting.
I see your problem: You are unable to generalize and think one specific highly untypical example is representative. No use arguing with you, you do not have what it takes.
Well, the "high intelligence" part here is somewhat variable.
These are decidedly special cases and you get no argument from me.
You can update 8 bit MCU based devices in the field? If so, I am deeply impressed, because you seem to be able to do something nobody else can do.
A good programmer learns assembly to better understand how to write simpler, smaller, and faster code.
A shitty programmer makes excuses for why they don't understand assembly.
And that is just the point. Most of the excuses here have stayed the same for the last few decades and are just as invalid today as they where back then.
Well, there is something to your stance, but I think a language that has bit-shift should also have carry-bit access. Of course, it should also have rotate with and without carry, and maybe the real issue here is that CPUs were not standardized enough in that area when C was defined. Although the carry-bit has been very standard for a long time. On the other hand, one primary design criteria for C was that writing a compiler should be very easy (and writing a non-optimizing C compiler is pretty easy), and things like carry, rotate, etc. may just have been cut to keep the language small.
I do fully agree that anybody that does not know what a carry-bit is is not a low-level coder at all and that many people that fancy themselves low-level coders do not qualify as such.
I have a set of tools, and I use the one I think is best for the job. Sometimes I will evaluate something new or less used, but only if I think it is still a good fit. People that have a default tool and use it for everything may "switch" after a time, but having a default tool that is not a good approach in the first place.
Very much so. I lost some passwords some time ago (dead disk and I had not included these in the backups by accident) and was very surprised how easy it was to get my accesses back.
Indeed. It is however something people with big egos, high intelligence and absolutely no wisdom whatsoever try time and again.
I fully agree that writing assembler without a very good reason is not a good idea today.
That is tragic. While rarely used, it gives you a far better understanding of how things work. Seems most engineering students these days aim for being mediocre.