Zefiroj

Actually, there are some ingredients that you need to increase linearly and some that are good to do in steps, others you actually might need to increase sublinearly and some not at all. And all of that could depend on how an ingredient is used in the recipe. I think this is actually quite useful.

AI is fantastic at creating recipes. I've been using it to adjust and tweak recipes according to my cooking experience and my specific equipment, and it tends to do quite well, at least as a first pass. It probably has internalized more science than most recipe creators. And honestly, New York Times cooking recipes are a hit or miss at best.

Sports is fundamentally entertainment. Let people do what they want.

Check out the lru_gen_min_ttl from MGLRU.

> But if you do that, things like the USPS donkey train [0] would be stripped, the US military would / should be reduced to a fraction of its current size or down to nothing, etc.

and that is a problem because? These are funded by tax dollars collected. It's impossible for people to stop paying for them whether they make sense or not.

in a sense, RCU is garbage collection.

I wonder how well the caching works. The FAQ says 30 days, so you might be getting a pretty stale result. That combined with Google's "fun fact: 15% of all Google searches have never been searched before", makes me wonder how identifying these queries can be.

The rust language is not well-specified, and if you take rust as the language specified by the compiler, then it has many soundness bugs. So even if you stay within "safe rust", you can segfault.

The "memory safety" of rust is oversold since "safety" is not formally proven for the rust language. While anecdotally memory-related bugs seem less likely, rust without unsafe is not absolutely safe.

There's a good balance between preventing accidents and reducing friction.

One person having "god-mode" access isn't usually that terrible.

Funny enough, Google is still on cgroup v1. Writeback is also very aggressive such that most of pagecache is clean.

The author has identified the issue to be memcg reparenting causing a spike in CPU usage. Reparenting mostly solves a problem with zombie memcg, where the memcg lingers because some resource is still charged to it. In the extreme case you can end up with tens if thousands of zombies. The zombie memcg problem is not unique to cgroup v2, but reparenting is fairly recent.

The article solves the cpu spike by disabling the io or memory controller, but if one would like to use those controllers, a better way to charge memory would be nice.

It is unfortunate that it's clear where the memory should be charged, but the kernel does not provide reliable way to deterministically charge that memory. If anyone has any design ideas, please feel free to chime in!

Linux excels at drivers and device support. The actual kernel is nowhere near as good as its competitors.

I get some horrendous peering at home, and proper DC networking is not going to have that problem.

star-triforce