So the same thing I said we do, a periodic validation of recovery, but with an acceptably short period.
SWEs can do that too. They can even write software to do most of it automatically.
They went through systems design interviews to ensure they know how to scale without picking technology choices that require a dedicated human caretaker.
It’s the opposite. Needing a DBA to operate a completely managed database is a sign of not enough maturity.
Are you saying DBAs would be doing _continuous_ recovery testing? That’s not even a thing that exists.
Managed databases don’t lose customer data. They would be sued and lose, and if word got out, they would lose their customers. They are optimized for the machines they run on. The proprietary tooling from AWS for managing HA clusters, doing blue-green upgrades and monitoring for slow queries is all miles ahead of the open source tooling available for self-managed databases.
I don’t have any benchmarks, but it’s surprisingly relevant. Not necessarily because parsing JSON is slow, but because managing memory is slow, and you’re dealing with potentially malicious input.
A non-streaming implementation needs to copy the request from the network stack into a contiguous GC-managed char array, possibly resizing it a few times as the data is received. Then when it’s time to parse, it goes through this array and allocates an unbounded number of JsonValue nodes. For JsonString and JsonNumber, it probably needs to create defensive copies of the data instead of spans of the input array, otherwise changing the input array corrupts the tree.
That’s kinda bad under memory pressure even for benign inputs. But consider malicious inputs, such as {"x":{"x":{"x":{"x":{"x":{…}}}}}. It would make this non-streaming implementation allocate a lot of String and JsonObject instances. The allocations would total multiple times the size of the input, and would be extremely fragmented.
On the other hand, a library that does streaming and that binds to objects could parse straight from the buffers in the network stack, and could avoid allocating objects for anything that it will not need to bind.
The XDG spec tells you exactly where to place your files. It isn’t in $HOME/.your-project ever. You know about XDG enough to mention in your docs, so you should know.
It does hijacks shell history. If I press the up arrow, I expect _my shell_ to handle it how I configured it, not your tool. Because you’re saying your tool is a shell prompt!
A shell prompt is the program that runs before and after every shell command to show me contextual information like the current directory, and the exit code of the last command.
If you want this to be include customizations beyond the prompt, stop calling it a prompt.
No, they are not? Atuin is not a shell prompt, you can use it with any prompt. Like Starship, Spaceship, liquidprompt, etc. None of those hijack shell history.
I don’t want my prompt to also handle shell history, and especially in such an “opinionated” way.
What happens to my actual shell-provided history?
Does too much for me.
edit:
> Both files follow the XDG base directory spec, so neither lives in the install directory. Removing whetuu with rm -rf ~/.whetuu cannot take your history with it. whetuu paths prints both locations.
My understanding from reading this is the complete opposite. This library is explicitly not supporting the features that web servers need to be performant and handle production traffic, like streaming.
A web server using this could only start parsing when it receives the last byte, and could only start responding when it’s done serializing, all while holding non-lazy trees of JsonValue objects in memory.
Yes. It contains a reference to the image in the source application.
When you paste, X or Wayland lets the source application communicate with the destination application to send the image over.
You’ll likely always have a very simple clipboard manager that stores a single copy of the clipboard so you don’t rely on the source application staying alive.
Clipboard managers are free to store the clipboard anywhere.
> hiring at least a couple of DBAs and get more flexibility
Every place I’ve ever worked at that had DBAs had the complete opposite of more flexibility. You have to do things the DBA’s way, and if their way doesn’t work for your service, you need to fight for their time and priority.
Meanwhile every place I worked at where every team completely owned their databases + did periodic data recovery drills had much more flexibility and no data loss.
The problem with Undo reverting the clipboard state is that Undo is usually file or app-local, but the clipboard is shared. You can cut from app A, switch to app B, cut something else from app B, then go back to app A and undo the cut.
“Ghost cut” can work across apps with reasonable undo support by not using the clipboard at all and some form of IPC instead. For example, when you cut from app B before resolving the cut from app A, app A could be notified to cancel its cut.
I think this is much less intuitive than the current convention though.
This might work if we have completely new harnesses for this, because the current one’s intentionally introduce non-reproducible context and tools.
The current way we’re doing SDD is extremely pointless. You reach a decision point that is under specified, make a decision, update the spec and continue the implementation. There’s no guarantee that the implementation followed from the updated spec, and not from the decision.
So the same thing I said we do, a periodic validation of recovery, but with an acceptably short period.
SWEs can do that too. They can even write software to do most of it automatically.
They went through systems design interviews to ensure they know how to scale without picking technology choices that require a dedicated human caretaker.
It’s the opposite. Needing a DBA to operate a completely managed database is a sign of not enough maturity.