foobiekr

It's great, but operationally there are lots of gotchas and little guidance.

We got bitten _hard_ in production when we accidentally allowed some of the nodes to get above 90% of the storage used. The whole database collapsed into a state where it could only do a few transactions a second. Then the ops team, thinking they were clever, doubled the size of the cluster in order to give it the resources it needed to get the average utilization down to 45%; this was an unforced error as that pushed the size of the cluster outside the fdb comfort zone (120 nodes) which is itself a problem. The deed was done though and pulling nodes was not possible in this state, so slowly, slooooowly... things got fixed.

We ended up spending an entire weekend slowly, slowly getting things back into a good place. We did not lose data, but basically prod was down for the duration, and we found it necessary to _manually_ evict the full nodes one at a time over the period.

Now, this was a few years ago, and fdb has performed wickedly fast, with utter, total reliability before that and since, and to this day the ops team is butthurt about fdb.

From an engineering perspective, if you aren't using java fdb is pretty not great, since the very limited number of abstraction layers that exist are all java-centric. There are many, many issues with the maximum transaction time thing, the maximum key size and value size and total transaction size issue, the lack of pushdown predicates (e.g., filtered scans can't be done in-place which means that in AWS, they cost a lot in inter-az network charge terms and also are gated by the network performance of your instances), and so on.

What ALL of these have issues have in common is that they bite you late in the game. The storage issue bites you when you're hitting the DB hard in production and have a big data set, the lack of abstractions means that even something as finding leaked junked keys turns out to be impossible unless you were diligent to manually frame all your values so you could identify things as more than just bytes, the transaction time thing is very weird to deal with as you tend to have creeping crud aspects and the lack of libraries that instrument the transactions to give you early warning is an issue, likewise for certain kinds of key-value pairs, there's a creeping size problem - hey, this value is an index of other values; if you're not very careful up front, you _will_ eventually hit either the txn size limit or the key limit. The usual workarounds for those is to do separate transactions - a staging transaction, then essentially a swap operation and then a garbage collection transaction - but that has lots of issues overtime when coupled with application failure.

There are answers to ALL of these, manual ones. For the popular languages other than java - Go, python, maybe Ruby - there _should_ be answers for them, but there aren't. These are very sharp edges. Those java layers are _also_ _not_ _bug_ _free_. So yeah, one has a reliable storage storage layer (a topic that has come up over and over again in the last few years) but it's the layer on top of that where all the bugs are, but now with constraints and factors that are harder to reason about than the usual storage layer.

One might say, hey, SQL has all of these problems too, except no. You can bump into transaction limits, but the limits are vastly higher than fdb and the transaction time sluggishness will identify it long before you run into the "your transaction is rejected, spin retrying something that will _never_ recover" sort of issue that your average developer will eventually encounter in fdb.

That said, I love fdb as a software achievement. I just wish they had finished it. For my current project, I have designed it out. I might be able to avoid all of the sharp edges above at this point, but since we are not a java shop, I also can't rely on all the engineers to even know they exist.

Nvidia’s value is completely out of line with their revenue and eventually that will catch up with them.

Intel has the same software issue as AMD but their hardware is genuinely competitive if a generation behind. Cost and power wise, Intel is there; software? No.

IBM was also incompetent and the os/2 team in Boca was had some exceptional engineers but was packed witg mostly mediocre-to-bad ones, which is why so many things in OS/2 were bad and why IBM got upset for Microsoft contributing negative work to the project because their lines of code contribution was negative (they were rewriting a lot of inefficient bloated IBM code).

A lot went wrong with os/2. For CUDA, I think a better analogy is vhs. The standard, in the effective not open sense, is what it is. AMD sucks at software and views it as an expense rather than an advantage.

and a pattern that deals with larger transactions and keys. it just is a requirement. People run into this late, and it kind of screws them up.

also, a lot more operational tooling would be nice.

ipv6 is very, very widely deployed in mobile networks. Download some net tools and check out your phone's interface table.

Also v6 did a bunch of things right. NDP and link local addresses for v6 actually work. The fragmentation changes were 100% the right thing to do. v6 extensions like SR and uSID are both solid and consolidate a lot of stupid stuff into something clean.

v6 had a bad, rocky start. A lot of that was completely inadequate attention to the transition, and the vendors fucked up almost everything for years, on their own gear and interop, but at this point v6 is fine.

Would I launch a v6 only service? No, because at this point the SPs are the problem. Verizon as of a few years ago and maybe now still didn't do v6 to any of their home users. So many things like that.

The problem with micropayments has ALWAYS been malicious actors. It will ALWAYS be malicious actors. This is not a technical problem but a problem with the whole concept that is structurally inseparable.

Why is this being downvoted?

