Dead Simple VPN - <AUTHOR> https://balaskas.gr/blog/2019/07/20/a-dead-simple-vpn/ <comment><USER2> If you already have OpenSSH installed, it has a built-in tunnel you can activate with a single command-line argument that exposes a SOCKS server on localhost.

<comment><USER3> It can also tunnel IP packets or Ethernet frames, see [http://rkeene.org/viewer/tmp/ssh-ip- tunnel.txt.htm](http://rkeene.org/viewer/tmp/ssh-ip-tunnel.txt.htm)

</comment></comment><comment><USER4> I'm very impressed with the blog. At least one post a month for ten years? Whoa. Impressive.

</comment><comment><USER5> jedisct1 sure is prolific with all these lean and friendly crypto-related applications.

dnscrypt-proxy, libsodium, libhydrogen, minisign, dsvpn, probably others I've never heard of.

<comment><USER6> minisign is pretty cool. I've added its signature to my software releases along with md5/sha256.

[https://github.com/jedisct1/minisign](https://github.com/jedisct1/minisign)

</comment></comment><comment><USER7> This is exactly what I have been looking for. One executable, symmetric keys and any port I want.

TCP is sometimes a must (library Wi-Fi that supports only known ports). But UDP is (i think?) better for wrapping TCP traffic.

<comment><USER8> UDP is just an IP packet with port information. That is all. That's why it is so easy to do something like TCP/UDP instead of TCP/IP, even though nobody calls it that. TCP over TCP is bad because the protocol uses congestion for traffic control, and if the underlying connection is lossless and never gets congested, the inner TCP layer cannot work right.

<comment><USER9> Just to clarify... IP = L3, UDP|TCP = L4. In your example TCP/UDP is still TCP/UDP/IP.

<comment><USER8> Yes obviously. But practically it doesn't matter as UDP doesn't add anything except expanding the addressing to include port numbers. That's like saying that we must always list all protocols below TCP: TCP/IP/ETH/Copper wire. It doesn't matter because what you run IP over can be ETH, 802.11, pigeons, door to door salesmen, etc. Same with TCP/UDP: it doesn't matter if UDP is implemented on top of something other than IP. In fact, if you don't make a distinction between IPv4 and IPv6, two wildly different protocols, you don't actually care what TCP runs on top of in a TCP/IP combo.

<comment><USER9> > That's like saying that we must always list all protocols below TCP: > TCP/IP/ETH/Copper wire.

My point was your conflation of L3 and L4. And in fact TCP does have some changes on v6 from v4. Consider, for example that ARP, is replaced by Neighbor Discovery (ND) and that is added to TCP/IPv6. So... If we're splitting hairs now then not exactly.

<comment><USER8> I am not conflating them. But consider that you can run IP over IP. What level protocol is IP in this case? What about IP/IP/IP/IP? Is IP on the left level 7?

Also, when you are using TCP you don't care whether it is using ND or ARP. That's what abstraction means. The implementation of course cares, but when you use it you do not and if you do the implementation is incorrect.

<comment><USER9> > I am not conflating them. But consider that you can run IP over IP. What > level protocol is IP in this case? What about IP/IP/IP/IP? Is IP on the left > level 7?

There is only one L3 to the local stack at any given point in packet flow. Sure, you can run IP in IP but the parent, or root, IP stack is the one in control until the encapsulated IP is deencapsulated and moved up. Encapsulating a L3 protocol doesn't magically make it something else as it pertains to OSI.

Finally TCP isn't an abstraction and it has rules based on it's version. So, yes, if you're writing network applications at the TCP level you very much do care about ND or ARP.

<comment><USER8> Look, if you believe in the sanctity of the network layers, sure. I don't. In a TCP/UDP scenario, to me UDP is the packet layer because that's how I'm using it. If I am doing TCP/IPv6/UDP/IPv4, which I have actually done in real life when IPv6 access required that you set up a tunnel over UDP/IPv4, I am free to think of IPv6 as the level 3 protocol because that's functionally what it is.

As for ARP vs ND, when I do

        bind('localhost', 5555, 'TCP')

I really don't care whether localhost is IPv6 or IPv4 or pidgeons throwing rocks with notes.

<comment><USER9> > Look, if you believe in the sanctity of the network layers, sure. I don't.

And herein lies the issue. A layer 3 protocol can never be anything else. Unless you're writing some sort of dissector or have another use case. This isn't a "belief", it is what it is. But even when said layer 3 protocol rides a higher layer, let's say IPv4 on UDP, it's still a layer 3 protocol that is layer 4 payload until decapsulated and processed as such. What you describe is encapsulation and decapsulation, this isn't new or interesting and in most cases it's generally a bad idea just looking at it from a perspective of overhead.

I'm also not sure your pseudo code is legit considering you're binding a socket that's already been defined and the socket() is the real question mark here that differentiates IPv4 and IPv6. I think you may have glossed over the fact that some platforms don't support binding v4 on v6 sockets, while some do. Regardless your example is neither universally correct or ideal in many cases.

<comment><USER8> The problem is that the layer models break down above IP/level 3. Imagine you defined IPv77 which was identical to IPv4 but included port info. So this is equivalent to UDP/IP. What layer protocol is that?

Or say you managed to run UDP directly on top of ETH. Because if you don't need routing across different networks this is perfectly possible. A protocol is just two interfaces: where it interacts with the lower level protocol and higher level protocol. It is all encapsulation, that's my point. This is why the layer model is mostly not really used when discussing these things.

So back to the example or UDP being implemented as a layer 3 protocol: when using it, you wouldn't actually know the difference, would you?

As for my code example, you are right. It should be like so:

        s = socket(TCP, IPv6);
        bind(s, "localhost", 5555);
        c = accept(s);

Note that past the call to socket() and storing the remote address, I don't care whether TCP here runs on carrier pigeons or paper planes. Heck, I could treat the addresses as completely abstract strings if I want and never know that they are the names of two pigeons. TCP _abstracts_ that away from me. I don't worry about things like packet delivery, congestion, routing, etc. When I _use_ the TCP interface, I can ignore most of the underlying details. When I _implement_ it, it's the opposite: I care a whole lot because I need a different implementation for every underlying protocol.

<comment><USER9> I'm sorry but you're making things up at this point. Feel free to read the first paragraph of RFC 767 [0], most notably the last sentence:

"This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol."

As for your code, again, you make a lot of assumptions. As I mentioned before opening a socket as IPv6 does not guarantee backwards compatibility with IPv4 addressing. So, again, my point is that you _do have to care about the version_ of IP. In your original example you conveniently skipped the socket call and claimed "See, I can just consume any IP!". Now you're just glossing over the glaring assumption, as I stated in the last post, that not every platform guarantees backward compatibility with IPv4 on an IPv6 socket.

Also... Your pigeon analogy makes zero sense to the argument you're attempting to make because it's highly irrelevant to the protocols and how they actually work in computing environments.

If you care to read the OSI layer 3 protocols state that they are concerned with deciding which physical path data will take. UDP and TCP have no _routing_ facilities I'm aware of because port numbers don't define path. So, again, UDP is not a layer 3 protocol just because you feel like it is.

[0] [https://tools.ietf.org/html/rfc768](https://tools.ietf.org/html/rfc768)

<comment><USER8> I understand and agree with you that IPv4 and IPv6 are OSI layer 3 protocols and UDP and TCP are layer 4. At the same time, the OSI model above the fourth layer has been widely considered mostly useless, and some have called into question the whole thing. Yes, RFCs exist that point to what you are saying. But again, I can 100% implement TCP on top of UDP without ever thinking about IP packets. And no, I don't care which layer 3 protocol TCP is using underneath, so long as I can initialize the socket properly and get the local/remote addresses. Take a look at a complete example of a TCP server: [https://www.cs.cmu.edu/afs/cs/academic/class/15213-f99/www/c...](https://www.cs.cmu.edu/afs/cs/academic/class/15213-f99/www/class26/tcpserver.c)

Where in there do you see anything about ARP or ND? Or hops vs TTL? Or IP packet header sizes? Or header checksums? Or priority flags? You can take this code, add a couple of macros for getting the correct AF_ value and structs and the code would be 100% abstracted away from any mention of the underlying layer 3 protocol.

Google has been developing transport layer protocols on top of UDP for years now. Why? Because getting a new layer 4 protocol to work is nearly impossible. Yet, if we all agreed that it was something we wanted, they could easily do so, which makes these new protocols functionally transport layer. If it helps you sleep at night, you can say that they are temporarily exiled to be encapsulated in UDP, but really they'll return some day to their proper place in the OSI model.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Does this provide some benefit over a Wireguard setup? ([https://www.wireguard.com/](https://www.wireguard.com/))

<comment><USER11> There's a comparison section on GitHub [1] – WireGuard doesn't support TCP while this does.

[1] [https://github.com/jedisct1/dsvpn#why](https://github.com/jedisct1/dsvpn#why)

<comment><USER12> > OpenVPN is horribly difficult to set up.

That statement could need some more explanation in my opinion. I never felt it being much difficult.

<comment><USER5> Using easy-rsa, choosing the right ciphers and other protocol options always seemed overly complex and opaque to me. Wireguard was a breath of fresh air in comparison.

<comment><USER11> There are multiple setup scripts like [1] that make it super easy to setup OpenVPN.

[1] [https://github.com/Nyr/openvpn-install](https://github.com/Nyr/openvpn- install)

<comment><USER13> Makes it super easy but even more opaque, that is not a good thing with incredibly security-related software.

<comment><USER11> Isn't it common advice to not roll your own crypto? If this software has sensible defaults, I see no problem with using it.

<comment><USER13> It is, but with this script it's a third party rolling their own crypto for you :D. OpenVPN should have good defaults instead.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Even simpler for some use cases:

`ssh -D 1080 -C -q -N root@your-vps`

<comment><USER15> Are you sure that -C is a good idea? Wouldn't it be possible in theory to exploit something similar to CRIME/BREACH?

> root@your-vps

People allow for root ssh connections?

<comment><USER16> Yes, what's wrong with that?

Security is multi dimensional matter, you can't just rely on rules like "no ssh to root" or "password should be more than 20 characters".

In my case ssh is allowed from 2 IP addresses (much more useful rule then "no ssh to root "btw!) with key auth (passwd auth disabled). Don't see any problem with that.

</comment></comment></comment><comment><USER17> So correct me if I am wrong but this is doing IP in TCP right ? Iirc, this is a big issue for tcp flow control, which relies on packet loss to detect congestion: as you encapsulate stuff in tcp stream, there will be no more packet loss and the tunelled tcp will not throttle correctly.

Did not read the code yet, so maybe there is something to simulate congestion packet loss.

<comment><USER18> From the README:

TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).

<comment><USER19> This is an intriguing quote. The biggest problem I saw with tcp over tcp is not during the regular operation, but when there was a noticeable packet loss present on the line. Then the the accumulated retransmits on stacked TCP most of the time killed it. Admittedly it was maybe a decade ago after which I concluded it's just a BadIdea(Tm) and never revisited it.

I had similar experience lately whenever using the mobile internet in poorer coverage cases (eg. a high speed train Brussels-Paris or Brussels-London) which result in frequent and big variations of latency. Of course that all is decoupled congestion control.

If anyone compared the performance of this solution on poor connections with and without BUFFERBLOAT_CONTROL, would be very very interesting to know the results!

<comment><USER20> WireGuard reconnects in less than a second whereas OpenVPN takes a good 8 (!!) seconds to reconnect. If you have an unstable connection, that's awful. If you only need SSH, Mosh (which utilizes UDP) could be suffice though.

</comment></comment></comment></comment><comment><USER21> Does this provide some benefit over Algo? ([https://github.com/trailofbits/algo](https://github.com/trailofbits/algo))

<comment><USER22> Algo is a set of scripts that sets up IPSEC and WireGuard VPN on a Linux server. This dsvpn is an entirely new VPN implementation—like IPSEC or WireGuard—written by jedisct1 from scratch.

</comment></comment><comment><USER23> Pretty damn cool, but I can't see this giving you much in way of anonymity. Yet, should be all fine for getting through to region-locked DRM content.

<comment><USER11> I believe this wouldn't work for Netflix because they check for known commercial IP addresses (DigitalOcean or AWS for example).

<comment><USER24> In those cases, I reverse ssh the vpn ports to my server, put it on a tiny computer, fly over to a country with limitless dsl and place it behind a router at a friend's house. Easy.

<comment><USER25> I think autonomous indigenous communities are sitting on a huge untapped market of data centers operating under their own globally competitive data privacy laws

Casinos are so 20th century

<comment><USER26> They have been doing this for years in Canada but the price of a server is extremely expensive

<comment><USER25> Can you give an example of a tribe and product offering? I've been researching Canadian indigenous communities and it seems the autonomy is even less than US tribes, but that the provincial and federal governments is just much less staffed (big area, low population, low interest, apathy)

<comment><USER26> The Mohawk nation is very high tech compared to some of the others.

When working for an un-named poker company we had a hosted a server. When a hardware problem happened we had to drive and replace ourselves.

The cost is high and getting accepted requires knowing someone but safest place to host in North America for gaming related materials.

Remember bodog.. I believe they hosted game servers as well there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> What are the implications of:

[https://eprint.iacr.org/2019/447](https://eprint.iacr.org/2019/447)

"Practical Key-recovery Attacks on Round-Reduced Ketje Jr, Xoodoo-AE and Xoodyak"?

As far as I understand round-reduced doesn't have to mean all rounds are broken, but it is still something to think about.

<comment><USER28> The security of block ciphers, permutations, hash functions and higher-level constructions is studied by modifying the function until some of its claimed properties are invalidated.

What is being analyzed is not the actual function. How much changes had to be made and how significant they were is an indication of the security margin of the actual function.

In this paper, key recovery requires a made-up mode, or an existing mode, but used incorrectly (nonce reuse with the same key and different messages) 2^43.8 times. In addition, the permutation had to be reduced to 6 rounds. The normal number of rounds is 12, which makes a huge difference.

The analysis actually shows that the security margin of the real construction is extremely comfortable.

</comment></comment><comment><USER29> DSVPN does not seem to support PFS [1] which would immediately disqualify for any purpose for me.

[1] [https://en.wikipedia.org/wiki/Forward_secrecy](https://en.wikipedia.org/wiki/Forward_secrecy)

<comment><USER28> While nice to have, this is not terribly useful in the context of a VPN.

PFS would prevent the following scenario: you're suspected to be an axe murderer, the police asks the cloud provider to tap your VPS traffic, and, later, asks for a dump of that VPS to get the key. Haha, the key is still valid, so the previously recorded traffic can be decrypted!

PFS however would not prevent the following more likely scenario: the police asks for the key, and effortlessly decrypts everything from now on. PFS doesn't provide post-compromise security, which is far more important.

But since a VPN server is essentially a proxy that decrypts traffic between itself and a client to forward decrypted packets to remote servers, here's an even more likely scenario: the VPS is tapped, and packets exchanged with the VPN client is not something to waste any time on since for each of them, the server also sent or received a decrypted copy.

That being said, a simple way to get PFS and post-compromise security is to change the key regularly. If you're just someone who needs a personal VPN to work in a coffee shop whose public WiFi has overzealous firewall rules, this is not something you have to worry too much about.

If you're an axe murderer, just add key rotation to your post-crime routine.

<comment><USER30> Um, I think you're wrong about the following claim. Let's use wireguard as an example.

> PFS however would not prevent the following more likely scenario: the police > asks for the key, and effortlessly decrypts everything from now on. PFS > doesn't provide post-compromise security, which is far more important.

Wireguard achieves PFS using regular ephemeral diffie-hellman key exchanges. If I understand the scenario you describe, Police has initial (long-term) key (from either endpoint or both) and taps VPS traffic. The long term key can probably be used to get the initial negotiation of the tunnel, but after the first ephemeral key exchange it can't decrypt any more of the traffic. Why? Well both endpoints kept their secret (random) portion of the key exchange on their machine, and continually wipe it (and the derived key) after every key exchange. So police needs the interstitial derived keys from either endpoint to decrypt the traffic. But it'll be probably too late after the conversation is over.

</comment></comment></comment><comment><USER31> I don't really understand network much. > dsvpn server /root/vpn.key auto 443 auto 10.8.0.254 10.8.0.2

So what does those last two ip means? Similarly for the client.

<comment><USER28> You can leave that to `auto`.

A VPN creates a virtual network between two machines. Each end needs an IP address.

In your example, `10.8.0.254` is the address that will be assigned to the server and `10.8.0.2` is the address that will be assigned to the client. These addresses are only valid within the tunnel. They are not the real IP addresses.

If you do `ping 10.8.0.254` from the client, you'll get a response from the server. If you do `ping 10.8.0.2` from the server, you'll get a response from the client. If you do `ping 10.8.0.2` from the server, you'll get a response from itself. Which is not very useful.

These IP addresses are not reachable outside the tunnel. The network is private.

You can use any pair of addresses you want as long as they are not used by anything else.

<comment><USER32> Since this is a point-to-point tunnel, you can get by without assigning IP addresses to the tunnel endpoints and route by tun device instead. It saves some `ip addr` configuration and reduces two NAT (once on leaving local tun and once on the server) to just one NAT (on the server only).</comment></comment></comment>


Pointing Users to DRM-Stripping Software Isn't Copyright Infringement - <AUTHOR> https://www.eff.org/deeplinks/2014/12/pointing-users-drm-stripping-software-isnt-copyright-infringement-judge-rules

<comment><USER2> Does Calibre by itself strip DRM? It's my understanding that you needed a series of tools by "Apprentice Alf" to do the work.

</comment><comment><USER3> > Judge Denise Cote dismissed two publishers' claims of contributory > infringement and inducement in Abbey House Media v. Apple Inc., one of the > many cases to come out of the antitrust litigation against Apple and a > handful of major publishers.

Is it me or does it feel like Denise Cote the only federal judge in the country?

</comment><comment><USER4> Until a judge with *IAA lined pockets comes along, that is.</comment>


Space Planes & Secret Prisons: 9 Secret Military Programs You Shouldn't Know - <AUTHOR> http://www.wired.com/dangerroom/2011/12/secret-programs/

<comment><USER2> The last thing they wrote was "Confessions of Hot Hollywood Starlets at Secret Clothing-Optional Parties" published in 'The National Enquirer' right next to "Aliens Impregnating Actresses? How Many?"?

</comment><comment><USER3> I love articles like this. Opened in a tab and moved to the left for reading over the holidays.</comment>


Texas judge admonished for posting on Facebook - <AUTHOR> http://arstechnica.com/tech-policy/2015/04/27/texas-admonishes-judge-for-posting-facebook-updates-about-her-trials/

<comment><USER2> "Say as little as possible so as to reduce the amount of data on which suspicions of impartiality can be cast"</comment>


Company size: Big is back - <AUTHOR> http://www.economist.com/printedition/displayStory.cfm?Story_ID=14303582

<comment><USER2> I am concerned by the public's changing mood, in regards to entrepreneurs. In the 1970s the American government began the process of deregulation, which allowed some important innovations in the industries that were deregulated. Transportation was probably the first big industry effected, followed by many others.

My impression was that there was a stretch when some combination of the public mood and the government's emphasis conspired to encourage small startups. The 1980s and 1990s were clearly good in this respect.

The mood of the last decade has been increasingly punitive. An increasingly harsh attitude toward flexibility in the law has been evident elsewhere for some time, but in the last 10 years that attitude has increasingly been expressed in the field of business. The Sarbanes-Oxley Act is the most evident expression of the new trend - what once would have been treated as a civil matter is now treated as a criminal matter.

At some point during the next 30 years I expect breakthroughs in biology to allow for a new wave of startups, if the government and the public allow those startups to exist. In matters relating to health, it is worrisome to consider what a punitive legal attitude means - a medical treatment that fails to perform leads to jailtime, rather than a lawsuit.

I think it is urgent that everyone who cares about entreprenurial culture in America to make the argument, to their friends and to strangers, that innovation in business depends in part on tolerance, and that, in practical terms, this means most matters of conflict should be treated as civil rather than criminal cases.

Once upon a time, before the mid 1800s, most Western countries treated bankruptcy as a criminal matter, rather than a civil one. The liberalization of bankruptcy law was one of the factors that allowed our modern economies to gain the dynamic nature they now enjoy. I would guess that most of us know someone who has tried to do a startup, failed on their first attempt, and then later met with greater success on successive tries. Tolerance of failure is the first pre-requisite of a dynamic economy.

Since the public seems at risk of forgetting this fact, we all need to make that case, to whoever is willing to listen.

<comment><USER3> When you cross the line into experimenting with medical treatments, you're not gambling with other people's money, you're gambling with lives. You can't just equate it to any other kind of start up, it has to be held to a higher standard.

<comment><USER2> Regarding medical innovation.

Other fields also threaten people's lives. If you build a new kind of jet engine, which gets through testing but which then is responsible for a spectacular crash, then your product has killed a few hundred people. And yet, unless there was fraud in the documentation of the tests, there have not been criminal cases in the past. I worry that in the future there will be criminal cases. Again, the trend that I worry about is that what used to have been treated as a civil matter will, in the future, be treated as a criminal matter. We do not need to focus on the medical field. Many other fields can cause people to die - industrial automation, the transport and disposal of toxic chemicals, the construction of buildings (which could then fail and kill people). All industries are in need of innovation all of the time, yet innovation brings with it risk, including the risk of death. How much innovation will we get if we make these matters criminal?

I should emphasize, just in case people forget, that fraud has always been criminal. It has been criminal for centuries. So the move to criminalize more aspects of business is not a move to make fraud criminal. If you think that the Sarbanes-Oxley Act made fraud criminal, then you are mistaken. Fraud has always been criminal.

Sarbanes-Oxley is representative of the new trend. The overall goal was to encourage greater accuracy in the reporting of a company's financial health. This goal could have been reached through a variety of methods, including both the carrot (rewards) and the stick (punishments). Rewards could have included tax breaks for meeting some additional level of compliance. Punishments could have included fines levied against companies that failed to meet a higher level of compliance. These approaches would not have raised the risk of jail time for CEO's. Instead, Sarbanes-Oxley decided to go with the heaviest kind of punishment of all - to treat infractions as criminal offenses, potentially meriting jail time.

This punitive attitude is going to have a chilling effect on the amount of innovation we can expect in any field.

<comment><USER4> The problem can be that punitive matters are handled as a 'cost of doing business.' Who cares if we kill a few people with our products if our profit will be more than the costs of any punitive settlements/fines? The problem really comes in when there is willful negligence or malice in the process.

If an engineer comes to you (as a manager) and tells you the your product will fail in certain circumstances and cost lives. Then you say, "I'll take that 'under advisement'," and completely ignore it because to take that into account would cause the project to run over deadlines and you want to look good to your bosses. Then the product is deployed in the field it fails under those same circumstances. Lives are lost. Lawsuits are filed. The 'company' loses and/or settles with the grieving families and pays out some money. But the _real_ cause of those deaths is _your_ willful neglect just to please some corporate masters in the hope of a promotion. I personally think that you _should_ be held legally responsible in such a case. But the prevalence of 'not me syndrome'... aka Diffusion of Responsibility (<http://en.wikipedia.org/wiki/Diffusion_of_responsibility>).

Once a sufficiently large group of people start to function as an entity, that entity can do things that no normal person would be allowed to do... and no one is held responsible.

<comment><USER5> Killing a few people will be more than just punitive settlements/fine, it will also lower overall revenues in the long term because consumers now have reasons to fear a certain company's product.

That, and your competitors will hawk their wares _and_ point out that their product never killed anybody, in addition to big suspicions from consumer magazines.

<comment><USER4> This kind of stuff happens all the time in the auto industry. Don't narrow your view to just medical companies.

<comment><USER5> What do you mean by this? Is my conjecture wrong?

<comment><USER4> When was the last time that you heard a car company bashing a competitor's safety performance?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> "Netscape and Enron promised to revolutionize their industries only to crash and burn"

Hard to believe they compare those two in the same sentence. Netscape made a great contribution to the early days of the consumer internet where as Enron was a complete scam through and through.

<comment><USER5> Apache killed netscape, not microsoft. Netscape's bread and butter is webserver, not a web browser.

Or so I heard.

<comment><USER6> What's your point?

<comment><USER5> I was pointing out one possible reason why Netscape crashed and burned.</comment></comment></comment></comment>


You probably don't need PostGIS - <AUTHOR> https://blog.rebased.pl/2020/04/07/why-you-probably-dont-need-postgis <comment><USER3> You (probably) should just use PostGIS, because it's the easiest thing to do, everybody understands it, it's eminently google-able, and ubiquitous. Unless you have a specific reason why you can't, just use PostGIS and enjoy your life.

<comment><USER4> I strongly agree. The article explains alternatives to PostGIS, but doesn't say anything about _why_ you should avoid PostGIS. I see no reason at all to avoid it, even when you're just storing lat/long points. (It's "overkill," says the article, but that's harmless at worst.)

<comment><USER5> > (It's "overkill," says the article, but that's harmless at worst.)

I don't disagree in this specific case, but that's not always true.

I remember on a contract years ago another team working on a project - <USER2> started before I joined and was still going when I left - to build a big data analytics pipeline (hadoop, kafka, etc.) that achieved nothing. The whole thing could much more easily have been implemented with SQL Server (which they already had), PostgreSQL, or whatever.

At the very least it cost them a lot of wasted effort plus maybe a dozen sets of salaries and contractor rates (there was a mix). But it also stymied solutions in other areas because the answer was, "oh, we don't need to do that because the big data project has it covered." The opportunity cost was significant: the company lacked the capabilities it needed for as long as this white elephant continued lumbering on its way.

</comment></comment></comment><comment><USER6> Isn't this like saying that you don't need a Datetime library since you can just use unix epoch timestamp? You should specify what coordinate system you're using [1] (not unlike a timezone). There's more edge-cases than you think: the suggested containment operator wouldn't work on shapes that cross the antimeridian line (at 180 W = 180E). The earthdistance module assumes the Earth is a sphere.

[1] [https://en.wikipedia.org/wiki/Geographic_coordinate_system#G...](https://en.wikipedia.org/wiki/Geographic_coordinate_system#Geodetic_datum)

<comment><USER7> In fairness, assuming the earth is a sphere is rarely a problem. A typical "closest to me" algo is will have a ton more UX error due to differences between travel time and as the crow flies travel time. Frankly I agree with the article in the sense I have implemented decent solutions with MySQL just using a bit of math to filter to a reasonable lat,long span and then ordering with the haversine formula.

You don't need PostGis to find the nearest McDonald's closest to an IP address of every visitor. A degree of lat is 69 miles, and a degree of long is easy to calculate based on the lat, but you may need an extra case if you want to be correct for the tiny number of people that live near the antimeredian line.

I wonder if people run toward PostGis just because they don't know to google haversine or the spherical law of cosines.

That being said, I have often come up with decent hacks that solve a customer problems but biting the bullet and adopting Postgres may have been ultimately better. I wish PostGis was a skill I have, but in a pinch the law of cosines is quite passable.

<comment><USER8> The thing is, it starts with find me the closest point. And then, in the next meeting, management wants to know which are in a specific area. And this case is about points contains by a polygon.

I'll gleefully counter-argue some run toward PostGis just because they don't like NIH syndrome ^^

</comment></comment></comment><comment><USER9> The arguments here aren't great. It's also mentioned to install some other extension (why, then, not use PostGIS at this point?). Don't really understand what the author was getting at.

Also, as was mentioned, this was posted earlier today: [https://news.ycombinator.com/item?id=22820485](https://news.ycombinator.com/item?id=22820485)

<comment><USER10> The "other extensions" are part of Postgres core, and are just "extensions" in the sense that they're loadable modules that are not loaded by default.

PostGIS is a whole big external thing that Postgres doesn't ship with.

 _Any_ running Postgres cluster can load and use the extensions in the article, with no ops work. Even environments like RDS have these extensions available.

If you want PostGIS, you need to explicitly run PostGIS; if you want PostGIS- as-a-Service, you need to find someone who is explicitly offering PostGIS-as- a-Service.

<comment><USER11> Worth pointing out that RDS includes PostGIS, which is good since you can't poke the DB server directly. Although I am sympathetic to the blog post, since PostGIS is overkill in complexity for simple use cases like a store locator.

<comment><USER12> Redis has GIS features built-in for store locator type calculations, so that's another option:

[https://redislabs.com/redis-best-practices/indexing- patterns...](https://redislabs.com/redis-best-practices/indexing- patterns/geospatial/)

Here's a couple Lyft talks:

Redis at Lyft: 1,000 Instances (2017)

[https://www.youtube.com/watch?v=U4WspAKekqM](https://www.youtube.com/watch?v=U4WspAKekqM)

Geospatial Indexing: The 10 Million QPS Redis Architecture Powering Lyft (2017)

[https://www.youtube.com/watch?v=cSFWlF96Sds](https://www.youtube.com/watch?v=cSFWlF96Sds) (2017)

</comment></comment></comment></comment><comment><USER8> Well you actually very probably do need PostGIS if you're doing real spatial analysis.

PostgreSQL geometry field are just that, 2D geometries, on a plane, in no particular projection system.

Spatial geometries are relative to a projection system. Try to "draw" a square with GPS coordinate and project it in your local official projection reference, you'll probably not get a squared.

Now, if you don't need precision, feel free to use geometries. But be very aware of the trade off you're making. The article, in my opinion, dismisses them a little too fast.

<comment><USER13> I think the position of the article is "if you're just making a web app with some dots on a map, you're not doing 'real spatial analysis'".

I basically agree with the post because I found myself in a similar position a few years ago. I inherited a map with dots on it, and I thought "oh, I need to move this to PostGIS." But it turned out to be overkill. I wasn't using any geometries, and I didn't even need distances from a radius. I was just showing events by location, time, and type. Two columns for latitude and longitude were more than enough.

<comment><USER8> Oh fair enough, not really arguing that point.

But there is a major trade-off and the article does not even mentions it. It is perfectly fine to consider the GPS coordinate system and basic geometries are good enough for short distance. _As long as_ you're aware that GPS coordinate are actually set in a precise projection system and that you are making a informed decision.

</comment></comment></comment><comment><USER14> OpenStreetMap is a prominent user of Mapnik, but it's not an OpenStreetMap project. It was started way back in time for the sake of starting it:

[https://mapnik.org/news/update](https://mapnik.org/news/update)

When it got so far along, OSM started using it in the demo rendering system that backs the 'standard' tiles on openstreetmap.org. Those tiles often get called "mapnik", because Mapnik is a big chunk of the rendering system, but they are really OpenStreetMap-Carto, a map style maintained for OSM.

<comment><USER8> Really OSM is kind of a special case. Database-wise it is more of a catalog of points and edges. Traditionnally, GIS databases support more complexe geometries natively.

<comment><USER15> Limit with PostGIS is that it uses "Simple features model" - OSM model is way more, not less complex: topology (object element hierarchy/links), versioning, editing metadata, schemaless tags etc - none of them were possible in plain postgis. Only more free data schemas (eg jsonb) are added to since OSM debate over db solutions over 10yrs back, the other things are still not there really.

<comment><USER8> Well, you've said better than I. IMHO, PostGIS is geared toward building classical GIS databases, while OSM is more a Topological Catalog. If I'm not mistaken, they say so themselves and visual map are just a by-product of geo- referencing "everything". Way more complex and way more harder to work with.

Edit: maybe I should have said "higher level geometries" than "more complex". In the sense that OSM "knows" about point and edges and nothing else.

</comment></comment></comment></comment><comment><USER16> > If using built-in Points, note that the order of ll_to_earth's coordinates > is reversed: points are (x, y) which corresponds to (lng, lat). But the > function takes lat, lng.

This is a strong reason to use PostGIS.

<comment><USER17> It's a contentious point, but plenty of formats and standards use lng, lat ordering.

[https://macwright.org/lonlat/](https://macwright.org/lonlat/)

[https://macwright.org/2016/07/15/longitude-latitude-is- the-r...](https://macwright.org/2016/07/15/longitude-latitude-is-the-right- way.html)

</comment></comment><comment><USER18> Has there been any work to minimize the size and number of dependencies, or modularize it, or produce a "PostGIS-lite"? Usually I'm happy to grab a good library even if it's overkill, but PostGIS pulls in many hundreds of megabytes -- far more than every other library I use combined. I wish there were a way to say "I want the GIS data types, but I don't need JPEG2000 and every other possible image format".

</comment><comment><USER16> The built-in geometric types work as expected only at the equator. They become more and more distorted as the move toward the poles. Circles become ellipses. Lines curve.

PostGIS's built-in Geometry types maintain their shape anywhere on the globe.

<comment><USER19> I think you might be thinking of Geography types. Geometry types really just operate in the 2D euclidean space which their associated SRS maps them to. And no 2D SRS can accurately represent the reality of working on a sphere, so I'd be very surprised if you found you could move a circle from the equator to europe and it remain a circle when back-projected.

Geography types try to deal with this sort of weirdness but are unfortunately slower and more complicated to work with.

</comment></comment><comment><USER20> > Can I measure the distance between two given points? Make sure you have the > earthdistance module enabled: CREATE EXTENSION IF NOT EXISTS earthdistance > CASCADE (cascade pulls in requirements, which are just the cube module). > Then use the eponymous earth_distance function; note that it doesn't take > coordinates directly, but its own type, which you convert to with > ll_to_earth(lat, long).

Maybe I'm missing the point but I don't really see how that is easier then using "CREATE EXTENSION postgis;" and "ST_Distance" ?

<comment><USER10> `CREATE EXTENSION postgis` implies that you have PostGIS _installed_. PostGIS is about five times the size of Postgres itself, and has about twenty requirements, some of which have their own heavy trees of recursive requirements, some of which are near-impossible to build in certain environments (e.g. macOS Homebrew) without weird finessing. The (alpine!) Docker image of a PostGIS-enabled Postgres is 713MB. That's a lot of extra binary if you just need to record some points!

And the _real_ problem with all that isn't the size/deps themselves, but rather the fact that the size/deps will probably lead to you wanting to use a binary distribution (or pre-made Docker image) _of PostGIS_ rather than treating PostGIS as any other Postgres extension installed against a regular running Postgres cluster. Which then means that you'll need to find/settle for the set of extensions that are packaged _for that binary distribution_ , rather than just using the standard set of extensions that come with a standard Postgres distribution (e.g. the PGDG Postgres apt repo, which contains many individually-packaged extensions.)

<comment><USER21> Postgres.app comes with PostGIS plus GDAL etc. There's no good reason to use Homebrew Postgres over Postgres.app.

<comment><USER10> Maintaining your own custom fork of Postgres is a pretty good reason.

<comment><USER22> Only if there's a good reason for doing that.

</comment></comment></comment></comment></comment><comment><USER23> Here I thought this article would have been written by The Flat Earth Society!

If the web frameworks - specifically Django - do a lot of the heavy lifting with their integration and the installation in modern Postgres is so much easier, I don't really understand why NOT use it?

</comment><comment><USER24> If you are storing points, you probably want to do things with that data. You don't know exactly what yet, but having standard formats and tooling is probably a good idea.

What is the downside, exactly? I guess you have to learn a few things, but it might be good to know anyway.

</comment><comment><USER25> Yes, for many use cases you can use other extensions to achieve what you want, but what advantage you have for not using PostGIS?

<comment><USER26> As mentioned above, in another comment, a big tradeoff is potentially maintenance and operations work. It may not be a hard thing to maintain, but it's another dependency that's not core to Postgres.

I've done a lot of ops work in my dev career, and I'm always reluctant to add another dependency (JS, btw, makes me crazy with how little is included in the standard library, and NPM is required for everything). So, I might be tempted to follow the advice in the article, and avoid using PostGIS for the simple use cases provided in the article.

For reference, I've also helped with non-devs work on python code for GIS systems for daily delivery systems. So I would most definitely be tempted to try to utilize PostGIS if I was in the GIS world dealing with map updates, and daily starts and stops.

Side note. Having been a programmer for several decades, and professionally for a decade at the time, I had truly forgotten how bad novice programmers are. Nested loops on long running functions all over the place (calculating optimal routes is not cheap computationally). It felt good to get some perspective at the time by helping the GIS department with their code.

<comment><USER12> Back in the day, a GIS pro gave a talk at OSCON on how far he could push Open Source software to do mapping for free.

One of the best talks I've ever seen, although if you do that much work yourself, you might as well form a company.

I consulted for the Canadian JPL, so I had tons of satellite data, but it was mostly ice, tundra and forest regions. Not much urban data, alas. :)

Although you could take your notebook down to the Ministry of Works and they would plug in a cable and give you all their street data at the time for free. I actually did that once.

</comment></comment></comment><comment><USER27> If I just want to find the nearest point in a small country using the <-> operator, do I need any extension at all?

<comment><USER8> Possibly, yes but be aware of the trade off and evaluate the actual error to decide for yourself for that given country.

</comment></comment><comment><USER28> This is a dupe from earlier today.

</comment><comment><USER29> latitudes should be numeric(7,5)...

<comment><USER8> Coordinate in general should be in an explicit and documented coordinate system (I suppose you mean GPS coordinate system, EPSG:4326/WGS 84)

</comment></comment><comment><USER30> Mongo is another alternative, has pretty solid support for geospatial queries built in

[https://docs.mongodb.com/manual/geospatial- queries/](https://docs.mongodb.com/manual/geospatial-queries/)

<comment><USER31> I stored the coordinates of Atlantis, Mu, and Sandy Island in a MongoDB database, but then…</comment></comment>


Tell HN: Productive.io & Action.io for sale - <AUTHOR>

Anyone want them? <comment><USER2> How much? Where'd you register them?

<comment><AUTHOR> They are $100 each, they usually cost about $99 a year.

Action.io expires on 21 Sep 2011 Productive.io expires on January 2012

Email me at sami {at} bashraheel {dot} org

</comment></comment><comment><USER3> if someone is interested, i'm selling:

       cool.io
       vm.io
       boot.io

see profile for contact info (I'm an accredited .io Registrar myself)</comment>


Hilbert's paradox of the Grand Hotel - <AUTHOR> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel <comment><USER2> And here's a great book that explains it to children: [http://www.amazon.com/The-Cat-Numberland-Ivar- Ekeland/dp/081...](http://www.amazon.com/The-Cat-Numberland-Ivar- Ekeland/dp/081262744X)

<comment><USER3> I've posed exactly these problems to children about 15 times now. Most children 10 and up I've talked to can figure out the first (one more guest) easily enough, the second (an infinite bus of new guests) with a little help, and the third (infinitely many infinite buses) if I draw a picture.

It helps a lot to be precise and use concrete examples. "Hilbert has an infinite hotel. We have to be careful with infinities, though, so I'll tell you what that means. If you think of a number zero or bigger, any number at all, Hilbert's hotel has a room with that number on it. Think of a number. ('2 million!') Yep, he's got that room. ('Six googolpillion!') Yep, he's got that room."

"A guest comes into the hotel and asks, 'Mr. Hilbert, do you have one more room?' Mr. Hilbert says, 'Sure!' He picks up his magic phone that calls everyone in the hotel at the same time and gives all the guests exactly the same message. After they do what he says, there's one room empty. What does he tell them to do?"

When they invariably come up with "Move up one room," it helps to belabor a couple of points. First, reformulate it as, "Look at your room number, add 1, and go to that room." (This helps them figure out "Multiply your room number by 2" as the answer to the second problem.) Second, dwell on who goes where, and whether it's a problem. "Where does the guest in room 0 go? ('Room 1.') Doesn't that have someone in it? ('Yes. Oh, no it doesn't, because he went to room 2!')"

No child has figured out my favorite fourth problem, but then it took mathematics until Cantor to figure it out, too.

"An _uncountable_ group of people shows up at the hotel. Let me tell you what that means. They all have infinite name tags, all filled with As and Bs. Every possible name tag is in the group. [Give example names. Blow raspberries to do it.] The head of the group, whose name is 'AAAAAAAAAAAAAA...' [said with a blank look, trailing off] asks Mr. Hilbert if he has room in his hotel. Mr. Hilbert says 'No!' Why does he say that?"

Let them stew for a bit, and ask questions. Going on: "Mr. Hilbert says, 'OK, tell you what. If you give me a room assignment, I can always find someone you left out.' How does Mr. Hilbert do that?"

You can illustrate this with a game, using only four-letter names. Write down something like

AAAA BBAA BABA AABA

"Can you find a four-letter name that's missing?" Play this a few times, and then ask, "Can you come up with an easier way that doesn't make you think of all the names in turn?" Show them how to flip the letters along the diagonal, and then extend to infinite names.

I've had 2 kids and 1 adult follow this to the end. It's always mind-blowing for them, though, no matter how far they get. I follow up with this:

"That stuff they taught you in school, that stuff a lot of people say they hate, is _arithmetic_. This is math."

EDIT: Come to think of it, I actually helped a friend's 11-year-old daughter decide that she _didn 't_ hate math using these problems. She's probably still bummed about being stuck doing arithmetic for now, though...

</comment></comment><comment><USER4> >"If an infinite set can be put into one-to-one correspondence with the natural numbers (N) it is called a countable set. Otherwise it is uncountable."[1]

This paradox hinges on the strange notion of cardinality of infinite sets. Specifically, the set of all even integers, the set of all odd integers, and the set of all integers(!) have the same cardinality, and therefore the same "size".

\---

[1][http://www.math.ups.edu/~bryans/Current/Journal_Spring_1999/...](http://www.math.ups.edu/~bryans/Current/Journal_Spring_1999/mlaycock_300_s99.html)

</comment><comment> semi-extrinsic What's really cool is that physicists have recently been able to realize experimentally some of the room changing operations in Hilbert's hotel, using quantum systems:

[https://physics.aps.org/synopsis- for/10.1103/PhysRevLett.115...](https://physics.aps.org/synopsis- for/10.1103/PhysRevLett.115.160505)

</comment><comment><USER5> It seems to me that the only thing that makes this a 'paradox' or is counterintuitive is the idea that a hotel with infinitely many rooms can be full. Is there some math concept that allows this or is it just semantics? It sounds like some sort of "quantum" effect where there's only a room there if you look for it.

<comment><USER6> What is the math concept that allows for a hotel with infinitely many rooms in the first place?

One way of (somewhat) formalizing this is to say that you have a set containing infinitely many rooms, and another set containing infinitely many tenants. Intuitively, it does not seem unreasonable that you can give every room its own tenant. Once you do this, then the hotel is "full" in the sense it is impossible to find an empty room.

Of course, we can also think about giving each tenant her own room, which also seems possible. If we can do both of these things, we say that the set of rooms is the same size (or cardinality) as the set of tenants. It is worth noting, that not all infinite sets are the same size [0]. For the purpose of Hilbert's paradox, I believe it is far to assume that we are dealing with countably infinite sets [1]. The mathematical result in Hilbert's paradox is that if you add elements to a countably infinite set, the result is still countable infitite.

[0] [https://en.wikipedia.org/wiki/Cantor%27s_diagonal_argument](https://en.wikipedia.org/wiki/Cantor%27s_diagonal_argument)

[1] That is to say, sets which are as large as the set of natural numbers.

</comment></comment><comment><USER7> A related derivation of the "uncountably infinite" is Cantor diagonalization: [https://en.m.wikipedia.org/wiki/Cantor%27s_diagonal_argument](https://en.m.wikipedia.org/wiki/Cantor%27s_diagonal_argument)

Put in more concrete terms (hard to say when we are talking about infinities): there are an infinite number of integers. For each integer, there are an infinite number of real numbers (decimals) between n and n+1. For each of those doubly-infinite real numbers, there are an infinite number of complex numbers with that real component and varying imaginary components. And so on ...

In fact, there are an infinite number of infinities ...

It's turtles all the way down.

<comment><USER8> That's the clearest, most concise explanation I've seen for how different infinite sets can have different cardinalities. Thanks!

<comment><USER9> I don't think the summary in the comment is correct, though. There are also an infinite number of rational numbers between any given integer n and n+1, and indeed an infinite number of rational numbers between any two rational numbers, yet the cardinality of the rationals is still the same as the cardinality of the integers.

Diagonalization is brilliant, though!

</comment></comment></comment><comment><USER10> Maybe this is my ignorance of the understanding of countably infinite. But if a hotel has infinite amount of rooms, and all rooms are full. Then why would anyone ever show up to take another room.. To me it would seem that all persons are in the hotel already.

<comment><USER11> Imagine you have one person for each (positive) integer, given a unique integer ID at birth, and a hotel with countably infinite rooms, each with a unique room number.

The hotel could have someone in everyone room if every person with an even number as their ID was staying there. That is, for every room number, twice the room number is a unique even number, so there's a 1-to-1 correspondence between the number of rooms and the even integers.

You could then have someone with an odd number ID show up looking for a room, and would have to rearrange from a stay-in-half-your-ID lineup.

It's a (arguably defining) property of infinite sets that they contain a strict subset (at least one guy not in the subset) with the same "size" as the whole set.

So the evens and the integers are an example of this, with both having the same "size", even though the evens are contained in the integers.

<comment><USER10> But the paradox says...

infinite number of rooms are all occupied by a person.. then a person shows up. There is one to one ratio here... of all rooms are occupied by a person.. infinite rooms.. infinite people.. if the infinity of people are all ready in the infinity of rooms..

Then who is showing up? Everyone is already in the rooms.. So no need to worry about moving anyone.

If we change it to be numbers it still doesn't work.. If we have an infinite amount of slots.. and in each slot is a number.. and all slots are full.. how can we make room for another number..

If you say that oh well there were only even numbers in the slots.. well then what you told me isn't true.. all slots aren't full with numbers.. only even numbers..

I understand what the paradox is trying to explain about sets.. but to me it just falls apart as a metaphor.

<comment><USER12> If there were one person for every natural number, then you could put every even-numbered person in room n/2 (where n is the number for that person) and still fill up the entire hotel.

This is because even numbers are infinite, and you can find a one-to-one relation with natural numbers (just divide the even number by 2).

In that case, the infinite hotel is filled, _and_ you still have an infinite amount of people outside it that you can accommodate (the odd-numbered ones) :)

</comment></comment></comment></comment><comment><USER13> I like this paradox for it's simplicity, but there's just one aspect that cracked me up.

>Suppose the hotel is next to an ocean, and an infinite number of aircraft carriers arrive, each bearing an infinite number of coaches, each with an infinite number of passengers.

hahaha.

How would we extend that?

suppose we have an infinite number of passengers, carried by an infinite number of coaches, transported by an infinite number of aircraft carriers, shoved in by an infinite number of tsunamis, which occur on an infinite number of continents, on an infinite number of Dyson spheres...

</comment><comment><USER14> If you're interested in this subject, can I suggest _Everything and More_ by David Foster Wallace? (Yes, that DFW.) Sure, as some reviews describe in painful detail, some of it is mathematically sketchy. On the other hand, it's a pretty good discussion of issues around infinity, such as Zeno's (and everybody else's and their cat's) paradoxes (paradices? paradise?), and why a theory of the infinite is so darn necessary.

</comment><comment><USER15> Reminds me of the proof showing that the set of all fractions are countably infinite.

</comment><comment><USER16> Situations like these are where math stops being an enlightening view on relationships between quantities and starts being a pedantic chore.</comment>


How Seawater Can Power the World - <AUTHOR> http://www.nytimes.com/2011/07/11/opinion/11Prager.html

<comment><USER3> After actually looking at the numbers and the details regarding fusion technology, I've come to the conclusion that the advantages over fission are illusory.

I think people believe that fusion is somehow "way more powerful", because they know that fusion bombs are way more powerful than mere atom bombs. Actually, in many of the most powerful fusion bombs, the vast majority of the energy is produced by fission, with fusion serving as only an intermediate step to release neutrons and create more fission. A step you don't need in a reactor, which can control the fission rate itself.

My guess is that a lot of people who haven't looked at the numbers think that fusion is hundreds of times more powerful than fission. Well, let's look at those numbers: the fission of a uranium-235 atom produces 202.5 MeV. The fusion of D+T produces only 17.6 MeV. That's more energetic per unit mass of fuel, since D and T are just hydrogen isotopes, but if you do the math, it's only about 3.5 times more energetic even using this measure. And fuel mass is a tiny portion of the mass of the whole powerplant. To make it worse, hydrogen is far less dense than uranium (by a lot more than a factor than 3.5), so you actually end up with a lot more fuel volume and containment volume. There are other reactions than D+T, but none of them look as good as plain old fission. That's before we even get into the fact that for most fusion reactions, a lot of the energy goes into extremely dangerous neutrons.

The talk about "getting the fuel from seawater" is also misleading. It's technically true, but the process is very expensive, and, if we are going to talk about seawater, uranium can also be extracted from it.

Finally, the idea that the danger from proliferation would go away is also false - anything producing a neutron flux as strong as a fusion reactor can be used to produce isotopes suitable for a bomb. And even aneutronic fusion (which is technically even more difficult) can be made to produce neutrons with suitable additions to the fusion fuels.

EDIT: P.S. I am not an expert. I do think I can understand numbers and technical arguments, and I would love to hear expert analysis. But one thing: for every technology which you assume will help fusion (such as wonder- containments for the neutrons), please analyze how fission reactors would benefit from it, as well. Then let's see if we can make fusion come out "better" than fission in some meaningful sense.

EDIT: I can't resist adding that the talk of "harnessing the reaction that powers the Sun" is aimed at people who don't know the numbers, and is very annoying. The Sun is not a good model; it has a huge mass (duh), and a tiny surface-to-mass ratio, which is why the energy it produces makes it so bright. But pound-for-pound, the Sun produces a lot less energy than _slightly warm chicken soup_. Do the math yourself, and be surprised. We can not build a reactor that works like the Sun.

<comment><USER4> I've never thought if the advantages of fusion power in terms of "more powerful" than fission, but rather "less dangerous," "cleaner," and "more sustainable."

The problem with fission is that the fuel is really nasty stuff that requires all kinds of special precautions when you mine it, when you process it, and when you dispose of or recycle it. Even when you shut down a fission reactor, you still have a bunch of highly radioactive material sitting there that has to be dealt with. Also, the world will eventually run out of uranium, just like it will eventually run out of fossil fuels. I'm not going to try and predict exactly when that will happen (I'm guessing probably not in my lifetime), but it _will_ happen eventually.

Fusion, on the other hand, uses hydrogen as fuel and leaves you with helium as waste. I don't know what kind of radioactive isotopes come out of fusion, but I'm willing to bet that, unless you're deliberately trying to produce them, you probably get way less than you do with a fission reactor. In short, waste disposal for a fusion reactor is trivial compared to a fission reactor, and when you shut down a fusion reactor the radiation hazard pretty much goes away immediately. Hydrogen is also a lot more common than uranium, so long after all of the uranium is gone we'll still have plenty of hydrogen around.

<comment><USER3> I understand that this is the promise, but it all starts to sour once you look at the details. The most commonly proposed fusion reactors use D+T fusion, which produces hugely energetic neutrons, the most dangerous kind of radiation that you can think of. You need hugely thick walls to contain these neutrons and be heated up by them, and some kind of system to extract the energy from the walls. And yes, the walls and the extraction system end up radioactive, and now you have this huge radioactive mass to take care of somehow, instead of tiny pellets of spent fuel in their cladding. You have other problems for other reactions. Again, the devil is in the details here, an individual fusion reaction might look good, but by the time you include everything else you need, not so much.

Also, any system of safety and containment that will make this look good, will make fission look even better.

<comment><USER5> yaakov, you are fighting strawmen. When we look at nuclear fission reactors, we note 4 major types of problem.

1) Meltdown. Chernobyl, Fukushima, TMI. This type of problem can't happen with fusion reactors, as the reaction stops as soon as reactant stops being fed in. This is not the case for fission, because of the need to attain near-critical mass before the chain reaction can occur.

2) Waste disposal. As fissile material is consumed by a fission reactor, the resulting waste products are still highly radioactive. This waste has to be stored safely (the famous cooling pools from Fukushima were the first step in this process), for very long periods of time, generally measured in decades and centuries.

3) Fuel availability - there are not huge quantities of fuel-quality fissile material available on Earth. This limits it's usefulness going into the future

4) Theft of fuel - although reactor fuel is not generally very useful for bombs, sometimes the waste is. Some reactors, eg breeder reactors were in fact designed to generate bomb material, more so than to generate electricity.

Have a look at that list, and think about how it applies to nuclear fusion. Meltdown is impossible, waste disposal is far easier (it's just the reactor's shield that gets radiated, which is a much more contained problem than that of radioactive reaction by-products. The amount of fuel for a fusion reactor on this planet is just huge, and you can't make bombs out of the material coming in or out of a fusion reactor.

These are the reasons that fusion reactors are highly interesting, not because of the possibility to generate more power.

<comment><USER3> I am arguing with the sort of vision of fusion power that's presented in popular articles, like the NYT one that started this thread. "Clean power that powers the Sun" - yup, he said that. A senior scientist who knows the numbers. See below in the thread how relevant this is. "Relies only on seawater as fuel" - check. "Offers no chance of a catastrophic accident" - oh come on, even a coal powerplant offers that.

Articles like this _are_ a strawman, and Stewart C. Prager, director of the Princeton Plasma Physics Laboratory, knows better and should be ashamed of himself. To take up just the matter of catastrophic accidents: it is said correctly that a fission powerplant can never explode like a fission bomb - the atoms of fuel are in the wrong arrangement for that. But any continuous system for producing fusion power is theoretically capable of "running away" - it is a self-reinforcing process, after all - and producing an actual nuclear explosion. They will design it to make this spectacularly unlikely? OK, sure they will, but let's not talk about this being danger-free.

Or the "fuel from seawater" thing. Seawater contains 3.3 ppb of uranium, and it would be commercially feasible to extract it if the prices were higher. It's actually easier to do this than to design fusion reactors. And you can use more advanced fission cycles, especially the thorium ones, to extend the energy you get out of fission fuels.

EDIT: let me clarify the actual quote from Dr. Prager that I am complaining about:

 _Harnessing nuclear fusion, the energy that powers the sun and the stars, has been a goal of physicists worldwide since the 1950s. It is essentially inexhaustible and it can be created using hydrogen isotopes — chemical cousins of hydrogen, like deuterium — that can readily be extracted from seawater._

This is so incredibly misleading in many ways, without containing an actual false statement. This kind of manipulation of popular opinion makes me angry. Does anyone want to defend this, even as a popularization?

<comment><USER6> _Or the "fuel from seawater" thing. Seawater contains 3.3 ppb of uranium, and it would be commercially feasible to extract it if the prices were higher. ... And you can use more advanced fission cycles, especially the thorium ones, to extend the energy you get out of fission fuels._

Indeed. There's about a factor of 100,000x right there -- 500x for increased uranium supply (5e9 tons in oceans, vs. 1e7 tons in "conventional" <$130 kg/ton reserves (IAEA est.)), and 200x for increased fuel efficiency.

 _But any continuous system for producing fusion power is theoretically capable of "running away" - it is a self-reinforcing process, after all - <USER2> producing an actual nuclear explosion._

Don't think this is true. Fusion plasmas need active confinement -- a hotter plasma is no longer confined, and will no longer fuse.

 _This is so incredibly misleading in many ways, without containing an actual false statement._

For example, the limited resource is not deuterium but tritium (a misdirection). The plan to create this is by fissioning lithium, which is actually a rather scarce element (comparable with uranium, ironically). To get more interesting sustainability you need to switch to something like D+D fusion, which is much harder to achieve.

<http://en.wikipedia.org/wiki/Tritium#Lithium>

<comment><USER3> Thanks for the correction about runaway fusion reactions. Does this only prevent it from doing a "Ivy Mike" on us, or can they actually make it passively self-regulating to the point that it can't breach the containment?

I still think he is being disingenuous when he says that there is no danger of accident with fusion reactors. Proposed designs have huge irradiated masses and very large neutron fluxes. There is going to be a ton of active safety systems needed, any way you imagine it.

<comment><USER6> There's also the fact that the plasma has extremely low density, so there is very little fuel in the core at a time:

"Less than 1g of fusion fuel is present in the Vacuum Vessel at any one moment."

<http://www.iter.org/mach/fuelcycle>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I wonder why so many people insist that there has to be a "winning" technology. So someday all of the world must commit to generate energy from nuclear fusion (despeite the horrendous cost and quite modest results scientists have to offer for the money spent) rather than harnessing the cheapest easiest energy sources around. Big Fusion (ITER style) looks more like a government program to employ physicists than anything really practical, something like "we already spent so much on this it would be foolish to stop now".

Not to mention the writer forgets there are countries without seashores. How are they supposed to generate their energy in this fusion-driven utopia?

<comment><USER5> What would you suggest as an alternative base load technology?

<comment><USER7> I would go for thorium fission. As it seems, it's orders of magnitude easier to implement than deuterium fusion. Fusion is safer, I agree, and we should not abandon the research, but developing a thorium cycle for now instead of betting money on an uncertain approach to energy generation is, IMHO, smarter. As a civilization we need more energy (and, if climate changes faster, we'll need more) and we need on a predictable schedule.

Fusion has been about the same number of decades (two) away since I was a young boy. I don't think it deserves the faith we are depositing in it. Much like space colonization and jetpacks, it is a broken promise.

I'd also not forget other alternatives like molten-salt solar, hydro, wind and even photovoltaics that can offset some of the needs for power generation.

</comment></comment></comment><comment><USER8> Fusion power has been 20 years away for the past 50 or 60 years according to the top scientists in the field at the time. I suspect there's a good chance that in 20 years, it will still be 20 years away.

<comment><USER9> I hear the statement: "Technology T is Y years away", all the time, it is usually is just speculation and wishful thinking.

I would rather people replace that overused line with the statement: "Technology T has barriers B, C and D preventing its successful implementation and mass production". Leave feel-good speculation out of it and focus on overcoming the obstacles.

<comment><USER10> I would imagine talking to lay-people in terms of road-blocks instead of hypothetical times would cause a net reduction in funding, and these kinds of articles are all about funding.

</comment></comment></comment><comment><USER11> I keep hearing "fusion" and keep wondering if we shouldn't go for the thorium route first. It's safer than fission w/uranium and can even be taught to third world countries without fear of giving them nuclear bombs.

<comment><USER12> Less proliferation risk, but not zero. It's still possible to build a bomb from U233 (obtained from the thorium cycle).

<comment><USER13> At this point in time, how much additional risk does it add though? Any nation-state that is bound and determined to develop nuclear weapons pretty much just does it (e.g. Iran, North Korea) and the supposed anti-proliferation watchdogs (UN, IAEA) pretty much just stand on the outskirts and say "please stop," which has about as much effect as you'd expect.

<comment><USER12> The thorium cycle is a higher technological level and more expensive to develop, so a state capable of developing one is more than capable of a conventional uranium bomb program.

<comment><USER11> But the way I understand it is that Thorium-based fission is more costly to weaponize than uranium, or plutonium based fission.

Might be more technical, but it should be able to be operated without such a high technological level. So you could sell a system to a third world country without a great deal of concern over their nuclear capabilities.

</comment></comment></comment></comment></comment><comment><USER14> If Asian countries are enthusiastically funding the research, why couldn't the US just license the technology after it is developed?

<comment><USER6> How would the director of the Princeton Plasma Physics Laboratory benefit from that?

<comment><USER15> Version 2.0.

</comment></comment></comment><comment><USER16> >A rough estimate is that it would take $30 billion and 20 years to go from the current state of research to the first working fusion reactor. But put in perspective, that sum is equal to about a week of domestic energy consumption, or about 2 percent of the annual energy expenditure of $1.5 trillion.

Millions of years from now after the human race fails and alien archeologists are picking apart the carcass of its long-dead civilization, they are going to find an _enormous_ number of exactly these circumstances. From education to space travel and power generation this kind of folly is so ubiquitous that it is more newsworthy when it _doesn't_ happen. There must be some aspect of human and group psychology that ensures it. As such it's hard to have much hope for the future.

Just kidding about the aliens though. It's unlikely any would ever discover our ruins.

<comment><USER12> Large infrastructure projects are wasteful no matter how you cut it, so at least they should have precise objectives (much shorter than 20 years) and per-objective pricing (rather than cost-plus).

<comment><USER16> How are they wasteful 'no matter how you cut it'? What if the cut is more efficient energy production, or access to plentiful resources, or freeing the fate of humanity from the fate of its home planet (everyone here should appreciate separation of concerns). And why twenty years? Why rule out a concrete multi-generational goal (assuming humanity can ever achieve that level of social organization first) which has a large payoff and reasonable chance of success?

<comment><USER12> _Why rule out a concrete multi-generational goal?_

The project would be doomed to failure without intermediary objectives. Long term planning is difficult as it is and politics adds to the implausibility.</comment></comment></comment></comment>


Drive In Complete Control In All Conditions - <AUTHOR> http://www.geekyedge.com/drive-in-complete-control-in-all-conditions/

<comment><USER2> What does this have to do with anything relevant to HN readers? Also, why do over 1/2 of your submissions point to geekyedge.com? Are you affiliated with them?

<comment><USER3> It's spam. Look at the very last line of the "article".

Flag it and move on.

<comment><USER2> I figure on checking before flagging all the back posts. Just in case I have a false positive. Which happened a couple of weeks ago. Anyway, flagged now.</comment></comment></comment>