Begin-End

The previous post dealt with lsd hogging the CPU. While investigating that, I also took a look at the disk: the data volume of this MacBook Pro is 466 GB in total, 389 GB were already used, and only 42 GB were available, i.e. 91% full. Drilling down with du level by level, ~/Library/Caches alone took 106 GB, 102 GB of which were under CloudKit.

Deleting these caches is easy; the hard part is figuring out where they came from. Below I first describe the cleanup, and then come back to three questions: where the cache came from, how to notice it early next time, and how to avoid accumulating so much of it again.

The MacBook Pro on my desk is a 2020 model with an Intel i5-1038NG7 (4 cores, 8 threads) and 16 GB of memory, running macOS 15.7.3. Recently I noticed that the fans kept spinning loudly even though I wasn't doing anything heavy. A quick look at top showed a load average between 10 and 17, and the top of the list was occupied by system processes: lsd, syspolicyd, trustd and duetexpertd. None of them was an app I had opened myself. lsd alone stayed at around 50% for a long time.

The machine had been up for 74 days, and I didn't really want to reboot it. I also still use Setapp and had no plan to uninstall it. So everything below was done without rebooting and without uninstalling anything. After the CPU usage came down, I went back through the data I had exported, to figure out three things: how the problem came about, how to recognize it at a glance next time, and whether it can be prevented.

The iOS 14.5.1 on hand has been unable to load battery usage information correctly since it was jailbroken with unc0ver 8.0.2. Today I finally couldn't stand this issue anymore and resolved it.

After updating OS to the latest macOS Monterey 12.3, some of my Apps crashes immediately on starting up. In detail log info, the dynamic linker reported that Python 2.7 is missing, with the following error:

1
2
3
4

Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: /System/Library/Frameworks/Python.framework/Versions/2.7/Python
Referenced from: /Applications/CHIRP.app/Contents/CHIRP
Reason: tried: '/System/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such file), '/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such file)

According to Apple's release note, Python 2.7 has been removed since macOS Monterey 12.3. This is the reason of the crashes. Considering that some of the latest version of these Apps still depend on Python 2.7, we'll have to install it manually. Python 2.7.18 could be found at the official site of Python. Download and install it, and these crashes shall then be fixed.

Hive is a great bigdata tool for the capability of translating SQL querying into a series of Map-Reduce tasks. In some cases, loading data into Hive becomes an issue to be solved. A tipical situation comes as followed: a large amount of structed data was generated by some process and was saved on HDFS, and now, you are finding a way to build database upon the mentioned data, and thus it could be handled by SQL querying. The problem is that, due to the big volume of data, the high cost of moving data from the birth place to Hive data directory could be ineluctable.

In the following parts of this post, a practical solution would be presented.