1) Deleting individual files from ~/Library/Caches based only on their mtime is not safe - especially since some files (like files extracted from archives or downloaded over HTTP) may be stored with an mtime matching the source data. At a minimum, you really need to base this on the last access time; even then, I would be hesitant to delete individual files from an application's cache while leaving others.
2) /tmp and /var/tmp are cleared on reboot. Clearing them manually is probably not worth the hassle.
3) A week is way too short as a default for DAYS_TO_KEEP. A more appropriate value might be on the order of 30 - 90 days.
4) brew doctor is purely a diagnostic tool; it doesn't perform any maintenance operations. It doesn't belong in this script.
Why is a week way too short? Surely anything in Caches should be effectively ephemeral. If you rm -rf the entire Caches/*, all that should happen is some apps might be a little slower for a bit?
It would be really great if operating systems (and applications) didn't have to be constantly cleaned up in the first place. Way too much software uses the user's filesystem as their personal dumping ground for crap. Crap that they leave around when not running and crap that they leave behind when they're uninstalled. My ~/Library directory is currently 47G(!!) and it's mostly a bunch of shit that I have no idea whether I need or not. As the user, I should be the one who decides what to put on my filesystem, not some application developer. We've completely lost control of our own filesystems.
I’ve found that with a good dotfiles[1] setup + cloud storage, it is better to just reset the whole system and re-install whatever is needed.
The ability to do that is actually quite powerful as both disaster recovery and getting new hardware - it is in my mind so much cleaner to just install everything again. The built in migration tools have always done too little or too much for my taste. Dotfiles feel just right.
Funny enough hkdobrev introduced me to this philosophy almost 15years ago which I still use to this day and try to spread wherever I am. Thank you!
Yep this is my setup. I'm a Windows/WSL2 or Linux-native person depending on machine but I basically have my system tune-up automated. The Windows+WSL2 one is a little more finicky because I haven't really desired to deep-dive on PowerShell but otherwise I can basically provision new machines really quickly for myself and it's just so much easier than maintaining a long-lived system.
I'm sure this script is wonderful, but it's not a replacement for the apparent target of the author's disparagement, created by the legit folks at MacPaw (established 2008). A good place to start is the free Unarchiver, which can extract anything you can throw at it. https://macpaw.com/the-unarchiver
Compatibility with older devices that aren't eligible for recent OS updates, I would assume?
Or, if the person is like me, they're more comfortable in Bash after years of it being the default. Hacking around in a less-familiar shell seems like a bad idea if it's optional when deleting data, regardless of what's currently the default. (I realize that zsh can execute commands with Bash syntax, that's not my point.)
Review:
- It took a while to run on my old Macbook. 30 minutes or so.
- Mac still seems to boot up slow. I don't really notice the performance improvement.
- "System Data" still takes up an insane amount of my disk space.
But hey, maybe my apps will be snappier?
If my 10 year old macbook doesn't see much improvement, I don't think a newer machine will see it either.
1) Deleting individual files from ~/Library/Caches based only on their mtime is not safe - especially since some files (like files extracted from archives or downloaded over HTTP) may be stored with an mtime matching the source data. At a minimum, you really need to base this on the last access time; even then, I would be hesitant to delete individual files from an application's cache while leaving others.
2) /tmp and /var/tmp are cleared on reboot. Clearing them manually is probably not worth the hassle.
3) A week is way too short as a default for DAYS_TO_KEEP. A more appropriate value might be on the order of 30 - 90 days.
4) brew doctor is purely a diagnostic tool; it doesn't perform any maintenance operations. It doesn't belong in this script.
Why is a week way too short? Surely anything in Caches should be effectively ephemeral. If you rm -rf the entire Caches/*, all that should happen is some apps might be a little slower for a bit?
Yep, df gonna run this rando script with such a detailed and inspiring README...
(in all seriousness folks, if you're gonna show HN, spend some time on your README, docs, etc).
The README should be better but the script is like 100 lines or so.
The main issue I'm finding is that `find` seems extremely slow at deleting things.
And half of that is parsing the options and processing the dry run...
The script is clean and straightforward.
It would be really great if operating systems (and applications) didn't have to be constantly cleaned up in the first place. Way too much software uses the user's filesystem as their personal dumping ground for crap. Crap that they leave around when not running and crap that they leave behind when they're uninstalled. My ~/Library directory is currently 47G(!!) and it's mostly a bunch of shit that I have no idea whether I need or not. As the user, I should be the one who decides what to put on my filesystem, not some application developer. We've completely lost control of our own filesystems.
I’ve found that with a good dotfiles[1] setup + cloud storage, it is better to just reset the whole system and re-install whatever is needed.
The ability to do that is actually quite powerful as both disaster recovery and getting new hardware - it is in my mind so much cleaner to just install everything again. The built in migration tools have always done too little or too much for my taste. Dotfiles feel just right.
Funny enough hkdobrev introduced me to this philosophy almost 15years ago which I still use to this day and try to spread wherever I am. Thank you!
[1] https://github.com/webpro/awesome-dotfiles
Yep this is my setup. I'm a Windows/WSL2 or Linux-native person depending on machine but I basically have my system tune-up automated. The Windows+WSL2 one is a little more finicky because I haven't really desired to deep-dive on PowerShell but otherwise I can basically provision new machines really quickly for myself and it's just so much easier than maintaining a long-lived system.
Loved AppleJack (free), back when it worked:
https://applejack.sourceforge.io
Nowadays, Onyx (also free) tends to do the trick:
https://www.titanium-software.fr/en/onyx.html
Does this script close any gaps left by Onyx's MAINTENANCE routines?
I'm sure this script is wonderful, but it's not a replacement for the apparent target of the author's disparagement, created by the legit folks at MacPaw (established 2008). A good place to start is the free Unarchiver, which can extract anything you can throw at it. https://macpaw.com/the-unarchiver
Isn't zsh the current #!/bin/sh on MacOS?
Why is this written for bash, which isn't getting recent changes?
Compatibility with older devices that aren't eligible for recent OS updates, I would assume?
Or, if the person is like me, they're more comfortable in Bash after years of it being the default. Hacking around in a less-familiar shell seems like a bad idea if it's optional when deleting data, regardless of what's currently the default. (I realize that zsh can execute commands with Bash syntax, that's not my point.)
zsh has been available in every version of macOS since 10.0 - there's never been a version where bash was installed but zsh wasn't.
i use this one https://github.com/Tencent/lemon-cleaner
Try adding a way more detailed readme.
Review: - It took a while to run on my old Macbook. 30 minutes or so. - Mac still seems to boot up slow. I don't really notice the performance improvement. - "System Data" still takes up an insane amount of my disk space.
But hey, maybe my apps will be snappier?
If my 10 year old macbook doesn't see much improvement, I don't think a newer machine will see it either.