A gun is now more likely to kill you than a car is in the U.S - <AUTHOR> http://www.economist.com/news/united-states/21638140-gun-now-more-likely-kill-you-car-bangers-v-bullets <comment><USER3> I keep looking through the data, [http://www.cdc.gov/nchs/data/nvsr/nvsr63/nvsr63_03.pdf](http://www.cdc.gov/nchs/data/nvsr/nvsr63/nvsr63_03.pdf), and it seems like cars still beat out guns by a good margin. They even say in the article most of the gun deaths are by suicide. Just the few numbers I grabbed says you're still 3 times more likely to be killed by or in a car. I looked again at the article and they don't even list the numbers because it conflicts with the story they WANT to have. The proper title is "The forecast for ways you might die in the next 5 years if you remain in the 15-24 age bracket shows a higher change of being killed by a gun, or killing yourself with a gun, than by being killed in or by a car."

Assault (homicide) by discharge of firearms 11,068

Accidental discharge of firearms 591

Discharge of firearms, undetermined intent 248

Motor vehicle accidents 35,303

Unless you're taking your own life: Intentional self-harm (suicide) by discharge of firearms 19,990

<comment><USER4> > They even say in the article most of the gun deaths are by suicide.

It says "suicides, accidents or domestic violence." These are all vital statistics in determining the deadliness of guns.

Gun advocates have been arguing here that suicides shouldn't be counted, which doesn't make sense. Access to an effective suicide method is one more consequence of a gun-owning society. It should be acknowledged, analyzed, and discussed.

It seems as though advocates are arguing that the statistics should be filtered to make guns appear less statistically deadly. That's nonsense. This is a comparison of deadliness; a gun death is a gun death. Despite a decline in gun ownership, gun deaths are trending _upward_ , and the NRA opposes smart-unlock features like thumbprint identification that contrast with the myriad safety controls placed on vehicles.

<comment><USER5> If this were epidemiology, we would talk about "total morbidity." If I develop a flu vaccine that 100% stops flu deaths but kills 10% of patients via heart attacks, I have not improved the situation. A troll or person otherwise committed to a narrative that my flu vaccine should be foist on everyone might say "a flu death is a flu death" but it's not what matters.

About half of American households have access to a gun while about half of suicides are done via gun. The US is within 10% of most other first world countries in terms of suicide rate. The real world evidence is that if you got rid of guns in an attempt to stop suicides, the strong majority of those who want to commit suicide would find another method.

<comment><USER6> > The real world evidence is that if you got rid of guns in an attempt to stop > suicides, the strong majority of those who want to commit suicide would find > another method.

What does "real world" evidence mean? Because real world evidence from England (paracetamol pack sizes; switch to natural gas from coal gas; removing coproxamol from general use) shows that many people do not find another method.

<comment><USER5> The real world evidence in the comment you replied to, from the paragraph that you selected your quote from.

1\. About half of US households have access to gun, implying half do not. Suicide-by-gun is about half the total suicide rate. With the assumption that people kill themselves with a gun if it's available, the no-gun-in-household suicide rate is very similar to the gun-in-household suicide rate.

2\. The fact that the US is within about 10% of most other first-world countries in terms of suicide rate. Unless you want to argue that something especially good about the US's mental health system such that only Luxembourg ought be in front of it.

If the US turned into Canada (meaning: essentially no guns and a suicide rate 0.92 of the US) then more than 80% of gun suicides would find another way.

<comment><USER6> You seem to be saying that there are two groups of equal size (people who complete suicide by gun and people who complete suicide by other methods) and then saying that if you remove access to guns that all or most of the gun group would just switch to the other group and that the total number would stay the same.

Don't think that an attempted suicide by gun is the same as an attempt using another method. Guns are a very lethal method of suicide. Other methods of suicide are not as sure. This might explain the differences in completed suicide numbers for men and women (more men die to suicide) and rates of self harm (very many more women self harm) -- men might be using more lethal methods.

Some members of the "want to use a gun as a method of suicide group" would use a different method and would complete suicide. But certainly not all that group. Some would use a less fatal method and attempt suicide but not die. Others would find help before attempting suicide.

For a tiny US example: look at the Taft and Ellington Bridges in Washington State. They were both used by people to complete suicide, although more people used Ellington. After a number of people dying to suicide in a short number of days a suicide barrier was put up. People did not switch to the other bridge, even though it was close.

[http://cebmh.warne.ox.ac.uk/csr/](http://cebmh.warne.ox.ac.uk/csr/)

Again: look at the rates of completed suicide in England after switching gas supplies; after removing coproxamol from general use; and after reducing the amount of paracetamol. All of these resulted in permanent drops in the suicide rate.

<comment><USER5> _You seem to be saying that there are two groups of equal size (people who complete suicide by gun and people who complete suicide by other methods)_

I think you might be misreading me. The reason it's important that gun-suicide and non-gun-suicide are about the same size is that about equal number of households have guns and don't have guns.

If about 10% of households had access to a gun, and about 10% of suicides were done via gun, I'd say the same thing: access to guns isn't the significant driver of suicide completion.

> But certainly not all that group

Sure, certainly not all. I agree some people would stop. My guess is that around 10% or so.

The problem I have with the thesis that "most people won't switch to another method" is that it leads to a world where the United States is supposed to have an amazingly low suicide rate compared to most other first-world countries. And the thing that is stopping the US is a hot-button political issue, _especially_ because most of the people who are inclined to try and get rid of the guns would _disagree_ that the United States has an especially good mental health system compared to Canada, the UK, Germany, Denmark, Iceland, France, and Finland.

You can point to a bunch of small effects, but you want to apply them to the big picture. Well, why isn't the big picture a lot different? If the US had twice the suicide rate of most other countries, I think you'd be right.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> From the article:

> By contrast, safety features on firearms—such as smartguns unlocked by an > owner's thumbprint or a radio-frequency encryption—are opposed by the > National Rifle Association, whose allies in Congress also block funding for > the sort of public-health research that might show, in even clearer detail, > the cost of America's love affair with guns.

Can someone explain the NRA to me? At this point they come across as cartoon villains, senselessly evil for no apparent purpose. Why can car companies be persuaded to invest in safety features but somehow the NRA works against its own interests to make guns as dangerous as possible? I feel like I must be missing some side of the story, because from the stuff I read, they're literally twirling their mustachios while cackling right now.

<comment><USER8> Accepting the premise that it's a good thing that the population at large can own guns, their argument is that they're thinking a few steps ahead:

If smartguns become popular, the government can then outlaw non-smartguns without too many people caring (they can still own and fire guns).

Then the smart-stuff is leveraged to "enhance" security - <USER2> ownership, for an example, could be made subject to a government permit, which can then be used, explicitly or implicitly - imagine a "no fly list" for guns, with the same opacity - to prevent large groups of people to own guns (well, specifically, to fire them).

Further not-very-fantastical "enhancements" could include remote-disabling of guns, initially for law enforcement use, but quickly extended to much broader use.

All this, of course, while the criminals (who are already obtaining guns illegally) keep using "dumb" guns and aren't affected by this.

These are the simple, practical reasons - there's also the ideological reason founded on the historical reason for the 2nd amendment: A government can't turn on it's own people if said people is armed. If the government can effectively control the guns of the people, that stops being a factor.

<comment><USER7> Is the "keep the government in line" thing really a reason that anybody actually believes anymore? Like, if things got so bad that the government was "turning on its own people" with weaponry, somebody really thinks some guys with guns from Wal-Mart are going to be what stops them?

<comment><USER9> Honestly? It's not a far step away from the kind of firepower they lost to in Vietnam and Iraq.

<comment><USER10> A US government worth overthrowing by armed insurrection _and that couldn 't be overthrown some other way_ would practically by definition be willing and able to engage in some _really_ nasty practices to put down a domestic rebellion. Like, filling-mass-graves nasty. Shooting at them wouldn't help.

Sympathy from the armed forces and various forms of political pressure, foreign and domestic, would be far more helpful than a few deer rifles, and if you've got that your private arms aren't really necessary. A domestic rebellion wouldn't win by shooting enough people, it'd win when the tactics necessary to stop it were beyond what the government and/or military were willing to do.

Guns are much more useful when:

1) the enemy is foreign (killing enough people actually _might_ make them go away), and/or

2) your position doesn't actually have popular support so other means are unavailable to you, and/or

3) foreign powers have the will and capacity to bomb the shit out of your country if the government goes too far in its attempts to suppress your uprising (this, or loss of military support for the government, are basically the only reasons authoritarian states fail to stop revolutions in the modern world)

<comment><USER11> >Sympathy from the armed forces and various forms of political pressure, foreign and domestic, would be far more helpful than a few deer rifles, and if you've got that your private arms aren't really necessary.

Actually, having closely studied the dissolution of a modern European country (the former Yugoslavia) and seen the fallout from up close, it's not that simple (at least not always).

What happened in that case was that although the Yugoslav government [1] retained control of most of the heavy weaponry (artillery, tanks), and although the succeeding republics (Croatia and Bosnia) were initially limited to small arms belonging to local militia and hunters, the republics _did_ have an abundance of active and retired officers with loyalty to their ethnic homelands who were quick to raise and lead battalions of troops into the field [2].

Those troops then went on to capture some heavy arms from the Yugoslav army, and scored lots of small arms, and eventually heavy arms and aircraft, from overseas allies.

