It's Time to End the War on Salt - <AUTHOR> http://www.scientificamerican.com/article.cfm?id=its-time-to-end-the-war-on-salt&WT.mc_id=SA_20110721 <comment><USER4> Here's a big copy paste from Harvards school of public health: www.hsph.harvard.edu/nutritionsource/salt/jama-sodium-study-flawed/index.html

A new study would have you believe that low-salt diets raise your risk of dying from heart disease—a surprising finding, and one that's sure to grab headlines worldwide. The only problem is that the study's conclusions are most certainly wrong.

In the study, published in the May 4, 2011, issue of the Journal of the American Medical Association (JAMA), European researchers followed 3,681 men and women for an average of about eight years. (1) They report that people with the lowest levels of sodium in their urine (a marker of salt intake) at the start of the study had a 56 percent higher risk of dying from cardiovascular disease than people with the highest levels. Equally unexpectedly, among the 2,096 participants who had normal blood pressure at the start of the study, urinary sodium appeared to have no effect on the development of high blood pressure over six and a half years.

Based on these findings, the study authors call into question recent estimates (2, 3) of the tens of thousands of heart attacks, strokes, and cardiac deaths that could be averted each year—and the billions of healthcare dollars that could be saved—by curbing Americans' excessive salt intakes. Yet the study has several weaknesses, chief among them its modest size: With less than 4,000 participants—and only 84 deaths due to cardiovascular disease—the study is too small to support the authors' sweeping conclusions.

Read about why cutting back on salt and sodium is a key to good health

Read about key studies that show the harmful effects of sodium on the heart

Furthermore, the study's findings are inconsistent with a multitude of other studies conducted over the past 25 years that show a clear and direct relationship between high salt intakes and high blood pressure, and in turn, cardiovascular disease risk. (4–10)

"Take this study with a huge grain of salt, and then dispose of it properly," says Dr. Walter Willett, chair of the Dept. of Nutrition at Harvard School of Public Health. "This study should not influence recommendations about sodium intake in any way.

Key problems that undermine the study's conclusions include the following:

Unreliable measurement of sodium intake: The study investigators base their main findings on a single measurement of sodium collected at the start of the study specifically the amount of sodium that study participants excreted in their urine over a 24 hour period. Yet sodium excretion from just one day does not reflect people's salt intake patterns over long periods of time. It's weak science to use one-day sodium excretion to predict heart disease or mortality decades later. Failure to account for key factors that influence sodium intake and heart disease risk: People who are taller (11) or more active (12) tend to have a lower risk of heart disease. They also tend to have higher sodium intakes, simply because they eat more food. Yet the JAMA study authors don't account for differences in height, physical activity, and total calories. (13) This oversight could make it appear as though high sodium intakes protect against heart disease deaths, when in fact physical activity or height is responsible for the lowered risk. Other weaknesses: There are other problems with the way that the investigators conducted the study, among them, missing or incomplete data from large numbers of participants. The study investigators, for example, could have accounted for incomplete urine samples by analyzing urinary sodium in relation to creatinine (another compound found in urine), but they did not.

The bottom line is that the researchers were trying to ask questions that their data are incapable of answering, and the study's many methodological problems make its results unreliable. So the study's findings do little to refute the strong evidence that cutting back on sodium would save lives.

Americans, on average, consume about 3,400 milligrams of sodium per day. Current U.S. recommendations call for a maximum of 2,300 milligrams of sodium a day (the amount found in a teaspoon of salt), and 1,500 milligrams of sodium (two-thirds of a teaspoon) for people who have high blood pressure or are at high risk of developing it. The latter group includes people who are over the age of 40, are African American, or have somewhat elevated blood pressure (prehypertension)—a group that includes almost 70 percent of adults in the United States. (14) A dash of prevention is worth a pound of cure: Since 90 percent of Americans will develop high blood pressure at some point in their lives, (15) it really makes sense for all of us to curb our sodium intake.

Read more about how to preserve flavor and cut back on salt

Try these delicious low salt recipes from the Culinary Institute of America

Seventy-five percent of Americans' sodium intake comes from processed foods. (16) That's why the Institute of Medicine has called on the U.S. Food and Drug Administration to regulate the amount of salt and sodium allowed in processed foods. (10) References

1\. Stolarz-Skrzypek K, Kuznetsova T, Thijs L, et al. Fatal and Nonfatal Outcomes, Incidence of Hypertension, and Blood Pressure Changes in Relation to Urinary Sodium Excretion. JAMA. 2011; 305:1777–85.

2\. Palar K, Sturm R. Potential societal savings from reduced sodium consumption in the U.S. adult population. Am J Health PromotOpens in New Window. 2009; 24:49–57.

3\. Bibbins-Domingo K, Chertow GM, Coxson PG, et al. Projected effect of dietary salt reductions on future cardiovascular disease. N Engl J MedOpens in New Window. 2010; 362:590–9.

4\. Strazzullo P, D'Elia L, Kandala NB, Cappuccio FP. Salt intake, stroke, and cardiovascular disease: meta-analysis of prospective studies. BMJOpens in New Window. 2009; 339:b4567.

5\. Intersalt: an international study of electrolyte excretion and blood pressure. Results for 24 hour urinary sodium and potassium excretion. Intersalt Cooperative Research Group. BMJOpens in New Window. 1988; 297:319–28.

6\. Cook NR, Cutler JA, Obarzanek E, et al. Long term effects of dietary sodium reduction on cardiovascular disease outcomes: observational follow-up of the trials of hypertension prevention (TOHP). BMJOpens in New Window. 2007; 334:885-8.

7\. Cook NR, Obarzanek E, Cutler JA, et al. Joint effects of sodium and potassium intake on subsequent cardiovascular disease: the Trials of Hypertension Prevention follow-up study. Arch Intern MedOpens in New Window. 2009; 169:32–40.

8\. Appel LJ, Moore TJ, Obarzanek E, et al. A clinical trial of the effects of dietary patterns on blood pressure. DASH Collaborative Research Group. N Engl J MedOpens in New Window. 1997; 336:1117–24.

9\. Sacks FM, Svetkey LP, Vollmer WM, et al. Effects on blood pressure of reduced dietary sodium and the Dietary Approaches to Stop Hypertension (DASH) diet. DASH-Sodium Collaborative Research Group. N Engl J MedOpens in New Window. 2001; 344:3–10.

10\. Institute of Medicine. Strategies to Reduce Sodium Intake in the United StatesOpens in New Window. Washington D.C.: National Academies Press. 2010. Accessed May 3, 2011.

11\. Ferrie JE, Langenberg C, Shipley MJ, Marmot MG. Birth weight, components of height and coronary heart disease: evidence from the Whitehall II study. Int J EpidemiolOpens in New Window. 2006; 35:1532–42.

12\. U.S. Dept. of Health and Human Services. 2008 Physical Activity Guidelines for AmericansOpens in New Window. 2008. Accessed May 3, 2010.

13\. Willett W, Stampfer M. Implications of Total Energy Intake for Epidemiologic Analysis. in Willett W, Nutritional Epidemiology. New York: Oxford University Press, 1998: 273–301.

14\. Application of lower sodium intake recommendations to adults—United States, 1999-2006. MMWR Morb Mortal Wkly RepOpens in New Window. 2009; 58:281–3.

15\. Vasan RS, Beiser A, Seshadri S, et al. Residual lifetime risk for developing hypertension in middle-aged women and men: The Framingham Heart Study. JAMAOpens in New Window. 2002; 287:1003–10.

16\. Brown IJ, Tzoulaki I, Candeias V, Elliott P. Salt intakes around the world: implications for public health. Int J EpidemiolOpens in New Window. 2009; 38:791–813.

<comment><USER5> Um, _why_ the giant copy & paste?

