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.
The program collects system resource metrics into a data structure and we need to display the fields with different styles and formats. In order to decouple the data structure from rendering, Queriable (Keyable) and FieldId (combine KeyPath + mirror struct into enum) are used. I will definitely like to checkout the KeyPath implementation as it seems more general.
I was recently searching for wedding gift for my photographer friend and found this. There does not seem to exist many other e-paper art frames and this one looks decent. It also has some open source software (https://github.com/framelabs-eu), but the firmware seems closed-source.
But that requires a wire that goes from the outlet all the way to the charge pad though, right? I think the main goal is to have no visible wire when it's on the wall. On the other hand 7k image changes before going out of battery seems quite a lot. Just not sure if that's a representative number.
They seems to achieve size reduction by transmitting only the forward upgrade patches, and let the machine generate the downgrade patches during the upgrade. How do they manage to keep install time the same while this definitely uses more resources (cpu, io)?
I believe this all comes down to enforcement, which is grey in the first place. It also matters if the game got (maliciously) reported to enforcement agents.
> Strictly limit the time for providing online game services to minors. Since the implementation of this notice, all online game companies can only provide minors with one-hour online game services from 20 to 21:00 on Friday, Saturday, Sunday and legal holidays. At other times, it is not allowed to provide online game services to minors in any form.
[1] https://github.com/facebookincubator/below/blob/main/below/b...