Interesting post. We wrote this “below” utility [1] that monitor system metrics similar to atop. We want the ability to collect all metrics into a single object, pass it around and visualize it elsewhere. Naturally we need some way to query into fields or even nested-struct fields. For example, to get the file cache usage of a particular process, we need to go through sample->processes->pid->memory->file cache. To do it ergonomically and also type-safely, we end up using proc macro to generate enums that represent field paths of the structs and then use them to query values of non-struct (leaf) fields. I always wonder if there are simpler ways or existing proc macro derives to safe us the efforts. Maybe I do need to look into serde internals for some inspirations.
- increase tolerance to slightly off taps, and gradually increase the number of ticks (not sure you already do this but right now it’s too hard win many times in a row)
- tik of the day mode. A long tick that challenges people who can win it in fewest trials
Bought and played for a while, 83 attempts with 12 corrects and max 2 corrects in a row. It s a very difficult game without visual and sound to aid figuring out the exact rhythm, and the game seems very strict about how much you can be off.
Suggestions:
- have an option to add 4 constant interval tiks at the beginning to help setup the base rhythm
- hold down the small white dot to return to menu so you can see progress without exiting
- have a way to visualize a rhythm similar to the example or skip it (maybe two finger hold?) if you are stuck
- some rhythms feel to have slightly uneven tempo. Is the duration of the tick taken into consideration when generating the tempo?
Many years ago I learned from some Japanese TV show that you can use centrifugal force to get the very last bit of toothpaste out of the tube even if you can’t squeeze out any more. Something similar to this: https://m.youtube.com/watch?v=u-4MKefJqbc
One of the best articles I have read for years. It's easy to underestimate how difficult it is to make things "just work" in the first trial. I really envy the author's ability to plan for known and unknown situations. Marvelous job!
We published this paper "TMO: Transparent Memory Offloading in Datacenters" last year which covers some Linux memory management mechanisms that may be quite useful for providing reasonable estimations to application memory usage.
We observed that the real memory footprint for applications depends on many factors: file access pattern, disk IO speed (especially if swap is enabled), ssd vs hdd, application latency sensitivity, etc. Instead of coming up with some overly complicated heuristic, we use the Linux kernel provided memory.pressure [0] metric via cgroup v2. It measures the amount of time spent waiting for memory (page fault etc). Then by slowly reclaiming memory from the application until its memory pressure hits some target (say 0.1%), we can claim that the steady state usage is the actual memory footprint.
This may not be useful for PC but could be very useful for data center to track memory regression, and also to harvest disk swap without concerning too much about the cliff effect when the host runs out of memory and suddenly kernel pushes everything to swap space.
[1] https://github.com/facebookincubator/below/blob/main/below/b...