What would have been wrong with a clickable link ([http://www.hsph.harvard.edu/nutritionsource/salt/jama- sodium...](http://www.hsph.harvard.edu/nutritionsource/salt/jama-sodium-study- flawed/index.html)) and small salient excerpt?

Also, this Harvard article is strictly raising concerns about a May 2011 JAMA paper. The Scientific American 'End the War on Salt' article also relies on a "meta-analysis of seven studies" published in July, and talks of another 11-trial review of the effects of sodium-intake-reduction in 2004.

<comment><USER6> The SciAm article makes it sound like there is literally _no_ scientific support in "the war against salt." This article pretty clearly claims exactly the opposite, so it makes a good counterpoint even if it was published before the most recent study.

> _Um, why the giant copy & paste?_

When I click on that link, a registration thingy pops up. You can dismiss it, but OP might have thought registration was required.

</comment></comment></comment><comment><USER7> While the causes of too much salt are debated, I see fairly regularly the effects to _too little_ salt.

In a hot climate (Southeastern U.S.), I'm often outdoors with sports teams or youth groups, and I see the effects of heat-related conditions regularly. These are prevented and treated with water and salt (electrolytes). [1] [2]

So yeah, too much salt may be a problem. Maybe not. But too little certainly is, and it's common in the active youth I observe.

1: <http://en.wikipedia.org/wiki/Hyperthermia> 2: <http://en.wikipedia.org/wiki/Electrolyte>

<comment><USER8> Couple things here, and I say this with the utmost respect. Your anecdote is not "data", and even if it were, you've failed to prove any sort of causality of "too little salt". Salt is but one of many possible electrolytes, and and "heat related conditions" are not necessarily solved with salt; chances are dehydration clear and simple could also be the cause of the effects you're seeing.

<comment><USER9> Hyponaetremia is well-documented, and I'm sure someone who has spent a summer supervising children in the heat can tell the difference between hyponaetremia and dehydration. With utmost respect, you sound like you haven't had first aid training and you don't spend much time outdoors in hot weather.

<comment><USER7> Thanks for the support. I think GP is right to be cautious (and data is not necessarily equivalent to multiple anecdotes over more than a decade). However, I would assert that my experiences are not unique.

You are correct that the symptoms are different [1][2], and that first aid training (in my case, Red Cross) acknowledges the necessity of both fluids and electrolytes.

More broadly, the term "[D]ehydration, despite the name, does not simply mean loss of water, as water and solutes (mainly sodium) are usually lost in roughly equal quantities" [3], meaning that even if water is replenished, salt intake must also be increased.

It's been my experience (and we're back to anecdote, unsupported by my first aid training) that dehydration may occur quickly (especially in hot weather), but insufficient electrolytes occurs over a period of days of insufficient replenishment (e.g., training, sports tournaments, resident camps).

1: <http://www.ncbi.nlm.nih.gov/pubmedhealth/PMH0001431/> 2: <http://www.ncbi.nlm.nih.gov/pubmedhealth/PMH0001977/> 3: <http://en.wikipedia.org/wiki/Dehydration>

</comment></comment></comment></comment><comment><USER10> Two things.

1\. It's possible that we've reversed the causal association for all these years. You don't always get expansion of the extracellular fluid space with chronic kidney disease due to hypertension; with some tubulointerstitial diseases, you develop salt-wasting nephropathies. Perhaps these were the hypertensive patients who were referenced in the article, voraciously eating salt due to a deficiency caused by their kidney disease? I'd like to see more data before being willing to overturn dogma, but it's not the most outlandish idea I've heard all day. Still, the authors' conclusions are most likely wrong.

2\. There's a group at MGH doing a randomized clinical trial in which they are administering intravenous salt and measuring near-term blood pressure response. It's a one-off exposure, but it will be interesting to better nail down the relationship between serum sodium content and blood pressure via experiment rather than epidemiology.

<comment><USER11> _It's possible that we've reversed the causal association for all these years._

Another possibility: Cortisol. People under chronic stress produce more cortisol, and high cortisol levels act to inhibit urinary sodium loss. Maybe the people having heart attacks aren't _eating_ more sodium; they're just retaining it better as a side effect of the stress which is killing them.

<comment><USER12> Stress, cortisol, and let's not forget sleep deprivation -- also typically associated with the same lifestyle, also highly deleterious to health, and also correlated with heart disease.

<comment><USER11> Right, my point was that cortisol is the link between "lifestyle which results in early death" and elevated serum sodium.

<comment><USER12> Understood your point; was just adding to it. Sorry for the confusion.

</comment></comment></comment></comment></comment><comment><USER13> > _But if the U.S. does conquer salt, what will we gain? Bland french fries, > for sure. But a healthy nation? Not necessarily._

 _This week a meta-analysis of seven studies involving a total of 6,250 subjects in the American Journal of Hypertension found no strong evidence that cutting salt intake reduces the risk for heart attacks, strokes or death in people with normal or high blood pressure."_

The article goes out of its way to dismiss the other impact of "French Fries" on health, obesity, and the role which salt plays in making manufactured food with low nutritional value habit forming.

[http://www.sciencedaily.com/releases/2006/11/061101151027.ht...](http://www.sciencedaily.com/releases/2006/11/061101151027.htm)

<comment><USER14> Which seems to be mainly down to drinking more non-water liquids.

So... maybe the effort expended in reducing salt intake should instead be spent on increasing water as a beverage choice?

<comment><USER13> Seems to me, that if people would readily forgo consuming flavored food products in lieu of something with little taste, a correlation between salt and obesity might be less likely to begin with. In other words, one could promote carrots in lieu of French Fries and expect similar results.

</comment></comment></comment><comment><USER15> The entire process of diagnosing people with hypertension needs a shake up. Managing blood pressure is such an important part of the human condition but the evidence as to what works and what doesnt can be confusing. Weight loss and stopping smoking works, but for exercise, cutting alchohol and cutting salt there are many conflicting reports.

Add in the fact that genetics plays such an important part, and the prevelence of White Coat Syndrome it's a shame that the medical world cannot make its mind up.

<comment><USER16> The confusion around hypertension is really annoying. I have a bit of white coat hypertension, and my BP is usually around 145/80 when measured by a medical professional, but is still around 132/80 when measured automatically. Getting it down to 120/80, or lower (where everyone else who I know in my age group is, and which _seems_ to be the safest in the long term) is stubbornly impossible, despite exercise and a healthy diet. A 24 hour workup by a doctor seemed to point to stress-induced hypertension, but I was told that there's no need to treat it.

Is hypertension brought on by being stressed/awake less harmful than "intrinsic" hypertension? That seems to be the opinion by my physician. But it's maddening that these issues remain unresolved.

<comment><USER17> What exactly do you eat / drink on an average day?

<comment><USER16> I usually have a cup of tea for breakfast and grilled cheese + tomato sandwitch for lunch. Dinner is either poached fish, grilled or curried chicken, steak or lambchops, and often features french fries or rice. Popcorn for a late snack. No alcohol. I avoid coffee, but have 2-3 packets of potato chips and the equivalent of 2 glasses of Coke a day (I think I'm hypersensitive to caffeine, and any caffeine after 4PM screws with my sleeping patterns). 2-3 eggs on weekends.

At one stage I had salad for lunch for about a year, and tried to eat vegetables 5 days a week, but it didn't seem to influence my BP.

I exercise a lot less than I used to, but when I exercised 4 times a week, I'd regularly check my BP before starting, and, if anything, it was higher than it is now. But I am trying to psych myself up for exercise for other reasons - <USER2> need to offset the general malaise that comes from being behind a desk the whole day.

<comment><USER18> While I don't know what such a diet means for hypertension, it sounds pretty poor in terms of nutritional value. You might have less malaise if you ate more fruits and vegetables, and weren't sending your blood sugar on a roller coaster with those two glasses of coke. Two cans of coke supplies over a quarter of the recommended daily carbohydrate intake!

Try eating nuts or seeds as a snack. The protein will help balance your energy levels and the fat will keep you satiated. Look at granola instead of potato chips -- not the top brand ones bars that are just sugar delivery mechanisms, though.

And really, you should eat breakfast! The first meal of the day has a lot of important effects. <http://www.webmd.com/diet/guide/most-important-meal>

<comment><USER19> I sleep ~6 hours per night, drink 6+ cups of coffee and 1-2 cups of tea per day, and only rigorously exercise for 25 minutes 2-3 times per month. My daily diet consists of 600+ calories from extra-virgin cold-pressed coconut oil and butter, 2-4 eggs a day, a handful of cherry tomatoes, 1000+ calories from beef/poultry/pork/fish, 400+ cals from hard cheeses (like swiss), a 1/2 pound - 1 pound of vegetables, maybe a handful of mixed nuts, and a whole lot of kitchen spices (including salt!).

I also try to take 5 - 10 minutes a day to do focused breathing/relaxation (i.e. meditation w/o the hocus-pocus).

With the above lifestyle, I have a resting pulse rate of 54, a bp of 122/70, and I have been losing 2-8 lbs a month for the past 18 months while maintaining strength, endurance, and muscle mass levels. Moreover, I feel wonderful!

I turn 30 at the end of the year, so my good results aren't because I am some youthful, exuberant teenager. I actually attribute them to my diet and lifestyle.

<comment><USER20> Traditional 'healthy' diet (low fat, low salt, high on carbs and grains) is very bad for health.

Your diet seems to be mostly keto (I assume your coffee and tea are sugarless). The diet of ern is very far from keto.

There are two very active community of redditors (keto and Paleo) with very good info on diets and foods that work to have good health, and bibliographies with explanations of why it works.

<comment><USER19> I like to think of my diet as "early-Neolithic". I am from one of the populations groups with adult lactose tolerance. So, I modeled it on the foods that might be available to what used to be called a "gentleman farmer".

I also recognize that scientific research has made real progress on determining what to eat in the past few years; so, I've also tried to incorporate some of those findings as well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> For reference, and for those who may not have already read it:

"The (Political) Science of Salt", Gary Taubes. Science. 1998. 281: 5379; 898-907

[http://web.archive.org/web/20060923051143/http://www.nasw.or...](http://web.archive.org/web/20060923051143/http://www.nasw.org/awards/1999/99Taubesarticle1.htm)

<comment><USER22> Here's a link to this paper that's a single page and doesn't require going through archive.org:

[http://storyarchive.tumblr.com/post/9437438977/the- political...](http://storyarchive.tumblr.com/post/9437438977/the-political- science-of-salt-gary-taubes-science)

</comment></comment><comment><USER23> While tangentially related, I am compelled to deliver a pointer to Alton Brown's special on the mysterious mineral which is salt, Eat-This-Rock.

[http://www.foodnetwork.com/good-eats/good-eats-eat-this- rock...](http://www.foodnetwork.com/good-eats/good-eats-eat-this- rock/index.html)

Or for the brave: <http://www.youtube.com/watch?v=0f62XQPBlTE>

</comment><comment><USER24> Interesting bit:

>>In May European researchers publishing in the Journal of the American Medical Association reported that the less sodium that study subjects excreted in their urine—an excellent measure of prior consumption—the greater their risk was of dying from heart disease. These findings call into question the common wisdom that excess salt is bad for you <<

If I'm reading this correctly it is saying that people that urinate less sodium have higher chances of dying from heart disease. Then the author uses this as evidence that less sodium actually increase your chances of dying from heart disease.

If so then I would hypothesize that less sodium could simply mean that the body is no longer able to expunge it from the body and hence that is what is causing the heart disease.

<comment><USER25> _"less sodium [output] could simply mean that the body is no longer able to expunge it from the body"_

 _"the less sodium that study subjects excreted in their urine - an excellent measure of prior consumption"_

These two statements seem mutually exclusive. If the amount of sodium a subject excretes is an excellent measure of prior consumption (ie, more out is demonstrably linked with more in, and less out = less in), then your hypothesis (less out may mean more retained, and therefore output can't be linked to input) cannot be true.

Of course, it could also be the "excellent measure" which is incorrect - <USER3> point is simply that these two are contradictory.

<comment><USER24> >>my point is simply that these two are contradictory

My hypothesis assumes that the following statement is false on sick individuals.

>>"the less sodium that study subjects excreted in their urine - an excellent measure of prior consumption

Hence there would be no contradiction.

<comment><USER25> You're assuming that statement is false in specific cases; the OP assumes it is true in all cases - that sounds like a contradiction to me.

</comment></comment></comment></comment><comment><USER26> IMO, one of the most overlooked variables in the great salt debate is potassium deficiency:

'The 2004 guidelines of the Institute of Medicine specify an RDA of 4700 mg of potassium for adults,[2] based on intake levels that have been found to lower blood pressure, reduce salt sensitivity, and minimize the risk of kidney stones. However, most Americans consume only half that amount per day.'

Personally, I think we have a potassium, weight, and pre-diabetic problem, not a salt problem.

</comment><comment><USER27> Not much more to say after Tim Harford…

MoreOrLess: Is salt bad for you? 19 Aug 2011

[http://itunes.apple.com/gb/podcast/more-or-less-behind- the-s...](http://itunes.apple.com/gb/podcast/more-or-less-behind-the- stats/id267300884#)

Starts at about 00:45 up to 16:07.

</comment><comment><USER28> Anecdotal, I know, but in my experience my blood pressure is directly correlated with alcohol consumption. I used to be a consumer of 2-3 beers daily. At this time, I was also running approximately 15 miles per week, and working out at the gym. I was about 20 lbs heavier and had borderline high blood pressure. One day I cut out the beer intake, pretty much completely. The 20 lbs have fallen off, blood pressure is normal to below, and I cut back my running to 3-5 miles per week. I crave salt and eat plenty of it with an otherwise healthyish diet(that didnt change)

</comment><comment><USER29> I understand their position up until the point of The NEJM Feb 2010 study, where they are dismissive of it as "conjecture". Granted it's a computer simulated model but they are using valid data from the National Health and Nutrition Examination Survey and the Framingham Heart Study.

</comment><comment><USER30> Do they still treat hypotension by increasing a patients dietary salt intake?

</comment><comment><USER31> Once again, yet another diet-related study which reinforces the old maxim of _everything in moderation_ (including moderation, of course :-)).

</comment><comment><USER32> I wish this article was programming related somehow.

<comment><USER33> A lot of us partake in the coffee and/or diet soda while programming. This jacks with our BP and invariably the subject of sodium comes up.

</comment></comment><comment><USER34> And it's about time. :)

</comment><comment><USER35> a) War on ______ tends to be a sensationalist phrase that causes me to flip the bozo bit.

b) This article doesn't have anything whatsoever to do with tech or startups.

<comment><USER36> For (b), a lot of articles submitted here have nothing to do with tech or startups. That doesn't mean we wouldn't be interested in reading them. I think the HN community tends to know what the HN community wants to read more often than not.

<comment><USER37> Technology, startups, business, and workaholics' diseases. I also think they fit fairly well together.</comment></comment></comment>


Ask YC: What's on your "Holy Shit" list? - <AUTHOR> http://www.randsinrepose.com/archives/2002/07/05/your_holy_shit_list.html <comment><USER3> It's funny, most of the ones people list, I didn't find all that exciting when they came out:

* The WWW: "It's so disorganized. I prefer gopher."

* Google: "Well, it gives good results, but Yahoo is 'good enough' for me

* RSS: "Who reads that many blogs?" (I still believe this, BTW; RSS is a technocrats' technology)

* Doom: "Why would I want to play a game where the sole purpose is to blow shit up?"

Things that really were on my "holy shit" list:

* Modems. "I can login to computers halfway across the world."

* VMWare/VirtualPC/SoftPC. "You mean it's like a computer, running inside a computer?"

* Napster. "Wow, free music."

* Gnutella. "Woah, no server, anywhere."

* Processing. "Those are awfully pretty pictures you just whipped up in the last 6 hours."

* GMail. "A gig of storage space. And it's searchable. And it has keyboard shortcuts. And it's got this conversation view. Where's my invite code?"

* Fanfiction. "Wow, hundreds of thousands of people trying their hand at writing stories."

* OLPC. "This'll open up a market of literally half the planet."

* Functional programming. "I'll never make a state error again."

<comment><USER4> You didn't have to want to play the game to be startled by Doom. I may be biased, because I was also startled by Wolfenstein (I was in high school when it came out, though).

Fanfic though? Really? Fanfic?

<comment><USER5> I think you underestimate the power of James T. Kirk in a fursuit.

<comment><USER6> or in drag :O

<comment><USER6> Here I thought this was genuinely humorous

</comment></comment></comment></comment></comment><comment><USER7> Unix pipes, cron, ssh, VNC and IRC.

Oh, and CPAN.

A Slashdotter once posted an insightful comment about cron being the 'height of computing': [http://linux.slashdot.org/comments.pl?sid=323287&cid=209...](http://linux.slashdot.org/comments.pl?sid=323287&cid=20922121)

Easy to take cron for granted these days, but I have to say I agree.

As for unix pipes, I once explained how one of my shell scripts worked to a longtime Windows programmer and he literally said, "Holy shit!" when the pipes concept clicked.

</comment><comment><USER8> When I discovered that Playboy and Penthouse was _FREE_ in early web days (around 1995 I think)

</comment><comment><USER9> VMWare was on my "holy shit" list when I saw how well they did virtualization

</comment><comment><USER10> When I discovered I could talk to people on IRC on the other side of the world, sometime in 1993, that was a holy shit moment.

Linux was pretty incredible too: I realized that with open source, the only thing limiting me was my own ability to hack it, which is a really great feeling.

</comment><comment><USER11> Rails.

"Holy shit, I can build the same stuff that I used to build, except it will take me less time than PHP and be more stable, clean, and maintainable than Java. How the hell did I live without has_many :through before???"

<comment><USER12> Although Django is my preferred Framework of choice, the first moment I heard about all those MVC Frameworks and what they do was definately a "HOLY SHIT"-moment.

<comment><USER13> I'd heard about them for a while before actually getting in there and using them. The first time I setup the django admin site was definately a "HOLY SHIT" moment...

Others: * Google Sketchup (This was only last week --> It's so simple!) * VM Snapshots * ITunes library/playlist structure (Don't laugh... The unified library showing every song was a revelation after mucking around with winamp playlists and folders.. Also - I remember winamp really sucking on the mac at the time) * HTML - "You mean I can publish stuff on the Internet and people can read it from across the world?" (I was about 11 at the time ('95))

</comment></comment></comment><comment><USER14> Apparently this list will date me. It's in approximate chronological order.

\- Atari - At a friends house! Stunning.

\- Commodore 64 - LOAD "*",8,1

\- 600 baud modem - CONNECT 2400 - BBSes and text based games!

\- email / fidonet - A huge change to the BBS scene.

\- telnet - Users could connect anywhere without long distance.

\- Mosaic

\- Doom ][ - IPX online play or modem-modem 2 person play.

\- Hubble Space Telescope - After it was fixed!

\- Lisp & Scheme - Atleast my understanding of it was huge.

\- Godel's incompleteness theorems - Understand and you'll never look at math the same way.

\- Wii - Finally a successful iteration of this user interface great idea.

<comment><USER15> LOAD "*",8,1

A buck to anybody who can remember what the parameters meant

<comment><USER14> From memory:

* -> last program you ran

8 -> the floppy disk. I vaguely remember using different devices with different numbers.

1 -> it's compiled - not BASIC.

After a quick Wikipedia stint I found a better definition:

 _In the following example, where '_ * _' designates the last program loaded, or the first program on the disk, '8' is the disk drive device number, and the '1' signifies that the file is to be loaded not to the standard memory address, but to the address where its program header tells it to go—the address it was saved from. This usually signifies a machine language program, as opposed to a BASIC program._

      LOAD "*",8,1

<http://en.wikipedia.org/wiki/Commodore_64_peripherals>

<comment><USER15> Great wiki link! What a walk down memory lane.

The dollar is yours, email if you want it.

</comment></comment></comment></comment><comment><USER16> Mosaic. Since the first day I saw it, I haven't gone as much as a week without writing a computer program.

</comment><comment><USER17> I am so NOT an Apple fanboy, but I gotta say "iPhone". Everytime I pick up any Smartphone, I'm reminded what a game-changer it is.

Add a keyboard and stop the crashes, and it's perfect. ;-)

TiVO is up there for me too.

</comment><comment><USER18> Quake 2 was pretty tits when I first saw it. Half-Life too.

Sub7 was definitely a holy shit moment for me in the late 90's.

</comment><comment><USER19> Betting exchanges.

"You mean I can bet on sporting events, and the people providing the infrastructure are don't mind me winning (because they get paid commission anyway)? And the commission is on my net winnings per market, so the transaction costs don't depend on how many bets I make? And I can name my own bid and offer prices, like on a stock exchange? And I can automatically place hundreds of bets per hour through a well-defined (and free) API? And all my winnings are tax free (under UK tax law)? Cool.

</comment><comment><USER20> Bright flash of light outside and a Nuclear Mushroom blowing up just behind the horizon.

</comment><comment><USER21> VMware snapshots. Before multiple snapshots, I didn't get the value of VMware.

AWS S3

AWS EC2

Yahoo Music subscription service, back when it 1) existed and 2) ran on an OS I had (W2k).

Moose

xmavisx on wretch.cc

</comment><comment><USER22> The X-Prize, because of the economic model.

<comment><USER23> That they funded the prize with an insurance policy was pure genius.

<comment><USER24> How did they do this? I cant find any such reference here, <http://en.wikipedia.org/wiki/Ansari_X_Prize>

<comment><USER25> Peter Diamandis talks about it in this Stanford talk (edcorner.stanford.edu/authorMaterialInfo.html?mid=2002 ) (not loading right now). Basically, he paid $1m (I think) for a $10m insurance policy. He almost lost it because he couldn't make the payments. The Ansari family stepped in and paid the rest of the policy premium so he named it after them.

</comment></comment></comment></comment><comment><USER26> I very rarely get a "Holy Shit" feeling. I get "Oh, that's clever" or "that's neat" quite a lot though. I think perhaps the fact I'm young so take things for granted and the fact nowadays I see everything as it appears on the internet makes everything seem more like a progression rather than shocking.

I do remember visiting Google Suggest and later Google Maps and being very impressed and knowing it would change the web - until that point JavaScript has largely been seen as a toy. Gmail also really changed the landscape when it came out too.

The first time I used Opera's tabs in 2000 wasn't "holy shit" as much as a "well, that makes perfect sense" moment which are even rarer.

</comment><comment><USER27> Nobody thinks iPhone? I only used them at experience stores, but when I first did I felt stricken by lightning. I think, holy shit, this will be the first un-Japanese interface phone to become a hit in Japan.

</comment><comment><USER28> In reverse chronological order:

* Looking at 200,000 x 200,000 pixel images of cortex, where each pixel samples 3.75 nm square (you see the wires and the solder)

* Sparsely expressing green fluorescent protein in pyramidal neurons of the hippocampus in a compound microscope

* Drosophila larva wriggling around under epifluorescent illumination, expressing green fluorescent protein in all its neurons

* Dictyostelium aggregation

* When, teaching myself how to program in Pascal on my Dad's Fat Mac, I wrote a program that drew circles of increasing radius centered on the mouse

* Thinking about how all we are is particles

* Looking at redwood trees for the first time, in person

</comment><comment><USER29> * git * jQuery * Python's decorators

</comment><comment><USER30> Wikipedia - when I first saw the potential for the ability to share and edit knowledge freely in what felt like a limitless way (that is gone now because of the deletionists)

HD TV - the first time you get to fully see actors with all their flaws gave me one of those moments, and you realise they don't look as good as they used too.

Adsense/Adwords - basically just a license for Google to print money really...

Virgin Galactic - wow.

Water on Mars - Double wow.

The LHC

EDIT - hmm, article is from 2002...

<comment><USER4> It's funny --- I am so the exact opposite on HDTV: I have one, I've seen my friends HD pictures, and I've walked past the top of the line with the demo pictures in the store, and I do not get it. Is it possible that I was born without the part of my brain that is supposed to appreciate HD? If so, I feel lucky.

<comment><USER31> That's how I am, and I feel lucky too. I can watch things that are so low quality other people can't even tell what's going on, and I see no difference

<comment><USER4> It's the same with music, right? 128 AAC sounds fine to me. The CD carriage and solid gold speaker cable set looks at me with pity. I just laugh. Suckers.

I knew someone during the bubble who lived in Manhattan, right when Kozmo and Urbanfetch arrived. He found gift certificate hacks in both --- you could order things on Mastercard web certificates (0-balance valid Mastercard numbers) and get issued a $5 _transferable_ gift certificate before the original purchase cleared. He had scripts that would literally generate money for their sites. The Kozmo and Urbanfetch delivery guys would meet every day in the hallway in his apartment, and apparently became friends.

Anyhow, one of the things he did with them was have a limitless supply of Godiva chocolates delivered for him and his girlfriend.

Eventually, the hack stopped working.

Shortly afterwards, his girlfriend bought a package of Hershey's Kisses.

"Bleh! Inedible!" He'd always liked them before, but had trained himself to hate them by eating nothing but high-end stuff.

Chocolate, sound quality, picture quality --- and absolutely, positively, cars --- all suffer from the Godiva "Paradox". It's better to satisfice than optimize.

This is also one of the key observations in The Innovator's Dilemma. Hulu is a bigger disruptor than HDTV is. I'll happily accept crappy picture quality if I can watch anything I want, whenever I want.

<comment><USER32> > [...] He'd always liked them before, but had trained himself to hate them by > eating nothing but high-end stuff.

He did not train himself to hate the low-quality product, he came to understand the difference between a high-quality product and a low-quality product. The same effect could have been discovered by tasting the two side- by-side. In a similar fashion, if you were to put an HDTV and a standard TV side by side in your living room for a while you would find yourself not watching the standard TV after a while.

Exposure to a superior product does that to you...

<comment><USER4> So, I see the logic of what you're saying, but the simple fact was, he was happy with the low-quality product. Very happy. They were Hershey's Kisses! But after 6 months of nothing but Godiva, he couldn't enjoy them anymore. Presumably, he now has to pay a Godiva premium to get the same level of happiness out his chocolate purchases.

<comment><USER33> I recommend See's. They are cheaper than Godiva, but just as good. Consumer Reports did taste tests that corroborate this a few years back. In regards to the freshness of certain ingredients, like nuts, they rated them superior. Godiva charges a premium and puts some of that into fancy boxes and marketing.

I used to be quite happy programming in C. Now, I find I am quite spoiled by the absolute dynamic power, full closures, magical seeming debugger, and everything is an Object environment I have in Smalltalk. I get paid more, but I also "pay" a premium in terms of fewer choices in places of employment.

Maybe there is some wisdom in choosing just not to know. But there is something in me that just wants to know no matter what. Even if I would've been happier otherwise.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> * Blogs: The fact that anyone could and would keep a journal online for the world to see was so exhibitionist that I could barely comprehend it. * Rails: Making web development so easy it hurts. * Valve Software's 'Steam': Digital distribution done right. * Microsoft Photosynth: Pure coolness. This is what the future should be like.

</comment><comment><USER4> Doom. Large MP3 libraries. Ricochet. ISDN. Image Analogies. Software radio. Kozmo (bonus points for "WTF"). Hulu. ReplayTV. The first unlink-write4 heap overflow. My first default-free BGP4 router. The ball-and-string model (still makes me smile). Force-directed graph layout.

Not: iPod, WWW, VMWare.

</comment><comment><USER35> QBasic.

I got a BASIC programming book from the library when I was 11... despite not knowingly having anything to program BASIC in. Poking around in my MSDOS system files I saw this mysterious program "qbasic". Holy crap! It was there all along and I didn't know about it...

</comment><comment><USER36> TiVo

The Commodore 64

 _Philip and Alex's Guide to Web Publishing_. Particularly the part where I learned what an RDBMS was.

</comment><comment><USER37> * USRobotics 16.8K HST connect sound, damn that was fast. Oh, and ATS11=40&W rox

* Kings Quest 4 install, 10 mb seemed insane at the time

* Google Guice, dependency injection rocks

* Writing my first program in TP7

* Win 3.0 DOS Box, multitasking is cool. Never had DESQview

</comment><comment><USER38> Lisp.

<comment><USER39> Hey Will,

Whatever happened with the startup you were working on?

<comment><USER25> Hank Williams (<http://whydoeseverythingsuck.com> ) mentions KloudShare every now and then.

</comment></comment></comment><comment><USER40> Skype

<comment><USER4> The mbone ruined Skype for me.

</comment></comment><comment><USER41> In chronological order in my own life:

* Satellite TV

* The WWW

* PASCAL -- just because it was the first programming lang I learned

* Doom

* ICQ / Instant messaging

* Napster

* Cell phones

* Broadband

* Scheme

* GPS Navigation / Google maps

* Yahoo! Pipes / mashups

* Ruby on Rails

</comment><comment><USER42> Couchdb. Easily scalable, understandable data storage using JSON and REST, built in Map/Reduce, open source, built in replication and doc revision, and it's not SQL!

</comment><comment><USER43> The first few months after i started learning python can be described as "The Holly Shit Trimester"

Also when i learned that you can use paint to draw stuff(i was 8)

</comment><comment><USER44> Ruby ".map" with a closure, chained. Suddenly I could do tons of text/data manipulation, all with a single line of code.

</comment><comment><USER45> <http://en.wikipedia.org/wiki/Fourth_dimension>

</comment><comment><USER46>
      - Number Munchers
      - <USER2>
      - Wolfenstein 3D
      - Grandpa's Flight Simulator

</comment><comment><USER47> I carried around the Google sawzall whitepaper, printed out, in my bag for a month.

</comment><comment><USER48> QQ. An entire fucking new world out there! -- and they LIKE flashy gifs!!

</comment><comment><USER49> Screen, in addition to a lot of the other stuff already mentioned here.

Recently, CherryPy.

</comment><comment><USER50> Funny how nothing has blown his mind since napster! EC2 maybe?

<comment><USER51> the post is from July 5, 2002

</comment></comment><comment><USER52> GameBoy. Super Nintendo. Nintendo DS (sorry, I'm a fanboy).

</comment><comment><USER53> Cloud computing, when I first learned about the AWS.

</comment><comment><USER54> _NetBus_ Quake _OpenGL_ Multiple Monitors

</comment><comment><USER55> for me it's a nintendo, look one of those on my friends home, holy shit, the graphics is cool, the music is much more cool than my atari

</comment><comment><USER56> RSS/Atom

Google (not suffering from cognitive dissonance)

Distributed Web Caching (Akamai)

Ruby on Rails

Sports on HDTV

</comment><comment><USER57> The genetic algorithm.

It programs _itself_?! Holy Shit!

</comment><comment><USER58> javascript

<comment><USER59> I can reiterate this. Specifically, "I've been using this language for 5 years and never realized it was a powerful language. Holy shit."

<comment><USER58> Yes, and not DOM manipulation. Its the anonymous functions, closures, functional programming, scopes and contexts, etc... pair it with Rhino and the power of "dynamic scopes" and shared scopes and you have multi-threaded programming.

</comment></comment></comment><comment><USER60> * Google (search, then maps)

* iPod and iPhone

* Programming

</comment><comment><USER61> Felicia Day. mmmm....

<comment><USER4> What/when is Felicia Day?

<comment><USER17> Tomorrow is Felicia Day! Celebrate!

Srsly, tho-- She's the female star from Dr. Horrible and (more obscurely) The Guild (a YouTube-only series about a WoW guild). <http://feliciaday.com/>

<comment><USER4> I'm having a "holy shit" moment right now at the thought that there are WoW TV shows. Not sure it's the good kind though.

<comment><USER62> Its actually very well done and pretty funny if you are into WoW. I'm not sure if that makes the concept of a WoW TV show more or less scary for you :P

</comment></comment></comment></comment></comment><comment><USER63> jQuery. "Modern" MVC frameworks. Regular Expressions.

</comment><comment><USER64>
      The Fabric of Reality
      The Fountainhead
      The Myth of the Framework
      The Skeptical Environmentalist
      The Machinery of Freedom

etc

Ideas are what impresses me most.

<comment><USER65> If that's your reading list, you must often be disappointed.

<comment><USER66> Yes -- having a great list, it's hard to find worthy new material.</comment></comment></comment>


Common Web Developer Interview Questions And Answers - <AUTHOR> https://blog.codegiant.io/25-web-developer-interview-questions-and-answers-3030b21ae016 <comment><USER2> I've done a lot of interviews and I want to add a few points about nervousness (As discussed in the beginning of the post):

1\. 99.99% of candidates sound extremely nervous for the first few minutes. That's fine. I think most interviewers expect it. Both the interviewer and the interviewee want to calm down, and a few min of introductory chat seems to help most people.

2\. If I notice a candidate is nervous in the middle of a technical question, I try to say something to calm them down. Often people seem super nervous while doing well/sometimes people confidently do badly — Point is that nerves are not a sign that the candidate is bad, but rather a sign the candidate might be able to do better/be happier if they were calmer.

3\. At least if you were interviewing with me, I'd hope candidates who feel too nervous tell me they are nervous. Maybe other interviewers wouldn't take kindly to this, but if it leads to better/happier hiring then I'm all for it. FWIW this has only happened a handful of times in my career.

<comment><USER3> Also done a ton of interviewing on both sides of the table. On 3:

There's a ton of interviewers who are on a power-trip would would potentially take an admission of something like that as a yellow or red flag. In engineering/business there's a ton of folks who have _huge_ egos and love to rip into candidates for stuff that's small to insignificant.

Then there's the legitimate "that may just weed you out" thing. I have had to hire engineers who I know can deal with tough social situations with grace. Someone admitting openly that they're nervous in an interview isn't necessarily someone who I'd trust going glove-to-glove with execs who will bend your arm to get their way.

Anywho - maybe my reasons aren't the right ones (and they're surely not universally applicable)... but I'd _absolutely_ not give someone the advice to show that card on the interviewee side of the table.

<comment><USER4> As much as I can agree to this, for me personally it wouldn't be worth it to work at a place where clearly defining your feelings and letting your coworkers know is seen as a weakness. In many of my interviews I've had no problem asking for a minute or two to recompose myself due to nervousness, and even though it might have led to me being rejected, at the end of the day it just means I wouldn't enjoy working there anyways.

</comment></comment></comment><comment><USER5> Example of a fibonacci recursion implemented in exponential time just after mentioning big-O notation? Looks just like one of those articles written by a copy-writer who knows nothing about programming and created the article by reading some similar articles thinking he understands it all now

If I were interviewing someone, I would expect the linear solution and from a CS graduate would at least expect mentioning the logarithmic one..

<comment><USER6> Do I get the job?

        defmodule Fibnoc do
          def fib(0), do: []
          def fib(1), do: [0]
          def fib(2), do: [1 | fib(1)]

          def fib(n) when n > 2 and is_number(n) do
            [a, b | _] = rest = fib(n - 1)
            IO.puts("a: #{a} b: #{b} rest: #{inspect(rest)}")
            [a + b | rest]
          end
        end

Although I wouldn't call these questions a great way to assess people for the job, they are fine as a way to weed out people who can't program at all. Most high schoolers spend hours leetcoding these days. I do wonder how tough the market would be by the time I can legally work given current trends of everyone jumping into IT jobs.

<comment><USER4> How does implementing Fibonacci weed out people who can't program at all? Spending hours doing Leetcode is far from a reliable assessment of someone's programming skills.

<comment><USER6> > Spending hours doing Leetcode is far from a reliable assessment of someone's > programming skills.

That's what I mean tho. In high school, they start leetcode practice from day 1 of programming or CS classes. Soon, you will get many leetcoders in the market.

> How does implementing Fibonacci weed out people who can't program at all?

There are many people applying for jobs who can't program a buzz fizz. They exist. A fibonacci is enough to throw them off in an unfamiliar language.

<comment><USER4> Well, for what it's worth I've been programming professionally for 4 years and never had to write fibonacci even one. I think doing something that's more immediately alike what you'll be doing in the project is more productive for both sides.

<comment><USER7> What they are looking for is recursion. Of course I believe there are more efficient ways of doing Fibonacci in a normal loop.

</comment></comment></comment></comment></comment></comment><comment><USER8> You might like this discussion from last year: "Hiring Is Broken: What Do Developers Say About Technical Interviews?"

[https://news.ycombinator.com/item?id=20708026](https://news.ycombinator.com/item?id=20708026)

</comment><comment><USER9> > AJAX is a new technique for creating better, faster, and more interactive > web applications with the help of XML, HTML, CSS, and JavaScript.

AJAX first appeared in 1999 [0], when people still ate Olestra and used pagers.

[0] [https://en.m.wikipedia.org/wiki/Ajax_(programming)](https://en.m.wikipedia.org/wiki/Ajax_\(programming\))

<comment><USER7> People still use pagers...

</comment></comment><comment><USER10> > Java developer interview questions are quite common.

Who wrote this article again? An HR?

<comment><USER11> It's a very low quality article.

The section on 'How do you organize your class modules and assets?' doesn't contain any useful information at all.

It even defines AJAX and Big-O notation for us. Who's the target audience here? Someone trying to impersonate a knowledgeable web developer?

</comment></comment><comment><USER12> Common _Web Developer_ Interview Questions...</comment>


Ask HN: Tips for engineer who wants to seed his own startup - <AUTHOR>

Hi,
I am in the process of mapping out a product for my first Startup.
If you have some time could you post links or comments on tips on the best way to start up?
My aim is to seed fund it, and run it apart from my day job.
Any comments will be appreciated!
Regards
Mark <comment><USER3> Personally I'm on the side of quitting everything and focusing entirely on your startup. If you don't, you'll find yourself 8 months from now and some other startup will come out with pretty much the same thing you've been working on.

And if you can't quit because of work...take a vacation. 2 weeks of working non-stop should be plenty of time to get most things up and running.

<comment><USER4> 2 weeks?

Call me a pessimist, but I think the era of getting funding and building a product with two weeks labour investment from one engineer isn't going to continue.

Quite apart from that, building the business is a much bigger concern than two weeks, there's a lot of boring business stuff that has huge lead times.

It's been done before, but it's like winning the lottery.

<comment><AUTHOR> Interesting Point, I will be funding this myself, the 2 weeks I would use is time to get a alpha product ready! So when I am setting up rest of the business I have something to show for!

Thanks for your comment

</comment></comment></comment><comment><USER5> It takes focus .. and longer than you expect .. to get going under a full head of steam.

The real question is what do you want to startup? -- a full scale business with lots of employees or a one man shop?

<comment><AUTHOR> Hi FredSource,

The idea I have could be a one man shop!

The focus is going to be the crucial factor!

Thanks for your comment!

</comment></comment><comment><USER6> As others said: Just Do It.

Get started and once you're moving you'll find that momentum takes over. To keep the momentum going, make plans: e.g., plan to work at least 1 hour/day on your startup whether it's coding, marketing, website, etc. Just work on it.

I wouldn't take a vacation to do it unless I was positive I could do most of the work in that time, but you need continuous long term effort, so the sooner you get started, the sooner you can succeed.

<comment><AUTHOR> Thanks for your comment, I agree the Just do it mentality is going to be my driver... not to mention energy drinks and high focus by Kelly Howell - <USER2> brain sync I use to wake myself up, and keep focussed on the tasks at hand

</comment></comment><comment><USER7> I've been doing it for ~2.5 years now. See blog in my profile.

Comments: just do it. All the administrivia is trivia. Don't worry about the competition. Build something. Charge money for it. Get better at marketing it. Make it better. Continue repeating "get better at marketing it" and "make it better".

Optionally, stir in a new project.

<comment><AUTHOR> Great Suggestion about the "Don't worry about competition"... The other day I saw something similar to the service I want to do, and at first disheartened me... but if I don't try I will never succeed or fail, just be disheartened! ;)

"If you sit, sit, if you stand, stand, what ever you do, don't wobble"...

</comment></comment><comment><USER8> Just start working on it, and don't worry too much about tips, etc. It's easy to get paralyzed on doing it the best. The best is the enemy of the good.

Always work on the most important thing. If it's not going to move the needle or if its a tangential/pet feature, recognize it and don't do it now. Your most precious resource is time.

<comment><AUTHOR> Thanks for your comment rantfoil, I agree its easily to get paralysed looking for the best way, and doing nothing!</comment></comment>


U.S. Defense Contractors Tell Investors Russian Threat Is Great for Business - <AUTHOR> https://theintercept.com/2016/08/19/nato-weapons-industry/ <comment><USER2> Whether that threat is real, imagined or made up.</comment>


Pentagon considers employees unhappy with US policies a security threat - <AUTHOR> http://rt.com/usa/pentagon-threat-insider-program-232/

<comment><USER2> Here's RT for you: take the most banal imaginable observation ("disgruntled employees pose security threat") and try to make a front page story out of it.

</comment><comment><USER3> RT is a hilariously (& obviously) biased news source, and yet seems to pop up on HN quite frequently. Come on guys, let's have some standards in our news providers.

<comment><USER4> Well, this news story is legit. The training isn't really new though, so I'm guessing they're just digging this up because of recent events enabling them to put some spin on it.

There's a link to the training itself in the article. It's not classified or restricted in any way. Everyone here can take the training themselves. It's actually one of the funniest bit of training I've ever had to take being a contractor working on a govt contract (not with the Pentagon, I don't know why the article mentions the Pentagon and DISA specifically... as far as I know ALL government agencies and contractors have to take this).

The training is very interesting, to me at least (but then again I find almost everything interesting, so I'm not really a good judge). You go into it expecting it to be kinda Orwellian, but they apparently anticipated that. And you'll get dinged if you're TOO strict!

Link to the training: [http://iase.disa.mil/eta/cyberchallenge/launchPage.htm](http://iase.disa.mil/eta/cyberchallenge/launchPage.htm)

<comment><USER5> If it's the "Information Assurance" training then yeah, we pretty much all have to (at least in DoD). I don't think it's been modified for years now though, so it can even seem antiquated in some areas.

</comment></comment></comment><comment><USER5> Is this the latest round of "No Shit" headlines?

"News at 11: Happy and content employees considered lower-risk for insider threat than unhappy employees. Stay tuned for the weather!"

</comment><comment><USER6> I'm curious what kinds of games you can download besides "programmers' games"</comment>


Ask HN: How does LinkedIn know so much about me? - <AUTHOR>

So browsing through my linked in account, it does a great job of recommending people I know (people I graduated with ... people from work, etc).
Here's the thing though, it's too good.  For example, it just recommended I connect with a SCUBA instructor I met with once in Florida.  I saw this guy once, 2 years ago, haven't seen him since and have no other connections to him.  The only way I can figure this out is if they somehow have access to my gmail account.  I'm fairly certain I never connected gmail to linked inn, and even if someone did, surely they don't have permission to parse their entire e-mail history...
How do they know so much? <comment><USER2> Is it possible that he gave LinkedIn access to his email account and he has your address in his email? Alternatively, could he have viewed your LinkedIn page? Maybe LinkedIn recommend connections that way also.

<comment><AUTHOR> I doubt he viewed my page (I was a random customer from years ago), but the fact that he might have connected his e-mail account sounds plausible.

</comment></comment><comment><USER3> LinkedIn is definitely doing something with your searches. I've searched for old high school/college friends (sure, ex-girlfriends too, you got me), only to have them pop up in the recommendation box a few months later.

Who's to say that LinkedIn isn't adding those people to some secondary network for you and later making recommendations off the people _they_ are searching for?

</comment><comment><USER4> On the flip side, I'd like to know how they seem to consistently miss one of the most important pieces of information about my career: I'm leaving the U.S. soon. I'm planning to emigrate in the next three years, either to Australia or New Zealand. I've made a few LinkedIn connections with folks there (hi, Duncan and Steve!). I've joined LinkedIn groups for software professionals in both countries. I subscribe to Google Groups for the same purpose. I regularly search LinkedIn's company listings for software companies in both countries that I'd like to keep my eye on. I have literally come right out and told them this in feedback about their apps.

LinkedIn has access to all of this data about me that really should be setting off alarm bells in their recommendation systems, and yet it's not happening. I'm constantly given recommendations for companies, groups and jobs I might be interested in in various areas of the U.S., and none of them take that fact into consideration.

How can they miss this?

</comment><comment><USER5> Sounds like they have developed tech similar to Katango - [http://www.building43.com/videos/2011/07/12/katango- organizi...](http://www.building43.com/videos/2011/07/12/katango-organizing- your-social-network/)

And now Google probably also knows that much about you because they bought Katango.

LinkedIn also bought Rapportive recently, so they have a very high quality people database.

</comment><comment><USER6> I have similar concerns. A referral from a friend of a friend, led to an email exchange...and nothing ever came of it. However, 2 years later, the guy is a suggested connection on linkedin.

Highlander is probably right. I doubt there is an instance where major providers are exchanging information behind closed doors. But if there is, it won't be long before it comes into the light of day.

</comment><comment><USER7> I've noticed the same thing. How could they possible know that I know _of_ these people I see. Perhaps they do look at who I view, and who views me.

Its quite disturbing, but at the same time fairly impressive. I'm very curious.</comment>


How I exploited a loophole in a system – Medium - <AUTHOR> https://medium.com/@xittycat/how-i-exploited-a-loophole-in-a-system-baea0937360b#.y07rj8heu <comment><USER2> "How I violated terms of service, defected on a prisoner's dilemma, and likely committed fraud to make some extra spending cash."

The ending is really weird. It's supposed to be introspective, but the supposed problem is that he's changed his relationship with money by getting so much of it by disreputable means, rather than considering that maybe what he was doing wasn't a good thing.

</comment><comment><USER3> Yeah.. People like this guy are the reason why we can't have nice things.

</comment><comment><USER4> this is just fraud...

</comment><comment><USER5> How old do you have to be to have a Medium account?

</comment><comment><USER6> If by loophole you mean fraud...</comment>


Instawallet Hacked - <AUTHOR> http://notice.instawallet.org/ <comment><USER4> >> If several claims have been filed for the same url, we will process those claims on a case by case basis, under the presumption that the claim we received first belongs to the legitimate balance holder.

Is this a joke? They can't be serious.

<comment><USER5> And when all of their wallet URLs were indexed in Google, I am pretty sure they're saying that nobody is getting a refund here.

</comment></comment><comment><USER6> I know it's been said many times before, but we're only going to see a rise in bitcoin thefts. With the price being over $100/coin and you're stealing virtually untraceable currency, I'm honestly just surprised that there hasn't been more thefts. I'm sure the security team at Mt. Gox is top notch as they probably have dozens of hack attempts per day.

<comment><USER5> I for one believe the barrage of attacks and attempted thefts will inevitably make Bitcoin safer. Just like Google Chrome's pwning contests, eventually nobody will be capable of claiming the prize.

<comment><USER7> It's not really comparable to Pwn2Own. Pwn2Own's only vector of attack is by finding flaws in the software directly.

All of these wallet service companies employ people and many, many successful hacks are performed by exploiting the people involved / mistakes the people make.

So while software with enough hardening can eventually get to a state that's quite safe, as long as people are an active part of the security chain, you're going to have valid attack vectors.

<comment><USER8> There have also been attacks on Bitcoin companies that exploited their hosting company's procedures or lax handling by their employees. Securing this stuff is fundamentally hard.

</comment></comment></comment></comment><comment><USER9> This [<https://news.ycombinator.com/item?id=5475389>] conversation suggests that there might have been a very large withdrawal of funds just prior to the system shutdown.

It points out again how careful you have to be when suddenly there is "real money" on the line.

I've yet to see the "exit strategy" where an enterprising crook sets up an exchange and then loots it once its net value is high enough. But I would not be surprised to see that happen. It has happened in the brick and mortar world with banks, no reason it shouldn't be any different in the digital world.

<comment><USER10> So everyone knows the destination address of fraudulent transfer. I wonder if it would make sense to mark it as "dirty" and mark as "dirty" every other address where the funds will be transferred from this address. And then every legitimate merchant, after receiving bitcoin payment would validate incoming address against "dirty" list to allow tracking of thief? This of course works only if _every_ merchant and service in bitcoin world would do that.

Just an idea ...

<comment><USER11> I doubt the miners would accept this idea. It goes against a key principle of Bitcoin: that transactions are irreversible and no authority can appropriate your coins.

Even the 0.8->0.7 reversal was hard for some miners to swallow. And in that case it was only accepted because only doubly-spent transactions would be reversed. Singly-spend transactions would just transfer over to the new chain.

I don't expect to ever see a Bitcoin fork where a cryptographically valid, singly-spent, included-in-a-block transaction is reversed.

<comment><USER10> That would be totally merchant-driven, nothing to do with miners. No reversals needed.

<comment><USER12> I don't understand how your proposal is tenable. There's nothing preventing the fraudulent party with their blocked Wallet A to just create a new Wallet B, transfer funds to that, and then use it.

If you're a merchant, you'd have to do origin tracing of the funds in all the wallets you accept. It's not as simple as just creating a blacklist, that would be very easily avoided. The only thing that might work is getting all miners to refuse to accept transfers from the "bad" address to ANY other address (good luck, that's never going to happen).

</comment></comment></comment></comment></comment><comment><USER13> I expect nothing less from Instawallet. Previously, they used to keep private keys in the URL and allowed google to index these URLs. It took a lot of pestering and hand-holding to get this fixed. I should have figured this would have happened sooner or later, given their incompetency regarding security.

<comment><USER14> Dunning-Kruger is an order of magnitude stronger for security.

<comment><USER15> If you are doing security for a Bitcoin site, your motto should be "I am an idiot and am forgetting something very basic." Then you should try to figure out how to protect yourself from your own idiocy despite being stupid.

And you should never assume you just got smart.

<comment><USER16> And then a 17 year old launches before you and takes your customers.

<comment><USER17> And the 17 y/o takes their customers' wallets, what's your point?

<comment><USER16> The market can stay irrational longer than you can stay solvent. Everybody who tried to "do it right" (TradeHill, CampBX, etc.) seems to have failed while users flock to the joker du jour.

<comment><USER17> Wouldn't it then be hard to be the joker du jour for long?

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> > Instawallet hacked

Another alternative is that the Instawallet people just decided to keep the "money" you had stored there, and retire to a small Caribbean island.

You'll never know.

</comment><comment><USER19> This type of incident is a key reason the US Treasury's Financial Crimes Enforcement Network ("FinCEN") issued sensible guidance requiring those who offer wallet (bitcoin transfers between persons and/or merchants) and currency conversion services to be regulated as money transmitters. While money transmitter regulation isn't perfect and is expensive for providers, it can provide some consumer protections in these scenarios.

Edit: Forgot to link to their guidance

[http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001....](http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.html)

</comment><comment><USER20> Clicking the logo directs the user to <http://localhost:3000>.

On a side note... New Business plan:

1\. Setup an online Bitcoin wallet service 2\. Wait a while till people actually trust/use it 3\. "We got hacked"

<comment><USER21> Very high risk for moderate reward, assuming you're based in a country with functioning law enforcement.

<comment><USER22> Depends on the countries laws. What makes you think anyone attorney is going to prosecute the theft of a "digital currency." At this time in the world most people when informed of bitcoin think it's a toy currency.

</comment></comment></comment><comment><USER23> How many more times do we need to go through this?

People: Only keep an amount you are willing to lose in an online wallet. Keep the rest offline and encrypted.

<comment><USER15> If you are using it as a currency, "offline and encrypted" is "unusable."

If you are using it as a commodity to trade, well, it's perfect.

<comment><USER24> Maybe. Perhaps it might be useful to compare online bitcoin storage with cash in your pocket. You wouldn't convert your entire nett worth to cash, stick it in your pocket (or for "added security", hide it in your sock!) then go out clubbing.

Unless you're about to buy a car or a house with bitcoin, there's no need to store tens or hundreds of thousands of dollars worth in an immediately useable (and hence potentially stealable) status.

</comment></comment></comment><comment><USER25> What made Instawallet better than Blockchain for an online wallet? why did people use it? what was the selling point??

<comment><USER5> Who ever said that it was better?

No online wallets are secure, nobody should be using them, but unfortunately the bitcoin system is still a bit too complicated for a lot of people.

<comment><USER26> Instawallet always made it clear that no one should keep anything more than spare change there.

<comment><USER5> I don't think they said that on the homepage, they advertised themselves as a bitcoin wallet.

They did say so at one time or another I believe, but that was long long ago.

</comment></comment></comment></comment><comment><USER27> Wow, could become a clusterfuck of epic proportions:

1\. It takes three months to get you BTC back, and only up to a max of 50. If you have more, it will take longer.

2\. If the hackers can figure out your url and key, they can dispute your claim. If they actually get their claim in before your legit claim, their claim is favored.

Yikes. I would not want to be either an Instawallet employee having to sort that mess, or a client with their BTC frozen for months and potentially at risk of being stolen.

 _"Important information on claims submission:

For the first 90 days we will accept claims for individual Instawallets. Your wallet's URL and key will be used to pre-populate a form to file the claim.

After 90 days, if no other claim has been received for the same url, your Instawallet balance under 50 BTC will be refunded. If several claims have been filed for the same url, we will process those claims on a case by case basis, under the presumption that the claim we received first belongs to the legitimate balance holder.

Claims for wallets that hold a balance greater than 50 BTC will be processed on a case by case and best efforts basis."_

</comment><comment><USER28> Also troubling is their logo links to localhost:3000. Why would you hard link that in the first place?

</comment><comment><USER29> <https://bitcointalk.org/index.php?topic=83794.0>

A good look at previous thefts. The last page contains links to the current Instawallet issue.

</comment><comment><USER30> If this is what it sounds like, and the "exploit" was google indexing a bunch of URLs which allowed direct access to the funds they referenced, how did google discover them in the first place?

There was mention of a missing/broken robots.txt which allowed GoogleBot to index them, but what I'm stuck on is how it learned about them in the first place; where they actually doing something utterly insane like autopublishing a sitemap, or was there some bug allowing g'bot to sniff/guess the URLs?

I've seen odd behaviour in my logs from google crawls in the past, like g'bot traffic within minutes of adding a new DNS entry/vhost to a domain, with absolutely assuredly no mention of it publicly available. I suppose it's possible they're watching DNS zone changes and scheduling a tentative probe, but it's a bit creepy (especially if you're disorganised and haven't got the robots.txt set up right away)

</comment><comment><USER31> In an authority-less and irreversible transaction currency it still surprises me when I hear about someone losing money to a service such as this - <USER2> an authority the burden of security truly is on the user themselves and they are at the mercy of the (supposed) security of whatever exchange or service they are attempting to use. In this case, having someone manage your wallet for you.

I personally keep my bitcoin wallet encrypted with GPG, I manually (like a safe) decrypt it when I want to make a bitcoin transaction and encrypt it when I'm done.

</comment><comment><USER32> logo link on this notice page points to localhost:3000, looks like dev/prod mixup

<comment><USER33> They seem to be physically relocating (or at least a new server).

</comment></comment><comment><USER5> Given the fact that instawallet was rarely used in the previous few years, I doubt this will have much of an impact on the Bitcoin market: <http://www.alexa.com/siteinfo/instawallet.org>

<comment><USER34> FWIW Alexa isn't accurate and can easily be gamed.

<comment><USER5> I am aware, but at least it doesn't look like this: <http://www.alexa.com/siteinfo/bitcoin.org>

Faking a high alexa ranking may be possible, but faking a low alexa ranking is not.

You can't fake the fact that next to nobody went to instawallet.

<comment><USER17> "Faking a high alexa ranking may be possible, but faking a low alexa ranking is not."

You need to be the sort of idiot who runs feature-free bloatware before you can contribute to their ranking system.

<comment><USER35> That is not a counter to his argument.

<comment><USER17> If you think it is not a counter to his argument, you're missing the point, that low scores are not indicative of low traffic, and high scores are not indicative of high traffic (except among a very specific demographic.)

</comment></comment></comment></comment></comment></comment><comment><USER36> I use coinbase. How long until they are hacked? Who can I trust! This is the one con to bitcoin.

</comment><comment><USER37> _stop. storing. your. wallet. online._ (I wanted to write this in caps, but I resisted)

I'll add this to my list of things that people _know_ they should do but are _too lazy_ to take a few minutes and setup: don't repeat passwords, use a password manager, make regular backups, don't use GoDaddy.

Stop thinking you're the exception dammit, these things don't take that much effort to do properly.

<comment><USER38> To me, this signals a strong need for more secure bitcoin storage options, and since this is hacker news, perhaps some of us should get started on that :)

<comment><USER15> I think I could do a pretty good job keeping wallets secure. But it would need to be a full-time job, not a side project, and it would need a big budget.

You don't bootstrap a bank.

(Plus I did some basics with Bitcoin a few years ago and got pissed off at the protocol and moved onto less annoying things.)

<comment><USER39> I don't like to spam with links, but <http://www.bitalo.com> aims to be the service you described, and will be launched soon. "Most secure" really means that no one, even the site admins/hosting platform can never touch your coins. This will be enforced by the technology used, not just some internal policies. And also, the site will be backed by a german AG company, which is basically a type of "Public limited company" backed by minimum of 50,000 EUR.

<comment><USER40> How do they plan to accomplish this without using javascript crypto?

<comment><USER39> I plan on using Javascript crypto. I've spent many hours reasoning over this idea, also studying security community reactions on mega.co.nz and I think it is possible to do now. I don't want to disclose all details now for obvious reasons, but all I can tell that I will not reinvent the wheel here - <USER3> parts needed are already available and mature, you just have to assemble them into a complete solution.

<comment><USER41> > you just have to assemble them into a complete solution.

Many (if not most) of the security vulnerabilites of the past years come from perfectly safe components assembled in an unsafe way.

Crypto-engineering is _hard_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER42> shit</comment>


Bringing GNU Emacs to native code [video] - <AUTHOR> https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7 <comment><USER2> I tried this out on my system last night. Compile time was quite large (I would say about an hour and a half on my Ryzen 3600X.) I use the DOOM Emacs config, and was surprised to find most things working out of the box with the native compilation. I noticed no difference in startup time. The speed boost was surprisingly noticeable, however, when e.g. opening a buffer that causes a language server to start. Opening CCLS was... instant. It's usually quite quick, but this was noticeably faster.

Great job all around!

<comment> s-km does it do anything to change/fix Emacs shitting itself on large buffers?

last time i gave it a try opening a large file would completely kill performance, and iirc in particular really long lines (ex. 1000+ chars) would make the thing chug even if the actual file wasn't super big or anything.

<comment><USER3> > _in particular really long lines (ex. 1000+ chars) would make the thing > chug_

My uninformed guess is, this is bottlenecked by an inefficient algorithm that accesses the memory too much, i.e. it's nonlinear with respect to the number of characters. I doubt that tweaking the overall speed would fix it.

<comment><USER4> My experience is it's generally either

\- inefficient font-lock regexes, which are rarely benchmarked / optimized since most files don't have long lines and because font-lock behavior is quite complicated to begin with;

\- inefficient thing-at-point implementations / use, e.g. an O(n*n) thing-at- point called at various points by an O(n) function;

\- modes using font-lock regexps where they really just need "fixed" styled text, but other Emacs architecture makes it difficult, e.g. compilation-mode and derivatives.

<comment><USER5> Emacs dev here. The primary cause is something else.

Emacs's inefficiency in handling files with long lines is due to two factors: (a) The primitive unit of work for the display engine (the code that determines how to combine text, font metrics, syntax highlighting, inline image display, etc.) is a line (a newline-delimited span of characters). (b) The redisplay routine is called very frequently—not just when the screen is repainted, but pretty much any time the screen location of a buffer element need to be calculated, and so, e.g., during navigation. So Emacs is constantly, under the hood, going back to the previous newline and re- calculating how the buffer contents from that point forward should be rendered.

<comment><USER4> I'm not an Emacs dev so I'll concede your expertise here - but if it is fundamental to the core navigation and redisplay, why does "stepping down" modes help so much? Fundamental and text mode certainly aren't great with long lines, but are usually orders of magnitude better (eg a few seconds per command instead of 10s of seconds).

(I have not tried so-long-mode and am mostly on Emacs 26 with some 25.)

<comment><USER5> What you're observing is caused by what I'm describing. The features of these other modes are expensive because they do things that implicitly invoke redisplay.

Consider an ostensibly simple operation like determining the column in which a particular character appears. The answer to that isn't the number of characters since the last occurrence of `\n`, because whatever modes are active can inject arbitrary spacing, or display particular strings as something shorter or longer (a trivial example is the mode that causes `lambda` to be displayed as `λ`), or cause some characters to be displayed in a non-roman font where a single glyph is more than one column wide, and so on. To determine the character's column accurately you need to take into account everything that could affect how you'd paint the screen at that position, i.e., run the whole redisplay loop for some portion of a buffer. The richer the set of active modes, the more expensive it is to do that and the more often it is done.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Note: this is a video. Here are the slides: [http://akrl.sdf.org/gccemacs_els2020.pdf](http://akrl.sdf.org/gccemacs_els2020.pdf)

<comment><USER7> I'd recognize a LaTeX beamer presentation anywhere.

Here is the corresponding paper: [https://arxiv.org/pdf/2004.02504.pdf](https://arxiv.org/pdf/2004.02504.pdf)

<comment><USER8> From org-mode too, as it has the pointless Outline page that org always inserts into beamer presentations.

<comment><USER9> It's not pointless, but the outline only shows up if the generated tex file is compiled twice. The default org to latex export will only compile it once.

Alternatively, it is easy to suppress the outline slide altogether (add "toc:nil" to "#+OPTIONS:").

<comment><USER8> Oh I know. I have toc:nil as my default because it annoys me.

It's just a bit of a giveaway as to how the file was made.

</comment></comment></comment></comment></comment><comment><USER10> I have a Gentoo ebuild [0] almost working for this (I think I'm missing the step where the eln files are loaded before dumping the base image). The compile times are ... substantial. However they don't affect the development process for new code since the interpreter is always there, and I am excited to see what performance gains we will see.

From an engineering perspective this is a excellent example of a direct path from interpreted to compiled code. The trade-offs are clear (heck, they are number 0-3), and while there is complexity, all the engineering time has been effectively concentrated inside a single project, rather than forced upon tens of thousands of maintainers and users. Bravo. I wonder what other bytecode interpreters could benefit from this toolchain. Compile times from qlop.

On a Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz Without comp `2020-05-03T15:33:27 >>> app-editors/emacs: 6′40″` With compile `2020-05-03T18:35:43 >>> app-editors/emacs: 2:11:45`

0\. [https://github.com/tgbugs/tgbugs-overlay/blob/master/app- edi...](https://github.com/tgbugs/tgbugs-overlay/blob/master/app- editors/emacs/emacs-28.0.9999-r1.ebuild)

<comment><USER11> nice, thanks for the ebuild!

</comment></comment><comment><USER12> As a exclusive emacs user for the last 20 years, I'm quite excited; my main complain about emacs is its slow down with some more sophisticated packages. I wonder if it improves magit performance with large codebases.

Pigs fly just fine with with enough thrust.

<comment><USER13> One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit, but the implementation leaves a lot to be desired. So the pig in this case is definitely not Emacs.

Example:

      # Doing a simple magit refresh results in the following processes being spawned (tracked with dtrace)
      # Notice how many calls are completely redundant

      2020 May  4 12:46:22 11819 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11820 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11821 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11822 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11823 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11824 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11825 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11826 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11827 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11828 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11829 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11830 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11831 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11832 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11833 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11834 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11835 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11836 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11837 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11838 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11839 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11840 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>
      2020 May  4 12:46:22 11841 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11842 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11843 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11844 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11845 <67471> 64b  /opt/local/bin/git --no-pager -c core.preloadindex=true -c log.showSignature=false <...>
      2020 May  4 12:46:22 11846 <67471> 64b  /opt/local/bin/git --no-pager --literal-pathspecs -c core.preloadindex=true -c <...>

<comment><USER14> Meaning, it's only really slow on macOS.

<comment><USER15> Multiple versions of macOS. And Windows. And possibly other less known systems.

Besides, why would a discerning engineer put up with magit creating all these wasteful processes knowing that most of them are redundant, regardless of performance feel? If I was a magit developer, I would surely try to fix this.

<comment><USER14> On Windows it's not as fast as Linux, but it's not terrible either (as far as I heard).

Also see [https://stackoverflow.com/a/16902730/615245](https://stackoverflow.com/a/16902730/615245) (I think it's not needed with the latest versions of Git anymore, though).

> If I was a magit developer, I would surely try to fix this.

Since you're just a regular user, did you check out the issue tracker for related discussions?

</comment></comment></comment></comment></comment><comment><USER16> Here some rough, non-scientific testing/benchmark statistics.

It took me 124.98 mins to build the native-comp branch with a 4-cores/8-threads i7-4790k, 32GB RAM on a LXC instance while the master branch took me 244 seconds. Both branches are obtained from latest available git snapshot as 2020-5-4 20:20 CDT.

The following function is passed to (benchmark-run-compiled 10 ...) for each run.

      ;; -*- lexical-binding: t -*-

      (require 'cl-lib)

      (defun bf-1 nil
         (/
           (apply '+
            (cl-loop repeat 300000
             collect (cl-random 1.0)))
         300000.0))

gc-cons-threshold is set as 268435456 (~ 256MB)

Before each run, (garbage-collect) function is called.

With Emacs's built-in core lisp functions, cl-lib functions and the above benchmark function are all native-compiled, it took 0.5823 second to complete.

With Emacs built-ins and cl-lib are native-compiled but the benchmark function is byte-compiled, it takes 0.6411 second to complete.

With byte-compiled Emacs built-in/cl-lib/benchmark functions, it takes 1.3574 second to complete.

With byte-compiled Emacs built-in/cl-lib functions and interpreted benchmark function, it takes 78.054 seconds with 1 GC taking 75.094 second, which implies the execution roughly takes 2.96 seconds.

I also ran same benchmark on a 4-core A10-6800k. and observed similar ratios on the builds from 2020-5-3.

</comment><comment><USER17> I posted the same content 5 days ago here: [https://news.ycombinator.com/item?id=23021574](https://news.ycombinator.com/item?id=23021574)

No reaction at all. I am really curios to understand what I did wrong at the time.

<comment><USER18> Nothing at all. You just lost the Hacker News lottery.

</comment></comment><comment><USER19> "Arguably the most deployed Lisp today?"

That's an interesting question. My other guess would have been Gimp, and based on a quick glance at Debian's popcon, I'd say Gimp might be slightly in the lead.

Then again, like Open Firmware deployed Forth on millions of computers, right under our noses, it would not surprise me at all if there were a simple Lisp implementation hidden on every computer in the world.

Is there anything more recent than DSSSL?

</comment><comment><USER18> Looks really cool! One thing I noticed was the generated code seemed to have fairly poor register allocation, looking more like it was just pulling things straight out from locals into registers and immediately storing them back. From the talk, it looks like that was what was being provided to libgccjit, but surely it could optimize that further?

</comment><comment><USER20> Just when I thought I know enough compsci to understand everything on a sufficiently high level, this guy totally lost me starting from LIMPLE

<comment><USER21> Compilers are "just" a series of transformations / translations from higher- level code to lower-level code. The top is code like C, python, elisp, whatever, and the bottom is machine code for amd64, arm7, whatever. All the in-between code is in some intermediate representation (IR).

Each successive step takes care of different optimizations, modifying the code as it goes down. At the last step, he converts LIMPLE to an IR (intermediate representation) that libgccjit understands, and hands it off to gcc for native compilation.

Could you just start with elisp and emit amd64 machine code in one step? Absolutely, but it would be hell to maintain, and then you lose out on all the pluggability of modern compilers. If you (consume and/or) emit standard(-ish) IRs, you get to participate in a pretty amazing ecosystem.

<comment><USER22> Also even if you do "one step" you'll want to have an intermediate data format which is SSA for the more efficient optimizations

</comment></comment></comment><comment><USER23> Did anyone successfully compile it for x86 32-bit target? The docker image is 64-bit and the compilation seems to be hitting the gcc-i386 limit of 3GiB.

</comment><comment><USER24> Very keen to try this out but that branch won't compile for me. What's the trick?

</comment><comment><USER25> This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

<comment><USER26> Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.

<comment><USER27> You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp.

You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps.

Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in SBCL for example), but this looks like a reasonable approach overall.

For example (just a draft, this might be incorrect):

        USER> (defun make-local-variable (symbol)
                (eval `(define-symbol-macro ,symbol (bvar (quote ,symbol)))))
        MAKE-LOCAL-VARIABLE

        USER> (make-local-variable 'foo)
        FOO

        USER> (macroexpand-all '(list foo))
        (LIST (BVAR 'FOO))
        T
        T

The BVAR forms would then be able to access a buffer variable, with the current buffer. This works with SETF too (but Emacs Lisp SETQ should be replaced by SETF during the transform).

BVAR could expand into code that calls FFI functions, for compatibility. Using an FFI approach would allow to progressively rewrite some parts of the runtime into CL.

Just to clarify, I know this is a huge work to undertake, but this comes from the assumption that we want to keep all existing Elisp files running identically.

<comment><USER28> Emacs contains a quarter million lines of C. What do you do with all the elisp that calls into it? Maybe that could be turned into a "libemacs" and used from FFI.

<comment><USER29> Or maybe you rewrite it in Common Lisp. If you're going to take the Common Lisp route, I think it might be worth going all in and just re-implementing Emacs in Common Lisp.

<comment><USER30> That's already been done. More than once, in fact. The problem is that, although there are perfectly serviceable Emacsen written in Common Lisp, none of them are GNU Emacs.

For example, there's Hemlock from CMUCL, and its descendants built into Lispworks and Clozure Common Lisp.

Those implementations aren't likely to work well as a substitute for GNU Emacs. For one thing, there's a substantial ecosystem of software that depends on specific APIs and other characteristics of GNU Emacs. Writing code to bridge GNU Emacs APIs with those available in the Hemlock descendants would be a lot of work.

There are some other obstacles as well. CCL's implementation of Hemlock uses the Cocoa text architecture, so it's not portable to platforms other than macOS.

The Lispworks implementation is portable across Windows and numerous UNIXEN, but the Lispworks license will not allow delivery of a proper substitute for GNU Emacs (it forbids building an application that can be construed as a Lisp development system, and when I pressed them about exactly what limits that policy implies, they explicitly used Emacs as an example of an application that would be forbidden).

The original CMUCL Hemlock and its portable version are designed to work with CLX. It could probably be made to work in a modern X environment, but making it fit well into modern GUI environments and porting it to all the platforms GNU Emacs works on would be a huge amount of work.

I'm probably overlooking some other Emacsen, but I don't know of any off the top of my head for which the situation is any easier.

<comment><USER31> Robert Strandh is working on an Common Lisp emacs based on McClim but, McClim basically forces you to use linux.

<comment><USER31> There's also lem, which is more portable: [https://github.com/cxxxr/lem](https://github.com/cxxxr/lem)</comment></comment></comment></comment></comment></comment></comment></comment>


Heat Records Shatter as a Monster El Nino Gathers Strength - <AUTHOR> http://www.bloomberg.com/news/features/2015-11-18/heat-records-shatter-as-a-monster-el-nino-gathers-strength <comment><USER2> I'm confused. I know we're supposed to believe in warming but isolated data points are logically insufficient. Articles like this that selectively show interesting data points without giving a broader picture actually hurt the cause.

In the news lately we've seen record south pole ice extent and lots of cold records in the southern hemisphere. It makes sense that if the southern hemisphere is cooler there will be fewer cold records because there's a lot less land mass. Lets get some data that points out how the northern hemisphere is getting hotter faster than the southern hemisphere is cooling.

By displaying a more world relevant dataset you could more logically support the global trend theory.</comment>


Hawaii put on the Startup World map thanks to MaiTai - <AUTHOR> http://startupworld.com/blog/hawaii-put-on-the-startup-world-map-thanks-to-maitai/

<comment><USER2> Cool, congrats Pharmly.

<comment><AUTHOR> It's a great idea. I'm really hoping it brings down the cost of healthcare.</comment></comment>