alecdbrooks

My impression is that ZFS makes the absence of ECC RAM more obvious. Discrepancies in RAM stand out when you're carefully hashing your file system.

If you're looking for a nice graphical way to play with data in Python, may I suggest IPython Notebook [0]? It's not always easy to configure, but it's maturing fast and lets you have Python code, Markdown, and graphs in one place, not to mention the 21 other languages available natively or as add-ons[1].

[0]: http://ipython.org/notebook.html.

[1]: https://github.com/ipython/ipython/wiki/IPython%20kernels%20... (I'm counting the two Perl kernels as one language and not counting Calico or the example kernel.)

In case some people skipped the bottom:

>Edits and corrections made after this date are marked inline, except for spelling errors spotted on Dec 30, 2012 and March 15, 2014, and an extra 'is' removed on April 1, 2013

That study is 8 months and 16 days younger than the last edit to the article.

>I'm guessing that this is wrong, though, and that the radioactivity from longer half-life radionuclides will eventually start to dominate and the "effective half-life" will be much longer.

Exactly. From a report on Chernobyl [0]: "Most of the decrease [in radiation] in the coming years will be at only the rate of the physical half-life of 137Cs." Cesium-137 has a half-life of 30 years [1], so if we use the number given in the article (10,000 roentgens/hour) the dose is apparently 434 million times background radiation, 23 microroentgens/hour [2]. It would take over a millennium to reduce Cesium-137 by a factor of 434 million[3]

That's the Elephant's Foot, though. Randall Munroe cites Chernobyl as having 6 millisieverts/hour on average[4]. That's 3000 times background radiation [2], or a 350-year wait before Chernobyl emits the same amount [5].

This is obviously a simplification, though. Plutonium isotopes were released too [0], which have a much longer half-life (thousands of years). It's possible those small amounts of plutonium will emit enough radiation to make Chernobyl have noticeably higher radiation levels than the background dose for much longer.

A final caveat: I'm not an expert or even a devoted amateur. Your question just sparked my curiosity. Although, this New York Times article [6] says scientists say it takes about 10-13 half lives for an area to recover, which is close to my 350 year figure.

[0]: https://www.oecd-nea.org/rp/chernobyl/c02.html. Search for 239Pu, not plutonium, to find the plutonium reference.

[1]: http://en.wikipedia.org/wiki/Caesium-137

[2]: http://en.wikipedia.org/wiki/Roentgen_%28unit%29#Significanc...

[3]: http://po.st/3ckuGC

[4]: https://xkcd.com/radiation/

[5]: http://po.st/T2qoni

[6]: http://www.nytimes.com/2011/03/20/weekinreview/20chernobyl.h...

