Disk activity indicators, the ramping up of fan speeds, or the flashing of network activity lights used to tell me when my computer was doing something I wanted it to do. When my computer started (or stopped) doing a bunch of things unexpectedly it was an indication of compromise or of an application gone rogue.<p>These days, any number of people feel entitled to use our computers whenever they like for whatever they like. The company who makes your mouse driver might want to phone home, then silently download and install a bunch of software you never asked for. The maker of your OS sends themselves a steady stream of data about what you've been doing on your computer: which files you've had open recently, what software you have installed, etc. With countless people using our devices for their own benefit on their own schedules it's nowhere near as useful to know when your computer is doing "something" because it's <i>always</i> doing something.<p>Personally, I've always preferred the soft whir of fans and the clicks of old hard drives. For a time they were a wonderful source of white noise for sleeping and I would sometimes find myself waking up if a computer I'd tasked with something overnight suddenly fell silent because it encountered a problem. I'd get up, fix the issue, and go back to sleep comforted by the sounds of my computer working away for me once more. Today our machines can be always silent while never being still, and they can spend at least as much time working for others as they do for us. Indications of activity can still be useful to me at times, but they're never comforting the way they used to be.
Totally agree with this article, there are no immediate consequences to bad CPU bound code. I am seeing the consequences of this at my current position as a Senior Engineer at a startup where a lot of things were written naively, pushed the burden to cloud costs to keep pushing out features.<p>Something that really taught me to look for things like the "HDD Light" or Fan speed was starting my career in embedded systems. 16 bit MCUs really let you know if you are trying to much on them. They also let you know if you toggle the wrong pin by going up in flames.<p>The disconnect between your fingers and what actually runs the code is becoming greater and greater for newer developers. It will be interesting to see how computing power keeps up with bad code (it had been doing a good job so far).
100% percent agree with the article.<p>Its funny how we all differ in respect to what kind of feedback we find acceptable from our computers. I turn off all audio notifications. I MUST have a hard disk light. I need graphs running at all times. I like to hear fans spinning up when the CPU/GPU is hot. And I never want to have my computer talk to me. ethernet jacks MUST have link and activity lights.<p>This is the way.
Long-term istat menus user here too, for the same reasons. I've found and removed so much crap through the years <i>because I could notice it</i>. I've fixed so many dumb issues <i>because I could see it was doing absurd amounts of pointless, unexpected work</i>.<p>And for istat menus specifically: it's super stable and they're extremely fast to support new OSes, unlike many fancy menubar apps. Easily worth the money for me.
Unfortunately, these performance monitors can make the computer use more power, by waking up every second to update the display, and therefore preventing the computer from entering deeper idle states. It's the same reason the default on-screen clocks no longer shows seconds by default, and blinking text cursors often blink for only five seconds or so before becoming static: waking up every second to update the screen can be costly.<p>Of course, a performance monitor which updates less often can avoid that issue (for instance, atop by default updates every ten seconds), but most people who run these graphical performance monitors want second-by-second updates.
Most of laptops still have fans these days. They just spin less because the machine is much more powerful. Maybe reading 100MB/s is not as concerning as 30 years ago? My M1 macbook still gives me fan noise occasionally, like when I forget to exit an infinite loop. But I appreciate that most of the background tasks would not need my attentions anymore.<p>Back in the days I didn't enjoy the LED or the sound of disks. They disrupted my workflow and not always actionable. I mean, I don't really need to know that the machine is working hard on reading the optical discs I just inserted. I will take action if the reading slows down my foreground program.
I totally feel this. Since I got my m1 air I have to constantly monitor my laptop's cpu and ram usage, because otherwise I get no feedback at all of what is going on in my computer. I never had the concept to constantly monitor these unless something was wrong. If something was overtaxing the cpu, I would hear the fans. Now, sometimes I only notice that it has gone hot to the touch after quite a while. If I messed up with memory management or forgotten some dozens of tabs open while running memory-heave computations, the OS would start lagging. Now, mostly I can only notice if I check the swap memory used.
When personal computers became just another consumer electronics gadget, they ceased being tools optimized for their prior primary use cases.<p>It's no surprise this has resulted in removal of things like status/activity lights. The same thing happened to automobiles when they went mainstream. Now you have to get an enthusiast/sports car just to get oil pressure and voltage gauges, and even then they're likely to be nerfed to non-linearity so they're always in the same place until so far outside of normal that it's too late to prevent any negative consequences.<p>I'm looking at you, rental Turbo Passat coolant gauge that stayed perfectly still until overheating in Death Valley accompanied by an instantaneous jump from Normal to pinned in the red on the temperature gauge I was attentively monitoring. smh.<p>Another example is the original MX-5's oil pressure gauge that was so active you could use it as a proxy for engine RPM, which is <i>normal</i>. The next generation "improved" this with one that stayed stationary in the upper range once the engine had any pressure at all, compressing all "normal" pressures to that needle position, effectively turning it into an oil pressure switch+light in analog needle form.<p>I'm still waiting for a PC/Laptop manufacturer targeting specifically this market. Clicky keyboards, hardware connectivity switches, status/activity lights galore, i.e. a rebirth of the OG classic ThinkPads w/modern SoCs/displays/batteries. They'll be expensive, but so are Porsches, I can't be alone in wanting this...
Ha, back in 1995 I could HEAR in advance when my PC was going to crash. I could tell from the certain crunching / grinding sounds of the hard disk. I could hear it and think "Uh oh, here comes a crash..." And then blue screen of death.
Heh, we need an external device, maybe something like a USB LED screen that shows CPU/disk/io usage outside of the regular desktop, much like we see on some fancy CPU coolers these days. At least for me I don't tend to keep things like usage utilities on screen and pinned to the top as they'll block the other things I'm doing on even multiple monitors.<p>If someone was clever about it, you could probably even feed data back to the external display via SSH from remote boxes.
I have no nostalgia for noisy PC fans and hard disks.<p>One thing that was cool though, was way back in the C64 days. If the SID chip's volume wasn't set to zero, then background sounds would come out of the speaker that were directly related to what the computer was doing. It was neat because it kind of sounded like an ethereal pipe organ. But you could "hear" basic things like complex computations vs. a short loop. I think disk drive data transfers were recognizable, but it's been a while.
<a href="https://github.com/exelban/stats">https://github.com/exelban/stats</a> is a solid open-source alternative to istat.
You still needed something to compare to, of course.<p>When I first started using Linux (kernel 1.2.8, I believe?) it took 8 hours to compile a kernel on my 486dx/33 with 4MB of RAM.<p>The endless hours of hard disk thrashing only told me that my computer was working very hard to compile lots of lines of code.<p>It was only years (?) later when I upgraded to 16GB that I realized this should only have been taking minutes.
I remember being transfixed by Aussie50's clever hack of wiring his 12V CPU AUX power connector to an old school mechanical ammeter. Probably not a great idea today due to the intense power transients modern machines draw, but the idea of physical instrumentation on machines has always seemed like a good idea to me, if space is available. I like my gpu's coil whine, I can hear if it's running a misconfigured job. Human brains are amazing multi modal pattern matchers, it's good to let them do so.
Desktop PCs (and mini-PCs) still have the blinking HDD LED.<p>Since the first time I got a second HDD, I was always disappointed that there wasn’t a dedicated LED per HDD. NAS cases actually have that.
I’ve found stats [1] to be a great open source alternative to the iStat Menus system monitor app mentioned in the article.<p>[1] <a href="https://github.com/exelban/stats">https://github.com/exelban/stats</a>
I always wanted more feedback, so that even in the mechanical disks and lots of fans era my desktop has always shown more data with GKrellM plus some of its plugins, namely multiping to show the status of my NAS and router, and bubblefishymon for a funny but very effective and immediate way to show that system load is growing suspiciously before fans start screaming.<p><a href="http://gkrellm.srcbox.net/" rel="nofollow">http://gkrellm.srcbox.net/</a><p>As for servers, embedded systems or any other situation where a traditional monitor can't be used, cheap external LCD modules showing system stsatus can be interfaced via serial, USB or parallel ports through lcdproc.<p><a href="https://www.lcdproc.org/" rel="nofollow">https://www.lcdproc.org/</a>
One of the biggest "steps" I experienced was when SSD'd first came around. Suddenly "slow db queries" ran at light speed instead of taking 5+ seconds. It was quite physically noticeable and now it's not. You have to run EXPLAIN on everything to be sure.<p>Going back a bit further, I fondly remember my dad yelling "did you PARK the hard disk?" whenever he heard me power down the old TRS80 with "state of the art" 5 meg HD physically bigger than my first PC (which had a 40meg HD - dad was jealous). If you didn't manually issue a park command, the read/write head could flop around and cause damage if you bumped or moved the HD.
> <i>The obvious example are Macs: they haven’t had hard disk LEDs for a really long time, and since the M1, they are silent and cold too.</i><p>And if the fans on your MacBook Pro do happen to spin up when you hit ‘run’ you know you’ve made something at least O(n^3)
Maybe its because I work on embedded firmware, where detailed logging is occasionally at the expense of device function, but I find the absence of blinking LEDs really unsettling.<p>I've repeatedly removed and replaced the batteries on my thermostat's remote temperature sensor, because there's no visual feedback that its otherwise working, and my house was cold.<p>The absence of "working" lights when I <i>know</i> I'm doing a processor-intensive operation on a computer is similarly unsettling. Its not directly actionable feedback, certainly, but it can be a proxy for a more directly actionable, but more onerous to implement or use, feedback mechanism.
A comment left on the post mentions in days of old you could detect viruses via drive sounds...<p>I have a 2u server sitting in a closet running a lot of things, it sits over a pool of spinning rust, one day I happened to be in the closet and hear the disks getting hammered, no alerts about any network hijinks, no login alerts or high volume traffic coming or going so I log in and it turned out to be a friend I had given a shell to because he wanted to learn linux and he was messing around with dd... His account now has an alert on login so I don't have a stroke.<p>Not exactly fun but did bring back memories.
This is exacerbated by the fact that most developers have nice, beefy machines compared to most people who will be using their products. Though we've also experienced the opposite in the case of server-side code. Improved a lot of little inefficiencies in our server-side code base through efforts to keep it possible to run on small VMs on developers' local machines. Things that we'd never notice on the monstrous 52-core 128GB of RAM infinity SSD servers, but show up quickly when you're giving it 2 cores and 4GB in a VM.
Ah, such rose-tinted glasses!<p>My first PC - much like the one pictured in the story, had a fan that was spinning 100% of the time, because most PCs then were too primitive to have a temperature sensor that controlled fan speed. And you couldn't hear the hard drive because the fan was so noisy. So much for these performance indicators!<p>The only thing audible above the loud PC was when the hard drive died, and spent all its time making nasty mechanical clicking sounds. But since the computer had locked up by that point, it wasn't much of a help!
MenuMeters on Mac solves this problem for me: you get a customizable set of little system load graphs in the menubar which can be glanced at to notice anything off.
>The computers of yesteryear had this little feature known as blinking LED lights .They also had this other feature called noisy disks and loud fans<p>You just described my reasonably current water-cooled PC (except the disks - it only uses SSDs). I have a direct die water-cooled ryzen 7950x and 2x 3090 gpus. Normally my PC is completely silent. The massive radiator surface is fine for passive cooling until about 300W. I can tell the cpu is doing more than usual, because I can hear the water pump (normally I can't hear it - yes I need to add rubber feet, then it'll be silent even when ramping up) in addition to all the hardware monitoring I do.<p>Also leds are extremely important for troubleshooting. Anyone who built an am5 PC knows the pain of "memory training". Having leds on the MB to tell you what is going on is very useful.<p>As for the typical "developer laptop" in my current place of work (and 3 previous ones - all fortune 300 companies) developers use either Windows or Linux laptops. Only managers use macs. How is this relevant? Well, because all these laptops have fans and you can tell when they're busy.
For working with remote machines that I need to ssh into I've found mobaXTerm[1] to be a very useful terminal emulator. It has an optional remote monitoring feature that shows the usual stats as a small bar under the active terminal window.<p>It's a windows only application though.<p>[1] <a href="https://mobaxterm.mobatek.net/" rel="nofollow">https://mobaxterm.mobatek.net/</a>
This article reminds me of how fucking stupid it is my laptop has no markings around the keyboard to indicate where ports are. It didn't take many instances of hearing a usb connector or microsd card scrape against the aluminum for me to break out colored paint pens and mark everything myself.
I swear I saw on LGR a CF card adapter that made noise with a little motor to simulate the sounds of hdd access.<p>Not an edit:<p>Found it!<p><a href="https://youtu.be/IZKttBr2Y8g?si=ij3eFlmtrpIsYrkf" rel="nofollow">https://youtu.be/IZKttBr2Y8g?si=ij3eFlmtrpIsYrkf</a>
My computers still have audible fan noise when they get hot. It's hard to believe others don't too, except perhaps water cooled rigs or something exotic.<p>Despite this, and in case I can't hear it for some reason, I have load and temperature gauges on my monitors at all times.<p>But hard disk noise, I completely forgot that was a thing until fairly recently something caused me to remember it. I don't miss the noise, but it was definitely a good canary or just a sign something was going on. I wonder what gauge I can add to my Linux system as a replacement for disk noise?
Since the theme is noisy feedback, I have to mention this old project: "Peep (The Network Auralizer): Monitoring your network with sound" (<a href="https://web.archive.org/web/20220930162655/peep.sourceforge.net/intro.html" rel="nofollow">https://web.archive.org/web/20220930162655/peep.sourceforge....</a>), discussed here some time ago (<a href="https://news.ycombinator.com/item?id=33017337">https://news.ycombinator.com/item?id=33017337</a>).
When I used to use macOS on Intel laptops I would be hit, every so often, by gpg’s smartcard pinentry getting stuck in a 100% loop. The only thing that ever notified me of it was the fan turning on!
The 3 best words an engineer cam ever utter: "hmm, that's interesting..."<p>Not good for the project schedule, but great for better understanding the system you are working on.
I like multiload-ng for this: <a href="https://udda.github.io/multiload-ng/" rel="nofollow">https://udda.github.io/multiload-ng/</a>
Essentially, a blog about metrics visualization. The hdd led is one artifact of a point in time of Moore's law, but long gone.<p>The embarrassment of riches of gigahertz quad core cpus available for 20 bucks or less... So much excess labor that can sneak by.<p>With some approximation of AI, those scifi stories of the distributed rogue AI living on ample excess cycles gets slightly more plausible every day
If you are using Windows and don't know where to start then you can try Rainmeter.<p>LiteStep folks liked it. Personally I never bothered with it, because, well I <i>could</i> hear it, lol, but I do miss LiteStep dearly.<p><a href="https://docs.rainmeter.net/manual/getting-started/" rel="nofollow">https://docs.rainmeter.net/manual/getting-started/</a>
I'm surprised that it's not standard to show some basic performance metrics when using an IDE's debug tooling. It's already aware of the processes that it's spawning so it should be able to keep an eye on them. Just enough information for you to go hmmm and open a profiler.
if you're using linux I highly recommend conky_seamod:<p><a href="https://i.imgur.com/oMPG7IO.png" rel="nofollow">https://i.imgur.com/oMPG7IO.png</a><p><a href="https://github.com/maxiwell/conky-seamod">https://github.com/maxiwell/conky-seamod</a>
There are plenty of ease to use libraries and tools to instrument and profile your code today.<p>If people don't use them, if they don't care about the performance, it is on them, not in the lack of noisy spinning disks and machines behaving as if they were hair driers.
My keyboard has RGB LEDs that are under-utilized. It would be a fun project to write a service that sends resource usage stats to the keyboard and some custom firmware to “render” it on the keyboard
> these monitors only help if you develop on your local machine—a workflow that’s becoming exceedingly rare.<p>Is it? Do I belong to the minority of developers that write code on their local machine?
Can't get with the recommendation to run perf monitors. These displays irritate me with their constant movement. When I want to know what's up, I run dstat, htop, and friends. Most of the time, my screens are calm.<p>Performance requirements should be covered by tests. Relying on the dev to notice is a form of manual testing. Nice if regressions are discovered that way, but don't rely on it.<p>On the flip side, I once had a mainboard where psu noise leaked onto the audio path. The little chirps were only audible when it was quiet and gave me nonintrusive feedback on the activity level of the hardware. I still miss that board.
They have LED cpu cooler displays now that you can stick anything you want on it including disk/mem/heat/whatever. They are really amazing.
It must be a conspiracy involving Microsoft. :)<p>For years, noisy hard drives with blinking lights served to highlight the difference between thrashy Microsoft operating systems and smoothly running, performant alternatives.
For anyone interested, I wrote an Mac app to provide a disk activity indicator in the menu bar - <a href="https://ttkb.co/soft/drivelight/" rel="nofollow">https://ttkb.co/soft/drivelight/</a><p>It doubles as a way to quickly eject and access mounted volumes as well.
Can we please stop obsessively monitoring (and $deity forbid, alerting on) low level metrics such as CPU and Disk I/O? Sure, they should be recorded as they are useful for troubleshooting and looking for bottlenecks. But relying on them for most software is trying to figure out if you should get a speeding ticket by looking at the tachometer.<p>CPU usage being high doesn't really tell you anything. You may suspect that there's an issue if you are familiar with the system, and you have only one system to worry about. It's definitely not OK if you have a 'modern' architecture and a fleet of machines running a distributed system. There's a whole lot of noise and you can't tell if traffic has increased, if someone pushed inefficient code, if there's a cooling problem and CPU is throttled, if a "batch" process started, or a million of reasons.<p>And even if it is high, and it is an anomaly(anomaly detection on those metrics can be useful at times), is it causing any issues for your customers? CPU usage can't tell you that.<p>Every piece of software has some work to do. What is that work? Figure that out and monitor that. Golden signals on the relevant metrics and you'll be in a far better position. Did the error rate increase? Are we getting higher response times? In that case it doesn't matter what the CPU metric says – it could even be <i>lower</i> than usual if there's a bottleneck somewhere else – it is a problem that needs to be addressed. You can then use the other metrics to confirm, or try to isolate the problem. But they should be supporting information, not your main diagnostics tool.<p>> In a project I worked on, our development builds started writing about 80 MB of log messages per second to disk.<p>Well, there you go. If you just look at disk I/O you'll see that it is high. But if you track metrics from your logging system, you'll be able to immediately see _why_<p>Datadog (no affiliation here) has a good blog that set me on the right track: <a href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/" rel="nofollow">https://www.datadoghq.com/blog/monitoring-101-collecting-dat...</a><p>By all means monitor those metrics on your work laptop - very few people are going to bother running prometheus in their dev machine and setting up alerts for third party apps. But for the apps you are responsible for? Figure out, from day zero, what metrics you should collect for your app and monitor those instead.