That is good news for Grok team. However, most of the time cost comparing to the result is secondary, and better results and conclusions can come from mixing AI brains together.
Having a crowded and sloppy environment, is not a good way to go. When you log in to your account, you should not source a bunch of environment files by default. It is always a good practice to have a simple environment, just whatever you needed be sourced. If you need extra, just source them before using them. Keep your home clean.
I have some experience with different databases and system designs. In one of my last projects I used SQLite. However, I used only one dedicated process for writing and other processes for read only. This might help.
This is the right practice. Why put the burden on the server? It is the job of client to remember, not the server. Server is there to serve requests, not do the remembering. That is how http worked from the beginning and that is why it has been successful.
It was clear from the start (to anyone who ever designed a protocol [1]) that MCP was a pile anti-patterns. They are slowly undoing the mistakes one by one. Maybe next years version will finally be something usable that it could have been from v1.
Yes. However, using something like MCP encourages many companies to claim that they are "integrating AI" -- and typical MCP implementations burn tokens quite profitably.
This is the same old good way from database world. A db client never touches the disk, but sends requests to a server who owns it. Same in your product. Keys are separated from agents and if needed, agents must send request to a proxy who owns them. Old proven design. Good luck.
The backups got wiped together with the systems, so they were reachable from same network. A backup the attacker can reach is not a backup. Good they had an offline copy, but a system this important should have that as regular schedule, not depend on luck.
That was my thought exactly on reading that line: that is not a backup. (Ok, the word isn't strictly defined, but you know what I mean.) They have said there's a "real" (offline) backup as well, luckily, but that just reinforces that the "pretend" backup was irrelevant and wasn't even worth mentioning in the writeup.
- We have 2 sources of data that we must backup to continue existing as a business; our postgres and binary files in S3. Everything else is derivable (elasticsearch, so on).
- For postgres, we use barman. With the help of opus/fable, you can get a streaming replication backup working in no time. We have one into another server in the same datacenter (we use baremetal) and another one in another server in a different datacenter.
- We then have a last resort barman backup with bi-weekly base backups + WAL streaming to S3 (both the base backup and WALs). It sends these backups + wal segments into an specific S3 bucket that has object lock in compliance mode. This is a feature from AWS S3 that even the most privileged account credentials (super admin) can't turn off nor delete the files before the object lock, which is 10 days in our case. Object lock compliance mode can only be extended, never shortened.
- For S3, we store them into another versioned bucket, with lifecycle rules to also expire non current versions (== deleted objects) after 10 days. No point in object lock compliance here because it would only protect objects for the most recent 10 days, and you gain nothing. What we do instead: the app servers only have access to these bucket tru an IAM credential that can't delete old versions (so deleted objects have to expire manually via the lifecycle rule) AND this IAM credentials also can't change the object policy.
IMHO, this protects us enough so that even in the worst case scenario (ransomware) we have 10 days to sort everything out and recover our AWS access.
And yes, we test the S3 barman restoration and it works fine. Data loss is at max 5 minutes due to the archive_timeout=300s on the primary.
For the streaming replications in the two servers I mentioned, it's less <1ms, but those wouldn't protect us much in the case of the ransomware - even tough we use tailscale and one compromised server can't ssh into the other.
i have daily backup instances to cold standby qemu-kvm VMs with snapshots of qcow2 storage which are kept for 10 days and i skip deleting every weekly Monday backup until space becomes a problem (usually months). sometimes the qcow2 storage backend becomes too slow with so many snapshots and that's when i qemu-img convert it which basically fixes it but removes the snapshots, so i keep both of them for a while.
You can use old school way. You can have a tape backup, ssd, or a device that is not connected to the network constantly. Copy there and unplug the device.
