matahwoosh

At Square most of the applications run in the datacenters and this project allows AWS Lambda instances to seamlessly call into the datacenters -- basically developers can break out part of their apps and deploy them as Lambdas.

This is a deep-dive on the mTLS set-up for Lambdas, but for general overview check out https://developer.squareup.com/blog/enabling-serverless-appl...

I don't know if it's true. People tend to conflate the price for cells with those of modules and entire battery packs. IIRC, the holy grail is < $100/kWh for a battery pack.

Batteries are a commodity, so I doubt Tesla would want to reduce themselves to an OEM and shrink their margins. Their energy business might eventually be bigger than their automotive one, but either way I think they will continue selling vertically integrated products.

I think the takeaway here is not that some corners of Go are not performant (and should be swapped for C++/D etc.), but that there are tools in the Go ecosystem that help you figure out what the issue is.

Until Twitch hit the bottleneck with their service, they were reaping multi-year benefits of faster development using memory-safe language (huge gain for security).

Their short- (or mid-) term solution seems decent and more importantly Go core team is working on addressing this particular issue (which given the Go 1.x backward compatibility promise makes it really easy to reap all the benefits with each Go release).

You're incorrect, Square has non-SF offices, too. I think @nrp has put it well in his comment https://news.ycombinator.com/item?id=21342101. Square is categorized differently than Salesforce by SF tax law and pays a different proportion of taxes than Salesforce.

EDIT: corrected username

Agreed, but also we don't know what exactly Apple (and also Google) is collecting - Apple Maps might only have subset of their data.

Not to mention, having a good way to build realistic virtual environment for acceptance testing is probably key here to enable self-driving.

potential bet on self-driving cars in the future - you'd want higher fidelity maps for those.

Also, they can get more accurate navigation for pedestrians etc.

Overall, IMHO, this is an investment in user experience.

Here's a neat demo in JS https://www.quaxio.com/steering/

Very recently there was a flurry of articles about Apple copying popular apps, among them woman health apps [1]. Although they were not wrong to voice their concerns about Apple, it's hard to cheer for the app makers when you later find out they don't exactly value your privacy and are not upfront with you, as a user, about that.

[1] washingtonpost.com/technology/2019/09/05/how-apple-uses-its-app-store-copy-best-ideas

EDIT: language

It's so that you can have a seamless module version checksum [1]. The checksum in proxy ensures that you don't "trust on first use" whenever you update a module.

[1] https://go.googlesource.com/proposal/+/master/design/25530-s...

It's not as bad if you start your company outside of Bay Area or get remote employees.

Yes, we can definitely incentivize people to change their energy usage habits as well. EVs will come very handy if/when their charging schedule can be centrally managed (thru automaker car networks or smart chargers).

Yes, renewable energy like wind and solar are intermittent, so we will need to invest (a lot) more into energy storage. So far storage has been expensive and need to drop a lot, so it can reach mainstream [1].

[1] https://www.pv-magazine.com/2019/08/12/new-us-study-finds-re...

I just finished this book: https://books.google.com/books/about/Tesla.html?id=5I5c9j8BE...

I thought it was really thorough and quite technical, so if you're interested in the early day of electricity more than just personal anecdotes, then this book might be for you :)

probably 2170, but yeah, small cylindrical batteries

It definitely depends on your use case, so it's hard to tell what's better for you. HAProxy is solid and doesn't take a long time to get started.

At the same time, some of the HAProxy 2.0 features have already been available in Envoy and tested in production, at scale (if HAProxy provided those features, there wouldn't be a big need for Envoy). For example, Envoy is pretty extensible, has good performance and has good support for dynamic cert management (including service-to-service mutual TLS).

Tesla Semi has multiple packs that can be charged in parallel. The Megacharger will (likely) be 4 Superchargers combined. 1MW should be enough ;)

re: announcement, I'm surprised not much has been said about the flagship cars (S/X). With their current battery architecture (using 18650 batteries), they're not capable of 250kW charge rates. I wonder if they have recently updated them to new 2170 battery packs or if they're going to do that soon.

Android-based.

Looks like they still don't have the "standard interior" option available, so that's extra $5k. Once (or if) they offer standard interior, we're talking $40k. If they're calling this battery option mid-range and it's 260mi range, then it's sounds like we're yet to see the 200+mi (maybe 210-220) $35k car. They're probably not able to produce the $35k car yet without losing money.

$78k is their most expensive version. The cheapest Model 3 you can get now is RWD + premium interior (no standard interior offered yet) + long range battery = $49k. Tesla still says that base version should come at $35k some time next year.

not really. 50kW max for Bolt. 120kW max for Tesla

hardly a model T with ~50-60k cars produced a year. And it hasn't been scaling production fast enough.

I believe Bolt is capped at 50kW fast charging, whereas superchargers provide 120kW, so not so fast for Bolt ;) (probably at least an hour to fully charge it's 60kWh battery)

yeah, makes sense. I wanted to make sure you were talking about RSA key exchange in particular.

Very good point! I was thinking about other potential drawbacks, but this must be the biggest! We're talking about PFS in the next article - https://fly.io/articles/how-ciphersuites-work/

Fair point! I think that quote should read "a random coprime to [...] to ϕ(n)". Then it makes sense.

There's a lot of math behind RSA computation and we were trying to distill as much as we could, but it's not perfect. We have added a simple example to tie everything together, but it just means that you might have to plow thru the heavy bits first.

Now, the totient it needed to compute your encryption and decryption values. You start with getting 2 primes:

  n = p * q

then you compute the totient:

  ϕ(n) = (p-1)(q-1)

then you compute your encryption and decryption values:

  e x d = 1 mod ϕ(n)

Then your private key will be be a pair (d, n) and public key will be (e, n).

Then, given that m is message and c is cipher:

  Encryption

  F(m,e) = m^e mod n = c

  Decryption

  F(c,d) = c^d mod n = m

It's most likely to be Fly-specific, but you could replicate this behavior with passing appropriate to tls.Config#GetCertificate (https://golang.org/pkg/crypto/tls/#Config). You could then have something like that :

  GetCertificate: func(helloInfo *tls.ClientHelloInfo) (*tls.Certificate, error) {
  	return myGetCertificateImplementation(checkClientSupportForECDSA(helloInfo))
  }

You would see what curves/ciphersuites are supported by the client and check that against what you'd be supporting (if you use LE than that's more than likely going to be ECDSA with P-256). You would then return ECDSA cert (if one exist) for supporting clients and fallback to RSA certs. :boom: :D

tptacek: I think this sub-thread has been mainly to explain what RSA could be used for, not that it would be a good idea. On the side note, I have been positively surprised to see how many devices support ECDHE key exchange.

Also, do you have a good resource that explains the drawbacks of RSA key exchange in more details?

what encryption are you talking about? IIRC, RSA has only been used for key exchange or authentication (sign/verify) in SSL/TLS. Even in the old days up to SSL 3.0, RC4 or (3)DES was used for actual (symmetrical) encryption.

you can also use RSA for actual encryption (like PGP) or for signing/verifying. ECDHE is better for key exchange, and ECDSA is better for signing/verifying. Check out goodroot's link!