yazaddaruvala

FSTs are “expensive” to re-optimize and so it’s typically done “without writes”. So the database would need some workaround for that low write throughput.

To save you the time thinking about it: The only extra parts you’re missing are what Lucene calls segments and merge operations. Those decisions obviously have some tradeoffs (in Lucene’s case the tradeoff is CRUD).

There are easily another 100 ways to be creative in these tradeoffs depending on your specific need. However, I wouldn’t be surprised if the super majority of databases’ indexing implementations are roughly similar.

Seems the embeddings would just be useful for a “nice corpus search” mechanism for some regular RAG.

I believe this is what they mean.

In practice, how fast will the model change (including tokenizer)? how fast will the vector db be fully backfilled to match the model version?

That would be the “cache hit rate” of sorts and how much it helps likely depends on some of those variables for your specific corpus and query volumes.

Are triangles cheaper for the rasterizer, antialiasing, or something similar?

?

The rest is time for feedback, discussion, and ideally a decision or collecting action items.

Amazon corporate is roughly broken down like this:

L4: 45%, L5: 45%, L6: 7%, L7: 2.5%, L8+: 0.5%

Only the first promotion has guardrails (L4 to L5). Typically you’re expected to be able to write at all. From there many people end their careers at L5.

Going from L5 to L6 requires being the best person on your team for multiple years running. Compared with some really smart, focused, and motivated people. You’re also expected to be able to write well, read, and kinda poorly coach other people’s writing.

Going from L6 to L7 is very difficult. One of the biggest differentiators really is scale. If you still need help writing docs - that’ll slow you down and you won’t scale. If you’re slow to read and provide valuable feedback again that will hold back scale (many people compensate by adding more time to their work days).

However, the funny thing is the doc writing culture at Amazon is built by and for L8+ leaders. Everything else was just training and weeding people out.

Going from L7 to L8 is where “in-meeting reads” really start showcasing the differences between leaders. I’ve known smarter people that made better decisions but had their careers stagnate while watching other “80th percentile” decision makers grow because of speed to grok information and deliver valueable feedback 9 of 10 times is more important than the incremental benefit of being right 10 of 10 times.

So I get your concerns about in-meeting reads throughs but just keep in mind who and what it is defacto built for.

The nice side effect is the author taking 10x more time to save 10x L+1 and L+2 leaders (ie more expensive people) from spending that same time trying to understand it.

I wonder if they could use that as the feedback mechanism.

Ideally if the sensors are small, low power, and cheap enough CO2 and lactic acid levels would also be good to check on to increase bloodflow.

But when a victimized population like Ukraine decides it wants to keep fighting. Especially given:

> Ukraine should be opposed to depopulating itself.

Then you gotta ask yourself:

Given they would rather die than suffer the consequences of a compromise.

Then maybe they know something about the consequences of that compromise that you and I can’t? and if so, maybe we should continue trusting the victims to not compromise ?

At work I’ve been helping push “use SQL with the best practices we learned from C++ and Java development” and it’s been working well.

It’s identical to your point. We no longer need to care about pointers. We need to care about defining the algorithms and parallel processing (multi-threaded and/or multi-node).

Fun fact: even porting optimized C++ to SQL has resulted in performance improvements.

I've been buying local, pasture raised chickens for the last 10 years. I am very fortunate to have had the income to allow me to do so. I also don't eat that many eggs (roughly a dozen a month - so it hasn't been that expensive).

The price of my eggs was always between $8-$12 / dozen (including this weekend when I easily found and bought another 2 dozen). I get that I was buying "already expensive eggs", because apparently other people were buying eggs $2 / dozen.

However, to be frank, I'm not sure how people expect eggs to be so cheap. Taking into account the land, the water, the feed, the labor, the transportation all to create a dozen eggs, it must cost more than $2.

Clearly paying a little more for the eggs has allowed me to support farms which are robust to large shocks like this (both in terms of input costs and in terms of health of chickens). I really hope as a society we can all move away from the unsustainable farms and improve the economics of sustainable farming so that everyone can afford locally grown, healthy eggs for centuries to come.

In the meanwhile, there will be people who have to buy fewer eggs (either because of health regulations - or because reality checks will always exist like with market shocks right now).

Hopefully, after this crisis, through graduated health regulation we can cause a controlled increase to the floor price of unsustainably grown eggs, while also (through technology and economies of scale) reducing the floor price of locally sourced, sustainably grown eggs.

This is stuff your Nokia didn’t do at the same scale. At best some sms at a significantly reduced polling rate.

My apps auto update in the background. Something my Nokia from 2007 didn’t do.

So there are many passively provided features but by definition they are not obvious to you and as such harder to appreciate.

If you have an iPhone: I use low power mode constantly. I have an automation to use it at 75% or less battery.

I get roughly 2 days of battery life without any YouTube usage.

https://www.youtube.com/watch?v=JBL3NdIK4DI

As long as some new thing is being invented in our industry, a new abstraction will be needed because the old one just can’t quite flex enough while being backwards compatible.

Regarding the context:

> A redundant wrapper is such a trivial mechanical problem to solve or work around,

The DMA maintainer explicitly NAKd a wrapper. He insisted that each Rust driver copy and paste the needed Rust code.

He even explicitly stated the reason was to ensure he did everything possible to keep C the only language in the kernel.

I’m not sure about AWS.

Been there and done that with and without. Junior (and Senior) devs fundamentally don’t read the docs. That and requirements churn are the problems.

Given that, it ends up so much better with React.

An L8 IC has similar responsibilities as a Director (roughly 100ish people) but rather than people, and priority responsibility it is systems, architecture, reliability responsibility.

Small organizations define efficiency based on time to make number go up/down. Meanwhile, if something bad happens at 2am and no one wakes up - whatever there we’re likely no customers impacted.

Larger organizations are really efficient at ensuring the p10 (ie worst) hires are not able to cause any real damage. Every other thing about the org is set up to most cost effectively ensure least damage. Meanwhile, numbers should also go up is a secondary priority.

The iteration order seems arbitrary to a human, but that is exclusively because function(name, insertion_id) is not optimized for a human. It seems strange to call the collection “unordered” because of how it appears to a human.

Is your argument specifically about the game developer's mental model for Linux's priority, or something core about the Proton abstraction layer?

All software runs on some abstraction. So specifically, if the game developer prioritized a Linux port by explicitly testing Proton, would that be enough for you to consider the game "developed for Linux"?

Is Proton in some way inferior to native?

This can simplify a bunch when using Rust but also better documents the internals for C.

Very likely if Firmware is successful they would use the current positive talking points from this blog post and lessons learned and keep trying to secure Android.

My guess would be the kernel and/or JVM are on the next step list.