Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mrkurt
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
52 ms
·
571.
▲
by
mrkurt
5y ago
If you get a big surprise bill, email me and we'll fix it. We're not interested in surprising people with bills.
572.
▲
by
mrkurt
5y ago
We kind of naturally got from Prometheus -> VictoriaMetrics. Vicky is very simple to operate, which was a win. I'm a huge fan of Timescale, though, and we have big Postgres plans that I hope include Timescale. :)
573.
▲
by
mrkurt
5y ago
You can get a reasonable idea of the problems people run into on our community forum. I use Fly for everything but that may not be the best signal for you: https://community.fly.io/
574.
▲
by
mrkurt
5y ago
It depends entirely on your stack + use case! If you feel like emailing I can give you an honest take. :)
575.
▲
by
mrkurt
5y ago
We're small, only 7 people. That's on purpose (so far). The magic 8 ball says we'll grow in the next few months though.
576.
▲
by
mrkurt
5y ago
Middle class engineers make 7 figure salaries?
577.
▲
by
mrkurt
5y ago
I don't understand why you keep talking about Apple's direct competition? Vertical consolidation is a very different, potentially more harmful problem than "a mobile phone monopoly". More competitive phone market is pret
578.
▲
by
mrkurt
5y ago
> That just indicates that the value of a modular component isn’t high enough to make it worth building for now. This is the dilemma. The value is low _now_ because Apple bought the vendor, rather than purchasing from a vendor. In a heal
579.
▲
by
mrkurt
5y ago
Maybe. The two biggest consumers (apple and google) of touch id like components won't buy from someone else. So the opportunity is quite small. And it's too expensive for a small company that might just want to build a consumer do
580.
▲
by
mrkurt
5y ago
You literally just said "no one is stopping someone else from building a vertical monopoly". The problem with vertical consolidation is _not_ that they prevent other large companies from competing. There's always a scale wher
581.
▲
by
mrkurt
5y ago
I'm less worried about moats (although we should be wary of anticompetitive moats) and more worried about an ecosystem where the already successful companies monopolize access to innovations. Forget competitors, you can't buy the
582.
▲
by
mrkurt
5y ago
Google buying Doubleclick helped them crush the ad market for publishers. Number of acquisitions is interesting, though, because you can also phrase it as "number of potentially viable independent companies that no longer exist".
583.
▲
by
mrkurt
5y ago
Vertical doesn't unequivocally work better, there's a high external cost. None of Apple's "stack" is available to other companies because they have no incentive to sell components. The reverse happens, they buy up i
584.
▲
by
mrkurt
5y ago
I'm really sorry to hear about your kids' struggles. Middle school seems especially intense these days. One of our kids has had a really rough time at middle school for similar reasons. We ended up pulling her out and homeschoolin
585.
▲
by
mrkurt
6y ago
Oops, yes this.
586.
▲
by
mrkurt
6y ago
This is actually how our autoscaling works. Since it works based on concurrent connections, it should be pretty good fore Liveview apps. https://fly.io/docs/reference/scaling/#autoscaling
587.
▲
by
mrkurt
6y ago
Would you mind emailing me with your IP address and a screenshot of what you see at https://debug.fly.io when you're on wifi? Finland to hkg is not what we want to be doing. kurt fly.io
588.
▲
by
mrkurt
6y ago
Your answer is pretty close to what most people do: https://en.m.wikipedia.org/wiki/Client-side_prediction
589.
▲
by
mrkurt
6y ago
Apps with state are wonderful to work with. I'm pretty excited to build apps that cache in process and don't rely on 47 external services to do CRUD.
590.
▲
by
mrkurt
6y ago
Those spikes are hilarious, they're probably from a liveview DoS. People are fond of using the debug console to "click" hundreds of times per second and there's no rate limiting in the app.
591.
▲
by
mrkurt
6y ago
In a couple of months we'll have instances in Chennai!
592.
▲
by
mrkurt
6y ago
If you're within ~50ms of the liveview server you can get really close to client side interaction responsiveness. Animations are still better off handled client side, though you can go far with web components and liveview updated HTML:
593.
▲
by
mrkurt
6y ago
Where are you connecting from, out of curiosity? 200ms is poor! Fly apps get anycast IPs, so it's basically bgp getting you to our "nearest" edge proxy, then we connect you to the closest vm from there. https://deb
594.
▲
by
mrkurt
6y ago
The thing we do that's (maybe) interesting is run processes all over the world. It's helpful for liveview because it minimizes latency to end users. Here's an example Liveview cluster running in 17 regions, if you scroll down
595.
▲
by
mrkurt
6y ago
Gosh dang this is amazing.
596.
▲
by
mrkurt
6y ago
https://thestorygraph.com is a better goodreads. It's found my last 8 or so books for me.
597.
▲
Does cloud load-balancing work for long-lived TCP streams?
(mux.com)
4 points
by
mrkurt
6y ago
|
0 comments
598.
▲
by
mrkurt
6y ago
We waive invoices when there's a mistake like this (we racked up a $20k Google bill a few years ago, we get it). We also work hard to keep bandwidth costs down. At $0.02/GB, even 2.5TB of traffic is ~$50. Which is why it's ea
599.
▲
by
mrkurt
6y ago
I also dislike docker. But it's a de facto standard. We have exactly one thing we want to "innovate": running app servers close to users. Which means we support what people already use. Postgres is great but I wouldn't c
600.
▲
by
mrkurt
6y ago
These are long running processes. They have 5gb of temporary disk space. You can attach persistent volumes as well.
More ›