Edit: Fixed math and added New York Times link. (Previously I based the Elephant's Foot calculations on 1,000 roentgens/hour.)

Non-paywalled links (incidentally, Google Scholar is very good about digging up free PDFs, often uploaded by the authors themselves):

>More than two decades ago, I conducted a study in which I presented women enrolled in a weight-reduction program with several short, open-ended scenarios about future events — and asked them to imagine how they would fare in each one.

Oettingen, G. (1991). Expectation, Fantasy, and Weight Loss: Is the Impact of Positive Thinking Always Positive?. Cognitive Therapy and Research, 15(2).

http://www.psych.nyu.edu/oettingen/OETTINGEN1991WEIGHT.PDF

>In a 2011 study published in the Journal of Experimental Social Psychology, we asked two groups of college students to write about what lay in store for the coming week.

Kappes, H. B., & Oettingen, G. (2011). Positive fantasies about idealized futures sap energy. Journal of Experimental Social Psychology, 47(4), 719-729.

http://eprints.lse.ac.uk/46284/1/__libfile_REPOSITORY_Conten...

>In a recent study on healthy eating and exercise. we divided participants into two groups.

Stadler, G., Oettingen, G., & Gollwitzer, P. M. (2010). Intervention effects of information and self-regulation on eating fruits and vegetables over two years. Health Psychology, 29(3), 274.

http://www.psych.nyu.edu/oettingen/Stadler,%20G.,%20Oettinge...

Stadler, G., Oettingen, G., & Gollwitzer, P. M. (2009). Physical activity in women: Effects of a self-regulation intervention. American Journal of Preventive Medicine, 36(1), 29-34.

http://www.psych.nyu.edu/oettingen/Stadler,%20G.,%20Oettinge...

I suspect he gave his standard advice about raises without considering the circumstances or that it wouldn't work equally well for men and women. That's not an excuse, but a reminder that sexism doesn't have to be deliberate to be sexism.

On the positive side, he did apologize without the typical spin or qualification.

>And when it comes to career advice on getting a raise when you think it’s deserved, Maria’s advice was the right advice. If you think you deserve a raise, you should just ask.

Sounds like an unambiguous repudiation of his previous answer to me.

EDIT: Just noticed geetee made the same comment. Didn't mean to steal it.

Stuck's pessimistic, but my experiences lead me to agree. I find it difficult to take the initiative with new people, so many of the people I know I met through a mutual friend.

I don't have a perfect solution, but I've found a few tricks. I've found that clubs and volunteer events tend to be full of friendly people who will introduce themselves. It also helps me socialize with new people when no one else knows each other.

It wasn't just the measure, it was that the experiment was randomized. Peer evaluations can be done for courses without follow ons and are more useful without randomization.

I agree that he should be more critical of his own recommendations. It's not clear that faculty would be free of the "gender, and ethnicity, and attractiveness" biases studies suggest students have -- I was hoping he'd have a clever way to blind evaluations.

Former YouTube developer Chris Zacharias has an informative story of the effect of reducing the page size from 1200 KB to 98:

>When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia... Large numbers of people who were previously unable to use YouTube before were suddenly able to.

Granted, that's a bigger leap than the one that made you cringe, but if it takes 2 minutes to load the new version in these areas (the number Zacharias gives), cutting 40 KB saves them 30 seconds.

The full article: http://blog.chriszacharias.com/page-weight-matters.

The last time this appeared on HN (https://news.ycombinator.com/item?id=5700562), I tracked down some of the citations:

>The social experience that most reliably predicted whether an HIV-positive gay man would die quickly, Cole found, was whether or not he was in the closet.

Cole, Steve W., et al. "Elevated physical health risk among gay men who conceal their homosexual identity." Health Psychology 15.4 (1996): 243. http://cancer-network.org/media/pdf/cancer_gay_men_disclosur...

>While Cole discovered that loneliness could hasten death in sick people, Cacioppo showed that it could make well people sick—and through the same method: by putting the body in fight-or-flight mode.

Cacioppo, John T., et al. "Loneliness and Health: Potential Mechanisms." Psychosomatic Medicine 64 (2002): 407-417. http://ccutrona.public.iastate.edu/psych592a/articles/Caciop...

>A longitudinal study of more than 8,000 identical Dutch twins found that, if one twin reported feeling lonely and unloved, the other twin would report the same thing 48 percent of the time.

Boomsma, Dorret I., et al. "Longitudinal genetic analysis for loneliness in Dutch twins." Twin Research and Human Genetics 10.2 (2007): 267-274. http://psychology.uchicago.edu/people/faculty/cacioppo/jtcre...

Finally, you may be interested in tokenadult's comment on twin studies: https://news.ycombinator.com/item?id=5701565. An excerpt:

>The article's explanation of "heritability" of human behavioral traits is poor. For four years now, I've had regular in-person interaction with a "journal club" of researchers and graduate students who are deeply involved in the Minnesota Twin Study...Your attribution of causes for human differences (e.g., human differences in IQ) is also heritable. Your opinion about regulation of the Internet is heritable. Everything about human behavior is heritable, including the tendency to loneliness mentioned in the interesting article submitted here.

I don't know what places the author's referring to, but according to one study, most fetuses diagnosed with Down Syndrome in Europe [0] and the United States [1] are aborted. The rate of live births has remained steady, but apparently it would be significantly higher if not for prenatal screening [2]. This discrepancy isn't very mysterious, nor is it really an absence, so maybe the GP has something else in mind?

[0]: https://www.ncbi.nlm.nih.gov/pubmed/10521836

[1]: https://www.ncbi.nlm.nih.gov/pubmed/22418958

[2]: http://onlinelibrary.wiley.com/doi/10.1002/pd.2702/full

Do you mean 802.11ac? Many new radios use 802.11ac[0], although maybe the rush is smaller than that for 802.11n. 802.11ad is a 60 Ghz protocol, a different frequency than 802.11n or ac use. It looks like 802.11ad would mostly be used as a sort of wireless USB or HDMI, [1] not networking, because it doesn't penetrate walls.

[0]: https://en.wikipedia.org/wiki/IEEE_802.11ac#Products

[1]: http://www.cnet.com/news/60ghz-tech-promises-wireless-dockin...

As a short-term stopgap, maybe create a "appreciation" field for maintenance to go up by a certain percent each year?

In any case, thanks for the calculator! I'll probably be using it alongside others to help me buy a car soon.

It resembles programming koans — you fork a repository and run tests to see if you succeeded:

>At the start of every chapter, you should go to Github and fork the chapters repository. There will be a link to the appropriate repository at the beginning of every chapter. You then clone your own fork of the repository and start working with the exercises when you encounter them among the material. You create commits and maybe push them in to your own fork while working. You also run the tests with lein midje to see if they pass.

Note that they mean the "chapter's" repository, not a "chapters repository" that contains everything.

Grading is done separately: a continuous integration tool runs your assignment and replies with your grade.

>When you want your answers graded, you push all of your work with git push. You then go to Github and send a pull request. At this point, Travis kicks in. It runs the tests for your code and then comments on the pull request whether the tests passed or failed. A link is also provided to see the nitty-gritty details.

Source: https://iloveponies.github.io/120-hour-epic-sax-marathon/bas....

It looks like Jawbone has a reasonable-looking API [1]. Alternatively, you can set up Beeminder [2] to collect the data (or for Fitbit) for free and then use Beeminder's API [3].

[1]: https://jawbone.com/up/developer [2]: https://www.beeminder.com [2]: https://www.beeminder.com/api

Releasing early and iterating works really well, but it's hardly the only way. Rich Hickey spent two and half years on Clojure before there was a public release[0]. Comment systems are much older today than social networks were in 2003, so I think it might make more sense to step back and plan rather than try a bunch of ideas.

[0]: https://en.wikipedia.org/wiki/Clojure#History

> The thinking is that of the 20 billion lines of code written each year, most of it repeats something that lots of programmers all over the globe have already done. MUSE will assemble a massive collection of chunks of code that can perform almost any task anybody could ever think of and tag all the code so it can automatically be found and assembled.

Excess hyperbole aside, this really is an interesting project. This seems like a logical extension of the existing practice of creating libraries, except that the effort of gluing code together would be automated.

That being said, it's hard not to point out the invariable difficulties:

* A large proportion of the 20 billion lines is probably fixing bugs or working around design decisions.

* Using pre-written code in a new context will unearth a few unaccounted-for edge cases

* Getting code from multiple languages to interoperate without human intervention would be a coup in and of itself.

I saw that. It's just that taking this line at face value, it's not clear why they would port TrueCrypt to Linux and Mac OS X or suggest that people using later versions of Windows should use TrueCrypt:

>The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.

Maybe EncFS [0]? Its Windows port is experimental, alas. I suppose it would be suitable if you were willing to make frequent backups.

[0]: https://en.wikipedia.org/wiki/EncFS

I'm with you. This seems like an odd move, given that most likely only a minority of their users used XP for some time. Why haven't they been warning Windows Vista, 7 and 8 users to use Bitlocker for years (not to mention Mac OS X and Linux users)? Perhaps I just missed the warnings, but I am really puzzled.

I suppose the developers could have just found a massive vulnerability (perhaps they're doing their own audit in advance of the public one?).

He's uploaded talks in this format before. Thoreau 2.0 [0] is a particularly good one.

[0]: https://static.pinboard.in/xoxo_talk_thoreau.htm

Video: https://www.youtube.com/watch?v=eky5uKILXtM

I think you're absolutely right on impact and self-promotion, but I don't think Wikipedia's brand is about quality. Or at least, not primarily about quality.

>Wikipedia won the reference race because of its quality.

Weren't convenience and quantity important factors and more important ones? To me the value of Wikipedia is that virtually any topic is discussed reasonably consistently with reasonable quality. If I specifically need quality, I'll look to the article's sources or find my own.

> People didn't build real applications in Hypercard.

Remarkably, they did! Wikipedia:

>A number of commercial software products were created in HyperCard, most notably the original version of the interactive game narrative Myst, the Voyager Company's Expanded Books, and multimedia CD-ROMs of Beethoven's Ninth Symphony CD-ROM, the Beatles' A Hard Day's Night, and the Voyager MacBeth.

It's true that Hypercard was not an ideal platform for development. Apparently, Myst developers had trouble making the high resolution images load quickly on machines of the time.

I've seen the same "oh, this is only for beginners" reaction to some of Victor's ideas on making data visible and making libraries "discoverable" that seems needlessly dismissive. That's why I mentioned him. Also, Light Table's initial concept was inspired by his work[0].

I'm not always impressed by Light Table, but I appreciate the work the team has put into the problem and think they have good ideas.

[0]: http://www.chris-granger.com/2012/04/12/light-table---a-new-...

I've been programming long enough that I know the magic incantations to get started in a few languages. But I am still in Anon's shoes any time I learn a new language or library. As the article says, "Even for experts, programming is an exploratory process." So, I'd say everything in this article applies to programmers, too.

Categorizing people into programmers and non-programmers neglects the people who need programming but not at an expert level. Some interns and students won't excel as programmers, but they still can bring programming into what they do instead, especially if efforts like Light Table succeed.

I suppose I shouldn't be surprised by this kind of pushback against reimagining programming — I've seen it as a response to some of Bret Victor's projects. Skepticism is great: Maybe the ideas behind Light Table are wrong or badly implemented. But we gain nothing from glib dismissals that seem to regard any attempt at improving or simplifying programming as beneath them.

The author of the article is aware of the article you linked to and wrote a response: http://lee-phillips.org/lispmath. The problem with the closed form is that once it exceeds the built-in data types, it no longer takes constant time to compute, so it's not actually always faster than doing it iteratively.

Apparently, the ideal method is "none of the above" but to use matrix exponentiation (or a formula derived from it) instead: http://nayuki.eigenstate.org/page/fast-fibonacci-algorithms.

Ankiapp appears to be something different. The web app Ankiapp links to below is not Anki's web app, and Ankiapp's site is copyright Admium Corp. instead of being attributed to Damien Elmes.

>A big annoyance is it's interaction with git. If you regenerate the output, git interprets that as a big file change, and the repository gets polluted with nonsense commits. There are workarounds, but none are perfect.

This is probably one of the workarounds you're thinking of, but I clear the output and use a precommit hook to make sure I haven't missed any cells. It's a bit annoying, but it works. I'm waiting for the day VCS integration is built-in. For now, I enjoy having my notes and code together and versioned.

Note that a number of these seem to be from people including Python itself within their project [0]. (Arguably, this could also be considered a mistake.) Python 2 defines the input() built-in, which is documented as:

>input([prompt]) -> value

>Equivalent to eval(raw_input(prompt)).

Github is turning up these results because that bit of Python is inside the C code as a string documenting the function.

Python 3 does not evaluate what's passed to input(), however. To get the same effect, use eval(input()). [1]

[0]: Limiting it to C examples https://github.com/search?l=c&q=%22eval%28raw_input%28%29%29...

[1]: https://docs.python.org/3.0/whatsnew/3.0.html#builtins