Stats – macOS system monitor in your menu bar • Hacker News Board

Re: Stats – macOS system monitor in your menu bar

#151

Post by cwizou » Fri, Jan 31, 2025, 3:00 PM UTC

grishka wrote: post #138

throwaway314155 wrote: post #130

Earlier quoted context omitted.

40 GB is not simple sloppiness when it comes to a simple screensaver. I would encourage you to explore other solutions than to just blame it on some historical precedent you've experienced. However true it may be. It's just not likely given the criteria.

Apparently it is slopiness in the form of an undocumented API contract breakage. https://github.com/lpar/RedPill/issues/8 (the screensaver I use) https://www.jwz.org/blog/2023/10/xscreensaver-6-08-out-now/ (linked from there) Maybe I should submit a PR with this workaround.

Yes I can confirm it's exactly that.

Basically Apple made a new "safe" API for screensavers (via .appex) but is only using it internally. 3rd party screensavers must still use the old unsafe API (that uses plugins, so unsafe code).

To bridge that gap, Apple made legacyScreenSaver, an .appex that loads the plugin code. It's a great concept in practice, but the implementation has been a mess since macOS 10.15 (Catalina...), breaking many things (multi monitor support was a big one, broken in many different ways over the years). Some Apple built in screensavers haven't been ported to the new API, so you may still have issues with legacyScreenSaver without that.

With macOS 14, Apple broke it again and indeed, legacyScreenSaver no longer tells the third party screensaver to quit! My rough guess is that this is linked to the way they implemented the transition with the new built in aerial videos they added that "slows" down on your desktop (on practice, it's not the screensaver that becomes the desktop, but 2 separate process/video players that gets synced up!).

Anyway, it's been a mess for third party developers for a while (I make one called Aerial). Our best workaround is to listen for a macOS event that tells us the screensaver will exit, and time our way to forcing an exit (literally, we call exit() which we shouldn't do, but that's the only workaround that works-ish). It works maybe 99% of the time. But sometimes legacyScreenSaver still craps out on its own.

Killing it manually will fix things (you will get a black screen + some CPU usage until you do, that can get bad depending on the screensaver) too.

I (and others) reported that bug multiple times but it's been 1 year+ and nothing. It's a mess.

Re: Stats – macOS system monitor in your menu bar

#152

Post by bilekas » Fri, Jan 31, 2025, 3:28 PM UTC

Oooh this is nice actually, I am curious though, are there any plans to integrate this into the Touch Bar ? I would offer to do it myself or at least have a crack at it but I haven't ever developed for the TouchBar and my motivation to start isn't too high..

Re: Stats – macOS system monitor in your menu bar

#153

Post by michaelcampbell » Fri, Jan 31, 2025, 3:47 PM UTC

iforgotmysocks wrote: post #59

freehorse wrote: post #23

Earlier quoted context omitted.

Alright, bet. Wanna make your Mac menu bar less clunky? Here’s the tea. Pop these commands in your terminal to tighten it up: defaults -currentHost write -globalDomain NSStatusItemSpacing -int 8 defaults -currentHost write -globalDomain NSStatusItemSelectionPadding -int 8 Changed your mind? No cap, just undo it with these: defaults -currentHost delete -globalDomain NSStatusItemSpacing defaults -currentHost delete -gl…

This makes me cringe. No one talks like that

No one uses footnotes in a webforum other than here either, but here we are.

Re: Stats – macOS system monitor in your menu bar

#154

Post by seam_carver » Fri, Jan 31, 2025, 4:39 PM UTC

Used this to identify that my 2019 16" MBP with 5300M GPU was drawing 20W at idle from the gpu when connected to a 1440p60 monitor.

Re: Stats – macOS system monitor in your menu bar

#155

Post by resource_waste » Fri, Jan 31, 2025, 5:15 PM UTC

Its been a long time since I've seen the word MacOS.

Seems like with AI + the faux Apple claims of running (any meaningful) AI, people are just not using it.

Like there has been a near total drop-off of mention since ~May 2024.

Re: Stats – macOS system monitor in your menu bar

#156

Post by bruckie » Fri, Jan 31, 2025, 5:30 PM UTC

I miss being able to hear the click of the hard drive to know when my system was doing a lot of disk IO, which often was caused by swapping when RAM had been exceeded. I wonder if there's something that turns high utilization into an audible signal these days.

Re: Stats – macOS system monitor in your menu bar

#157

Post by kcplate » Fri, Jan 31, 2025, 6:02 PM UTC

kcplate wrote: post #118

rodgerd wrote: post #80

Earlier quoted context omitted.

No-one you know, old person.

[flagged]

Perhaps I should have said:

“Simmer down there sonny boy, we may not speak your lingo but at least our generation can recognize obvious sarcasm”

Re: Stats – macOS system monitor in your menu bar

#158

Post by tempodox » Fri, Jan 31, 2025, 6:02 PM UTC

> There is no way to obtain a CPU frequency on Apple silicon macs.

Ha! You can rip my Intel Mac from my cold, dead hands.

Re: Stats – macOS system monitor in your menu bar

#159

Post by efitz » Fri, Jan 31, 2025, 6:05 PM UTC

ChrisMarshallNY wrote: post #140

parl_match wrote: post #120

Earlier quoted context omitted.

iStat menus hit a lot harder when 8GB of RAM was a $2000 upgrade.

I remember when 4 MB of RAM was several hundred dollars. My first computer (a VIC-20) had 3KB of RAM. There was so little memory, that I had to write most of my software in 6502 Machine Language.

The first computer I programmed on was a Data General mainframe with 8k of RAM. But shortly before my first class they got CRT terminals so I didn't have to use punch cards, and it did support BASIC.

Re: Stats – macOS system monitor in your menu bar

#160

Post by efitz » Fri, Jan 31, 2025, 6:07 PM UTC

cwizou wrote: post #151

grishka wrote: post #138

Earlier quoted context omitted.

Apparently it is slopiness in the form of an undocumented API contract breakage. https://github.com/lpar/RedPill/issues/8 (the screensaver I use) https://www.jwz.org/blog/2023/10/xscreensaver-6-08-out-now/ (linked from there) Maybe I should submit a PR with this workaround.

Yes I can confirm it's exactly that. Basically Apple made a new "safe" API for screensavers (via .appex) but is only using it internally. 3rd party screensavers must still use the old unsafe API (that uses plugins, so unsafe code). To bridge that gap, Apple made legacyScreenSaver, an .appex that loads the plugin code. It's a great concept in practice, but the implementation has been a mess since macOS 10.15 (Catalina…

Why use power and memory to run a screensaver when you can put the display to sleep?