Eventually, after lots of brutal warfare, ethnic cleansing, and in Bosnia, genocide, the republics did gain their independence from Yugoslavia (with significant help from the U.S. and other countries).

What was key in this case were the experienced military leaders who quickly assumed charge in the succeeding republics.

I suspect a worst-case, nightmare U.S. scenario would look much the same, with experienced military leaders taking control of ad hoc forces in their respective states and/or regions, and then fighting with small arms until they were able to capture heavy arms, receive outside help, or were defeated/captured.

1\. Essentially, Serbia and Montenegro, plus ethnic Serbs elsewhere

2\. Slovenia's succession was a different story than that of Bosnia and Croatia, for a variety of geographical, cultural, and historical reasons.

</comment></comment></comment></comment></comment></comment><comment><USER12> Scary title, but I think I'll mark this one up as a victory for auto safety. Especially considering a good chunk of death by firearms are (tragically) suicides.

<comment><USER13> As a European it seems blatantly obvious that your gun laws are absurd in the States. (I am assuming you are from the States from the fact you see the argument that way around, correct me if I am wrong).

<comment><USER14> Most of the perceived absurdity comes from disingenuous framing of the issues. Here are some examples:

Over half of all quoted gun deaths are suicides. [edit: removed mention of suicide survivability as I don't have a reference handy. But remember: The most likely person to shoot you is yourself.]

Let's remove suicide from the discussion and talk about violence. The primary driver for violence is socioeconomic. The US has a huge wealth and education disparity problem, exacerbated by a drug war which focuses primarily on the lower economic classes. Most political rhetoric surrounding gun violence focuses on denying lower-class individuals access to firearms and is inexorably linked to institutionalized racism [ cite: [http://en.wikipedia.org/wiki/Saturday_night_special#Economic...](http://en.wikipedia.org/wiki/Saturday_night_special#Economic_class_and_racial_inequality) ]

What these stats don't show is the EXTREME socioeconomic skew involved in violent crime. If we look at gun deaths by wealth quadrile we find that the upper 40% have very, very few gun deaths -- on par with the nicer areas in Europe. Our inflated gun death statistics come almost entirely from the lower 40%. That is, gun deaths are emblematic of America's class divide.

The right to self defense is a convenient target for politicians to score easy wins. Constructively addressing the USA's violence problem is a very different issue and frankly is almost entirely unrelated to firearm legislation.

<comment><USER4> > Let's remove suicide from the discussion and talk about violence.

Why? This is the second time I've seen that suggestion in these comments, and I don't understand why suicides should not be counted as gun deaths.

<comment><USER15> Because the fact that there is a very small chance that a person may kill themselves with a gun does not mean the government should deny that person the right to own a gun. And people with a history of mental illness are already excluded from owning guns.

<comment><USER16> This argument seems at odds with the claim that suicide constitutes the majority of the deaths.

<comment><USER15> How so?

<comment><USER4> I believe the point is that if the chance of suicide is very small, and the mentally ill are forbidden from owning guns, it would seemingly be at odds with the claim that "over half of all quoted gun deaths" are suicides.

<comment><USER15> I don't see the direct connection between the suicide risk of a single gun owner and the ratio of suicide to homicide in total gun deaths.

The claim regarding suicide vs homicide is easy to confirm ([https://en.wikipedia.org/wiki/Gun_violence_in_the_United_Sta...](https://en.wikipedia.org/wiki/Gun_violence_in_the_United_States)). It is not possible to predict every suicide, the best we can do is make an approximation using obvious risk factors like hospitalization for mental illness. There are millions of gun owners in the US, so yes the chance of a suicide is small.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Including suicides seems unfair.

> The U.S. Department of Justice reports that approximately 60% of all adult > firearm deaths are by suicide, 61% more than deaths by homicide. [1]

[1][http://en.wikipedia.org/wiki/Gun_violence_in_the_United_Stat...](http://en.wikipedia.org/wiki/Gun_violence_in_the_United_States#Suicides_involving_firearms)

<comment><USER18> Just making suicide slightly more difficult dramatically reduces suicide rates. It's difficult to stop someone determined to kill themselves, but most suicides are impulse decisions, so removing the opportunity often prevents the suicide. That's why suicide barriers on bridges actually reduce suicide rates rather than changing the method.

<comment><USER19> I agree with you generally… but in this specific case, do regions with very strong and effective gun control have dramatically lower suicide rates than the US? My understanding is that suicide rates in Europe aren't dramatically lower, though they do appear to be a bit lower in western europe and higher in eastern… I can't tell if this might be handgun related, is the delta large enough?

[http://en.wikipedia.org/wiki/List_of_countries_by_suicide_ra...](http://en.wikipedia.org/wiki/List_of_countries_by_suicide_rate)

I don't have any information on the suicide rates by gun in each country, though it would be useful information from a public health standpoint (especially if, as you pointed out, the accessibility could be reduced).

<comment><USER5> Just eyeballing, I see a handful of strongly liberal European countries above the US, and a bunch that are just below the US.

But this is a tough thing to compare, as you note. Suicide rate is encompassing a whole _bunch_ of things. I'm tempted to compare against Canada, where the suicide rate is only less by 1 per 100,000 people per year, but I have no idea if I'm picking that out fairly.

[http://www.who.int/bulletin/volumes/86/9/07-043489.pdf](http://www.who.int/bulletin/volumes/86/9/07-043489.pdf) suggests that the US is the only country where firearm is the preferred method of suicide. A bit morbid to read but there you go.

</comment></comment></comment></comment><comment><USER20> According to the CDC, homicides by discharge of firearm was at about 11,000 in 2011. Death by motor vehicle accident was 35,000.

By contrast, 53,000 die from the flu, 27,000 from falls, 36,000 from accidental poisoning, and 600,000 from heart disease.

Table 10: [http://www.cdc.gov/nchs/data/nvsr/nvsr63/nvsr63_03.pdf](http://www.cdc.gov/nchs/data/nvsr/nvsr63/nvsr63_03.pdf)

</comment><comment><USER21> It's important to note that, according to the chart, both are on the decline. Auto deaths are simply declining further.

Gun ownership is an important civil liberty in the USA, but one that comes with danger.

The Economist is recommending a technological approach to mitigating that danger. Research and development has been done in this department, and many technologies have been applied to modern firearms. Better safeties that prevent accidental discharge, better safes, ammunition that prevents over- penetration, etc.

We have yet to see a simple and trustworthy technology that limits who can fire a gun. When we do, it will start to be used.

For such a technology to work, the user needs to feel in complete control of it. There can be zero risk that an authorized user won't be able to fire the gun due to system failure or low battery.

Ultimately, though, no technological solution will prevent suicide. For that, a different approach will be necessary, and I don't have an answer for that.

<comment><USER22> >ammunition that prevents over-penetration

Ironically, many gun control advocates still argue against civilian ownership of ammunition that doesn't overpenetrate. In some California cities hollow point ammunition is illegal to buy. In New Jersey it is illegal to carry hollow point ammunition outside the home. The Brady Campaign still to this day calls hollow points "cop killer bullets" despite the fact that every law enforcement department in the country uses them.

</comment></comment><comment><USER23> For some perspective, check out the CDC's "Leading Causes of Death":

[http://www.cdc.gov/nchs/fastats/leading-causes-of- death.htm](http://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm)

</comment><comment><USER24> Ignoring the click-bait headline implying that guns have _become_ more dangerous than cars - what we actually see are that deaths from both have declined. Car deaths slightly more quickly than gun deaths.

I find that incredibly encouraging. Nothing about guns or gun ownership has changed dramatically in the United States over this period. Perhaps this signals that the bizarre, and often fetishized, culture of violence in the United States is on the wane. I hope so.

</comment><comment> slipstream- Google cache link to get around paywall: [https://webcache.googleusercontent.com/search?q=cache%3Ahttp...](https://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.economist.com%2Fnews%2Funited- states%2F21638140-gun-now-more-likely-kill-you-car-bangers-v- bullets&oq=cache%3Ahttp%3A%2F%2Fwww.economist.com%2Fnews%2Funited- states%2F21638140-gun-now-more-likely-kill-you-car-bangers-v- bullets&aqs=chrome..69i57j69i58.2239j0j7&sourceid=chrome&es_sm=122&ie=UTF-8&safe=active)

<comment><USER25> I understand that Hacker News is a sharing and discussion website and that it sucks not being able to read the submitted stories, but it seems people here are generally against paywalls and try to subvert them in any way possible. It also seems that many people here also subvert non-paywall sites that monetize their content using ads by installing various adblockers.

As a publisher myself, I'd be interested in hearing if there are any other ways to monetize my website and content other than paywalls and advertisements which people seem to dislike so much?

<comment><USER3> Sponsored posts, sponsored events, sponsored custom takeovers don't fall into ad blockers since they aren't being served by Akamai etc. If you're doing products, affiliate links from your posts.

<comment><USER5> "Don't sell your product; give it away and cram it with ads!"

<comment><USER25> I'm assuming this is snark, but print magazines actually do both by selling the magazines themselves and filling them with advertisements.

<comment><USER3> I read a lot of watch blogs, they do sweepstakes and brand reviews that I love to read. [http://www.ablogtowatch.com/watch-giveaway-tudor-heritage- ch...](http://www.ablogtowatch.com/watch-giveaway-tudor-heritage- chrono-70330n-truefacet/)

</comment></comment></comment></comment></comment></comment><comment><USER26> Comparing cause-of-death rates between automobiles and firearms is a lot like comparing the median number of miles traveled riding in a car versus carrying a gun.

Death is a possible unintended side effect of riding in an automobile. Death is the explicit primary purpose of discharging a gunpowder weapon.

Thus, this is far more laudable accomplishment for automotive safety than it is a deplorable statistic for gun owners. Cars now cause less deaths by accident than a consumer product that is actually designed to kill things when used correctly. Yay.

I don't ever have an absolute need to own or use a gun, but it is practically impossible to earn a profitable living without spending at least 40 minutes _per day_ driving in my car, or riding in any other form of on-road transportation.

I don't particularly feel like the jerkass riding on the hard shoulder at 50 mph to bypass a rush-hour jam is in any way comparable to someone who plinks beer bottles--the ones they just emptied--off their back fence without stopping to consider if there are neighbors living in that general direction. They could even be the same guy. If so, I meet him far more often on the road.

Neither guns nor cars kill without an operator--not yet, anyway. If I am now less at risk from an idiot behind a wheel than an idiot with his finger on the trigger, that is unequivocally good news, because I encounter far more of the former. But the article doesn't exactly break the statistics down by intent. I suspect that rates of deaths by gun due to accident or operator negligence are still less than deaths by vehicle due to accident or operator negligence.

So I still feel like guns are safer for me than the average person, because I don't particularly feel like anyone has an actual desire to kill me specifically, especially given my own disinclination toward suicide.

The article doesn't tell me anything meaningful. It seems to be presenting the statistics in a very narrowly interpreted way to advance a particular editorial point of view. The Economist might as well tell me how likely I am to die from falling off a ladder while cleaning my gutters, and compare that to deaths by food poisoning, except that there are far fewer passionate advocates for pasteurization and ladder stabilization bars.

<comment><USER27> > Death is the explicit primary purpose of discharging a gunpowder weapon.

That isn't true for any target rifle, target pistol, or shotgun intended to be used for skeet or trap.

<comment><USER26> While you make a true statement, it is a non sequitur from my argument.

</comment></comment></comment><comment><USER28> Statistics don't work that way. It's not an even distribution. For instance, I am not around gun violence at all, but I've seen and been involved in several serious car accidents. I live and work in areas nearly devoid of gun crime. My odds of being shot are vastly less than being injured or killed by an auto.

<comment><USER29> Good point. If you think about it, due to the distribution of guns and the fact that the majority of gun deaths are suicides, accidents, or domestic violence - living in a gun-free household should reduce your risk even more dramatically than these statistics might suggest.

<comment><USER5> About half of suicides are done via gun, and about half of households have access to a gun.

There's nothing "dramatic" about reducing your chance of dying via suicide by being in the second half. I don't want to say it's zero, because I'm sure someone's life is spared by not having a gun around when the urge to suicide pops up.

</comment></comment></comment><comment><USER30> Depending on your source of numbers, 40-60% of gun deaths are suicide and 30-60% are gang related. That at most leaves 0-30% "preventable" shootings. Gang member aren't going to use "smart guns" and I have the moral right to kill myself.

<comment><USER31> _" I should have the legal right to kill myself."_

And of course, even if someone disagrees with that, getting rid of the gun is more likely to change the method than the result.

<comment><USER32> I think the stats are that suicide by gun shows far more successful percentage than most other attempts. And I believe there's evidence that thwarted attempts often work out for the better. Essentially, if the only options for suicide fundamentally required a persistent decision over time to carry out rather than a spur-of-the-moment decision, there's an argument that it would be better for society and for suicidal people overall.

<comment><USER31> Note that I didn't say there wouldn't be any improvement.

The statistics do show guns more effective than, for instance, overdose. However:

1) it is still the case that the method is more likely to change than the result; and

2) it is likely that means is not assigned randomly, and those more intent on ending their life pick more lethal means - absent guns, some comparably lethal means remain readily available.

<comment><USER32> I'm really not an expert here, but I heard an argument that guns aren't chosen more in some sort of thought-out way like you describe. Instead, guns are there already, and get used by people who realize that there is a gun and they might even not make the attempt otherwise. Regarding suicide, I have much less concern about guns as a method than I do about _any_ sort of lethal tool being available on short notice instead of a situation that requires persistent determination and waiting.

</comment></comment></comment></comment></comment><comment><USER33> Good, finally people can stop trotting out the inane adage "if you ban guns you have to ban cars" whenever the gun control debate comes up.

<comment><USER15> Cars are not a good example because people need cars. But alcohol is a good example, nobody needs alcohol and plenty of innocent people die from drunk drivers. Yet most people consider alcohol "normal" and the idea of restricting it to home use only, for example, as absurd. But since these people didn't grow up with guns they consider them "abnormal" and see no problem with restricting them, since it doesn't affect them. This is why I think the conflict is mainly cultural.</comment></comment>


OpenSSL Security Advisories – LibreSSL Largely Unaffected - <AUTHOR> http://undeadly.org/cgi?action=article&sid=20150319145126

<comment><USER2> They didn't mention anywhere whether or not CVE-2015-0207 was patched, so I'm left to assume it's still vulnerable (but hopefully a patch is being written for it).

<comment><USER3> The patch for this issue is integrated in LibreSSL 2.1.6:

         * CVE-2015-0207 - Segmentation fault in DTLSv1_listen
             LibreSSL is not vulnerable, but the fix was safe to merge.

[http://marc.info/?l=openbsd- tech&m=142677928417277&w=2](http://marc.info/?l=openbsd- tech&m=142677928417277&w=2)

<comment><USER2> Oh, thank you very much.

Every day, LibreSSL looks more attractive. I should take the time to learn to compile PHP to hook into it instead of openssl.

</comment></comment></comment><comment><USER4> _> Log message: Fix several crash causing defects from OpenSSL._

Is there some reason they're obscuring the fact that these are security vulns? Trying to keep their 'street cred' intact? (undeadly.org even uses quotes around "crash-inducing" in their announcement, so it seems obvious this is unusual language)

<comment><USER5> Indeed. It will be embarrassing if the libreSSL turns out to be as buggy as its predcessor from the get go. Rewriting everything from a scratch does not necessary lead to better code unless methodologies change too. OpenBSD guys should open up their test suites (are there any) in order to gain credibility with their rewrite efforts.</comment></comment>


Ask HN: What RSS readers do Emacs/Vi users use? - <AUTHOR> I'm curious what the Emacs/Vi community uses for reading RSS content.<p>Do you use Emacs/Vi-specific plugins for this? Feedly? Tiny Tiny RSS? <comment><USER2> For a while I used to TinyTinyRSS [1] (web gui) and Newsbeuter [2] (cli) but switched recently on FreshRSS [3] hosted on a free Openshift gear.

I never used Vim plugins to read my fresh news.

[1] [https://tt-rss.org/gitlab/fox/tt-rss/wikis/home](https://tt- rss.org/gitlab/fox/tt-rss/wikis/home)

[2] [http://newsbeuter.org/](http://newsbeuter.org/)

[3] [https://freshrss.org/](https://freshrss.org/)

</comment><comment><USER3> I use TTRSS (TinyTinyRSS)

Never tried using a plugin to read my RSS - I feel it would over-complicate most of what I use my RSS reader for.

It's a web gui, so I can use it at any browser I suppose if you're stuck in a terminal you could use the plugin to read it though.

</comment><comment><USER4> I use an rss reader on my phone only. I use emacs for other stuff, except for work projects, for which I use Eclipse, and personal projects, for which I use Xcode.

<comment><AUTHOR> You don't use an RSS reader on your laptop/desktop?</comment></comment>


D.H. Lawrence's stunning, indefensible essays - <AUTHOR> https://www.bookforum.com/print/2604/d-h-lawrence-s-stunning-indefensible-essays-23766 <comment><USER2> I'd wish that not every other article I read these days feels the need to focus on detecting misogyny or racism. It is absolutely important to identify the ways in which outdated world views led to injustices and move towards a brighter future but there's a fatigue setting in with it taking center stage in every discussion. Particularly troubling is the tendency towards wanting to separate the art from the artist whenever the artist held problematic views. It's a result of a cognitive dissonance setting in when you can see value or beauty in someone's work but don't agree with some aspects of that person. But the person behind the work is an integral part of it and vice-versa. If you hold someone's output in high regard but find objectionable fragments in it or in their life story you can't just go dissecting it into those pieces you wish to keep and discard the rest. I guess what irks me is the classification of Lawrence's essays as "indefensible". A view can be troublesome, even reprehensible, but to deny it representation by calling it indefensible is setting up a dangerous precedent where anyone can be silenced or their opinions simply cherry-picked to find what fits our desires. And that's no different than the biases that are railed against.

</comment><comment><USER3> > I love how it is broad and indefensible and could never be written today.

Why not? Paralysed by fear sounds perfectly apposite for the current political situation in both countries.

</comment><comment><USER4> It's a long read, but worth it if you've ever wondered why you never got into Lawrence.

<comment><USER5> This quote in the article jumped out at me:

"Life is more vivid in me than in the Mexican who drives the wagon for me,"

That's an awful thing to say, in more ways than one.

<comment><USER6> This always brings me the thought that how many highly/naturally intelligent/skilled people never get a chance to shine because they are born in the wrong part of the world or wrong side of the poverty line :-(

</comment></comment></comment><comment><USER7> If you've never seen a goat's 'glands' (skin tags) you've led a pretty sheltered life imo</comment>


Analyst: Apple May Announce iPhone 4G on Verizon, iPhone OS 4.0 - <AUTHOR> http://digitaldaily.allthingsd.com/20100120/iphone4g-verizon/

<comment><USER2> It seems like 'analysts' are pulling this shit out of a hat or making shit up as they go along. Obviously they have no idea of what's going on and you can't make money without saying something.

Must be wonderful to have a job where you can phone it in.

</comment><comment><USER3> So tired of all this constant iWhatever speculation.

<comment><USER4> it is getting a little old, isn't it?

seems fairly inevitable, though. with the release of the iphone, apple shook the mobile phone business down to its very core. it's hard not to wonder if they are about to do it again.

</comment></comment><comment><USER5> Too bad there's no such thing as 4G.

<comment><USER6> 4th Generation.

1st - iPhone/Jesus phone

2nd - iPhone 3G

3rd - iPhone 3GS

4th - Speculation!

</comment></comment><comment><USER7> If Verizon is really going to deploy LTE that much faster than all of the other carriers, I find this possible. Does anyone know how many cities are supposed to have Verizon LTE by the end of 2010?

</comment><comment><USER8> If someone suggests that Apple is going to put CDMA and GSM in the same phone, or even that they'd have two versions, I think you can safely disregard everything else they say.</comment>


How GitLab uses Unicorn and unicorn-worker-killer - <AUTHOR> https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/

<comment><AUTHOR> GitLab engineer here. Let us know if you have any questions or comments.</comment>


Massive Update To Retyped - <AUTHOR> https://blog.bridge.net/massive-update-to-retyped-91248454e72e <comment><USER2> (Retyped is part of the Bridge.NET C# -> JS/TypeScript converter)

It's super exciting too see Bridge maintaining its place in a world that includes both C# -> WebAsm and mature TypeScript ecosystems.

I'd started to wonder if Bridge still had a role to play now that those two ecosystems are maturing, but I think the marshalling cost between WebAsm and JS/Dom is likely to discourage full WebAsm implementations in many cases, and if it does the ability to do seamless code sharing between frontend TypeScript and backend C# is pretty killer.

<comment><USER3> Have you seen '[https://github.com/aspnet/blazor'](https://github.com/aspnet/blazor')? Looks (very) promising. I haven't used Retyped myself, but from the looks of it Blazor does more or less the same thing but maybe better?

<comment><USER2> Blazor is an example of C# -> WebAssembly tech, which is related to but different from ReTyped's C# -> TypeScript tech. It's easy to take a quick look and conclude compiling to WebAssembly must be better than compiling to TypeScript, but it's far from clear that's always the case at this point. WebAssembly runs faster than vanilla JS when you are inside the WebAssembly stack but there are costs to cross back and forth between WebAssembly and the Dom/vanilla JS and there are also non-trivial memory management issues with WebAssembly. The memory management situation will hopefully be fixed a few browser versions from now. It's less clear whether there is a good fix for the WebAsm <-> JS marshalling cost coming in the near future.

<comment><AUTHOR> Take a look at the following thread about WASM performance, might be interesting to you: [https://www.reddit.com/r/csharp/comments/8gjx3v/a_small_perf...](https://www.reddit.com/r/csharp/comments/8gjx3v/a_small_performance_comparison_of_monowasmblazor/)

Benchmark results for Bridge.NET are provided here: [https://github.com/stefan- schweiger/dotWasmBenchmark](https://github.com/stefan- schweiger/dotWasmBenchmark)</comment></comment></comment></comment>


Instagram Reversal Doesn't Appease Everyone - <AUTHOR> http://www.nytimes.com/2012/12/22/technology/instagram-reversal-doesnt-appease-everyone.html

<comment><USER2> The new (and revised) TOS is not the same as the current TOS. Referring to it as a reversal is inaccurate.

Instagram may have dropped certain language but the upcoming TOS claims the right to transferable licenses and sub-licensing, wording not in the current TOS.</comment>


Project Jigsaw: Complete - <AUTHOR> https://mreinhold.org/blog/jigsaw-complete <comment><USER2> I don't follow Java too closely and the world "module" is so hopelessly generic that I had a hard time understanding what the article was talking about. It links to this document [1] though, which is a long read, but does an excellent job of describing of describing all the ins and outs of the module system.

(tl;dr Packages can now declare themselves as modules instead of simple namespaces, and they get to choose exactly what they export and what other modules they require. Projects can now resolve their types from within modules with a _module path_ instead of on a per-type basis from the class path. It's a huge step forward for Java modularity and dependency management.)

I have a hard time being _too_ impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust), but acknowledge just how monumental of an effort it was to design the new system and then build it into Java's core in a way that's mostly backwards-compatible. Java's going to be around for a long time, and this is a big long-term gain for the ecosystem.

I'd _really_ love to see languages like Ruby tackle this next. It's sorely needed.

\---

[1] [http://openjdk.java.net/projects/jigsaw/spec/sotms/](http://openjdk.java.net/projects/jigsaw/spec/sotms/)

<comment><USER3> > I have a hard time being too impressed because more modern languages are > doing this out of the gates and with far fewer hacks

Well of course - it's easier to build something like this into a clean-slate language isn't it? It's harder to build it into an existing language and VM spec with an incomprehensibly large volume of existing code to be compatible with. It's backwards to say it's not impressive because someone else with zero constraints to work with also managed it.

<comment><USER2> > _Well of course - it 's easier to build something like this into a clean- > slate language isn't it? It's harder to build it into an existing language > and VM spec with an incomprehensibly large volume of existing code to be > compatible with. It's bizarre to say it's not impressive because someone > else with zero constraints to work with also managed it._

I hope my original comment was relatively clear on this, but sure, it's a big accomplishment and will be a quantum leap for the ecosystem. However, given that languages elsewhere have had better systems for quite some time now, it's not like they're advancing the state of the art in dependency management.

But again, it wasn't an easy thing to do (a very hard thing even) and everyone involved deserves major felicitation.

<comment><USER4> I guess the real question is, why do you find advancing the state of the art to be more impressive or deserving of acclaim than integrating improvements to existing systems?

Both activities seem valuable and complementary to me -- there's no point in advancing the frontier if nobody will bother to make those advances practically useful.

</comment></comment></comment></comment><comment><USER5> I think it's going to take me a while to learn about the module system in Java 9, I'm probably going to bank on watching other projects do it first to see if any best practises emerge as developers get used to the new way of working.

One thing I will say though is Java 9 has had a definite improvement on Java applications that run on my Raspberry Pi 3, I think because this got included [http://openjdk.java.net/jeps/297](http://openjdk.java.net/jeps/297)

One application used to take 55s to start up, now it takes around 15s!

<comment><USER6> > _15s_

Still sounds ridiculous. Assuming this is how much time it takes to initialize the VM, I wonder if it would be possible to have a pool of VM processes that are already running and ready to accept an application code.

<comment><USER5> It's a spring boot application so comes with the baggage of initialising Spring + Spring MVC, that took a long time on JRE 8

<comment><USER7> I don't know if it's still a problem with Spring, but at a previous job about 8 years ago I was able to cut our application's start time from about 80 seconds to ~12 by writing a custom implementation of the logic that Spring used to find bridge methods to determine the proper annotations. We profiled the startup and found that over 80% of the time was being spent in reflection to resolve those bridge methods and that could be done significantly faster by using asm to load the classfile bytes and resolve the bridge method by looking directly at the invokevirtual call. Spring avoided this approach because it could fail in situations where the SecurityManager prevented filesystem access.

I don't know if that's still the case, but it always bugged me that Spring would slow down the >99% case by so much just to accommodate the <1% case.

<comment><USER8> Dave Syer looked at this topic recently[0]. Most of the time spent in loading isn't due to reflection or annotation processing: it's proportional to the number of classes loaded.

That said, Spring is fairly enthusiastic about pulling stuff. As he says:

> _Since more beans mean more features, you are paying at startup for actual > functionality, so in some ways it should be an acceptable cost. On the other > hand, there might be features that you end up never using, or don't use > until later and you would be willing to defer the cost. Spring doesn't allow > you to do that easily. It has some features that might defer the cost of > creating beans, but that might not even help if the bean definitions still > have to be created and most of the cost is actually to do with loading and > parsing classes._

I imagine that they'll keep poking at it, especially since they're working on Spring Cloud Function[1], where cold starts for single invocations are common.

[0] [https://github.com/dsyer/spring-boot-startup- bench/tree/mast...](https://github.com/dsyer/spring-boot-startup- bench/tree/master/static)

[1] [http://cloud.spring.io/spring-cloud- function/](http://cloud.spring.io/spring-cloud-function/)

<comment> semi-extrinsic > most of the cost is actually to do with loading and parsing classes

It boggles my mind that loading and parsing even a few thousand classes is something that a human can perceive as "dog slow" when carried out by a quad- core 1.2 GHz CPU.

<comment><USER8> My understanding is that it's I/O bound, that the JVM more or less fetches each class from the JAR file or disk individually.

I am not sure if that's an implementation decision or whether it's imposed by the JVM specification. At some point I want to tinker with OpenJ9 to find out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I think its very exciting they were able to get the number of discrete modules up to 26. That's extremely impressive to me given the age and complexity of Java! I went to a talk a few years back from one of the contributors to this project (forget the name, sorry!) and I think if my memory serves me they had significantly fewer discrete modules at that time -- perhaps 6?

Anyhow, I think this is a great step forward for Java.

</comment><comment><USER10> Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.

Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.

<comment><USER11> > Jigsaw was what held up the Java 9 released, due to some members rejecting > the proposal.

That was only a few weeks. If you check the official release schedule [http://openjdk.java.net/projects/jdk9/](http://openjdk.java.net/projects/jdk9/) Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule.

> It was changed and revoted upon, but it's hard to follow what was modified > to make it acceptable.

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18)

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-22)

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-23)

Not much really. Basically Oracle called their bluff. At that point is was really too late as Jigsaw was already merged to master and more or less touched every part of the JDK.

> Is there anywhere the design goals and constraints for modules are? I'd > really like to know how they ended up in their current form.

Not really, it was really just Oracle making things up as they went. For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different. For example they have no good explanation while they mashed the module declaration into a .class file, basically everybody except Oracle thinks it's a bad idea but the just went with it anyway. They claim "reliable configuration" as a goal but without versioning that's meaningless.

<comment><USER12> > They claim "reliable configuration" as a goal but without versioning that's > meaningless.

Versioning is not currently _built into_ Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.

> For the past ten years Mark Reinhold would give talks at Java conferences > what the module system comping in the next Java version was supposed to do > and every year the content was different.

Plus the entire development was done in the open, in an open source project with an active mailing list and frequent prototypes.

<comment><USER11> > Versioning is not currently built into Jigsaw, but Jigsaw provides all the > building blocks necessary to support it in third-party tools.

If I need third-party tools to validate my dependency graph at compile time and at runtime to ensure "reliable configuration" then why do I need Jigsaw at all? That's the current state of affairs with Java already, Jigsaw provides no value.

> Plus the entire development was done in the open, in an open source project > with an active mailing list

Ostensibly. There is a difference between having an open mailing list (where people could give feedback and get a superficial thank you before getting ignored) and a readonly repository and actual open development. Quite frankly I find it telling that in 2017 we have to stress that there was and open mailing list and readonly repository. The most important thing, the decision process, was completely intransparent and all Oracle/Sun internal.

> and frequent prototypes.

Which weren't useful because none of the frameworks, libraries and tools would support it.

<comment><USER12> > Jigsaw provides no value.

I think you should read more about Jigsaw.

> I find it telling that in 2017 we have to stress that there was and open > mailing list and readonly repository.

We don't need to _stress_ it, just to correct an incorrect report.

> The most important thing, the decision process, was completely intransparent > and all Oracle/Sun internal.

This is simply not true, as a quick look at the mailing-list archive would show, as well as from the fact that the project took 9 years.

> Which weren't useful because none of the frameworks, libraries and tools > would support it.

They were welcome to support them. I'm not sure what it is that you want, exactly.

</comment></comment></comment></comment></comment><comment><USER13> I'm still not sure of the practical benefits? Seems to be purely for IOT and nothing else. Am I correct?

Edit: To add to my question, jar hell was solved by tooling which generates your classpath for you. So it hasn't been an issue for me in years. And they refused to add versioning, so you still need to use those tools. Strong encapsulation just means they disabled reflection access to non public members, which I consider a regression on functionality. Either way, not a particularly useful feature to me, in fact it breaks some of my code. So I'm left with being able to have small JVMs which don't bundle the full standard lib, which seems to be mostly of use for memory constrained environments like IOT. But I'm actually hopeful there's some bigger practical benefits I'm not thinking of, so I'd love to hear from people who know more about jigsaw.

<comment><USER14> Encapsulation is another one.

Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.

If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.

This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.

<comment><USER15> .NET does have the module level directive "InternalsVisibleTo" that declares another assembly as a friend assembly that can use internal API's from the first assembly. So if you have e.g MyLib.Core and then two impls on top say MyLib.Windows and MyLib.OSX, where everyone would only use one of the impl libs but always the core lib (which is why it was split - then you could make internal API in the core lib visible ONLY to the Windows/OSX libs by using InternalsVisibleTo, and users of the library could not see that internal API.

<comment><USER14> Yep, that is what I meant by mentioning .NET in "This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept."

<comment><USER15> Right. Thought you meant "the file/assembly is the module, no way around it" was the concept.

</comment></comment></comment></comment></comment><comment><USER16> In the organization I work for, we're contemplating a move from Oracle JDK to OpenJDK, when we move from 8 to 9. I'm still nervous about OpenJDK from some historical scary stories of things not working well in OpenJDK or at least different. I've not found much on the subject, or even on OpenJDK as a functioning open source project. (Or is it just a code drop of the Oracle JDK?) If anyone has good insights, or links to some realistic comparisons, I'd be thrilled.

<comment><USER17> Note: Oracle is my employer, the following statements are my own — (insert Safe Harbor notification)

Good news regarding any trepidation on the differencesa between the runtimes — recently we announced that there will no longer be a difference between OpenJDK and OracleJDK [1]

To quote: "The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)"

[1] [https://blogs.oracle.com/java-platform-group/faster-and- easi...](https://blogs.oracle.com/java-platform-group/faster-and-easier-use- and-redistribution-of-java-se)

</comment></comment><comment><USER18> I think this is for people that had issues w/ 'jar hell'. I did not.

<comment><USER19> The biggest pain for me was that it felt like there was no good way to create a library with some internal structure in the form of packages without exposing parts of your internal implementation as public.

When Jigsaw was delayed I was playing with the idea to create a project called shitty-jigsaw, which would just merge all of the packages in a module and change the access modifiers to be more restrictive according to some module definition.

<comment><USER16> Would shading have done the job? Not to say that's a _good way_, but it _is_ a way.

<comment><USER19> Sure you can use shading to move everything you don't want in your public API into some other package, or you can use something like ProGuard to obfuscate everything but your intentional public API. However those things will still be public.

The only way to not have those things visible for the user of your library is to only use one package in your implementation.

</comment></comment></comment></comment><comment><USER20> Does it have any positive impact on startup time for simple programs if you are not loading large chunks of the JVM?

<comment><USER21> yes. especially since in the future you can actually compile modules as libraries and aot load them. at the moment this is experimental and should probably only work for java.base

</comment></comment><comment><USER22> Will this resolve the slow start problem in serverless apps?

<comment><USER23> It's a step. Still 10x slower start I suspect compared to node, but much better "warm" performance.

<comment><USER11> Nope, it makes things (a little bit) worse because now you also have to start up a module system.

<comment><USER24> > start up a module system

i thought jigsaw was about compilation artifacts. are you saying there are is a (nontrivial) runtime component? what does it do?

<comment><USER11> > i thought jigsaw was about compilation artifacts.

Nope, jigsaw doesn't affect compilation artifacts other than an additional module-info.class present in a .jar file.

There is an intentionally completely unspecified, Oracle/OpenJDK proprietary extension (yes) called jlink that generates different artifacts. The aritfacts are unspecified, only work with Oracle/OpenJDK, and the licensing restrictions for redistribution are unclear.

> are you saying there are is a (nontrivial) runtime component? what does it > do?

1\. module definitions have to be parsed into memory structures to build a runtime model of the module system

2\. the runtime model built in 1. has to be validated

3\. every access has to be checked if it is permitted by the module system based on the information from 1.. If it is not permitted a decision has to be taken what should be done, this can include figuring out whether it is the first such access which needs additional memory structures (this is the default). See [1] for more information.

Probably some additional things that I forgot about.

[1] [http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-June/...](http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-June/012841.html)

</comment></comment></comment></comment></comment><comment><USER25> I remember this from... 11 or so years ago, i think. I was making some Java applet based game and the slow startup time and big JVM download was something that an issue among people making such games (which by the time i was into were dying - although they'd soon get a short lived shot in the arm thanks to Minecraft, but that was later). There were some posts in javagaming.org forums from some people who were talking with Sun (that was before Oracle - Sun at the time was actually interested into uses of Java in gaming and talked with devs, including from smaller/indie developers) about a new improvement for the VM to modularize the packages so that only things that are required would be loaded (faster startup) and the default JVM download would be much smaller (sort of comparable to Flash) which was a big issue at the time for those making web-based games (that niche for Java games would soon die with the introduction of Flash Player 9 and ActionScript 3, although it took a bit for people to actually upgrade).

I remember it was released at some point, but at the end it didn't amount to much since most of the JVM's actual implementation relied on everything else and the "optional" bits were only a small part, so it didn't help almost at all with applets. And by that time Java applet gaming was dead (it never reached Flash gaming's heights, but for a few years in the early/mid 2000s it was still something you could make a living off - if you didn't expect much).

I never heard about it much after that and personally moved away from Java with Flash becoming dominant on the web game scene and soon with Oracle being an dick to everyone. The only reason i used Java was for NetBeans' GUI editor for my tools but with Lazarus [0] becoming very stable by that time and NetBeans looking and behaving weird in my -then- brand new iMac, i abandoned Java for good (the only active Java project i still have is a tilemap editor [1] but this only if you stretch "active" to "hack on it a little every few years").

I also never liked Java much after Java 1.4 - it moved further away from its "simple language" roots and i liked how everything was solved in the library instead of adding extra stuff to the language. Well, that, and things like generics felt very "bolted on" while annotations like `@override` felt unnecessary verbosity (and ugly syntax-wise).

My favorite Java was probably around 1.1 or so (i have a book on that too), some times i think i should make a new language and VM after it but i lose interest quickly - i think i have a bunch of parsers for Java-1.1-like languages lying around in my backups, from every time i get that urge :-P.

[0] [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/) [1] [http://runtimeterror.com/rep/mapas](http://runtimeterror.com/rep/mapas)

<comment><USER14> That was the Kernel VM project.

[http://www.oracle.com/technetwork/java/javase/kernel-135055....](http://www.oracle.com/technetwork/java/javase/kernel-135055.html)

[http://openjdk.java.net/jeps/148](http://openjdk.java.net/jeps/148)</comment></comment>


I Love Walled Gardens, by Rory Marinich - <AUTHOR> http://www.rinich.com/post/358597818/i-love-walled-gardens <comment><USER2> I like what you have said here, however I have another analogy that describes the part I disagree with.

The iPad is a 4 star restaurant, my linux box is my kitchen. I like 4 star resturants and they are not evil (unless they have a 90% monopoly on the market [and the food is crappy (Microsoft circa 2001)] [Apple might do this to in which case they are evil for being a monopoly not for being closed]). They are closed. I can't go into the kitchen and make food. But I can be inspired by the food I enjoy there.

The idea of teaching children to learn to program using iPad apps is some what intriging, however, I would compare it to <http://dreamdinners.com/main.php?static=index> its not the same as buying a cook book and being in your own kitchen. Or going to culinary school.

So yes we will see people using the iPad to learn to program , possibly, but I think there will always be those who prefer to learn on an open platforms.

ps. I think you might like this graph :) <http://chris.smeder.com/essays/3_stevejobs.htm>

<comment><USER3> That's a very apt analogy. I've got nothing against kitchens, but I think it would be nice if there were cheap gourmet lessons out there also. (My analogy is much worse than yours.)

</comment></comment><comment><USER4> > We lose nothing by having closed systems.

For good or for bad, for the past 25 years or so, programmers have effectively been subsidized in that the tools to design and create programs are effectively the same as the tools to _run_ programs.

So every system, simply by installing a compiler, is ready to write computer programs.

Early computers didn't even have that step. They had assemblers and basic in the ROM. It was assumed that you were going to be writing programs; how else were you going to get computers to do what you want?

The iPad/iPhone is the latest and greatest step in that huge gap. A little uneasy, for some of us, perhaps, who grew up with QBASIC on-device-coding and can't imagine any other way.

But that is sort of a straw-man issue. You have to buy a real computer, so what? There's a closely-related, but way-more-troubling problem.

App review.

App review is painful. I've had two apps axed by Apple not for bugs or for security issues, but because, quite simply, Apple didn't like them (technically I had 3 such rejections; one was "reversed" on "appeal").

Think this doesn't affect you? It does. Google Voice found out the hard way. It was easier for them to rewrite their app in HTML5 then to talk Apple into letting it on the app store. Same goes for Google Navigation, that will never see the light of day.

For every app that you hear about, there are hundreds (I suspect more like thousands) of developers who had an app rejected and quietly went away.

That's the danger in these new devices. Not that you need a computer to develop for them. Not that the apps are sandboxed and you can't animate your icons or you require some ridiculous API nobody should ever need.

The problem is that Apple can--and, in fact, does--reject well-behaved applications that it simply doesn't like. Not just the buggy ones. Not just the malicious ones.

That's a thought that should chill every developer to the bone.

</comment><comment><USER4> > It is not productive to spend an hour learning how to change the font on > your computer's clock.

Fair point. But is it better than not being able to change the font at all?

That's the Apple alternative. To have an idea in your head and _not be able_ to implement.

Not because it's too hard. Because somebody simply doesn't want you to.

<comment><USER3> The argument I put forward (and I completely respect people that disagree with it) is that yes, it's okay to let somebody else control the clock font, because the clock font doesn't matter. I'd rather not have the choice to change it, because I've got twitchy fingers and am terribly good at procrastination.

<comment><USER4> Sure, the clock font doesn't matter. But the limiting form of the formula ("It's OK to let someone else control X because X doesn't matter") for lots of values of X is a recipe for total disaster.

We're watching this play out right now with Letters ([http://arstechnica.com/apple/news/2010/01/rage-against- the-m...](http://arstechnica.com/apple/news/2010/01/rage-against-the-mail- machine-the-genesis-of-letters.ars)) because apparently Apple Mail.app isn't good enough for power-emailers.

Nobody expects Letters to become the new default OSX Mail client. Rather, it will probably be a successful niche app for power users.

An app like Letters would never see the light of day on the iPhone because it "duplicates system functionality." Mail is good enough, so the logic goes.

<comment><USER5> But the iPad is not for powerusers. It is marketed to the general user. And for the average user, good enough is good enough.

<comment><USER6> But us power users want the nice hardware too ?

Why should we have to have the horrible experience... I don't think it's asking to have our cake and eat it, to be able to play with the toys we've bought?

Should all developers just stick to linux and windows ? - Your walled garden will be a much duller place for it.

</comment></comment></comment></comment></comment><comment><USER7> This is the first blog post (or article or anything) which perfectly captured my own feelings on the subject of the iPad. Thanks to Rory Marinich for writing it. Great piece.

I had been dragging my feet about writing down my own thoughts, felt it both necessary and unappealing. But thanks to Rory, I have another option. I'll do what hackers (or in my case, aspiring hackers) do when they find what somebody else has which both a) accomplishes what they would've/intended to accomplish and b) accomplishes it in a superior manner: forget about mine and just use theirs.

I'mma link to this here post all over the fuckin' place.

</comment><comment><USER8> Using the iPoad for programming could be tricky; there is an explicit policy disallowing user-accessible runtimes.

<comment><USER3> I know; I was informed of that after I wrote it. Shame. Web-accessible runtimes are still a possibility, but certainly that's not as cut-and-dry as having one in the App Store would be.</comment></comment>


Reflections from smartphone transmissions enable gesture control - <AUTHOR> http://www.microwave-eetimes.com/en/reflections-from-smartphone-transmissions-enable-gesture-control.html?cmp_id=7&news_id=222905355

<comment><USER2> interesting - just got a pointer to this gesture arduino shield this morning [https://www.tindie.com/products/ootsidebox/3dpad- touchless-g...](https://www.tindie.com/products/ootsidebox/3dpad-touchless- gesture-controller-arduino-shield/)</comment>


In Silicon Valley, a new emphasis on barriers to government requests for data - <AUTHOR> https://www.washingtonpost.com/news/the-switch/wp/2016/05/24/what-is-driving-silicon-valley-to-become-radicalized/ <comment><USER2> And yet, through all of this, it's still easier and takes less time for them to violate our privacy rights than it is for private citizens gather similar data about elected officials and information regarded as "public".

I've been trying to get Chicago's mayor's office's phone records for a while now. 1.5 years, 4 FOIAs to two different city departments, state's attorney FOIA request for review, redactions left and right, a fight for AG anonymity, and a lawsuit later, I got a list of phone numbers and created [0].

The amount of pushback and bad interpretation of FOIA that prevented me, or anyone else, in getting that data was _shameful_. And after all of that, the judge didn't give me the FOIA suit payout since the city eventually "complied".

It's no wonder nobody actually tries to make positive change - it's just so damn hard.

[0] [https://docs.google.com/spreadsheets/d/1hgG79eIr8MbkjYrCvcTR...](https://docs.google.com/spreadsheets/d/1hgG79eIr8MbkjYrCvcTRN8n876KL8aXYYu5it8Lg0g8/edit#gid=0)

edit: cleaned up a wee. Also, that link's for the whole office suite, not just the room the mayor calls his office. Please don't try to come to any direct conclusions.

<comment><USER3> Wow nice work. I'm glad you persevered. What they finally gave you is hilarious.

The first design feature of the panopticon is that any inmate can be seen by the guards at any time without his knowledge. The second equally important design feature is that the inmate can _never_ see the guard, can never see what he's up to or who he is looking at. Or even if he's around.

In the present context this manifests itself in the above hilarious obstructionism against FOIA and open government, and more ominously in Obama's war against whistle blowers.

<comment><USER2> Thanks :). What's absurd is that they released (redacted) numbers for phones outside of government, but claimed that even redacted government phones were exempt from release. Because of privacy reasons, and because they'd be interrupted at home. So, they essentially gave themselves FOIA privacy while giving strangers information on strangers.

The judge eventually just told them to just Google the phone numbers as a check if they're public numbers. They followed with other checks, and a longish list of numbers was the result. There was one government phone redacted, but we got the name of the person a bit later, with just a name, no number.

</comment></comment></comment><comment><USER4> Stewart Baker's quote from the article is so disingenuous: _"This is a Silicon Valley delusion that the government wants to outlaw encryption,"_

If you replace "encryption" with "secure encryption", that's absolutely what's being proposed.

</comment><comment><USER5> Can we please stop calling these demands 'requests'? "n. the act of asking for something to be given or done, especially as a favor or courtesy; solicitation or petition". The connotation is really misleading.

I've held my tongue about this through dozens of stories, and I won't harp on it again, but after the third time in this article I'm sort of snapping.

</comment><comment><USER6> A factor that I feel is more important but was sort of glossed over during the article is the fact that it is a competitive disadvantage NOT to do this.

The average person is becoming increasingly security conscious, and so are small and medium sized businesses. I seem to remember that Azure was having a really hard time selling to an international audience because foreigners thought the data would be vulnerable in the hands of the US government.

As someone who doesn't live in the US and works in consulting the few years post Snowden were quite curious, with clients who previously didn't mind using cloud solutions like Amazon S3 actively refusing any architecture choices which would lead to having their data stored in the US, even if it meant greater expense.

I really do believe that not taking an approach similar to this where we use End to End encryption and companies minimise their access over their customers data as much as humanly possible can and does lead to lost business.

<comment><USER7> This is one of the advantages to my employer's cloud product - you can architect your servers and networks entirely outside of the US. Choose only European datacenters, and your data stays in Europe. By the exact same token, if you have a requirement to keep your data in the USA, you can easily design your networks and services to comply.

</comment></comment><comment><USER8> > _Investigators say two such services, WhatsApp and Telegram, were used by > terrorists in the Paris attacks last November_

I thought they communicated using burner phones and _not_ encryption [1].

[1] [http://arstechnica.com/tech-policy/2016/03/paris- terrorist-a...](http://arstechnica.com/tech-policy/2016/03/paris-terrorist- attacks-burner-phones-not-encryption/)

<comment><USER9> It hardly matters. These liars are going to find _some_ tenuous link between terrarism and the encryptions and scream about it at the top of their lungs.

ps -- remember the san bernardino attacks? The attackers destroyed their personal cells and left a work cell behind. It's pretty obvious there never was anything on it. And had the fbi found anything germane, they would have trumpeted it.

</comment></comment><comment><USER10> When the German Verfassungsgericht (our equivalent of the US Supreme Court, I guess) struck down the data retention law on phone/Internet metadata, there was a sentence in the verdict that was just priceless - "Wo ein Trog ist, da kommen die Schweine" (Where there is a trough, the pigs will come).[1]

If more services start to avoid storing data altogether (or at least only encrypted in a way that prevents them from accessing the data), there will be less food so to speak for the various creatures that might gravitate towards the trough.

[1] NB that the choice of words is not mine - the irony of a supreme court judge calling law enforcement and intelligence agencies pigs is kind of nice, though. ;-)

<comment><USER11> When it comes to data privacy and security, it's hard to find a more saavy people than the Germans. I wish we had a chaos computer club out in America.

<comment><USER12> Not necessarily the same thing, but NoiseBridge is a pretty nice hackerspace and it's in SF.

<comment><USER11> Some hackerspaces are nice. Their goals are different most of the time and unfortunately they aren't as well respected in government.

Worst part is that I currently live in Texas, and not the cool parts :p

</comment></comment></comment></comment><comment><USER13> _> "They are afraid of a phone call from someone high up saying that they are unpatriotic," Baylor said._

Looks like McCarthyism is alive and well in the United States.

<comment><USER14> Trump will bring a new level of fear to non-WASPs. A true authoritarian. I really hope he does _not_ receive the presidency.

</comment></comment><comment><USER15> The article's actual title is much more inflammatory:

      What's driving Silicon Valley to become 'radicalized'

</comment><comment><USER16> An effective barrier is making it IMPOSSIBLE for a government request for data to be fulfilled - such as end-to-end encryption where the intermediary never has the key, like Whatsapp has done. This is easiest if implemented into a new system from the beginning design of its architecture.

It completely removes the need to waste person-hours attempting to fulfill a "wiretrap" request, whether from a warrant or FISA-court type thing, if the request is impossible due to lack of crypto keys. And at least at present completely legal unless the US passes laws outlawing crypto.

<comment><USER17> Essentially what Apple is going for with iOS. I honestly doubt they will allow them to do that for long. There's going to be a rematch eventually.

<comment><USER18> What can be done? Building a new open-sourced layer on top of the current internet, from scratch, that's impervious to snooping and censorship by design?

There are precedents for that kind of thing here and there already, in Bittorrent, Bitcoin, Ethereum, Freenet, TOR... and as [1] said, SMTP.

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

<comment><USER16> TLS1.2 for SMTP end-to-end is obviously a good thing, but it has its own problems aside from all of the crap we've been piling on top of SMTP for 20+ years (SPF, DKIM, DMARC, TLS1.2, etc) for ISP mail server operational reasons.

At some point that mail has to go into storage somewhere so it can be accessed by a user/client via IMAP, and that's where the subpoena/national security letter/warrant/FISA court request will go. To whatever location the disk storage resides at.

</comment></comment></comment></comment><comment><USER19> There is a guy in Florida who is championing for more open government. The number of FOIA requests and lawsuits he has brought and won is pretty interesting. His work in general is very interesting and he is currently working on a pretty cool database idea for the state of Florida. His website is:

[http://fogwatch.org/](http://fogwatch.org/)

His name is Joel Chandler and he lives in Lakeland, FL. You can Google him for more details on some of the requests he has made and lawsuits he has filed to get information.

</comment><comment><USER20> FTA: _The trade-offs can be significant: Heavy encryption risks slowing down your service._

"Heavy" encryption? Srsly?

</comment><comment><USER21> I hope the government realizes that their aggressive requests is leading to lost business overseas.

Companies are merely doing what they need to, to be relevant outside the US

</comment><comment><USER22> Keeping governments out of private data is a great goal. I wish the same emphasis were placed on Silicon Valley's own practices of tracking every bit of our lives. At anywhere between 75-200 billion of revenue, the largest Silicon Valley behemoths have more economic power than any of the poorest 122 countries in the world, including places like Ethiopia, Croatia or Uruguay.

</comment><comment><USER23> The government has an easy answer to this, data retention laws, which are already common in many countries. The more companies start doing this, the quicker the laws will be passed, and the stricter they will be when they are. It's a temporary solution to a structural mismatch between government and startup incentives.

<comment><USER24> The easy answer to this is decentralized protocols. For example SMTP. You can just delete evidence of criminal activity and then run for president.

<comment><USER23> You would have to have a direct link to your counterparty. Otherwise you'd have to account for why your upstream ISP had record of traffic that you cannot produce any records for.</comment></comment></comment>


An Interactive Introduction to Fourier Transforms - <AUTHOR> http://www.jezzamon.com/fourier/ <comment><USER2> Previous submissions [https://hn.algolia.com/?q=An+Interactive+Introduction+to+Fou...](https://hn.algolia.com/?q=An+Interactive+Introduction+to+Fourier+Transforms)

</comment><comment><USER3> There are three really important things about the Fourier transform in my mind. Two are math and one is engineering.

\- the Fourier Transform preserves energy (Parceval's theorem, the norm of the transformed function is the same as the norm of the original)

\- there exists an inverse transform to get the original function back

\- once you grasp that magnitude/phase describe patterns in the function you can gain powerful intuition about the transform and how to use it as an analytical and design tool.

Those first two properties tell us that the transform preserves information, basically it's another way of looking at the same thing to gain more insight without loss. The third is something not harped on enough in engineering courses, and failure to teach it in my mind is one reason so many people thing controls/signal processing is black magic.

A big followup question here is, are there other transforms for which energy is preserved, and there exists an inverse? The answer is yes, there are infinitely many. The third property is more useful, which begs the question, which of those other transforms are useful?

An example of this is a cousin of the Fourier Transform called the Discrete Cosine Transform which is critical in compression, classification, and machine learning (especially contemporary speech recognition). It's not as straightforward as Fourier, since the result isn't as obvious as breaking down the energy into patterns, but rather what it does is break the energy into _correlated_ parts, in other words it preserves the energy while representing it in decorrelated bins. The strongest of those bins is the most important part, which is why compression technology works by taking the DCT and tossing out low magnitude components (it preserves the most important energy) while also showing how it can work for machine learning, where it decomposes the input information into an equivalent but decorrelated representation where inputs aren't shared for different parts of something like a neural net.

There are other equally cool orthogonal transforms, I like the Hilbert transform myself because it can extract really useful info like signal envelopes and be used to make wacky noises, like a frequency shifter.

<comment><USER4> Can you recommend any good textbooks?

"The Scientist and Engineer's Guide to Digital Signal Processing" is a bit too verbose and hand wavy for my liking; looking for something more succinct and rigorous.

<comment><USER3> Two texts I keep on my desk that are a bit more rigorous than most:

\- Oppenheim & Schafer _Discrete Time Signal Processing_ (the Bible of DSP)

\- Manolakis & Ingle, _Applied Digital Signal Processing_ (good discussion of orthogonal transforms).

A lot of what I know about transform analysis comes from self study of linear algebra/vector spaces with some reading here and there in commonly cited papers. Might want to pick up a text on that subject, it's the same idea but more rigor than an engineer would use.

There's also a book I haven't worked all the way through yet and is dated, heavily based in EE concepts (non negligible amount of circuit theory) and extremely rigorous called _Theory of Linear Physical Systems_ by Ernst Guilleman. I picked it up last week actually and quite like it.

It has a lot of information and approaches with Fourier/Laplace methods, which is interesting since it predates the FFT and has so much information on concepts that engineers 50 years ago would need to build their intuition with instead of through tooling. I picked it up for the network theory/dynamical systems angle (which relates to some stuff I'm working on) but the rigor is definitely higher than what you'd see in those more digestible books.

</comment></comment></comment><comment><USER5> It's good that they link to 3brown1blue's video as well. I was already decently well learned in DSP and information theory before I saw that video and it still managed to teach me a very unique perspective on the fourier transform.

These visualizations are very useful for those without an intuition built up. This is the exact way to think about things if you need to work in the frequency domain.

I do wish they mentioned phase. It's always glossed over when teaching the fourier transform but is incredibly essential to describing a coherent signal.

</comment><comment><USER6> love the interactive demos.

one fundamental thing i always feel is missing with all these videos and articles about the spinny circles set end to end with different phases and amplitude is: why on earth do such configurations happen to have the capacity to approximate any function you prescribe?? to me this is the entire mystery behind fourier transforms. the spinny circles are kind of unusual to look at, but do nothing to illuminate to me why convergence of fourier series happens, and for this reason exactly i am of the opinion that this meme analogy is not useful for beginners beyond entertainment.

of course the details for convergence of fourier series are the entire topic of classical harmonic analysis. one hand-wavy way to make sense of it is to first sample and then identify that the dft matrix for the vector space of sampled signals is a basis. kind of similarly, int dx sin x sin nx from 0 to 2pi is 0 for all n, and the span of {sin nx,cos nx} is somehow dense in some function space. although that isn't really very illuminating since to the uninformed it amounts to a numerical coincidence. every single article of this sort that i have seen falls flat in this respect and i feel like this most interesting part has been obscured.

<comment><USER7> why on earth do such configurations happen to have the capacity to approximate any function you prescribe??

Well they don't. Only certain classes of functions with bounded varitation will have a convergent Fourier series approximation. I think the best way for these demos to introduce this stuff would be to focus on the one with the steps, point out the Gibbs phenomena around the jumps (ringing). Then show for smooth blobby things you are all good though. I think historically a lot of mathematicians had a lot of problems with Fourier's methods applied to the heat equation for these types of reasons (which initial/boundary conditions are ok, etc) hence we have the whole field of harmonic analysis now...

</comment></comment><comment><USER8> 1\. The only thing that matters in engineering is the discrete Fourier transform (DFT). That's what anyone who wants to calculate anything must use. 2\. The fast Fourier transform (FFT) is used to to calculate the DFT. Cue up Matlab or LabView. 3\. Knowing the units of the abscissa in sample and frequency space is next. 4\. Studying the sampling theorem so hard you can describe it in a number of different contexts, rigorously, is critical. 5\. Knowing what aliasing and antialiasing are is critical. 6\. Knowing how to use transforms to interpolate is next. 7\. Knowing how to mess around with the real and imaginary parts of the complex DFT to improve the S/N is a good achievement. 8\. Convolutional filters. 9\. Smoothing data sets with non- causal filters. 10\. What windowing functions, and why?

Have I left anything out?

<comment><USER9> Where could someone go (ideally online) to learn those things and practice them?

<comment><USER10> "The Scientist and Engineer's Guide to Digital Signal Processing" by Steven W Smith available online here: [http://www.dspguide.com/pdfbook.htm](http://www.dspguide.com/pdfbook.htm)

One of my colleagues lent me a hardcover copy very good explanation I found it a huge help for a recent project I was working on (Sonic vibration sensor).

Clearest explanation of everything I was able to find. Fourier transforms were covered during my engineering degree but it had been some years since I'd needed to concern myself with them. Top google hits were not really helping and I found this textbook was invaluable.

</comment></comment></comment><comment><USER9> This is very cool.

Tangent idea: it seems like the way we describe Earth's movement in space (rotation + orbit + precesion) is akin to the image of the hand that draws itself; where instead of describing the whole trajectory, we instead describe it in terms of "circular components" (rotation, orbit and precesion, yes I'm aware the orbit is not perfectly circular).

The closest visualization of Earth's "full trajectory" in space, that I've been able to find, is a video on YouTube ([https://youtu.be/0jHsq36_NTU](https://youtu.be/0jHsq36_NTU)), which unfortunately is a bit exaggerated and not very accurate.

Has anyone seen something better than the above?

</comment><comment><USER11> Great job on the article! Really succinct and a good introduction to the topic. Would've really helped me in undergrad when I first was learning about the Fast Fourier Transform.

</comment><comment><USER12> Two easy questions: 1\. Metaphysically, is everything actually constructed from sine waves? Or is this totally arbitrary (e.g., just as easy to construct things from square waves) 2\. Neural firing approximates sine waves in the brain (e.g., alpha waves). Is a single neuron firing a square wave with a small duty cycle, or something else altogether?

<comment><USER13> 1\. Square waves also work. That's the Hadamard transform.

2\. Individual neurons produce very short spikes (action potentials). EEGs measure those spikes in aggregate, which creates a very noisy and not at all sinusoidal signal. The Greek letters denote particular frequency bands, so if a graph of "alpha waves" looks somewhat sinusoidal, it's because the signal has been filtered to suppress other frequencies.

<comment><USER12> Wow. Fantastic.

1\. Can I ask where you learned that? So happy to know this. By virtue of the 0/1 approach, it seems almost more fundamental than sine waves. Or, maybe negative infinity to infinity is more fundamental? Anyhow, that's just metaphysics. I'm also curious what it implies for digital computing

Here is a nice article that taught better than Wikipedia: [https://www.mathworks.com/help/signal/ug/walshhadamard- trans...](https://www.mathworks.com/help/signal/ug/walshhadamard- transform.html) 2\. Alpha on a single EEG channel can _look_ pretty sinusoidal. Is there a measure of sinusoidality that would allow me to assert how sinusoidal they are?

:) awesome answers to my easy questions, thanks!

</comment></comment></comment><comment><USER14> Bug: If you move the harmonic-count slider to the left and redraw the wave, the slider moves to the right... If you press Play right after redrawing the wave, the harmonics are there. If you keep spamming Play as the right side of the image animates into a filtered wave, the quieter (not necessarily upper) harmonics gradually fade into silence.

</comment><comment><USER15> The write-up is so amazing. The animated diagrams are so amazing too. I wonder how many weeks it would have taken to create such a write-up.

</comment><comment><USER16> Well this doesn't actually explain FFT at all, but it could be interesting to use the circle like thing on speech.

</comment><comment><USER17> This is such a nice intro, really well done.

</comment><comment><USER18> Best illustration ever for the saying, "Give me 19 parameters and I'll fit an Elephant!"

</comment><comment><USER19> This is the best introduction to FTT I've ever seen. I wish I had this when I was an undergrad.

</comment><comment><USER20> Thanks for this article. It had Fourier-transformed my brain-waves!

</comment><comment><USER21> Small Nitpick: You cannot reconstruct a square wave even if you use infinite fourier coefficients due to Gibbs phenomenon.([https://en.m.wikipedia.org/wiki/Gibbs_phenomenon](https://en.m.wikipedia.org/wiki/Gibbs_phenomenon))

<comment><USER22> Your link seems to contradict you?

> Informally, the Gibbs phenomenon reflects the difficulty inherent in > approximating a discontinuous function by a finite series of continuous sine > and cosine waves. It is important to put emphasis on the word finite because > even though every partial sum of the Fourier series overshoots the function > it is approximating, the limit of the partial sums does not. The value of x > where the maximum overshoot is achieved moves closer and closer to the > discontinuity as the number of terms summed increases so, again informally, > once the overshoot has passed by a particular x, convergence at that value > of x is possible.

> There is no contradiction in the overshoot converging to a non-zero amount, > but the limit of the partial sums having no overshoot, because the location > of that overshoot moves. We have pointwise convergence, but not uniform > convergence. For a piecewise C1 function the Fourier series converges to the > function at every point except at the jump discontinuities. At the jump > discontinuities themselves the limit will converge to the average of the > values of the function on either side of the jump. This is a consequence of > the Dirichlet theorem.[11]

<comment><USER23> the second paragraph spells it out? at the jump the series converges to the average rather than either value.

</comment></comment></comment><comment><USER24> One bit of pedantry to complain about: this (really clever) essay is really only describing Fourier Decomposition, the idea that any function can be described in a vector space of sinusoidal basis functions. The Fourier _Transform_ is an algorithm that exploits some (also really clever, and obviously of critical practical impact) factoring representations to compute that sum of functions in N*log(N) time in the number of data points instead of the naive N^2 summation of products.

<comment><USER25> You're describing the "Fast" Fourier Transform, which is a specific algorithm for efficiently calculating the Discrete Fourier Transform of a signal.

The plain ol' Fourier Transform is also a bit different than what's described in this blog post. Fourier Transforms can be thought of as an extension of the Fourier Series described there. The Fourier Series shown there all have not only finitely many terms, but also a finite frequency spacing between successive terms (eg. 1Hz, 2Hz, 3Hz, ...). Fourier Transforms build up signals from _all_ frequencies, so are expressed as an integral over frequency components instead of a sum, even if it's an infinite sum.</comment></comment>