IBM Audible Random Timer
oldbytes.space
oldbytes.space
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC225293/pdf/mlab...
[2] https://www.hca.wa.gov/assets/billers-and-providers/particip...
The biggest drawback is non uniform distribution and low bit rates. Another was radiation concerns.
https://apps.apple.com/us/app/bereal-photos-friends-daily/id...
But a corporate version!
I figured if it works for software profiling it oughta work for people. And I set the interval to some Golden Ratio thing like 37 minutes, with the hopes that it wouldn't log the same times every day, but also wouldn't be purely random.
Everything that feels like a "half-day" task took an entire day or two. I would look back on every feature and think, "No way was I working on that for X days straight?"
Basically nothing takes less than half a day.
Small wins are still wins
Not positive if this is the same though.
I’ve used bash like this many times before:
while sleep 600
do
say “hey!”
sleep $(( $RANDOM % 300 ))
doneThat might literally drive me crazy. Watching with dread as the line disappeared would disrupt my work completely. Eventually I’d just lose it like a character in a Poe story.
Would find it funny to see IBM had an official tool to help people focus, but for now I'll assume it's for random sampling of something.
This seems conceptually similar but without being part of a fail safe mechanism.
I think the above probably isn't right...
The 4060 counters have a built-in oscillator. My guess is that it starts them at the same time and the alarm is when they don't have the same number...when there's drift as compared across the two oscillator sources. And that the clock dial probably changes the speed of one of the oscillators, so they match well enough to stay in sync for the rough desired period.
All that to say the random distribution is probably based on the variability between any two 4060 counters.
Lesson learned: we built a 42-node several petabyte storage cluster. Worked fine as we were starting small, and got bigger, and bigger. When we “had it” and disconnected from our internal network and moved to an isolated network we discovered quickly that the timebase on all the systems drifted very quickly to be seconds and then minutes out of sync after several days. This was because they couldn’t access NTP.
Set up an ntp server and “resolved” it, except now we had an entire cluster of hardware that was (in lock step) drifting out of sync with the rest of the world. Fixed that. Moved on.
Another example: we bought a bunch of really cheap LED ropes to make our LGBT+ pride float’s backlighting for a pride parade several years ago. I wired it. The ropes were all independent and we planned to have them rotate colors. The little controller boxes had a mode that would smoothly transition through presets. It turned out that simply turning on the power would cause the lights to start in sync, and then quickly drift out of sync in a really mesmerizing way. They’d occasionally come back together but frankly it was better than anything we could’ve programmed.
We also learned we could control the rate of the “smear” by over or under volting the LEDs a bit.
Even if it’s digital, everything is eventually analog. And analog is weird.