What's crazy is the pricing difference given that OpenAI recently reduced latency on some models with no price change - https://x.com/OpenAIDevs/status/2018838297221726482
25 karma · joined February 3, 2014
That being said, I procrastinated on getting postgres backups working and ended up causing self-inflicted corruption, so it is nice to see you've got that setup and have thought of pretty much everything!
I recently had a bunch of breakages and needed to port a setup - I had a complicated k3s container in proxmox setup but needed it in a VM to fix various disk mounts (I hacked on ZFS mounts, and was swapping it all for longhorn)
As is expected, life happens and I stopped having time for anything so the homelab was out of commission. I probably would still be sitting on my broken lab given a lack of time.
Clearing is definitely a key part and a large amount of signal can be derived simply through the zero-balance assertion. To give you some more detailed examples of that:
1. System A bookkeeps +$11 and system B bookkeeps -$10 against the same account, where this is representative of A handing off responsibilities to B during some multi-step process and something was off. In practice, this might look like a Charge being handed off from a product team to the team integrating with card networks for submission. There's plenty of reasons this could have gone awry internally from either team like incorrect fee handling, incorrect FX handling, etc.
2. Pipelines reconciling data may bookkeep $11 and -$10 against the same account, where the two events come from different data sources. This could be a difference in Stripe data vs partner reporting or even a difference between two reports from the same partner (e.g. a transaction-level report against a aggregate we've estimated attributions for). Again, there's plenty of reasons this goes wrong like an error on our side, unexpected partner behaviour, actual partner error, or our incorrect interpretation of a complex partner behaviour.
This approach is general in that we don't need to be concerned about what the actual data models or system interactions are to effectively apply monitoring to everything. Another element is to not create a lot of noise on for non-zero balances while they're in an interim state. Some amount of modelling happens to establish an expected time to clear for accounts, and with the right granularity, like "Charges from product teams to integrating teams usually take 10 minutes", "partner report A and B arrive and are processed 1 day apart", or "we receive money from partner A about 2 days after submitting".
In the end, we're trying to boil down every other Stripe system and partner integrations into a Stripe-wide set of discrete states, transitions, and with dollar value they're for. Teams may have their own system diagrams but they'll also have a parallel Ledger event diagram if they handle money which takes consideration to get right (e.g. failure modes, modelling everything well). I suspect that's what the author is getting at with reasoning more mathematically about distributed systems, as we add a twist on a typical system design here.
I ended up mostly giving up because it was a bit janky and I always had something else in more disarray.
Sweet idea on the macropad! I haven't used them before and placement of the USB switch is always a pain.
I had an at-home test that was not positive for obstructive sleep apnea so I landed on a 6-month queue for a test at a sleep lab (hello from over in Vancouver).
I've felt really discouraged by that because it's left me back at "I have no idea what's wrong". I snore (occasionally "like a banshee"), always have nasal congestion while sleeping, wake up every night once (or even twice) needing to urinate and with an extremely dry mouth, and no longer remember what a well rested sleep feels like.
Even now, I'm taking an extended time off work and hoping the lack of work stress would increase my sleep quality but to no avail. If anything, because my circumstances are keeping me away from home, my sleep has gotten even worse to the point where I'm consistently lethargic and too tired to do anything most days.
I only very recently learned about sinus obstruction after taking Affrin (for a cold) and realizing just how clear my sinus was compared to mu average day.
Everything you wrote about allergies and other self-experimentation is very helpful for awareness. I also had no idea positional therapy was a thing, which is helpful as I'm a stomach sleeper.
It has certainly given me more to understand and proceed with doctors for.
On the other hand, TiKV is more comparable to the internal distributed transactional K/V layer to CockroachDB that its SQL layer is coupled to. That of course is not a usable external interface. You could utilize CockroachDB like a K/V store with simple table to forego the SQL functionality and planning (e.g. only primary col index, only key/value column, so on), but I am not sure what the practicality of that is as I have not kept up with CockroachDB development.
(disclaimer: I interned at Cockroach several years back)
I did a similar thing and built isochronic maps while at a start-up for business intelligence back in 2014. I'm curious how you got the going, data processing and all.
When I'd done it I set up all roads and continents in OSM but it took quite a bit of work to do so. I'd used Osmium to import everything into postgres and set it up to using pgrouting. It took quite a bit of work but with a lot of query mangling it had a lot of traversal cost variates (street type, population, daytime pop) it had pretty good approximations of Google!
The most awful part was trying to set up the data to be usable, quick, and deal with large queries (set it up for a maximum 150km without issue), but it was a great challenge!
The primitives uC++ make it very easy to form the concurrency models that are present in other languages and these days the prof does exactly that and shows exactly how to implement common models, such as channels, actors, and a few others.
Everything done is very mappable to how other languages provide concurrency.
For any other issues you run into when using it, you may want to see the discussion about postgrex compatibility at https://github.com/cockroachdb/cockroach/issues/5582. If you run into different problems please do file the issue :).
I'm also an Elixir junkie, so I would also love to see ORM compatibility here! I definitely want to dedicated time to it if I can. (Disclaimer: I'm currently interning at Cockroach Labs.)
When you are trading on an exchange, there could very well be nothing happening in the background. It's instead a process that's just flipping some bits for who owns what in their own database.
I forget the details, but I'm pretty sure it's the former, so it's not exactly easy -- which is yet another testament to how much work goes on behind such a seemingly simple new product.
Do you know of any other alternative routing libraries that can be used with OSM data similar to pgrouting?
I'm currently a CS student and I do find many of the startups locally do involve loads of problem solving on the job, which is beneficial from general algorithm knowledge. Although I believe it's more so the ability to understand the concepts as opposed to spouting knowledge for any specific abstract data type or algorithm.
But by any means all companies are not similar, and outside of the purpose of prodding for problem solving aptness it is definitely not the best topic to discuss in an interview to find the /right/ employee for many of the companies of which do ask it.
I say this because I received an absurd amount of BTC compared to what I put in (bare minimum, only a few cents) which would only have happened as a side effect of a technical issue.
This is personally why I wouldn't trust any programs to handle currency so openly on the web. The inability of the average user to stress test or put proper testing through applications can cause quite a fault. Having experienced the methods that banks undergo for software cycles there is a tiny chance someone would have the resources to properly engineer something so fragile (relative to money) properly.
Because of this I would assume the main reason the author actually shut the site down (or at least so suddenly) was because of scaling technical issues.