• 0 posts
  • 30 comments
Joined 3 years ago
Cake day: August 3rd, 2023
  • To mitigate these limitations and reduce write pressure, we’ve migrated, and continue to migrate, shardable (i.e. workloads that can be horizontally partitioned), write-heavy workloads to sharded systems such as Azure Cosmos DB, optimizing application logic to minimize unnecessary writes. We also no longer allow adding new tables to the current PostgreSQL deployment. New workloads default to the sharded systems.

    “wow, we’ve made our postgres so good and fast… by moving heavy workloads to a NoSQL database engine”. Truly mind-blowing, OpenAI. Just like their LLM service, not even their technical staff can stop themselves from lying and writing misleading statements.

    The only interesting part could have been what they use for caching… but of course they don’t give any details at all. And all the rest is already well-known DBOps stuff… and basically all automatic with stuff like cnpg.

  • But why should we think so much about the final result when it’s out of our hands? Without you, these people probably wouldn’t have gotten any care whatsoever (or at the least, delayed with it -> higher risk for worse results).

    Unless you did stuff to worsen their condition, you’ve undoubtedly saved many lives, and many people are very thankful for your contributions. So, thank you!

  • Was it not possible to draw Ethernet, or did they just want the cheapest solution? I consulted for a place that had a similar situation, and it was unacceptable for most of the students due to the jitter. So we drew Ethernet and put mini APs in each room.

  • That’d be an unusual setup. If you have users deploying containers on your host – that you trust enough to run whatever containers, but don’t want to give them ssh to the host – you’d usually have some kind of frontend such as Portioner, where you can have container exec and such.

    Containerization is not virtualization. It’s very possible to break out of containers, especially if configured badly, or if there are any found exploits in the container engine or even the kernel. Containers are “good enough” for the majority of projects, but it has never been designed to be a truly hardened sandbox.

    Basically, if you’re running an OpenSSH server inside a container, it’s likely that you’ve gotten the wrong ideas about securing your environment, and thus some old libraries in an old Debian image is the least of your worries.