Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:Give up "popular music" != calcify. (Score 1) 361

Ah, and *now* I find this paragraph:

"Kalia himself indicates the study refers to popular music and not specific genres or time periods with the title of his analysis: “Music was better back then: When do we stop keeping up with popular music?” It’s not that you stop listening to new artists or even discovering new styles as you age, just that you won’t care as much who is taking home platinum records and leading the iTunes downloads race."

That's a long way from calcifying...

Comment Give up "popular music" != calcify. (Score 4, Insightful) 361

I'm in my late 30's (*sigh*) and my music tastes have only expanded. Thing is - they expanded into areas that still aren't the current "popular music." It's difficult to tell how that would be represented in this report.

Granted I'm likely an outlier of sorts but it's not clear that the methodology would consider me such.

Submission + - Australia Outlaws Warrant Canaries (schneier.com)

An anonymous reader writes: In the US, certain types of warrants can come with gag orders preventing the recipient from disclosing the existence of warrant to anyone else. A warrant canary is basically a legal hack of that prohibition. Instead of saying "I just received a warrant with a gag order," the potential recipient keeps repeating "I have not received any warrants." If the recipient stops saying that, the rest of us are supposed to assume that he has been served one.
Lots of organizations maintain them. Personally, I have never believed this trick would work. It relies on the fact that a prohibition against speaking doesn't prevent someone from not speaking. But courts generally aren't impressed by this sort of thing, and I can easily imagine a secret warrant that includes a prohibition against triggering the warrant canary. And for all I know, there are right now secret legal proceedings on this very issue.
Australia has sidestepped all of this by outlawing warrant canaries entirely:
        Section 182A of the new law says that a person commits an offense if he or she discloses or uses information about "the existence or non-existence of such a [journalist information] warrant." The penalty upon conviction is two years imprisonment.
Expect that sort of wording in future US surveillance bills, too.

Comment Re: Centralized on GitHub! LOL! (Score 1) 116

GitHub negates the decentralization of git in order to make it practical for real world use.

Negates? No - it just provides a single location through with to share code. You're confusing "using a central repository" with "requiring a central repository." It is just above trivial for any git project to switch to a new "central" server through with to share code.

Comment Re: Centralized on GitHub! LOL! (Score 2) 116

# git remote add newupstream git://new.server/my-project
# git push master newupstream

Aaaaand, done.

You're not going to do that with Subversion anytime soon. Sorry - I like SVN. But to claim that having a central repository is anything like *requiring* a central repository is just missing the point.

Comment Re:It depends (Score 1) 486

Which makes it very strange that they would think to write a paper on it. It's not even worth a blog post.

Not to mention that in the Java implementation they're writing to a BufferedWriter. So even with the StringBuilder they're comparing "concatenating a string, writing it to a buffer and writing that to disk" to "copying strings to a buffer then writing that to disk."

If you do more work it takes longer. QED.

Comment Re:It depends (Score 1) 486

In the Java application they're using a BufferedWriter as well - so they're buffering before the OS buffer.

It seems pretty clear to me that "concatenating a string then writing it to a buffer and flushing that to disk" would be faster than "writing a bunch of strings to a buffer then flush that to disk." They're basically copying that data around at least twice.

Comment Re:Anyone who believes Wikipedia (Score 1) 264

I disagree with your first statement but agree with the second. Most people believe what their friends and uncritical family members tell them and do zero verification with outside resources. Trusting Wikipedia, while risky, is a big step up from that. It's way over the top to say they're complete idiots for doing so. Otherwise everybody is a complete idiot for believing in anything they haven't themselves verified - and we can hardly expect such rampant skepticism to lead to a better society.

Comment Re:Unfair comparison (Score 5, Interesting) 447

though in some cases, reporting you feel better is the same as actually BEING better. Antidepressants, for instance.

This still isn't quite correct. For example: patients may want their doctors to feel as though a treatment is working and thus report an effect that isn't real ("yeah, sure - I feel better"). But the minute they walk out the door they feel just as crappy as when they entered. Other "effects" from placebo are simply bias in the study on the part of the researchers. Or the "observer" effect where people change simply because they're being watched. Placebo is a catch-all for any reported result that isn't explained by a real treatment.

Also - something quacks^Hhomeopaths never want you to know is that any reported effect *size* is minuscule from both homeopathy and placebo. So a small percentage of people reporting a tiny improvement? Your money is best spent elsewhere.

Comment Re:Unfair comparison (Score 5, Informative) 447

This represents a gross misunderstanding of the placebo effect.

Placebo has no physiological effect (like homeopathy). Often people taking placebo, homeopathy, etc. will *report* feeling better - but this does not mean they are better in any meaningful sense of the word.

More info here: http://www.csicop.org/si/show/...

It is very unethical to sell somebody a treatment which does not *treat* anything.

Slashdot Top Deals

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Working...