Can we agree that legacy admission should be completely done away with? The only people I think would be opposed would be the managers of the endowments and fundraising (and legacy beneficiaries, who are smaller in number).

None of that changes what the poster you were replying to was getting at. The opposition to standardized testing was entirely due to the performance of _some_ minorities and entirely political.

I feel this way about most of the standardized tests. I took the LSAT on a whim which no prep and scored 95th percentile. The whole thing was completely reasonable and mostly tested basic logical reasoning and vocabulary/reading comprehension. At the time, there was a short essay component which was entirely about the ability to express whatever thoughts you were supposed to express clearly.

The thing about these tests is that they are all perfectly reasonable. The main reason people have a test with them is they also tend to identify people who _probably_ should not be in college at all and that is not a message anyone wants to accept needs to be sent.

Indeed. Ada killed itself, partially because it was one of the DoD approved languages and so the vendors got on board with raping and pillaging everything they could, killing the whole thing in the process.

You would be pleased to know that Whiptail exceeded whatever low bar you might have had. I like to see people achieve the things they set out to do, and I am assuming that was their goal.

Rare to see a product completely canceled and removed from the market as soon as customers started reporting minor things like total data loss due to corruption..

The original oculus rift cv1 was just so comfortable. I wish someone would get there again.

A lot of inspecting transparent TLS firewalls look for high entropy blocks, the idea being to sniff out encrypted exfiltration. Making them low entropy is straightforward, as you say.

Smells like Igneous or TinTri.

Story shows too much competence for Springpath or Whiptail.

Storage is particularly rife with stuff like this for some reason.

Ada is such a lost opportunity honestly. As powerful as C, performant and clean.

There's a kind of naive thing going on on HN where peopel see a bug and ask whether or assert Rust will fix it. The problem is they are homing in on just the bugs Rust addresses - this is fine, I've had this conversation at work (not involving Rust, even) for two decades, including discussions about Java.

The problem is that Rust solves _a_ class of issues without even beginning to address other kinds of problems, and so this sort of thinking is evolving toward a mindset that "oh it's rust so no security issues", which is completely wrong.

It's not the lack of a fine grained permissions model, it's the total lack of a real threat model and any consideration at all for what happens as extensions change over time.

Forget all that.

1. They increase the attack surface of the browser 2. They have routinely been transferred to (for money) or taken over by malicious entities 3. Often they subtly break things in ways that are fine for expert users but which result in support reach out by others

The whole extension thing is a mess.

It’s not 1%, more like 0.005%.

In a shallow way, and ignoring the degree, yes, they are similar.

This. Basically this is the new civic projects spending.

smuggling things past firewalls is trivial. base48 or some other nonsandard scheme or encrypt a zip file and use a bananaphone scheme to make the content look low entropy. No firewall will flag that.

Not everything has to stay the way it always was.

It's not really true though. Incremental expansion doesn't actually require more heads if the compute is uniform.

I should really have mentioned storage. Networking is a vendor-imposed shitshow, but storage, storage is next level. It's almost like the vendors in 1995-2020 actively built their products around spite and hate for their customers.

To me it is interesting that despite the massive economic advantage that vendors _should_ have, they've made their products so unusable that people will pay 3x-10x more just to not have to deal with them, which is what cloud amounts to for enterprise customers.

Honest, I have literally never heard anyone ever say "junta" with a hard /j/ sound. Is this really a thing?

Cloud was actually the answer to "how do I give more virtualized compute to people without hiring more expert server and networking admins."

The rest is noise.

Startups aside, most enterprise teams match the following: apps don't need to scale massively (scale up is enough and a surprising number of large, well-knwon services are entirely based on scale-up architectures behind the facade), most don't need dynamic scale, and most aren't even going to be started and stopped dynamically.

But hiring people who can run a network, only to have them sit idle most of the time or - and this is common - doing things and as a result breaking things, and people who can run servers and VMware and so on, and firewall, and WAN connectivity, ...

A lot of these things are, in fact, trivial, but vendors made them stupid and hard and painful to set up and doubly painful to troubleshoot. Cloud exploited that situation.

Things aren't a _lot_ better now but they're somewhat better, and now the economics of cloud are starting to get looked at.

From a timing perspective would that not have been during the FOGBANK debacle? A lot of military contractors temporarily got very interested in data preservation...

Nobody needs DPUs. It’s a fake market.

The stuff you’re listing, other than CPUs, which I explicitly called out as going to Intel and AMD, is ultra low margin.

Apple will never build cars. Each dollar of car revenue will hurt their margins. It doesn't matter how lux the car is or the target market, it isn't going to happen.

Tesla isn't going to be able to hold their margins, either.

It's going to be more like Nvidia - Nvidia captures all of the margin in the servers - with some going to Intel or AMD - and SuperMicro, Lenovo, HPE, etc. eke out their existence on the low value chassis.