Langsec explained in a few slogans - <AUTHOR> http://www.cs.dartmouth.edu/~sergey/langsec/occupy/ <comment><USER2> > Every piece of software that takes inputs contains a de facto recognizer for > accepting valid or expected inputs and rejecting invalid or malicious ones.

This should be expanded: Langsec isn't about adding complexity so much as it's about getting the complexity right.

You say you want a revolution, well, you know, those things have a way of coming back around. In this case, your "revolutionary" ideas about YAGNI and Do The Simplest Possible Thing have already occurred to others, and they're the ones who wrote the parser libraries you're so sure you're not going to need.

All you need is a simple lexer and some extra state... and a little more extra state, with a bit of recursion to get nesting right... and now you're unsure how string escapes should work...

The end result isn't an input language without grammar. Every language has grammar. The problems come when nobody actually knows what that grammar is. Because if you don't know, you don't know if one of your grammar's productions is INSERT ZERO-DAY HERE.

So Go YAGNI Yourself and use some pre-written code, or at least act as if you did by writing an actual grammar first and then implementing it, and then implement it again, _correctly_ this time. Your users will thank you.

</comment><comment><USER3> I feel like this focuses too much on the recognizer than it does on the implementation of the language itself. Sure, given a grammar you can implement a correct parser that accepts only valid inputs. This doesn't really buy you anything if your implementation contains a bug though. It's like an undergrad compiler course that spends all its time on parsing and how great it is then tells you almost nothing about the actual meat: the middle- and back-ends.

Is your position that formally specifying the input language is a necessary first step toward formally specifying the language (operational/denotational) semantics, and eventually having a provably correct implementation? If so, why stop short at just talking about the parser when that's typically the least complicated part of any interesting input format?

</comment><comment><USER4> neither necessary nor sufficient. you can have a "turing complete" input with no exploitable bugs (or really, no bugs at all) and you can have a very simple recognizable and computationally limited input that has all kinds of crazy buffer overflows.

the story is about abstractions and security boundaries. what is it that allows an application to write a value of type A to a location expecting type B? why is this expressible? the langsec focus on inputs and parsers is missing the forest for the trees.

<comment><USER5> All Turing complete inputs can be attacked by sending an non-terminating program. You could limit the amount of time an input is allowed to run, but then it's no longer Turing complete.

<comment><USER4> it turns out that every system we've ever devised has had a limit on the amount of time the input is allowed to run, so this really seems more like a matter of degrees. this is also only an "attack" if the availability of the system is an invariant that is relevant from a security perspective. usually, we care much more about confidentiality and integrity and absent termination sensitive noninterference (which is a different problem that langsec wholly ignores and has nothing to do with the complexity of the input), i'm not sure how the termination of a program will have any impact on its confidentiality or integrity...

<comment><USER5> DoS isn't an attack? I agree it's less severe than leaking credit card numbers, but availability is a big deal in many applications.

<comment><USER4> if DoS was the only problem we had to worry about, we would have won.

</comment></comment></comment></comment></comment><comment><USER6> I think the unix philosophy is the model to follow here. Design an input method just capable of receiving the information and let other applications process your input. Input is also about context, in which case you need to process an input to context prior to an input in a context.

Example: Context = Numeric question about integer numbers and four operators, +, - , _, /

input = r'[0-9,\\+,\\-,\_,\/]'

</comment><comment><USER7> I'm thinking about this and I'm finding it hard not to read it as a direct violation of the robustness principle. I'm probably reading it incorrectly but where am I going wrong here?

<comment><USER8> You're totally right! Security practitioners hate the robustness principle! This article, for instance, contains a small rant.

