- Building a floor and then the room/office is a bit annoying…. Should auto build the floor (like Sim Tower)
- Stairs are difficult to build, it should be possible to build a vertical column, seems you always have to build horizontally?
- It should be possible to have multiple elevator cars in 1 shaft. Of course this is not possible in real life, but we are looking at a 2D shape of a 3D building. Either that or reduce the demand on the elevators
- In real life, Stairs and Elevators generally share a fire space away from residential, that should be encouraged
It's honestly insane how terrible their reliability is. Over the past 4 weeks, 8 days with GitHub Actions outages, many of them multi-hour outages: >3 hours on each of July 9th, July 20th and today, and 1.5 hrs on July 23rd.
Outages happen, but this many outages so close together, and so many of them so major/long lasting, something is systematically wrong for sure. It's been seriously hamstringing our ability to ship code at my company.
I don’t love GitHub, but that number is a little misleading… That’s the intersection uptime of all GitHub services, most of which I (and most users) do not care about; code spaces, copilot, packages etc…
When you take out those uptimes, it becomes a lot higher. I’ll admit there seems to be a lot more incidents than usual though…
Yea just try requesting an SLA credit from them. According to THEIR numbers it’s 99.995%. It’s intolerable and I am going to put my full weight behind stripping as much work as we can from GHA as possible, even if leaving GitHub itself is effectively logistically and contractually impossible.
Based on previous posts I've seen about this, IIRC the timing seems to imply that it has more to do with them being hammered with AI slop than it does with the Azure transition. Who really knows though
> ...IRC the timing seems to imply that it has more to do with them being hammered with AI slop...
It can be both things. I've worked professionally with AWS, Azure, and GCP, and Azure is just really flaky and unreliable. It's easily the worst of the three.
AFAIK, the move to Azure is still ongoing. Rumor has it that it was delayed for a very long time after the Github acquisition because Azure was too bad to move Github to.
Azure remains too bad to move Github to, but the relevant executives have pretty clearly decided that that's no longer a good reason to delay the move.
Time to touch some grass. Better use of my time and energy than twisting the remaining things on my todo list today to make more progress on them than I have managed. I should have taken a long lunch but I rebased the hell out of a PR instead.
Agree with the above, we built and run a ticketing platform, the actual transaction of purchasing the ticket at the final step in the funnel is not the bottleneck.
The shopping process and queuing process puts considerably more load on our systems than the final purchase transaction, which ultimately is constrained by the size of the venue, which we can control by managing the queue throughput.
Even with a queue system in place, you inevitably end up with the thundering heard problem when ticket sales open, as a large majority of users will refresh their browsers regardless of instructions to the contrary
You would use TigerBeetle for everything: not only the final purchase transaction, but the shopping cart process, inventory management and queuing/reserving.
In other words, to count not only the money changing hands, but also the corresponding goods/services being exchanged.
These are all transactions: goods/services and the corresponding money.
Yes, I was wondering what is to stop you replaying the same PoW multiple times.
All I can find is:
To prevent the vulnerability of “replay attacks,” where a client resubmits the same solution multiple times, the server should implement measures that invalidate previously solved challenges.
The server should maintain a registry of solved challenges and reject any submissions that attempt to reuse a challenge that has already been successfully solved.
This doesn't seem very scaleable? Or am I missing something?
For me (where our BE consists of maybe 100 endpoints) we’ve found the sweet spot to be Google AppEngine. Incredibly simple to deploy, we don’t really need to manage infrastructure or networking (although you can if you want), decent performance, plays well with other GCP services, great logging and observability, etc
We’ve tried deploying services on K8s, Lambda/Cloud Run, but in the end, the complexity just didn’t make sense.
I’m sure we could get better performance running our own Compute/EC2 instances, but then we need to manage that.
