They’re extremely temperamental vehicles because they’re not fit for purpose.
The original Range Rover is an upmarket agricultural vehicle, and used the same platform from 1970 until the 2000s. When you actually use them as intended, for off road farm work you realise they’re better off road than they are on road.
That's fair. Especially in environments in 2025 where it's common to only care about a DB URL for the app config and pretty much never manually jump into the DB.
I run into this with lots of tools and I just shrug and move on... I've actually never given this a second thought until you pointed out this inconsistency.
Imagine you're writing trading software, you have an algo go haywire and it machine guns the whole order book, and then you refuse to put a "max order size" outside of the algo to stop it from happening again because you can't figure out why it happened in the first place.
Try telling a regulator or your boss that was your reasoning.
How many one-off band aids do you think should be applied for rare, never reproduced problems before you slap a “100% safe” label on it and ship it with the confidence of a bloated, cruft-ridden job well done?
Are you arguing in bad faith, or do you just not have any practical experience dealing with complex systems?
Even if the bug can't be reproduced, on the basis of multiple user reports the first step absolutely should be to add some assertions and logging around email deletion.
The point is not to give it a "100% safe" label, the point is to start narrowing down possible root causes. If the problem recurs again, you'll have assertions ruling out certain possible culprit code paths as well as logs displaying the values of relevant variables.
Just not true. Lots of oil companies have a vested interest in renewables now. A lot of the infrastructure for offshore oil is being redeployed for offshore wind.
The New York Times is a glorified blogging platform. Not to long ago it was a Wordpress site.
I'm fully aware of how jaring it is for the median HN reader to hear this, but maintenance of a news website isn't the kind of skilled labour that commands a 250k a year paycheck anymore.
Linux outages and upgrade fuckups happen all the time. The difference is that Linux isn't on a unified upgrade cycle so issues come as a trickle rather than a dulge, so the problems are usually localised to a corporation and don't make the news.
Also Linux fanboys will usually blame the system admin for not configuring things properly if things break: "it's not the operating system, it's <something stolen from OpenBSD>".
End of the day Linux is only popular because of the inertia UNIX had on mini-computers/servers. For standard end users GNU Linux is lightyears behind Windows and macOS in terms of usability and stability.
> The Monolog is our new source of truth for published content. Every system that creates content, when it’s ready to be published, will write it to the Monolog, where it is appended to the end.
> The Monolog contains every asset published since 1851. They are totally ordered according to publication time. This means that a consumer can pick the point in time when it wants to start consuming. Consumers that need all of the content can start at the beginning of time (i.e., in 1851), other consumers may want only future updates, or at some time in-between.
> As an example, we have a service that provides lists of content — all assets published by specific authors, everything that should go on the science section, etc. This service starts consuming the Monolog at the beginning of time, and builds up its internal representation of these lists, ready to serve on request. We have another service that just provides a list of the latest published assets. This service does not need its own permanent store: instead it just goes a few hours back in time on the log when it starts up, and begins consuming there, while maintaining a list in memory.
Absolutely insane. The only reason this works is that the NYT publishes less than 300 articles per day so you can get away with doing un-indexed full table scans of your entire database. But the engineers can put "I created a log based time-series architecture on their resumes".
> If your firm has had KDB for ages there's a good chance it's big enough to be signed up to one of the research groups who maintain a set of test-suites they will run over a vendor's latest hardware offering, letting them claim the crown for the fastest Greeks or something. If your firm is a member you may be able to access the test-suites and look at how the data in the options tests is being written and read, and there are quite a few, I think.
Unfortunately my firm isn't that big ~150 in total and maybe about ~40 developers, if which there are 2 full time KDB devs who's job is mostly maintaining the ingestion and writing some quite basic functions like `as_of`. There's only two people who work on our options desk as developers, so there's a lack of resourcing for KDB. When I have these issues with KDB around performance, it's quite hard to get support within my firm from the two KDB devs (one of which is very junior).
> I've never worked on options data and so can't opine on the problems it presents
The thing about options data is that it's generally lower frequency but a lot more complex. If spot data is 1 dimensional, and futures data is 2 dimensional, options are 3 dimensional. You also have a lot more parameterizations which leads me to the second point :)
> you may not want to load data out of KDB a day at a time. Try to do the processing in KDB
Just to give you a very specific example of the processing I need to do. I have a data structure in KDB like this (sort of typescript notation):
This is vol surface. To convert that into volatility requires:
f = log_moneyness - m;
total_var = a + b * (rho * f + (f * f + sigma * sigma).sqrt())
vol = total_var / time
Then in order to calculate the log_moneyness I need to calculate the forward price from an interest rate which is slightly more trivial.
Now I have a base in which I can start generating data like the delta, but this also requires a lot of math.
I was pulling this stuff out of KDB because I already had my code in rust that does all of this.
> You said you're scared to do queries that return a lot of data, and that it often freezes. Are you sure the problem is at the KDB end?
Yeah, I'm pretty sure in my case. We have some functions designed for getting data written by the KDB guys. Even for functions that return 30 something rows, like an as_of query it takes ~10s.
The volatility calculation looks like it should be doable in q/k, I'm not sure about the more complicated stuff but at the end of the day it's a general purpose language too so anything is possible. KDB being columnar means thinking in terms of rows can often be slower. Sounds like you have a keyed table? If the KDB guys you have aren't that good/helpful you could check out some other forums. Could be useful for the future to be able to circumvent issues you have with the kdb devs.
The original Range Rover is an upmarket agricultural vehicle, and used the same platform from 1970 until the 2000s. When you actually use them as intended, for off road farm work you realise they’re better off road than they are on road.