This reminds me of a script I wrote at work. A lot of us do our compiling in VMs. This means we're left out of all of the fun of hearing fans spin up for large jobs. My script fixes that by polling top over SSH every few seconds and modulating the volume of a looping fan sound by the load average.
I think you could make a pretty good product by doing something similar (varying beep, boops and clicks) for database accesses, server reboots, etc. and making an acoustic uptime monitor. Keep it in a pinned tab and you'll notice right away when your web server's RPS goes way down or way up.
I used the same idea when setting up long-range WiFi (couple of KMs) via antenna for a mesh network.
In order to get the best latency/bandwidth, you need to point the antennas with precision at each other, and in order to know if you're pointing it right, you need to run some tool on a display at the same time, like `ping`, and see when it gets lower when you're pointing it right.
So rather than having to look with one eye towards the horizon, and one eye on a screen to see a tiny number (which I found impossible), I made a quick script that outputs a beep each time ping returns output, with the frequency being higher when the latency got lower. So now I could focus solely on the horizon while using my ears to hear if I was getting in the right direction.
Lots of fun, super useful and makes me wonder (just like you) what other tooling we could use more senses with, rather than just our eyes.
It's a good idea. Glider pilots make use of audio variometers which provides a tone to indicate your rate of climb or decent. Basically, it beeps when you go up and it beeps when you go down.
Once you start accelerating up or down, it's sometimes difficult to tell what your rate is which is the reason for the instrument. Whether you are climbing or sinking, not having to look at the instrument is really helpful. This is particularly true in turbulent/rowdy conditions where you're 100% focused in on flying the glider.
Yeah, that makes sense, professionals have a lot more tools in their toolbox, including lasers and what not. The setup we did was amateur at best, via bunch of WiFi consumer gear like what Ubiquiti has/had.
Years ago, a friend and I talked about a similar idea. We called it a log file "audiolizer" (as opposed to visualizer). The idea is was you'd tail log files through it, and it would produce sound based on the log lines. The hope was that you'd learn what things should normally sound like, and if it started to sound "weird", you could investigate.
Have a look at Peep (the Network Auralizer) [1] for an example of such a tool. I had this running about 24 years ago when traffic on the 'net was a bit more manageable but turned it off when I got fed up with the place sounding like a jungle.
In Xcode, you can edit breakpoints such that they emit sounds when they are hit (and continue automatically). Depending on the sound pattern you hear then, you can decide whether something fishy is going on.
In my previous company, as a prank, we setup a well-hidden raspberry pie to play back choking laughter in the office, whenever a coworker made a push to gitlab...
I used this back in 1994. I wrote a script that analyzed logs and beeped in some cases. It was a background noise you would get used to and then -suddenly- something was off and you knew you had to look at the logs.
This was inspired by a yet even older discussion with someone who was listening to the dot matrix printer printing his logs.
In nuclear plants the "alarm" is a constant "tick-tock" noise played through the PA which stops if there's a problem. You tune the noise out very quickly and by ghods you notice when it stops!
I think you could make a pretty good product by doing something similar (varying beep, boops and clicks) for database accesses, server reboots, etc. and making an acoustic uptime monitor. Keep it in a pinned tab and you'll notice right away when your web server's RPS goes way down or way up.