But here’s the funny thing: when we work out the numbers of our best theoretical calculations, the ones produced by getting kicked out of young solar systems represent far less than half of the rogue planets that we expect.
So the author tries to explain a huge number of expected rogue planets, but fails to describe how we've arrived at the number in the first place. "Work out the numbers"? Yes? Could you please share? Why didn't you start with that in the first paragraph?
Also what's with all the exclamation marks? Is this article pitched at grade-schoolers? Fine but if so, what is it doing here?
It's not just a simple mistake that anyone could have made. If you know anything about computers at all, the error in the title, when you read it, is about as subtle as someone smacking you across the face.
If Soulskill doesn't know the difference between TFLOP and PFLOP, what is he doing posting articles here?
The player made maps were usually better than the ones the game came with.
Uh, no. The player made maps were usually much much worse. They tended to be designed by mappers with no architectural skill, or tended to be horribly buggy as mappers stumbled haphazardly outside the limitations of the game engines. There were few exceptionally good maps. Most were crap. To claim otherwise just reeks of blatant nostalgia bias.
Strange, I found the reverse to be true. The maps me and my classmates made tended to be the best and the most popular for deathmatch. We even had a televised tournament one year. And it was awesome, right down to the final game.
Dear god those were the days. The GPA of our entire fraternity dropped a whole point that semester.
The first thing I learned about storing passwords is that you use a salted hash, which is impossible to decrypt back into plaintext. Am I missing something, or is this practice not standard practically everywhere now?
Apparently you are missing something because while common practice, it's not ubiquitous. And like all common practices, it gets spoken of less and less until new developers reinvent the wheel and decide they want passwords in plain text to make password recovery 'easier' ("click on the http link in your email and you'll see your password!")
It's been many years since I've seen that done anywhere.
To decrypt the password of a user, the attacker has first to have access to the password storage. At which point the first and most critical security failure has already occurred. And the user had nothing to do with it.
When it comes to decrypting a password, the algorithm used is a more important than the complexity of the password. If the service provider has not done his home work, complex passwords offer only little protection. [...] I want to point out, that the safety of the encrypted password is not the responsibility of the user.
The first thing I learned about storing passwords is that you use a salted hash, which is impossible to decrypt back into plaintext. Am I missing something, or is this practice not standard practically everywhere now?
The web should have been given a low-level, machine readable standard which human-friendly formats and tools could have formed and evolved around. Sure we'd still have markup and CSS and script, but you can bet your ass applications wouldn't have been built on that crap. We are easily 10 years behind where we could have been because of a poor choice of level of abstraction.
I don't think that's a good argument that nobody can be required to take responsibility.
By law, C-level execs are required to 'sign off' on a lot of important things, which puts them on the hook for X (regardless of claims of ignorance) because it is a statement that they have checked, with due diligence, the legality of X.
It would be relatively straightforward to add to that list a little.
For best effect, there should be a rider that wrongdoing past a certain scale automatically gets all compensation paid to the exec, to date, doubly seized - seized from the exec (spent or not), and seized from the business.
Dealing With an Unresponsive Manufacturer Who Doesn't Fix Bugs?
Dunno, it's a good question. But I'm sure that someone at slashdot can answer it with the same reasoning that they' use to still be apparently trying to roll out the beta design, despite the fact that some of it's own users (customers???) have in their sig, "FUCK BETA".
As a matter of fact, does anyone know why Steam does not prominently feature Metacritic ratings anymore? Those really helped me choose games that I wanted...
I don't know about you, but when I see a AAA PC game also has a console version, I just stop right there and don't buy it, no matter what the ratings are.
I think the test-driven advocates would say that relying on the compiler is OK for that one particular kind of error, but you really should be writing tests to catch that kind of error along with many others.
The reality is probably, as you kind of imply, sometimes you have a task that is more suited to one approach or another.
The nature of testing is that complete coverage grows combinatorially with state. What you're saying is you don't want to eliminate the possibility of an entire class of errors, but rather rest this (rather significant) burden on testing. From my point of view that's like abandoning DRI in a database and saying tests can detect foreign key constraint violations and all the other things DRI can check. While technically true, it just doesn't make any practical sense.
Niven's view of such devices seemed pretty realistic, that the problem would take care of itself after a few generations.
Even if you were immortal, a droud would still be equivalent of death; remove the constraint of time, and limitation is measured by the boundaries of your mind's total potential state-space.
Any sufficiently intelligent being - no matter how powerful or long-lived - would avoid pleasure-death.
What is not mentioned is that these low-carb and the low-fat diets were both done in the context of the typical, and rather terrible, Western diet. Since no distinction is made between simple and complex carbs, naturally 'low-carb' is going to win, since sugar is the worst offender for creating obesity.
I also have to roll my eyes because we already know what a healthful diet is. The most massive study of this kind in history came to a simple, unambiguous conclusion: eat a whole-foods, plant-based diet, and keep animal protein under 10% (even better, 5%) of your total calorie intake.
Consumers want number(s) to base their decisions upon. The wattage problem could have easily been solved by putting useful measurements of vacuum effectiveness on the packaging, such as guaranteed pressure drop and flow rate over the life of the product.
And the industry could do that all by itself without any regulation.
But here’s the funny thing: when we work out the numbers of our best theoretical calculations, the ones produced by getting kicked out of young solar systems represent far less than half of the rogue planets that we expect.
So the author tries to explain a huge number of expected rogue planets, but fails to describe how we've arrived at the number in the first place. "Work out the numbers"? Yes? Could you please share? Why didn't you start with that in the first paragraph?
Also what's with all the exclamation marks? Is this article pitched at grade-schoolers? Fine but if so, what is it doing here?
this was the first thing I thought of.
It's not just a simple mistake that anyone could have made. If you know anything about computers at all, the error in the title, when you read it, is about as subtle as someone smacking you across the face.
If Soulskill doesn't know the difference between TFLOP and PFLOP, what is he doing posting articles here?
"I'm not sure I have cancer, but based on the ads I've been seeing lately..."
This idea would make for a good near-future science fiction short story, riffing off what's already happened to pregnant teens.
The player made maps were usually better than the ones the game came with.
Uh, no. The player made maps were usually much much worse. They tended to be designed by mappers with no architectural skill, or tended to be horribly buggy as mappers stumbled haphazardly outside the limitations of the game engines. There were few exceptionally good maps. Most were crap. To claim otherwise just reeks of blatant nostalgia bias.
Strange, I found the reverse to be true. The maps me and my classmates made tended to be the best and the most popular for deathmatch. We even had a televised tournament one year. And it was awesome, right down to the final game.
Dear god those were the days. The GPA of our entire fraternity dropped a whole point that semester.
you didn't write it correctly. TDD.
The first thing I learned about storing passwords is that you use a salted hash, which is impossible to decrypt back into plaintext. Am I missing something, or is this practice not standard practically everywhere now?
Apparently you are missing something because while common practice, it's not ubiquitous. And like all common practices, it gets spoken of less and less until new developers reinvent the wheel and decide they want passwords in plain text to make password recovery 'easier' ("click on the http link in your email and you'll see your password!")
It's been many years since I've seen that done anywhere.
DECRYPTING PASSWORDS
To decrypt the password of a user, the attacker has first to have access to the password storage. At which point the first and most critical security failure has already occurred. And the user had nothing to do with it.
When it comes to decrypting a password, the algorithm used is a more important than the complexity of the password. If the service provider has not done his home work, complex passwords offer only little protection. [...] I want to point out, that the safety of the encrypted password is not the responsibility of the user.
The first thing I learned about storing passwords is that you use a salted hash, which is impossible to decrypt back into plaintext. Am I missing something, or is this practice not standard practically everywhere now?
with a bitrate higher than "shitty"?
The users are the product, not the customer.
Not necessarily. Adblock Plus 2.6.4 (for firefox) blocks all of slashdot's ads.
Does that make you not-a-product? Something special above other users?
Nope.
The web should have been given a low-level, machine readable standard which human-friendly formats and tools could have formed and evolved around. Sure we'd still have markup and CSS and script, but you can bet your ass applications wouldn't have been built on that crap. We are easily 10 years behind where we could have been because of a poor choice of level of abstraction.
I don't think that's a good argument that nobody can be required to take responsibility.
By law, C-level execs are required to 'sign off' on a lot of important things, which puts them on the hook for X (regardless of claims of ignorance) because it is a statement that they have checked, with due diligence, the legality of X.
It would be relatively straightforward to add to that list a little.
For best effect, there should be a rider that wrongdoing past a certain scale automatically gets all compensation paid to the exec, to date, doubly seized - seized from the exec (spent or not), and seized from the business.
Dealing With an Unresponsive Manufacturer Who Doesn't Fix Bugs?
Dunno, it's a good question. But I'm sure that someone at slashdot can answer it with the same reasoning that they' use to still be apparently trying to roll out the beta design, despite the fact that some of it's own users (customers???) have in their sig, "FUCK BETA".
The users are the product, not the customer.
As a matter of fact, does anyone know why Steam does not prominently feature Metacritic ratings anymore? Those really helped me choose games that I wanted...
Maybe because games are given very high ratings that completely ignore the PC, even when these ratings are supposed to be for the PC versions?
I don't know about you, but when I see a AAA PC game also has a console version, I just stop right there and don't buy it, no matter what the ratings are.
because I have nothing good to say about s-voice.
it looks like someone played Star Control II
no reference to the wrong trousers?
I think the test-driven advocates would say that relying on the compiler is OK for that one particular kind of error, but you really should be writing tests to catch that kind of error along with many others.
The reality is probably, as you kind of imply, sometimes you have a task that is more suited to one approach or another.
The nature of testing is that complete coverage grows combinatorially with state. What you're saying is you don't want to eliminate the possibility of an entire class of errors, but rather rest this (rather significant) burden on testing. From my point of view that's like abandoning DRI in a database and saying tests can detect foreign key constraint violations and all the other things DRI can check. While technically true, it just doesn't make any practical sense.
All I can find is that the resolution is "higher" than the DK2, and the screen door effect is gone, or nearly so.
Can anyone confirm that they've gone to 4K?
Niven's view of such devices seemed pretty realistic, that the problem would take care of itself after a few generations.
Even if you were immortal, a droud would still be equivalent of death; remove the constraint of time, and limitation is measured by the boundaries of your mind's total potential state-space.
Any sufficiently intelligent being - no matter how powerful or long-lived - would avoid pleasure-death.
Amen. I got mine back in 92, and remember everyone making fun of the kids who went with a TI because RPN scared them.
Now that I think of it, that was a good dropout predictor.
I still have mine and I love it.
What is not mentioned is that these low-carb and the low-fat diets were both done in the context of the typical, and rather terrible, Western diet. Since no distinction is made between simple and complex carbs, naturally 'low-carb' is going to win, since sugar is the worst offender for creating obesity.
I also have to roll my eyes because we already know what a healthful diet is. The most massive study of this kind in history came to a simple, unambiguous conclusion: eat a whole-foods, plant-based diet, and keep animal protein under 10% (even better, 5%) of your total calorie intake.
when I discovered that he doesn't bother to proofread or use a spell checker.
I don't care how long he's been doing it, sloppiness is a sign of a poor programmer.
I see only stock photos. If they had anything at all working they would have released either a video demonstration, or before-and-after pictures.
What they're attempting is non-trivial - I'm going to go out on a limb here and say that they're going to fail on the chemistry.
Consumers want number(s) to base their decisions upon. The wattage problem could have easily been solved by putting useful measurements of vacuum effectiveness on the packaging, such as guaranteed pressure drop and flow rate over the life of the product.
And the industry could do that all by itself without any regulation.