gazzini

They chose a 1-time payment model (which funds an interest-generating endowment), which seems a lot weirder than a subscription.

This actually makes sense -- if the goal is long-term set-it-and-forget-it, it solves the problem of getting a new credit card every few years & forgetting to change this service. It also eliminates any recurring payment-processing fees.

The back-of-the-napkin math checks out: accounting for storage, data-transfer, and business overhead, if they pay around $0.20 / GB / year, and they charge $10, then with 0 interest they would still have your files for 50 years, which is probably longer than your children will have your password to this service.

I still wouldn't trust it -- I have a pavlovian response to the combination of "permanence" and "give all your data to this new internet service". Maybe it's irrational here, but still, this product is at the wrong layer of abstraction for me personally :)

In your last sentence, you compare future quantum computers to “today’s” non-quantum computers, which might be a false dichotomy.

[warning: uninformed tangent]

A more optimistic interpretation could be that quantum & non-quantum machines will be similar because we have huge leaps to make in non-quantum computer architecture.

This is strictly a theoretical thought-experiment for me, but it has always intrigued me that quantum computers sort-of model the problem itself in the hardware circuit & shove a bunch of qubits through it.

In digital computers, we mostly model Boolean logical structures & then, in software, translate our problem into that Boolean logic. This translation into discrete steps places a limit on the theoretical efficiency.

However, perhaps there is room in analog computing hardware to more closely model specific types of optimization problems & then shove a bunch of electrons through it (shouldn’t the electrons follow the path of least resistance?).

I disagree with this — more regulation will make it harder to innovate.

For example, I’ve met several founders who wanted to enable tele-medicine years ago but decided against it because “the lawyers cost more than the engineers”, and walking-on-eggshells destroys morale & iteration speed.

I’m not arguing to de-regulate heath data — my point is that we should selectively apply regulation.

It’s likely a great thing to regulate self-driving cars. But please keep the lawyers away from my niche online forums, 3rd-party clients for social apps, blogs, video games, calculators etc...

I think Aurora Serverless has even worse [1] cold-start times (for the DB itself), and it was intended as more of a price-optimization than a performance boost.

[1] https://forums.aws.amazon.com/thread.jspa?threadID=288043

You raise a fair point, this was possible, although it seems safe to say it would be a compromise on security.

I think it’s best not to expose the DB to outside connections in general, although it is still possible [1] when using RDS instances.

I think this is different for things like DynamoDB because, instead of a standard SQL-like db “connection”, they use AWS role-based auth for each request.

Of course, one could always configure some type of proxy service between the lambda and the DB... but that seems antithetical to going “serverless” in the first place.

[1] https://stackoverflow.com/questions/45227397/publicly-access...

Edit: I thought it was not possible to expose an RDS instance outside of a VPC, but I was wrong (you can place it in a public subnet, linked in [1]).

This is huge for Lambda. It allows devs to create “serverless” apps [1], with relational databases, without 10+ second cold-start times. In the article, they measure it as 988ms.

I have tried building an API using API Gateway <-> Lambda, but had to choose between using DynamoDB to store data (no-SQL, so challenging to query) or suffering unacceptably long response times whenever a request happens to cause a cold-start. Theoretically, this problem is now going away!

[1] https://serverless-stack.com

There's an enlightening graph in this post:

https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat...

I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC, and anything inside of a VPC needs an IP address, so the Lambda function has to wait ~10 seconds on cold-start for the Elastic IP service.

The only workaround I've heard of is to setup a service, such as CloudWatch, to call your Lambda function every ~25 secs to keep it "warm", but this seems anti-thetical to the value proposition of serverless architecture in the first place.

Of course, you could "just" use DyanmoDB, but IMO the query language is really limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)

I’m surprised at how few lines of code this is.

EarBuds Music | Android Developer | FULL-TIME | Austin, TX | ONSITE | $100K+ (USD), 0.25-0.50% equity

EarBuds is a social music startup looking to round out our fierce little development team with a self-directed Android developer. You’ll get to own the Android app from scratch. Our iOS app will be your initial template, but there’s still plenty of room to help guide the product’s features and functionality.

Responsibilities: Own the implementation, release, and maintenance of our native Android app Work with our design team to create a slick but uniform cross-platform experience

This position is on-site in downtown Austin.

Apply here: https://angel.co/earbuds-2/jobs/372776-lead-android-develope...