Hacker Newsnew | past | comments | ask | show | jobs | submit | timvisee's commentslogin

A VPN won't make your route shorter

It actually can, depending on where it is. Paperclip optimizers don't optimize for route length - they optimize for paperclips received. When Vodafone or Deutsche Telekom gets your packet, they try to send it to one of their customers, because their customers pay them to receive traffic, even when it's a longer route.

If you're sending a packet from German Shittytel to German Okaytel, and Okaytel just happens to buy a connection to Singapore from Asiatel to get packets to Asia, and Singapore Internet Corp just happens to buy a connection to German Shittytel to get packets to Europe, they'll be glad to send your packet all the way to Singapore so Asiatel will have to pay them for it. But if you sent your packet to a VPN server in Berlin with a neutral peering with both ISPs, the packet would take a nearly common sense route.

In practice, these situations don't happen, at least not this extreme. Partly because ISPs are trying their best not to be the recipient of this. Okaytel doesn't want their packets to be round-tripped through Singapore - that's a bad user experience and they're ultimately paying for it in money as well. So they might negotiate with Asiatel that Asiatel won't tell Shittytel that it's able to deliver packets to Okaytel - in fact there are often BGP attributes they can set to do this automatically. Business is incredibly cut-throat and incredibly stupid. I guarantee Shittytel has a lot more money than Okaytel because they are better at "extracting value". Not only the ISP business is like this btw.


If the shortest route is congested, a longer route can be advantageous if it avoids congested hops.

It can.

Datacamp, which hosts lots of them has very good peering


The email I have in that list is invalid and must be generated. It's on a domain I own.

I'm seriously impressed on how far this has come. Tried a few websites in the experimental mode, it renders quite well.


If not now, maybe in the future


I do have a good use case for magic links.

I creates a bar management/sales platform for our group of friends. It's self service so people purchase their products on their phone and pay later.

People get... intoxicated... after which passwords appear to become quite the problem. Magic links solved that.

To solve the multi device and in-app browser problem people can also open the links on another device. That'll show a short code they can enter on the original device to actually log in. It's not perfect, but it works.

I do fully agree that passwords should always be an option as well.


I always feel rendering such blurred panes takes quite a performance hit. Do we have any numbers on this?

I might just be old - when this was done on the CPU.


While I agree FOSS doesn't give you the right to users money.

It is especially painful if (big) companies make big money with your free product.


`git rebase --onto FIRST_ID^ NEW_PARENT`

is also super powerful to put a series of commits on top of a new parent when history has changed.

That happens with PRs and squash merges quite often.

https://stackoverflow.com/a/29916361/1000145


Does it still do this when piping into things?


It does for me. Firefox on Android.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: