fizx

The Everettian multiverse is a bit like seeing some bubbles and foam in the surf and concluding that there are "many oceans." Yes, there are many surfaces of water, but calling each bubble an ocean is a bit disingenuous.

Like the bubble analogy, new Everettian universes are local, small, and the total amount of probability density (water in this analogy) is conserved.

Much like Javascript, the problem isn't Kubernetes, its the zillions of half-tested open-source libraries that promise to make things easier but actually completely obfuscate what the system is doing while injecting fantastic amounts of bugs.

The error correction itself requires qbits, but reading out the final answer apparently becomes more probabilistic and complex, to the point where a neural net is a reasonable solution for interpretation and denoising.

Prices always go up. Sometimes faster, sometimes slower. We can slow it, but it's a fool's errand to make them go down. When I was a kid, I could get an ice cream cone for a 50 cents. That's never coming back.

Now that we've slowed inflation to a manageable level, we need to grow wages to catch up. I never heard a good plan on that from either side.

When you're a scientist, you'd assume the calculus is the most useful thing you learn in high school, but actually its the 10 page essay on deadline for grant writing.

Don't think of an H100. Think of the factories, the tooling, the datacenters and the power supply needed to light one up.

I think that's true for e-bikes, but that's perhaps to be expected in a newer market.

Over in analog mountain bikes, we have the new UDH standard, and basically everything else was standardized except some bearings. All mountain bikes are pretty modular. The main manufacturers make the frame, and then bolt on parts from different brake, shock, etc suppliers. There's at least two of each, which keeps things competitive.

My dream here is probably webassembly transactions with bounded resource consumption

Redis's transaction api is terrible, and doesn't work across shards. Any reasonable transactions are done in Lua, and because Lua mostly works well, there's not a lot of pressure to fix transactions.

However, if you're giving redis access to different tenants, Lua is too dangerous.

I'd love to see a "real" transaction API for Redis.

I'm curious how well a o1-like model thinks, given minutes instead of seconds and the temperature set relatively high.

It might be better by now with the newer GC options (ZGC, G1, Azul). For a while those had their own problems, but I'm a little out of the loop.

Tuning the older options wasn't really all that beneficial. We tried tuning, then running a custom build of OpenJDK to mess with the survivor space (which isn't that tunable via config), then ultimately settled on more aggressive (i.e. weekly) rolling restarts of servers.

Seems like he fell on his own sword.

A problem here is that ES (and Solr too) are pathological with respect to garbage collection.

To make generational GC efficient, you want to have very short lived objects, or objects that live forever. Lots of moderately long-lived objects is the worst case scenario, as it causes permanent fragmentation of the old GC generation.

Lucene generally churns through a lot of strings while indexing, but it also builds a lot of caches that live on-heap for a few minutes. Because the minor GCs come fast and furious due to indexing, that means you have caches that last just long enough to get evicted into the old generation, only to become useless shortly thereafter.

The end result looks like a slow burning memory leak. I've seen the worst cases take down servers every hour or two, but this can accumulate over time on a slower fuse as well.

It got a lot better in the ~7 series IIRC when they added checksums to the on-disk files. I don't know if you still have to recover corruptions by hand, or whether the correct file gets copied in from a replica.

The replication protocols and leader election were IMO not battle-hardened or likely to pass Aphyr-style testing. It was pretty easy to get into a state where the source of truth was unclear.

Source: Ran an Elasticsearch hosting company in the 2010's. A little out of the loop, but not sure much has changed.

Whenever I see these google SRE articles, I kinda reduce the message to "don't be a hero in a cost center in an org with nearly unlimited resources."

If you're in a profit center, you might get rewarded for your risk.

Writing a protoc plugin would have been 5x easier, but its harder to get a blog article out of it.

Also, this reads like they might not have seen the newer proto3 optional keyword, or know about the well-known wrapper types.

No one will notice the bike's exhaust!

I think we're alluding to making private property ownership more accessible, by making it more favorable, tax and otherwise, to own one house or small-business-zoned property, but less favorable to own many.

So true.

