1. He assumes computing power will continue to scale. There are rather strong indications that it will not. And no, we are still very far removed from "fotorealistic" (and may never get there) and we do not have "millions" of people interacting on the same servers. At best, we can manage a few thousands and that not in real-time.
2. He assumes there is such an other civilization, completely without any basis for it. At all.
3. It is very likely that there are other problems than computing power and software for the necessary degree of immersion to be feasible.
4. He assumes a physicalist world model without any scientific basis to that assumption. The scientific state-of-the-art is very much "we have no clue" on that question,but there are some rather strong indicators that Physicalism may be the wrong model.
In short, his statement about the likelihood is unmitigated nonsense. It _is_ one possibility, but one among a great many others.
At this time, I am very seriously considering throwing out udev and all the instability and auto-mess it brings with it and going back to statically created device nodes. While a bit more work initially, that does not fall over foaming at the mouth if something is not quite as it expects.
Current Debian still works pretty well without the systemd atrocity. Sure, you will probably have to do without the now fundamentally broken Gnome and some mostly inert systemd cruft will be lying around unless you go to extreme measures, but a stable, reliable, server-grade Debian installation is still pretty easy to get from the current stable Debian version by booting it with via sysvinit. I really do hope this will stay a viable option, as systemd is basically bad in every regard imaginable, including security, reliability, least surprise and maintainability. It is really uncanny how these people managed to screw up this badly.
You only have demonstrated that you do not even understand basic crypto terms. Nobody with even basic valid crypto knowledge would confuse hashes and encryption, for example. As to digital signatures, hashes are completely optional there and _only_ serve to improve efficiently, they do not serve a security function at all in that usage. You really are completely clueless, and you do not know it. You may also want to look up the "Dunning-Kuger Effect".
And you just demonstrated that you have no clue what you are talking about as you confused symmetric and asymmetric crypto. Here is a hint: Verifying a hash means to verify a shared, known good value, that is known-good by a different mechanism. Verifying a signature means an asymmetric verification, no shared value involved.
And then you have a machine with a digital input that is actually fed digital music. And, oops, you are screwed. The problem here is that for one user that knows what he is doing, this is fine. As a general solution, this falls flat on its face. The actual solution would be something like the Intel RDRAND instruction, but unfortunately that is a compromised design that you cannot trust. ("Compromised Design" means they can swap out the actual secure implementation for a compromised one and the design prevents detection of this attack.)
Exactly. You add points of attack, but _all_ have to be compromised for the attack to succeed. If, for example, you have one of the compromised Intel CPUs with a bad RDRAND generator (not detectable except with in-dept analysis of the physical chip), then even one other system feeding you good entropy makes you secure again.
Indeed. You go from one point of attack to a group, and _all_ have to be attacked successfully for the scheme to be compromised. As long as even one source delivers good entropy, you are secure with a distributed mechanism.
An entropy-source is not a point of attack, as long as it is not relied on exclusively. This is a threshold-thing. Get enough good entropy and you are good, no matter how much "bad" entropy you add as well. Fundamental entropy-pool design principle. You really are clueless as to how this works.
Do you have any examples where it has been harmful in the long run to learn to use some overly simplistic tools, languages, etc?
Like are there kids who never learned to ride a bicycle because they had training wheels? Is there a CS equivalent to that? I can't image there is one.
That is exactly the problem. With training-wheels, you still learn the real thing, and the wheels can eventually be removed for almost all people. The simplistic things being taught in "hour of code" and cretinized programs like that are more like keeping people in a baby-stroller as preparation to learn how to ride a bike. There is no way they will learn anything useful or anything about what the skill really is about that way. The harm comes from both people that select to go into this direction and ones that select to stay away because of a fundamentally wrong impression of what the field is about. You end up with a lot of people that after all do not want to be in this field when they see what is really about and others that would have been good and enjoyed it, but were turned away early.
Same experience here. I find that many things I code today need advanced algorithms and data-structures, estimates, and the occasional proof. Coding on advanced difficulty-level cannot really be done unless you also have a solid CS background. And that is where the money is, because you become very hard to replace.
CS can be taught academically, in worse or better versions. Coding cannot really be taught at this time. We do not know how to do it. Like most advanced skills it needs about 10'000 hours of practice to become reasonably good at it, and most of that time people need to spend in self-directed study by themselves, practicing on a variety of projects, tools and languages. The "learn coding quick" bullshit-meme of today is really "learn some very restricted form of coding very badly" and it harms a lot more than it helps.
No. The title is bullshit. This is about generating very hard to predict pseudo-random numbers, because you have to guess a large, distributed state and distributed seeding values.
As there is zero need for "true random" numbers in crypto (you only need "not guessable fro an attacker"), this is still a significant improvement.
Side note: Whenever something "mainstream" reports about random number generation, they get it wrong. It seems that non-experts routinely have no clue what is important here and what not. As for crypto, the philosophical question what "random" means is completely immaterial. Crypto just cares whether an attacker can somehow find out the "random" number or not and how difficult it is if it is possible. There is no need for "true" random numbers anywhere in crypto.
Indeed. And this has been known for more than a decade. But I expect nothing will happen until ISPs become liable for damage done if they do not implement source address filtering.
Slashdot Mirror
There is a difference between a stunt and a mainstream-usable technology. A smart person can spot that difference.
1. He assumes computing power will continue to scale. There are rather strong indications that it will not. And no, we are still very far removed from "fotorealistic" (and may never get there) and we do not have "millions" of people interacting on the same servers. At best, we can manage a few thousands and that not in real-time.
2. He assumes there is such an other civilization, completely without any basis for it. At all.
3. It is very likely that there are other problems than computing power and software for the necessary degree of immersion to be feasible.
4. He assumes a physicalist world model without any scientific basis to that assumption. The scientific state-of-the-art is very much "we have no clue" on that question,but there are some rather strong indicators that Physicalism may be the wrong model.
In short, his statement about the likelihood is unmitigated nonsense. It _is_ one possibility, but one among a great many others.
Indeed. Something the Windows-world does not know: There you only get what you deserve.
At this time, I am very seriously considering throwing out udev and all the instability and auto-mess it brings with it and going back to statically created device nodes. While a bit more work initially, that does not fall over foaming at the mouth if something is not quite as it expects.
Current Debian still works pretty well without the systemd atrocity. Sure, you will probably have to do without the now fundamentally broken Gnome and some mostly inert systemd cruft will be lying around unless you go to extreme measures, but a stable, reliable, server-grade Debian installation is still pretty easy to get from the current stable Debian version by booting it with via sysvinit. I really do hope this will stay a viable option, as systemd is basically bad in every regard imaginable, including security, reliability, least surprise and maintainability. It is really uncanny how these people managed to screw up this badly.
You only have demonstrated that you do not even understand basic crypto terms. Nobody with even basic valid crypto knowledge would confuse hashes and encryption, for example. As to digital signatures, hashes are completely optional there and _only_ serve to improve efficiently, they do not serve a security function at all in that usage. You really are completely clueless, and you do not know it. You may also want to look up the "Dunning-Kuger Effect".
And you just demonstrated that you have no clue what you are talking about as you confused symmetric and asymmetric crypto. Here is a hint: Verifying a hash means to verify a shared, known good value, that is known-good by a different mechanism. Verifying a signature means an asymmetric verification, no shared value involved.
Even if it is, unless you do something very stupid, they cannot easily identify you.
And there you have provided an excellent example of FUD. Are you paid to spread fear?
And then you have a machine with a digital input that is actually fed digital music. And, oops, you are screwed. The problem here is that for one user that knows what he is doing, this is fine. As a general solution, this falls flat on its face. The actual solution would be something like the Intel RDRAND instruction, but unfortunately that is a compromised design that you cannot trust. ("Compromised Design" means they can swap out the actual secure implementation for a compromised one and the design prevents detection of this attack.)
These things are unworkable in practice. Too expensive, too unreliable and nobody wants to pay for them. OS support is typically lacking as well.
What you're thinking of is in the actual encryption stage
Possibly. Talk about incompetence coupled with arrogance. Dunning-Kruger at work.
Exactly. You add points of attack, but _all_ have to be compromised for the attack to succeed. If, for example, you have one of the compromised Intel CPUs with a bad RDRAND generator (not detectable except with in-dept analysis of the physical chip), then even one other system feeding you good entropy makes you secure again.
Indeed. You go from one point of attack to a group, and _all_ have to be attacked successfully for the scheme to be compromised. As long as even one source delivers good entropy, you are secure with a distributed mechanism.
An entropy-source is not a point of attack, as long as it is not relied on exclusively. This is a threshold-thing. Get enough good entropy and you are good, no matter how much "bad" entropy you add as well. Fundamental entropy-pool design principle. You really are clueless as to how this works.
That is the idea. Although entropy-pools are much more sophisticated than using simple xor for this.
Do you have any examples where it has been harmful in the long run to learn to use some overly simplistic tools, languages, etc?
Like are there kids who never learned to ride a bicycle because they had training wheels? Is there a CS equivalent to that? I can't image there is one.
That is exactly the problem. With training-wheels, you still learn the real thing, and the wheels can eventually be removed for almost all people. The simplistic things being taught in "hour of code" and cretinized programs like that are more like keeping people in a baby-stroller as preparation to learn how to ride a bike. There is no way they will learn anything useful or anything about what the skill really is about that way. The harm comes from both people that select to go into this direction and ones that select to stay away because of a fundamentally wrong impression of what the field is about. You end up with a lot of people that after all do not want to be in this field when they see what is really about and others that would have been good and enjoyed it, but were turned away early.
Same experience here. I find that many things I code today need advanced algorithms and data-structures, estimates, and the occasional proof. Coding on advanced difficulty-level cannot really be done unless you also have a solid CS background. And that is where the money is, because you become very hard to replace.
CS can be taught academically, in worse or better versions. Coding cannot really be taught at this time. We do not know how to do it. Like most advanced skills it needs about 10'000 hours of practice to become reasonably good at it, and most of that time people need to spend in self-directed study by themselves, practicing on a variety of projects, tools and languages. The "learn coding quick" bullshit-meme of today is really "learn some very restricted form of coding very badly" and it harms a lot more than it helps.
AFAIK, they do not. ISPs pay for upstream data and less and less of that. For downstream, they only pay bandwidth, as they do not control that.
No. The title is bullshit. This is about generating very hard to predict pseudo-random numbers, because you have to guess a large, distributed state and distributed seeding values.
As there is zero need for "true random" numbers in crypto (you only need "not guessable fro an attacker"), this is still a significant improvement.
Side note: Whenever something "mainstream" reports about random number generation, they get it wrong. It seems that non-experts routinely have no clue what is important here and what not. As for crypto, the philosophical question what "random" means is completely immaterial. Crypto just cares whether an attacker can somehow find out the "random" number or not and how difficult it is if it is possible. There is no need for "true" random numbers anywhere in crypto.
"sophisticated political views" = "views I agree with and I think I am sophisticated".
Is it just me or has the amount of propaganda-language like this recently increased a lot in /. stories?
That is so far removed from reality, I will not even comment on it.
Indeed. And this has been known for more than a decade. But I expect nothing will happen until ISPs become liable for damage done if they do not implement source address filtering.
Well, I expect you are now on a list of "violent crazies".