[http://noxxi.de/research/http-evader- explained-8-borderline-...](http://noxxi.de/research/http-evader- explained-8-borderline-robustness.html)

At a minimum, the robustness principle leads to exploitable parser differentials (filter bypasses such as the above being the most minor form). When you've already determined the data doesn't meet your assumptions, it's really easy to make a mistake in handling it, leading to memory corruption etc.

Don't try too hard to be robust! Call broken data out for what it is!

<comment><USER7> I mean I think I do see that side of it, but the robustness principle is highly pragmatic. I think if HTML parsing was completely strict then the internet might not exist.

It's an adage born from the fact that if you aren't tolerant in what you accept, you end up accepting very little. Especially when the people trying to create valid documents are not highly skilled or knowledgeable about why it can't "just work."

Of course, all of security is about tradeoffs like these, because an ideally secure computer is one that isn't turned on. The robustness principle may be a nightmare from a security standpoint, but so is JavaScript, Java plugins, Flash other assorted NPAPI crap, and basically anything else having to do with the internet.

<comment><USER8> You probably won't see this response, but in case you do:

I see what you're saying, and I'm not going to criticize decisions people made more than a decade ago, but we've outgrown the robustness principle.

You should not be tolerant of accepting bad input to coddle your users. You should write simpler languages (so the effort they must put in is reasonable) and better development tools (so they understand their mistakes). Even if you decided to let HTML be "robust" since it comes from humans, why would you let an HTTP client or server emit broken headers?

The real problem with the robustness principles is that it has short-term benefits and extreme long-term costs. Today it means that you can open up netcat and talk to Apache without using CRLF linebreaks (as per the spec). But next year, and the year after that, and the year after that, you'll have to support increasingly noncompliant legacy implementations.

We write specifications to make things concrete. The robustness principle, over time, creates a "shadow standard" one must abide by, putting bad code into your project to support the bad code everyone else has been writing because we _let them do it_. Maybe it makes Firefox better able to process its inputs but it makes the web as a whole fragile. It does not make broken data any less broken, it simply silences errors.

In short, it is neither robust nor principled.

Security is about tradeoffs, but after so much time building broken systems, it's time to realize that this tradeoff is not reasonable.

<comment><USER7> HTTP clients and servers should absolutely not emit broken headers, but that's a violation of the robustness principle of itself.

The way I think about it is imagining how many websites I use daily just _wouldn 't work_ if HTML parsing were completely strict. I regularly open up Dev Tools to see which of the websites I visit work without CSS or HTML parsing errors.

My primary concern is that there needs to be a way to implement strict parsing that doesn't greatly raise the barrier to entry or make the product unusable. I do think a lot about this but it's nonetheless confounding from both perspectives and I think the usability of strict parsers needs to be addressed, whether that means better error messages or really good linting or whatever.

</comment></comment></comment></comment></comment><comment><USER9> The last one is a little misleading. While the equivalence problem for two such parsers is undecidable, this just means that some pair of parsers are identical but cannot be proven such--for many pairs such a proof exists.

</comment><comment><USER10> Link is dead but there seems to be a mirror on the langsec website itself:

[http://langsec.org/occupy/](http://langsec.org/occupy/)</comment>


How To Lose Friends And Alienate Twitter Followers - <AUTHOR> http://www.fastcompany.com/1822211/how-to-lose-friends-and-alienate-twitter-followers-5-stupid-social-media-mistakes

<comment><USER2> So, basically, if you apply common sense to Twitter, everything will work out fine. While this may seem to be an obvious fact, unfortunately, a lot of people seem to forget that.</comment>


ToffeeScript – CoffeeScript with async syntax and some additional features - <AUTHOR> https://github.com/jiangmiao/toffee-script <comment><USER2> I've never really understood the problem with "callback hell" that people talk about. The biggest annoyance I've seen from it is that indentation can get a little out of hand, but the examples I've seen could be fixed with smarter coding rather than new language features.

<comment><USER3> well, imagine you have 4/5 sequential db calls, and for each async call need to write a success callback and a failure callback ... async lib helps though defer/await programming style would be a better option.

</comment></comment><comment><USER4> It looks like a CPS transform, which can be very useful; but I think it's something you'd rather opt in to rather than apply everywhere.

</comment><comment><USER5> Is there something similar (i.e. syntactic sugar/macros for defining callbacks that provide similar functionality) for "plain" javascript as base language?

<comment><USER6> StratfiedJS ([http://onilabs.com/stratifiedjs](http://onilabs.com/stratifiedjs)) does this and more[0]. It's more heavyweight than a set of macros, but we believe the features warrant that.

[0] including a module system, fork-join parallelism, try/catch and stacktrace support even for async code.

(disclaimer: I joined Oni Labs to work on SJS, after struggling with my own coffeescript fork for 6 months)

</comment></comment><comment><USER7> Could someone please explain what's Callback hell and why Toffee-script is doing to resolve it? The compiled JS code looks harder to read than using callbacks to me.

<comment><USER8> "Callback hell" is when you need to do many asynchronous actions / call several asynchronous APIs with inputs to each call depending on the delayed results of some other call(s), and you are using callbacks to organize your control flow. Often you end up with either a large set of named functions being passed around as callbacks, or a deeply nested hierarchy of anonymous callbacks. Either way, control flow can be difficult to follow or reason about, both when reading the code and when debugging. Even simple tasks take large amounts of boilerplate code.

The generated code _is_ using callbacks. The point is that instead of writing something like (a cleaner, but still ugly, version of) the generated code on the right, you'd instead write the (quite easy to read) toffeescript code on the left.

That said, I think coffeescript's "it's just javascript" slogan (and goal of generating readable code) is one of its most important features. It has to be quite a bit harder to debug than the coffeescript version, since the generated code has control flow that's so different looking from the input.

<comment><USER9> What did you use to create the generated JavaScript? I'm still new to this and trying to figure out out.

<comment><USER10> toffeescript is a language which has a compiler that generates Javascript.

</comment></comment></comment></comment><comment><USER11> [http://opalang.org/](http://opalang.org/) has something like that. I do find it a lot easier than all other proposed solutions so far. Wish a language like Clojure(script) would have something like this for general use with async processes/callbacks (in Java/.NET running threads, in JS this).

<comment><USER12> You might want to take a look at Javelin. It sounds like that's what you're looking for. The talk InfoQ talk about it is probably the best place to start.

<comment><USER11> Thanks, I'm checking that!

</comment></comment></comment><comment><USER13> Is this just like C#'s async, F#'s mon^H^H^H workflows aka computation expressions, Haskell's do notation?

<comment><USER14> Not at all in the case of Haskell whose IO is automatically async. You write IO in a normal blocking style and your current thread will automatically be suspended and resumed. You are just required to do it in the IO monad since the language is pure.

</comment></comment><comment><USER15> While it may be slick, it does violence to the call stack which will grow tremendously with the size of your functions. Plus, it's very hard to optimize any of the generated code since it contains so many jumps and context switches.

</comment><comment><USER16> I'm actually more excited about the Ruby-style pattern matching. The last time I had to do that in Coffee I was wishing for that syntax.

I'll need to see more real world examples to decide if Toffee's async syntax is better than Iced.

</comment><comment><USER17> I don't understand what the Basic example is supposed to do:

var x, y, _this = this;

a(b, function() { x = arguments[0], y = arguments[1]; return console.log(x, y); }); ReferenceError: a is not defined

<comment><USER10> a is a function which would already be defined at this point. Anything after the exclamation point is arguments to the callback function. Any following code is wrapped in an anonymous function passed as the final argument to the function a.

Anything on the left-hand side of the assignment (in this case, x and y) are arguments passed to this anonymous function. A concrete example of why you would do this would probably be useful.</comment></comment>


A JavaScript NES emulator - <AUTHOR> https://github.com/bfirsh/jsnes <comment><AUTHOR> A JavaScript NES emulator. [https://jsnes.fir.sh](https://jsnes.fir.sh)

It's a library that works in both the browser and Node.js. The browser UI is available at [https://github.com/bfirsh/jsnes- web](https://github.com/bfirsh/jsnes-web).</comment>


C++ Library for Linear Algebra on Supercomputers - <AUTHOR> http://libelemental.org Elemental is an open-source C++ library meant for performing dense linear algebra on tens of thousands of processes (via the Message Passing Interface). I have been the primary developer for the past four years, but a community is starting to emerge. In addition to the website, the project is also hosted on github: http://github.com/elemental/Elemental <comment><AUTHOR> I'm happy to answer any questions about the pros and cons of the library (and to remain quite objective). The main feature that the library currently lacks that is available in ScaLAPACK is a parallel Schur decomposition, but one is in the works.

I'm also happy to answer general questions about parallel linear algebra and to point people to the appropriate literature.

<comment><USER2> Do you see this getting put into the ACTS toolkit ([http://acts.nersc.gov/tools.html](http://acts.nersc.gov/tools.html))? I see some on your project team are at Argonne, which would seem like a natural fit.

<comment><AUTHOR> Honestly, I doubt it. Getting added to such a list has both political and merit-based components.

<comment><USER2> Interesting. I had the impression it was just meant to be a repository for DOE-related numerical tools.

That's a shame, because having collections of useful tools like that makes it a lot easier to keep track of options.

<comment><USER3> Given that a few dozen US-based students attend ACTS every year, I hardly see how it is a game-changer w.r.t. the widespread acceptance of Elemental. I think the internet is doing just fine so far.

</comment></comment></comment></comment></comment><comment><USER4> Great.. another C++ linear algebra library...

      boost::uBLAS
      eigen
      armadillo
      a dozen other...

why not contribute to an existing project?

The reoccurring bifurcation of talent and resources in the open source community is really disheartening. Can't we focus on one or two libraries and make them actually good? Or at least fork off of something that already exists and add your own features. I look at benchmarks of the existing tools and one library will do one operation very efficiently, while another will work well with something. Often the differences in speed are huge (more than a factor of 10). So I end up having to flip a coin in choosing which library to use.

<comment><AUTHOR> With all due respect, did you even read the title of the post? This is a distributed-memory library, unlike all of the ones you just mentioned. This is a fundamental difference in design and capability. The only related libraries are ScaLAPACK, PLAPACK, and DPLASMA.

<comment><USER4> And why exactly can't that be made part of an existing library?

<comment><AUTHOR> Essentially all distributed dense linear algebra libraries are built on top of sequential dense linear algebra libraries (mine as well, but on the interface rather than the implementation). Distributed libraries are at least an order of magnitude more complex than their sequential counterparts.

<comment><USER4> I guess I don't get what you're saying:

the C++ linear algebra libraries are basically syntactic sugar for interacting with optimized Fortran libraries like BLAS, LAPACK, etc. (I'm sure I'm overlooking some complexity here, because the C++ libraries, while linking to the same Fortran libraries have very different run times)

Yours interacts with ScaLAPACK and other distributed memory libraries.

Why would it not be possible to simply extend say armadillo or eigen to interact with distributed memory libraries? If you need more syntax, then extend the interface.

<comment><AUTHOR> Elemental _implements_ , as opposed to wraps, the distributed-memory algorithms. In other words, it does not call any library like ScaLAPACK; it is an alternative approach. Elemental builds on top of BLAS/LAPACK/MPI in order to provide a nice interface to dense linear algebra on clusters/supercomputers.

The other major difference is that sequential libraries tend to get away with letting users not have to worry about where data resides. This is of fundamental importance in distributed libraries, and, for this reason, it is usually a bad idea to think of simply modifying sequential APIs.

<comment><USER4> So why not contribute to (or extend) say ScaLAPACK to make it do what you need and add a wrapped to an existing linear algebra library?

Looking at ScaLAPACK, it's been developed since 1995. I've never touched it, but it's probably many many lines of code (and maybe a few PhD thesis) with all sorts of kinks worked out that will take you decades to iron out yourself. To throw out all that knowledge/work/man-hours and to start from scratch seems like a waste.

<comment><USER5> Because ScaLAPACK has a cumbersome interface, poor internal design, relies on incorrect premises that affect performance (block cyclic vs. elemental cyclic), and is buggy. In contrast, Elemental is a joy to use and is almost always faster, often by a large margin (see the Elemental paper). Elemental is not a toy project by any means; it is already the basis for a large share of the interesting parallel linear algebra research and is used by many important applications. Jack is currently the best researcher/implementer in the direct linear algebra world. Anyone that knows me knows that I am a critical bastard that does not throw such praise around lightly.

<comment><AUTHOR> I appreciate the complements, but I disagree with a few of your points:

1\. What granularity to distribute the entries in the matrix is a long and subtle argument which doesn't provide a clear winner for every operation (the current conclusions are different for LU with partial pivoting vs. reduction to tridiagonal form). I would by no means say that the approach used by ScaLAPACK is _wrong_ , but only that it is unnecessarily complex and only one operation purposefully targets the finest granularity case.

2\. Again, I appreciate the complement, but I don't think that arguments from authority are valid, nor do I think that one can be the "best". I have a large number of colleagues doing wonderful work, much of which I find extremely impressive.

Also, it would be good to disclose that you're affiliated with the project you were promoting.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Without GPU support I don't see how this is a good idea, if we are talking about HPC applications. Based on my understanding, a large number of dense matrix operations can be significantly accelerated in GPUs.

<comment><USER2> This targets distributed-memory applications, so it's not clear why failing to support GPUs with the first iteration makes it a bad idea.

I imagine the authors could make a single node of the cluster use a GPU, if they wanted.

<comment><USER6> Maybe I should have just said that I think GPU support would be a great addition.

Distributed memory and GPUs are not mutually exclusive. Multi-GPU clusters are extremely common. In fact the latest devices (e.g. Tesla K10) have multiple GPU processors packaged in a single card, so it is necessary for applications to target multiple GPUs. There is explicit support for distributed-memory applications in GPUs through the "GPUDirect" technology that allows peer-to- peer DMA and RDMA transfers between GPUs.

Given that reports of 30-50x GPU performance gains (versus CPUs) are common, the issue is important because it means solving a problem with (say) $10,000 of kit instead of $500,000.

<comment><USER5> 30x to 50x claims are the result of a terrible CPU implementation. When normalized by power consumption (e.g., TDP) or by acquisition cost (assume high-end rather than consumer versions, as with all supercomputing centers), you'll find about a 2x advantage for operations like DGEMM and much less for other operations. Strong scaling is important for many super-computing applications and accelerators like GPUS and Intel MIC are much slower for that purpose.

For examples, look at the MKL benchmarks for Xeon Phi ([http://software.intel.com/en-us/intel-mkl/](http://software.intel.com/en- us/intel-mkl/)) and normalize as 3 Sandy Bridge sockets per Xeon Phi (common configurations pair one SB socket with one Xeon Phi, the Phi has more than twice the TDP and costs more than twice as much). Don't forget to look at QR and Cholesky, for which the Phi at best breaks even, but only for enormous matrix sizes.

<comment><USER7> It may sound strange, but one of the advantages of GPUs is actually the programming model, hence why many applications suddenly perform 20-50x faster instead of only the theoretical 5-7x.

Let me explain: One of the most common issues with x86 HPC applications coming from the scientific crowd is a lack of vector optimization such as loop unrolling. Even having the right compiler flags is rather difficult for this kind of thing. Another reason is a lack of understanding on how to program for memory bandwidth optimization. GPU programming on the other hand, especially with CUDA, is hard to get into at first, but once you have the right formula you can apply it pretty easily to most common tasks. Getting to, say, 70% of model performance on GPU is _much_ easier than on x86. One reason is the implicitly bandwidth optimized idiomatic way of writing CUDA/OpenCL programs as a set of scalar kernels applied over a whole data region - this allows the programmer to think of block dimensions in an abstract way - no need to fiddle around manually with loops to achieve this. There is also no need to use any intrinsics, just plain C in idiomatic CUDA is enough.

So, to wrap it up, there is more to GPU programming than just the hardware itself, the software model actually makes a lot more sense than traditional OOP/procedural programming for HPC - often resulting in higher than expected speedups when going from idiomatic x86 to idiomatic GPGPU (since there is no such thing as easy to learn idioms for HPC x86 programming).

And btw. Xeon Phi is the result of Intel not understanding exactly this interrelation, since it doesn't even have OpenCL support as of now.

<comment><USER5> This is actually very subtle. Intel's OpenCL stack is currently atrocious, but if they ever make it decent, it will be able to vectorize. The problem is that vectorization is only part of the equation and many (likely most) applications today are limited in some way by memory and/or communication rather than by vectorization. Meanwhile, vectorization is generally at odds with memory bandwidth. CPU cache, shared memory on a GPU, and registers on a GPU are limited and vectorization usually leads to less effective use of these precious resources. Additionally, many kernels have inconvenient dependencies (e.g., an 30-term equation of state, a 70-species reaction mechanism) that force extremely low occupancy for typical GPU implementations (e.g., one thread per quadrature point). If you try to make the parallelism finer grained to reduce the register demands (break the quadrature point into several parts), you either need physics-dependent decomposition within a thread block or multiple kernel invocations (higher latency and needs to reload from memory). All of these things are counter-productive for strong scaling. Recall that a lot of applications are run near the limit of strong scaling and that CPU network latencies are in the microsecond range while GPU kernel launch overheads start at 20 microseconds (and you likely need several of them per inter-node communication).

While it's true that there are kernels that are easier to optimize for a GPU, I still think most claims of huge speedup are due to neglecting the CPU implementation. See "Debunking the 100x GPU vs CPU Myth" and other papers on this. And amidst all of that, there are a lot of applications that utterly fail on GPUs, despite having lots of parallelism, just not at quite the right granularity.

</comment></comment></comment></comment></comment></comment><comment><USER8> Nice work, this is important stuff. Next step... sparse linear algebra!

<comment><AUTHOR> Thanks! I actually work on a lot of fast/sparse linear algebra. For example, see Clique: [http://github.com/poulson/Clique](http://github.com/poulson/Clique)

<comment><USER8> Interesting, a direct sparse solver (for structured sparse matrices?). The name "clique" implies graph theory, so I was expecting to see distributed iterative SVD. I've yet to see a good distributed SVD for huge real- world/power-law graphs.

<comment><USER9> SLEPc, [http://www.grycap.upv.es/slepc/](http://www.grycap.upv.es/slepc/), has distributed SVD for sparse matrices.

<comment><AUTHOR> Yes, I should have mentioned this. SLEPc has the only distributed implementation of partial reorthogonalization (the key component of high- performance Krylov SVD and Hermitian eigensolvers) that I'm aware of.</comment></comment></comment></comment></comment>


Ask HN: What payment gateways do you use for your app? - <AUTHOR>

I guess the question is more toward the Canadian HN entrepreneurs. Since Authorize.Net require you to have a merchant account in US, we, Canadians, can't use it. What are your choices for merchant account/payment gateway (in terms of building a web app)? <comment><USER2> We use Beanstream for our Toronto based company. One nice thing about them is they support something like authorize.net's CIM feature, so you can do recurring billing without having to store CC numbers yourself.

One thing to be aware of, though. It is nigh impossible to get a USD American Express merchant account in Canada. If you plan to charge exclusively in USD, this can be a real problem, as you won't be able to take AmEx. We're soon going to go through the hassle of setting up an account at authorize.net or Braintree so we can take AmEx -- too many of our customers insist on paying either by AmEx or cheque.

For more info about the USD-AmEx-in-Canada problem, see: [http://www.freshbooks.com/blog/2008/09/25/freshbooks-now- acc...](http://www.freshbooks.com/blog/2008/09/25/freshbooks-now-accepts- amex/)

Note that it is possible to use a US payment processor for a Canadian company. The two things you need to do are:

a) Get an EIN (we haven't yet done this, but apparently it isn't too difficult, even for foreign corporations)

b) Open a chequing account at a US bank. We've done this using Harris Bank (<http://harrisbank.com>). Since they are a subsidiary of BMO, they are used to opening accounts for Canadian businesses.

<comment><AUTHOR> wow, I did not know about the AmEx problem in Canada. Looks like there's more battling to do after setting up my merchant account/payment gateway. Did you guys look at PSIGate at all or did you just go with Beanstream?

</comment></comment><comment><USER3> > _Since Authorize.Net require you to have a merchant account in US, we, > Canadians, can't use it._

Actually we can. The do however require that you open an account with Global Payments Inc and these guys have seriously sleazy sales tactics. They break down their fees into a multitude of categories and groups, and it is fairly unobvious what combination of these fees you are going to hit most frequently. It took me literally a week of back and forth emails with them to get an idea of what the average transaction fee would look like. It was really like pulling a tooth.

I have also dealt with Moneris. _Extremely_ arrogant. They are really big and they basically do not care. They are also the most expensive of all that I have talked to.

Lastly I spoke with VersaPay and they first quoted me fees that were frankly exorbitant. Only after I told them the Global Payments fee level, they brought theirs to the comparable level.

In the end I haven't gone through with any of these, but if I were to pick one now I would probably give VP a try.

YMMV, etc.

</comment><comment><USER4> I am using paypal, and I would definitely not use them again. They are holding 30% of our order values for 90 days... [http://www.businessweek.com/smallbiz/running_small_business/...](http://www.businessweek.com/smallbiz/running_small_business/archives/2009/08/paypals_reserve.html)

</comment><comment><USER5> We use Braintree. They have a secure vault similar to Authorize.net CIM for storing credit cards safely without PCI concerns. Also, they were the only payment gateway that could give us true multi-currency support. Apparently in most cases you need revenues at least in the 7-figures to swing that, but Braintree set up USD, EUR and GBP for us on the cheap. Note that some payment gateways will claim to support multi-currency, even though what's really happening is they are just doing an exchange rate conversion and the customer gets nailed with an unexpected conversion fee from their bank.

<comment><USER6> I just looked at the Braintree site. It looks like they provide very developer friendly services which is rare in the industry. The listed rates are high though. If anyone goes with them, keep in mind it's the industry norm to heavily negotiate those.

<comment><USER7> Our (Braintree's) pricing is actually very competitive. It probably looks higher because we disclose all our fees. Nearly every provider we know of obscures fees both during the sales process and in the monthly reporting statements so merchants never really understand what they're paying. Here's an example of pricing trickery <http://bit.ly/9NSZCa> . Prospective customers regularly do thorough pricing comparisons and we are consistently among the most competitively priced. Our objective has always been to provide the best value in the industry for a fair price.

<comment><USER6> I work at a provider (PowerPay) and completely agree about obscured fees. The rates I was referring to are posted on your site and do seem a bit high to me. With that being said, there are a ton of variables involved in pricing an account, so it was a bit unfair of me to bash your prices. I suppose that is why most providers don't list rates on their sites.

</comment></comment></comment></comment><comment><USER8> Anybody here know good payment gateways for us folks outside the US?? (specifically India, in my case)

<comment><USER8> To be fair, there are a few options out there (see [http://www.pluggd.in/review-of-payment-gateways-in- india-297...](http://www.pluggd.in/review-of-payment-gateways-in-india-297/)) but from the quick research I did, they have really high transaction rates (upwards of 6%).

If no better options exist, this might be an opportunity for an entrepreneur, though figuring out and complying around the laws might take some doing.

<comment><USER9> Setting up a payment gateway is really capital intensive business

</comment></comment></comment><comment><USER10> Based in the UK, we use a Barclays merchant account and SecureTrading as our payment gateway. SecureTrading is great as they provide excellent customer service. Their payment gateway set-up is a bit funny (involves setting up a java gateway), but it works.

I've written an ActiveMerchant plugin for ST:

<http://github.com/swombat/active_merchant>

</comment><comment><USER11> I am trying to figure out if I want to accept credit cards on my site, instead of sending the customer to a different site, how I can become PCI Compliant. It sounds like for a low volume of transactions you just have to answer a questioner and keep decent security precautions. Is that true? Also does your host have to be PCI Certified or can it be any VPS host like linode?

</comment><comment><USER12> I was about to post the same Ask HN yesterday, but for other UK. Anyone have any recommendations?

We usually use PayPal or Google Checkout, but our clients often want to use their business bank's merchant service e.g. Barclays EPDQ. This can sometimes pose a problem, as we use Ubercart and have to find/develop the necessary adapter modules.

</comment><comment><USER13> Wish we were using BrainTree, as evidenced by a coworker exclaiming that he found a bug in their dev sandbox, and they fixed it in a few minutes and sent him a nice email thanking him. So, anecdotally, they sound great.

Authorize.Net is otherwise stable, though poorly documented, and works when their datacenter isn't on fire.

<comment><USER14> They look great - but - seems that they require a US presence

</comment></comment><comment><USER15> In the US, but we've used PayPal's direct payment gateway (Websites Payment Pro) for a number of client sites, and its been great.

The rates are very reasonable ($30/month, 2-3% + $.30 per transaction), and the only weird requirement is that you have to offer PayPal as a checkout option (and we would anyway).

<comment><AUTHOR> I'm looking for a subscription model so unless PayPal has a recurring billing, I can't use it. Thanks for the tip anyway.

<comment><USER16> I'm pretty sure Paypal does have recurring payments. I think they call it a subscription payment.

<comment><USER15> AFAIK this is not available through their gateway - you have to send the user to PayPal.com and even then I believe they have to use a PayPal account to subscribe.

If there's a way around this I would love to know.

<comment><USER17> subscriptions are available through the direct api (your site) and express api (paypal hop) if using websites payments pro. however, if you offer direct, paypal requires that you offer express as well.

payments standard only supports something similar to express, although it's a totally different beast.

<comment><USER15> That is awesome, thank you.

</comment></comment></comment></comment></comment></comment><comment><USER18> TrustCommerce (<http://www.trustcommerce.com/>) seem like good people. In particular, they seem very FOSS-friendly; see (<http://www.trustcommerce.com/opensource.php>).

</comment><comment><USER19> Amazon has a very strong subscriptions/reoccurring billing system with a nice of API for subscription management.

[https://payments.amazon.com/sdui/sdui/business?sn=devfps/adv...](https://payments.amazon.com/sdui/sdui/business?sn=devfps/advanced)

<comment><USER20> We use Amazon FPS at Mixpanel and it's okay. The fees are certainly low.

However, you have to send your users offsite to a co-branded page to get them signed up, which is a pain in the ass. They also _have_ to have an Amazon account, which many businesses don't (if you're a B2B startup).

</comment></comment><comment><USER21> If you're looking for a Canadian company, look to Beanstream:

<http://beanstream.com/>

They're based out of Victoria, BC - my hometown! They're supposed to be good, although I can't speak from personal experience.

<comment><USER22> I'm in the process of setting up Beanstream - seem like nice guys out there! And they give test accounts, etc. Very friendly. When you call the 1800 number, someone answers the phone!

<comment><AUTHOR> Let us know after you get everything running. I'm counting on this as an alternative to PSIGate now.

</comment></comment></comment><comment><USER23> I use these guys: <http://www.paysimple.com/> They walked me through getting a merchant account and charge $30/month for the gateway with an API, credit card vault, subscription billing on credit card or ACH

</comment><comment><USER24> Have you tried ringing the banks direct?

Back in AU (I now live in Canada) I was able to get a pretty good deal and system from my local bank. I have no idea why it was not promoted online but their merchant facilities did the trick!

<comment><AUTHOR> My business bank account is with BMO, so I tried to contact their own solution called Moneris. Their sales rep didn't know what I was talking about. They tried to push me to use virtual terminal and other stuff that usually retail uses. In the end, the sales rep said she'd have to talk to the manager to see if they have anything like what I want. So that pretty much failed.

<comment><USER25> We use Moneris. The product that covers what you want is eselectplus. You can get info on their API here <http://www.eselectplus.ca/en/downloadable- content>. They are pretty clueless. We went with them because at the time (2006) they were the only company we could find that would support Canadians that had recurring billing. Their API isn't complete. We actually have to do screen scraping against their virtual terminal to compensate for missing APIs.

</comment></comment></comment><comment><USER26> Although I still did not build any web app, for my software I'm using FastSpring and, if I'm not mistaken, they should be usefull also for subscription based web apps.

Very good support and very good interface. It works very well.

</comment><comment><USER27> Is there anything like Authorize.net CIM in Canada? The CIM piece is awesome because you don't store any credit card information on your server, which takes all the PCI hassle out of the equation.

<comment><AUTHOR> That's exactly what I want to know. I definitely do not want to deal with PCI compliance. Sadly Authorize.net doesn't support banks in Canada.

<comment><USER28> Solutions like CIM only simplify PCI compliance. You're still handling the card info, just not storing it. To completely get away from handling card data you have to send your customer over to another site like PayPal to enter their payment info. A sub-optimal user experience.

That being said, it's less likely for someone to sniff the info as it passes through your server's RAM than if it was stored on disk.

</comment></comment></comment><comment><USER29> I (Canadian) have an account on <http://www.internetsecure.com/> \-- I haven't used it yet so I can't advise, but it's one for your list.

</comment><comment><USER30> Have a look at Recurly as well: <http://recurly.com>

We use PayPal though.

<comment><USER31> Recurly, Chargify, Spreedly, et al don't actually handle the merchant account for you so you still need an account at Authorize.net or similar.

<comment><USER32> This is true but if you use Recurly you can swap merchant accounts as you need as they store your CC numbers. That plus TransFS is a powerful combination.

</comment></comment></comment><comment><USER33> Try out <http://www.boku.com/publishers/> for mobile payments

</comment><comment><USER34> My first consideration was paypal, but after doing the same thing you doing, i came up with 2checkout.com

</comment><comment><USER35> e-xact: ruby on rails based group out of Vancouver, check out their hosted checkout product which is what we use so we don't need to store credit cards ourselves and avoid all that PCI BS:

<http://www.hostedcheckout.com/>

<comment><USER36> I've used e-xact for a few different projects. Never had any problems with them, and they're relatively developer friendly (I wrote the Business::OnlinePayment::Exact module on CPAN).

</comment></comment><comment><USER37> We use Chase Paymentech, but probably switching to BrainTree after speaking to them several times.

</comment><comment><USER38> I use virtual access, not cheap but very good.

full disclosure, run by friends of mine.

</comment><comment><USER39> I previously used psigate, although I'm not sure I would recommend it

<comment><AUTHOR> I was actually in contact with them recently. Did you receive bad service? I'd like to know before I go with them.

<comment><USER39> There was a bit of a hassle with them. Setting up the account was rather annoying.

</comment></comment></comment><comment><USER40> Authorize.net's CIM with custom app for flexible rebilling.

<comment><USER41> How has that gone? I am looking into a similar setup.</comment></comment>


Why news editors will become community moderators - <AUTHOR> http://marciovm.com/?p=81

<comment><USER2> I wonder how this impacts objectivity. As an editor, your duty is to "maintain objectivity" yet this becomes a lot more complex when you have to interact with your audience in the way that most community sites require.</comment>


Stop the Cyborgs: Privacy 'impossible' with Google Glass warn campaigners - <AUTHOR> http://www.bbc.co.uk/news/technology-21937145

<comment><USER2> Google should add a feature to there glasses, if it isn't already there, facial recognition. If it's not a face you have seen many times or approved, then blur the area of said face. Yes I know this idea isn't perfect but it might work? Thoughts?</comment>


Defcon 28 Is Really Canceled - <AUTHOR> https://defcon.org/html/defcon-safemode/dc-safemode-faq.html <comment><USER2> Also being discussed here: [https://news.ycombinator.com/item?id=23118161](https://news.ycombinator.com/item?id=23118161)</comment>


Facebook Places In New Hampshire Turns Into A Real-Life PleaseRobMe.com - <AUTHOR> http://techcrunch.com/2010/09/10/facebook-places-please-rob-me/

<comment><USER2> Invest some of that ad money into actual editors, Techcrunch. My old state is spelled with a "p"!

In response to the content, I used to live in Nashua. It's a fairly sleepy little town without much crime in general, though some areas are becoming a little rough around the edges. A lot of people left their doors unlocked. I'd say broadcasting your current whereabouts to the world instead of merely your friends is a 21st century way of leaving your doors unlocked: it only works when everyone plays nicely.

<comment><USER3> I live in Nashua. I think we're still ranked 27th safest city in the US.

</comment></comment><comment><USER4> I wonder if this will eventually become a clause in insurance contracts: "If you broadcast publicly the fact that you aren't home, any subsequent robbery will not be covered." Hard to believe, but possible.

<comment><USER5> uh. no.

Because, if I so wished, I could post on FB places that I'm "at the movies with <whoever>".

<comment><USER4> I don't understand how this objection would defeat the clause in question?

<comment><USER5> the idea is, you can't effectively stop what other people post about you. Sure, you can elect to not post anything showing your location, but other people can also elect to post stuff showing their location, as well as information indicating that you are with them.

<comment><USER4> That's why the clause would be, "If _you_ broadcast publicly . . ." Obviously there'd be no way to enforce this if someone else broadcasted your location.

</comment></comment></comment></comment></comment><comment><USER6> Techcrunch robbed New Hampshire of its p.

<comment><USER7> New Hampshire shouldn't have posted on Facebook that it was out partying with Maine and Delaware at Vermont's place.

</comment></comment><comment><USER8> Do you suppose someone's working on a system that recognizes valuable objects in geo-tagged photos, correlates that with Facebook/4sq checkins to figure out who lives with those objects and when they're not home, and produces a live feed of where the fleet of home burglary vans should go next? Kinda like the FedEx logistics system, but for evil.

</comment><comment><USER9> This doesn't describe how they got the addresses of people to rob. Presumably, they robbed their Facebook friends. Regardless, there are easier ways to find out when people aren't home. Most people are at work during the day. Maybe you should randomize your work schedule to feel more secure.

<comment><USER10> Actually, I suspect that the victims just shared their addresses with everyone.

<comment><USER9> You have to go out of your way to do that on Facebook. I doubt many people have addresses shared with everyone.

</comment></comment></comment><comment><USER11> It's trivially easy to burgle a house. It's not so easy to get away with it. LBS seems like it would make things easier for burglars, but by Amdahl's Law, it's not much different from before. <http://en.wikipedia.org/wiki/Amdahl%27s_law></comment>


TCPCopy: A Live Flow Reproduction Tool to Support Real Testing of Server Apps - <AUTHOR> https://github.com/wangbin579/tcpcopy

<comment><AUTHOR> Unlike tcpreplay, tcpcopy is mainly used for replaying network traffic to servers either offline or in real-time.

This tool is mature and has been already used in many famous companies such as taobao and Netease in China.

BTW, it is free.

</comment><comment><USER2> tcpcopy is a good tool.

</comment><comment><USER3> awesome tool!</comment>


Savedroid was here, is here, and will be here [video] - <AUTHOR> https://ico.savedroid.com/ <comment><USER2> An unintended side-effect of this stunt is that it showed how strong convictions ICO experts hold about their recommendations: [https://twitter.com/SatoshiAnswers/status/986645861655633920](https://twitter.com/SatoshiAnswers/status/986645861655633920)

<comment><AUTHOR> I wonder if that changes now again back to better values. Crazy

</comment></comment><comment><USER3> Is this the equivalent of a bank faking foreclosure as an April Fool's prank? Not sure I want my financial institutions to have a wacky sense of humour.

<comment><USER4> This could actually be the perfect meta scam: The hoax appears to have done rather substantial damage to their business prospects, so now they have the perfect cover story to "go broke" and "lose" all their IPO proceeds.

</comment></comment><comment><AUTHOR> I think this is neither funny nor insightful. Maybe something on the level of Tesla's April's Fool prank. But April 1st was 3 weeks ago

</comment><comment><USER5> TIL "blockchain ICO consultant" is something people call themselves.

</comment><comment><USER6> My phone browser dies whenever I try to visit the website. Is there some kind of weird script running?

<comment><USER7> If you click on "Learn more", you are redirected to [http://anditsg.one/](http://anditsg.one/). Or directly to the youtube video: [https://www.youtube.com/watch?v=o5_bwFf_byo](https://www.youtube.com/watch?v=o5_bwFf_byo)</comment></comment>


Kinematics of Reverse Angle Parking - <AUTHOR> https://observablehq.com/@mourner/kinematics-of-reverse-angle-parking <comment><USER2> For those in regions without reverse angle parking (like me)…

It's used in areas where you might have roadside parking along a road, either parallel or angled. It has higher linear density than parallel and is easier/faster. Compared to forward angled parking it removes the "backing out into traffic you can't see because your rear pillars and the hausfrauenpanzer next to you have completely blocked view of the oncoming traffic" (so you go slow and figure any drivers coming down the road don't want to die today either). You safe the road by stopping to park, and have road visibility as you back in. Coming out you get better visibility because your upstream neighbors corner is further from the traffic and your eyeballs are also closer. An added bonus is that bicyclists have very little reason to ride in the zone of opening doors, compared to parallel parking.

Some places it is popular. Changing to it from forward angled makes people crabby.

[https://en.wikipedia.org/wiki/Back- in_angle_parking](https://en.wikipedia.org/wiki/Back-in_angle_parking)

<comment><USER3> What's the advantage over back-in perpendicular parking? I don't actually think your eyeballs are closer to the road (since the diagonal to your front corner is longer than the line to your nearest headlight), and you can always force neighboring cars to be further away by just painting the lines wider apart.

At first I wondered if the road can be slightly narrower while still allowing one to get into the parking space, but if you look in the OP article at how the orange envelope is shaped by the way the front end swings around, I don't really think that's the case.

In general, I'm confused about why angle parking is picked over perpendicular parking. It's significantly less linear density (reduced by the factor cos(theta)), but the square shape of cars means the road width occupied by the parking is hardly less. (The wasted space is the triangular patches between the parked cars and the road/sidewalk.) Parallel parking has even lower linear density, of course, but takes half the road width.

<comment><USER4> I've never seen perpendicular parking outside of a parking lot. one immediate issue is that many vehicles will not have a sharp enough turning radius to make a right angle turn from a single width traffic lane into the space. they will have to make a multiple-point turn and/or cross into the far lane (possibly with opposing traffic) to get into the space. I can't imagine how this wouldn't be a huge obstruction every time someone parked something larger than a honda fit.

<comment><USER3> I see perpendicular parking pretty often. It's probably at least as common as angled parking in San Francisco (although obviously much less common than parallel parking).

[https://www.flickr.com/photos/ricardipus/2575893591/](https://www.flickr.com/photos/ricardipus/2575893591/)

<comment><USER5> Perpendicular parking on SF's steep streets usually has huge backouts and is necessary due to the high pitch.

<comment><USER3> I see perpendicular and parallel parking on the same street, so I don't really understand the necessary claim.

</comment></comment></comment></comment></comment></comment><comment><USER6> I need to sit down and work it out on paper, but as a long standing reverse parking fan - I can't park forwards, as it's too difficult - I don't think the diagram shown here is quite right. When going backwards at low speeds, the fact there are two rear wheels is very important! When reversing when turning fully left, the left rear wheel stays pretty much where it is; when reversing when turning fully right, the right rear wheel behaves that way.

OK - well, this is of course not _quite_ true, because the car is moving, and so it's not quite rotating around a fixed point. But it's close enough that you can pretty much start your reverse parking manoeuvre by putting one wheel in the right place, so its contact point is lined up with wherever it ultimately needs to be - but it doesn't really matter which angle, provided it's within 45° or so. Then turn full lock in that direction (left for left wheel, right for right wheel), on the spot, and slowly reverse until the other wheel is lined up too.

Now you're done. Straighten the front wheels and go in backwards.

It's handy to bear in mind the swept volume, as there will be some overhang, but when going in backwards with this technique you don't typically have to worry about it too much.

(Making the wheels turn on the spot is not the best thing, but you can fix this once you're confident with the basic manouevre.)

<comment><USER7> There's a chance I may hate you.

I park in a standard parking garage, with forward angle parking and one way traffic flow. I occasionally encounter vehicles reverse parked, which confuses me, but whatever, but then also encounter vehicles driving backwards (well, forward facing, going against the posted signage) through the parking garage. This is always a big headache, because again, this is a one way parking garage, and for some reason THEY never seem to think they should back up or get out of the way of the person driving the correct way through the garage, so I always have to do some extra maneuvering and wait for them to pass, and I usually only have a small margin before the train arrives, and--

Assuming they are not simply idiots who can't follow the signs, my next assumption would be that these are the people who are reverse-parking, looking for a spot to back into.

Anyway, if you have difficulty making the turning radius to pull straight into a forward angle parking spot, there is a very simple trick: make a three point turn, attempting to pull into the spot to the _right_ of the empty spot, then when you are almost to the bumper of the parked car, back up and straighten out, which puts you at the perfect angle to drive straight into the angled spot now in front of you.

It beats the pants out of getting halfway into the spot before realizing you're about to hit the car on one side or the other and trying to straighten out after the fact.

<comment><USER8> Presuming tom_ isn't a criminal, I'd hazard that the reason tom_ likes reverse-parking and thinks forward barking is hard, isn't because tom_ drives the wrong way down one way streets, but because tom_ has trouble parking without the extra lane worth of turning radius.

<comment><USER9> I find reverse parking easier to reason about spatially. Ok I do have a backup camera, but even without that you can roughly see where the back of the car is in the mirrors. With the front of the car I have absolutely no idea at what point I should stop (meaning the bottom of my front bumper is rather scratched).

</comment></comment></comment></comment><comment><USER10> I learned to reverse into spaces in the military. That's the way that all military vehicles are supposed to be parked. I started doing this in my civilian vehicles and found that once you get the hang of it, it's absolutely the best way to park a car. Once you have the skill--and spatial awareness-- you will find that it's much easier to get straight into a space with this method. Leaving the space is obviously easier, too.

I drive a large Ram pickup truck and backing in is pretty much the only way that I can park it accurately.

</comment><comment><USER11> Amusingly, I have to solve this problem for a minor game project. Drivers have to back their trucks into a loading dock. Players aren't good enough drivers to do this without assistance, so I have to write an assistance system that yells "Left", "Right", "Straight", "Slow", "Stop", etc. as appropriate.

</comment><comment><USER12> This page by the same author is also fantastic: [https://observablehq.com/@mourner/non-robust-arithmetic- as-a...](https://observablehq.com/@mourner/non-robust-arithmetic-as-art)

<comment><AUTHOR> Thank you! A fellow programmer Jacob even printed that viz as a woven textile — floating point errors can be very pretty :) [https://twitter.com/jashkenas/status/1191829600214507520](https://twitter.com/jashkenas/status/1191829600214507520)

</comment></comment><comment><USER13> What's missing from this model is a variable rate of turn. You want to turn so that your front bump stays at roughly a fixed distance from the bollard line. As you go, you slowly turn the wheel sharper and sharper until reach your maximum turn radius or you are lined up with your space. You can slightly vary that fixed distance as you go to adjust for minor differences in your initial position. You can also aim for a bit to the right/far side of the space (, and then re-center on the space once you are lined up.

<comment><AUTHOR> Yeah, the model is definitely contrived and I could try adding a lot more to it, but I still found it very useful just to understand how the path changes with the wheel turn.

Also, as a beginner, it's very hard to "feel" how much you're supposed to turn with variable rate — I guess this only comes with a ton of practice. In the driving school, the way we were taught all the parking maneuvers is to reverse straight until you catch some reference point, then immediately turn to the max for the sharpest turn.

</comment></comment><comment><USER14> Given the example show, I would make this a much easier problem by pulling across the center line onto the opposite side of the street, then steering back towards the right hand side. I would time this so I'm parallel with the lines. Now it's a simple back-in job since you're already lined up.

This may or may not be a legal traffic maneuver where you live and obviously can only be performed with both lanes clear.

<comment><AUTHOR> There's just one lane here — the thick line at the top is a barrier (a line of bollards).

<comment><USER15> Even so, the thing to do here is first turn the wheel to the right and pull past the parking space and pull up to the bollards, then back in.

</comment></comment></comment><comment><USER16> I don't think I have ever seen a parking area with reverse-angle parking. Any angled parking usually has signs to make it clear that cars must park forward facing only.

Having said that, it would be nice to see this adapted to parallel parking since that is a much more common parking scenario.

<comment><AUTHOR> Observable makes it easy to fork notebooks and make modifications, so I'll be happy to see other parking arrangements!

I made the viz for my real-world situation — reverse angle parking is quite common where I live (Ukraine), and it's the type where we got our parking spot (took a long time since all the spots around my apartment complex are sold out). [https://en.wikipedia.org/wiki/Back- in_angle_parking](https://en.wikipedia.org/wiki/Back-in_angle_parking)

</comment></comment><comment><USER17> It's interesting how quickly analytically solving this problem gets almost impossible (the problem being 'given a start position and a desired end position, how do you maneuver there). I've had a lecture that was basically just about this class of problems.

But it was concerning trucks and how adding additional axes and especially adding even one trailer joint (but especially two) made solving this conventionally impossible.

With some funky transformations into other number-spaces there were some analytic solutions for it though.

<comment><AUTHOR> Yep! It can be solved for some specific cases though — e.g. I stumbled upon a few papers that calculate the optimal path for parallel parking using systems of differential equations [1][2]

[1] [https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7463491](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7463491)

[2] [http://www.tsi.lv/sites/default/files/editor/science/Researc...](http://www.tsi.lv/sites/default/files/editor/science/Research_journals/Tr_Tel/2012/V4/zadachyn_dorokhov.pdf)

</comment></comment><comment><USER18> This may be obvious, but for me, reverse parking got a lot easier once I realized that (on my Mini Cooper) if I pull forward until my B-pillar is exactly aligned with the next dividing line past the space I want to enter, then I can reverse into it almost without looking. (Does that make sense? I'm not great at describing visual concepts.)

Presumably there's a spot like this on every car; you just have to figure out where it is.

<comment><USER19> You should use the rear axle as a guidline, not the B-pillar, it's more accurate, and it's how a 2-point reverse turn is taught to be done by driving instructors here.

Driving exams involve performing a 2-point reverse turn with the rear inside wheel not going further away than 1 meter from the kerb, no more than two stops (except for traffic/safety related reasons), no more than one engine stall, no forward movement and no contact with the kerb itself.

<comment><USER18> > _Driving exams involve performing a 2-point reverse turn with the rear > inside wheel not going further away than 1 meter from the kerb_

Which curb? I'm mostly parking in lots with perpendicular parking on both sides of the lane. The only curb involved is the one at the back of the space I'm backing into (unless there's a pull-through from the other side, then not even that).

<comment><USER19> The "inside" one obviously. The 2-point reverse turn is more designed to test your skill into reversing outside a blocked street back into a perpendicular street, but the skills involed apply to reverse angle parking too.

</comment></comment></comment></comment><comment><USER20> For anyone in the Palo Alto area who wants to try this out in person, the first block of Stanford Avenue next to the Dish trail entrance converted to reverse angle parking a while ago:

[https://firstname.lastname@example.com,-122.1605769,294m/da...](https://firstname.lastname@example.com,-122.1605769,294m/data=!3m1!1e3)

</comment><comment><USER21> The key to reverse parking (parallel parking is a bit more complex) is to make good use of your side mirrors and the fact that if you can see a cap between your car and whatever the object is, then you're on course not to hit the thing. Then it just becomes a matter of course-correcting your way to where you want to be, which is pretty easy after a little practice.

<comment><USER22> Where does the cap come from?

I assume you mean gap, but when you start reversing and are not aligned with your parking spot yet, the thing you'll soon see in the rear mirror is the car parked in the next slot. No gap.

Idk about other people but I feel like I've got very bad depth vision in general, and telling how far my car's rear is from a wall or another car when looking through the mirror is very difficult.

<comment><USER21> When you are not aligned and you don't see a gap between your car and the thing next to you, that is the signal that you need to turn more in order to get where you want to be.

Regarding how far back to go, I find that it's the same problem as parking forward. You just need to figure out how to judge some reference point on your car with whatever is around you. I agree that's one of the trickier things to figure out.

<comment><USER22> Yeah, the problem with turning is that you don't exactly turn in place, and if you're too far backward, you'll back into the thing you're trying to turn next to..

Forward parking sure has the same issue but for me at least it's much easier to assess depth right in front of me than 2-3 meters behind, through a little mirror. And I mean I can park in front of a wall and leave a 15-20 cm gap between the bumper and wall without much trouble, but it is seriously difficult for me to say whether there's half a meter or one and a half between my rear and the next object. I guess they invented reverse cameras for a reason, I just haven't bought one.

<comment><USER21> I think depth perception for the rear of the vehicle is mostly a matter of practice. If you can develop spatial awareness of what is in front of you, developing it for what is behind you is just a matter of trial and error.

</comment></comment></comment></comment></comment><comment><USER23> I was sure this would be related to Matt Parker's recent video on back-in parking: [https://www.youtube.com/watch?v=0rxghexCKj8](https://www.youtube.com/watch?v=0rxghexCKj8)

<comment><AUTHOR> Nice video! I only saw it a few hours ago when I was about to post my viz on /r/math :)

</comment></comment><comment><USER24> Control Schemes of Steering System of a Multi-axle All-wheel-steering Robot:

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

<comment><AUTHOR> Awesome! This paper uses the same model for calculating wheel angles (Ackermann steering geometry).

</comment></comment><comment><USER25> FWIW: A good backup camera helps you visualize this. Both of my cars have lines that curve as I turn the wheel.

<comment><AUTHOR> Yep, mine has it too and it's super helpful! What I have more trouble with is feeling when the right front side is about to collide when the car sways in the other direction — there is some beeping proximity detector but it doesn't seem to work well against bollards.

</comment></comment><comment><USER26> Why is the interactive diagram on this page so much slower in Firefox than Chrome?

</comment><comment><USER27> That's great.

</comment><comment><USER28> Slightly related - when reverse parked and pulling out of a 90 degree parking spot with the wheel turned, is it possible for the rear outside corner of the vehicle to clip an adjacent vehicle? In other words, if you were reverse parked, pulling out turning left, and you plotted the track of the outermost portion of the right rear fender/bumper, would it ever cross the rightmost edges of the wheelbase in the parked position?

<comment><AUTHOR> Good question! Since the model is reversible (you would have the same trajectory when pulling out of the parking lot when reversing the steps), you can see the effect there — seems like it would cross the rightmost edges but very slightly (like 10cm) in my case, but protrusion would be bigger with a car that has a bigger rear overhang (e.g. sedan rather than hatchback). You can try it out by tweaking the constants in the car specs section.</comment></comment>


Show HN: FOLD – a platform for reading and creating modular, multimedia stories - <AUTHOR> https://www.readfold.com

<comment><USER2> It's a reinvention of storytelling. It breaks stories into their component pieces and reassembles them in new and interesting ways -- kind of an "atomization." It's a logical next step from hyperlinks. If it takes off, it will lead to writers rethinking how they tell stories. It will also change how readers read and absorb information.

</comment><comment><USER3> very beautiful! some promising concepts. mosaic assemblage of stories seems like the next logical step. love the attention to design and mode.</comment>


"Hacking Silk Road would not have run afoul of the Fourth Amendment," claims FBI - <AUTHOR> http://arstechnica.com/tech-policy/2014/10/us-says-it-can-hack-into-foreign-based-servers-without-warrants

<comment><USER2> So let me get this straight. If my web application is running on American servers. I go to secret court, to get issued a secret search warrant. If its not an American server I just get hacked.

I'm sorry but this really sounds like Oppressive Police State stuff.

</comment><comment><USER3> Does this mean foreign governments are free to hack US servers if they believe any of their foreign laws have been broken?</comment>


We must continue to offend - <AUTHOR> https://dispatch.no/blog/we_must_continue_to_offend.html <comment><USER2> Flagged this, site has a bad SSL cert.

<comment><AUTHOR> Really? It's Let's Encrypt...

<comment><USER2> My bad, sorry. Unflagged. Wonder why Chrome doesn't trust Let's Encrypt, though.

<comment><AUTHOR> Chrome should trust Let's Encrypt, and it does on every Chrome I've tried. Which version/OS are you on and what exactly is the message from Chrome?

<comment><USER2> Chrome 55.0.2883.91 on Android 6.0.1, it says server certificate is not trusted.

<comment><AUTHOR> Could you test again now?

<comment><USER2> Works now.</comment></comment></comment></comment></comment></comment></comment>


Show HN: YouTube API + Backbone UI - <AUTHOR> http://player.harpb.com/

<comment><USER2> Good job. I built something similar a year ago. Is based on Backbone as well with the difference that you can search by genre and for karaoke results <http://440.fm>

</comment><comment><USER3> Or, you know, you could just use Youtube's playlist feature.

<comment><AUTHOR> Which works for playlists only.

</comment></comment><comment><USER4> Why?

<comment><AUTHOR> no page refresh

<comment><USER4> If I had that problem then I guess I'd use it then.</comment></comment></comment>