The advice of "commoditize your complements" is working out great for amazon. Ironically, AWS is almost a commodity itself, and the OSS community could flip the table, but we haven't figured out how to do it.

"The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." ~ G.B. Shaw

To make progress, you have to keep the optimism of a neophyte.

When going about the unreasonable, I tend to ask myself 3 questions:

1. Has this area recently been unlocked by progress elsewhere? e.g. ML with cheap GPUs

2. Have I built skills that make me uniquely suited to tackle this?

3. Is this problem relatively unsexy? Everyone wants to build a better javascript framework, no one wants to wear the pager.

I find the most promising areas to be unlocked when I can answer yes to all three things.

I think we have ok generalized value functions (aka LLM benchmarks), but we don't have cheap approximations to them, which is what we'd need to be able to do tree search at inference time. Chess works because material advantage is a pretty good approximation to winning and is trivially calculable.

Most people choose themselves ;)

Fun story time: I was at twitter for a few years and tended to write quick hacks that people wanted to replace with better engineering.

We never had scala thrift bindings, and the Java ones were awkward from Scala, so I wrote a thrift plugin in JRuby that used the Ruby thrift parser and ERb web templates to output some Scala code. Integrated with our build pipeline, worked great for the company.

I also wrote one era of twitter's service deploy system on a hacked up Capistrano.

These projects took a few days because they were dirty hacks, but I still got a below perf review for getting easily distracted, because I didn't yet know how to sell those company-wide projects.

Anyhow, about a month before that team kicked off Parquet, I showed them a columnar format I made for a hackweek based on Lucene's codec packages, and was using to power a mixpanel-alike analytics system.

I'm not sure whether they were inspired or terrified that my hack would reach production, but I like to think I had a small hand in getting Parquet kickstarted.

I was tech lead on that subsystem for a little while in 2010. A lot of smart people thought about the hybrid approach, either by using the search index to drive the timeline or building a custom ring-buffer-based index of all tweets. Ultimately two systems are harder to maintain than one, custom indices are hard, and the low-complexity approach dominated a higher-performance approach.

Also, contrary to popular opinion, we didn't go down when Justin Bieber tweeted, but we did have elevated error rates when large quantities of Justin Bieber followings put pressure on the MySQL row lock of his following count. In retrospect, lock striping would have helped, but the migration would have been horrific.

Hi, sometime middle-manager here. The goal isn't to have me make decisions, its to let people around me make decisions quickly and well enough that most of the time it works out, and when it doesn't, we can roll back easily.

If this isn't working out, I hire experts to improve the quality of decision-making, with me making decisions as a last resort.

Ehhh, there's pros & cons, just like anything else.

Maybe some VCs want you to dig to the bedrock, but not all, and everything in life is a negotiation.

I look at YC as grad school for entrepeneurs. You'll learn a ton, build a network, and have a good time for a while. Unlike grad school, there's direct upside, and you won't have to take out loans or live off the lab stipend.

Now would I go to grad school at 40? Maybe, but the calculus is certainly different than at 20.

YC is clearly good for something. You really have to figure out how to make it work for you.

There's a million paths, but here's one I like.

Use ElasticSearch. It will scale more than Postgres. Three hosted options are AWS, Elastic, Bonsai. I founded Bonsai and retired (so am partial), but they will provide the best human support for you, and you won't have to worry about java Xmx.

Your goal with ES is to use the Regex PatternAnalyzer to split the code into reasonable exact code-shaped tokens (not english words).

Here's a rough GPT4 explanation with sample config that I'd head towards: https://chat.openai.com/share/e4d08586-b7ef-48f2-9de1-7f82ea...

> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users.

The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return.

Sounds a little crazy, but we've actually pulled it off for a project, and its magic.

It's worth noting that if you're messing around with large text files from the CLI, awk, grep, etc will be an order-of-magnitude faster if you opt out of unicode parsing.

I'm pretty confident adding LC_ALL=C to the awk solution would get it easily under a minute.

You don't need Max Verstappen to drive your armored truck, but you sure do need Steph Curry to sell basketball tickets.

The level of competition between companies--the level of talent needed to win--is what drives the salaries.