DEV Community: 侯惠阳

A Packaging Bug I Found in Homebrew Redis 8.10.0

侯惠阳 — Mon, 17 Aug 2026 10:00:00 +0000

I recently installed Redis 8.10.0 with Homebrew for local development:

brew install redis
brew services start redis

The installation completed normally, and Homebrew reported that the service had started. Its actual state in brew services list, however, was:

redis  error  1

The problem was not that Redis itself could not run. The default configuration shipped in the bottle did not match the files included in that bottle. I reported the bug as Homebrew/homebrew-core#296698. As of August 11, 2026, the issue remains open.

The mismatch

The bottle-provided redis.conf enabled four modules:

loadmodule ./modules/redisbloom/redisbloom.so
loadmodule ./modules/redisearch/redisearch.so
loadmodule ./modules/redisjson/rejson.so
loadmodule ./modules/redistimeseries/redistimeseries.so

The installed bottle contained none of the referenced .so or .dylib files. Redis read the directives, failed to load the missing modules, and exited.

This is an easy failure to misread. “Successfully started” means the service command was submitted; it does not prove that the Redis process remained healthy.

Verifying the cause

I compared the configuration with the installed artifacts:

grep -n "loadmodule.*modules" \
  /opt/homebrew/Cellar/redis/8.10.0/.bottle/etc/redis.conf

find /opt/homebrew/Cellar/redis/8.10.0 \
  -type f \( -name "*.so" -o -name "*.dylib" \)

The first command returned four active loadmodule directives. The second found no corresponding module libraries. That configuration–artifact mismatch was the direct cause.

Temporary workaround

For local development that does not need these modules, the directives can be commented out before restarting Redis:

sed -i '' \
  -e 's|^loadmodule ./modules/|#loadmodule ./modules/|' \
  /opt/homebrew/etc/redis.conf

brew services restart redis
redis-cli ping

After the change, redis-cli ping returned:

PONG

This is a workaround, not an upstream fix. If an application depends on RedisBloom, RediSearch, RedisJSON, or RedisTimeSeries, disabling them is not an acceptable solution. In that case, use a distribution that explicitly includes the required modules or wait for the Homebrew bottle to be corrected.

The practical lesson

When a service fails to start, repeatedly reinstalling or restarting it rarely produces new information. A better sequence is:

Check the real service state and exit code.
Run the process in the foreground and read the direct error.
Compare configuration declarations with installed artifacts.
Make the smallest possible change to verify causality.
Publish a reproducible report for the upstream maintainers.

Open-source contribution does not always begin with a code patch. A focused bug report with clear evidence and reliable reproduction steps can be just as useful.

References

Building CoreX: A Native Real-Time macOS Monitor in Swift

侯惠阳 — Mon, 17 Aug 2026 07:31:41 +0000

I built CoreX to answer a practical question: why does a Mac feel slow right now, why did its fans become audible, is memory pressure affecting the workload, and can those answers remain entirely on the device?

CoreX is a native, local-first macOS system monitor. Its interface is built with Swift 6, SwiftUI, and AppKit. Its sampler uses Mach, IOKit, Metal, Foundation, and Darwin to observe aggregate and per-core CPU load, GPU activity, memory, storage, network throughput, uptime, and system thermal pressure. The main window supports diagnosis, the menu bar supports quick awareness, and settings determine how the tool fits into everyday work.

Download CoreX 1.0 (macOS 14+, Apple Silicon)

Download CoreX-1.0-macOS-arm64.zip · approximately 2 MB

SHA-256: ae116fe638e81e3b2acfa34dd531ebbe4251bfa2b3cae7074a223136a7ea321a

Product boundaries: more data is not automatically better

System monitors tend to fall into two extremes. Some display a few percentages without enough context to explain a problem. Others expose every low-level counter and force the user to find the anomaly. CoreX uses three information layers:

Overview: CPU, GPU, memory, storage, network, and thermal state for a fast health check.
Diagnosis: per-core activity, P-core/E-core grouping, live histories, and device details.
Ambient awareness: a small menu-bar surface for the metrics that matter most.

Sampling is separated from presentation. SystemMonitor produces a normalized snapshot; SwiftUI consumes state. Historical series are bounded rather than allowed to grow forever. Pausing monitoring stops sampling, not merely animation. This keeps collection, presentation, and preferences independently testable.

Mach / IOKit / Metal / Darwin / Foundation
                    │
                    ▼
             SystemMonitor sampler
       deltas, normalization, and clamping
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
    current Snapshot      bounded histories
          │                   │
          └─────────┬─────────┘
                    ▼
       SwiftUI Dashboard + MenuBarExtra
                    │
                    ▼
      AppStorage / alerts / launch policy

Reading real macOS state from Swift

CPU: utilization is a delta between samples

CPU times are cumulative counters. Treating a single read as instantaneous load is incorrect. CoreX calls Mach APIs including host_statistics and host_processor_info for user, system, nice, and idle ticks, retains the previous sample, and calculates:

usage = Δ(user + system + nice) / Δ(user + system + nice + idle)

The same rule applies to aggregate and per-core load. On Apple Silicon, cores are grouped into performance and efficiency groups for presentation. A production implementation must handle the first sample, counter anomalies, allocated processor arrays, and value clamping to avoid misleading startup spikes.

Memory: pressure matters more than a scary percentage

CoreX uses host_statistics64 to read active, inactive, wired, compressed, and free pages. macOS deliberately uses spare memory for caching, so high usage alone is not proof of a problem. The interface combines the current value with history instead of turning one percentage red without context.

GPU: Metal identifies devices; IOKit attempts load sampling

MTLCopyAllDevices() supplies GPU identity and capabilities. Live utilization is read from IOAccelerator performance statistics through IOKit. This is not a uniformly documented, stable metric across every macOS and hardware combination. If a driver does not expose the necessary field, CoreX reports the metric as unavailable instead of inventing zero.

Storage, network, and thermal state

Storage uses URLResourceValues.volumeTotalCapacity and volumeAvailableCapacityForImportantUsage, which better reflects capacity available to important work.
Network sampling aggregates active interfaces through getifaddrs, excludes loopback, and derives upload and download rates from byte deltas. Interface switches and counter resets must be handled.
Thermal pressure comes from ProcessInfo.thermalState. It is an operating-system pressure signal—not a sensor temperature—so CoreX labels it nominal, fair, serious, or critical rather than fabricating degrees Celsius.

All readings are collected and rendered locally. CoreX requires no account and does not upload monitoring data.

Why SwiftUI still needs AppKit

SwiftUI is effective for dashboard cards, state-driven presentation, themes, and settings forms. A polished Mac utility also needs precise behavior for window activation, the Dock, application reopening, and the About panel. CoreX deliberately combines both frameworks:

WindowGroup owns the primary window and its sizing constraints.
MenuBarExtra(.window) creates an interactive status surface.
NSApplicationDelegateAdaptor controls termination after the last window closes and restores a hidden window when the Dock icon is clicked.
NSApplication.setActivationPolicy switches between a regular app and a menu-bar-only utility.
SMAppService manages launch at login.

SwiftUI describes the interface; AppKit closes the lifecycle gaps. That is more robust than forcing a real macOS utility into a single-framework ideology.

Settings are behavior, not decoration

CoreX organizes preferences into Appearance, General, Monitoring, Notifications, Shortcuts, and About. Each setting is intended to connect to runtime behavior:

system, light, or dark appearance; accent, density, corner radius, glass, and motion;
launch at login, open-window or menu-bar startup, background operation, and Dock visibility;
1/2/5-second intervals, enabled categories, and 60-second/5-minute/15-minute histories;
icon-only, CPU, or CPU-and-GPU menu-bar content;
CPU, memory, storage, and thermal-pressure notifications;
shortcuts for opening the overview and pausing monitoring.

@AppStorage persists preferences, but persistence is not implementation. A Dock setting must change the activation policy. A refresh interval must alter the sampling cadence. Closing behavior must reach the application delegate. I tested each preference as an end-to-end path from UI control to operating-system behavior.

The menu bar is the high-frequency surface

The menu-bar panel deliberately limits itself to CPU, GPU, memory, current status, settings, update checks, and quit. It works well while compiling, running local models, processing video, or switching among heavy applications. The dashboard explains; the menu bar informs without interruption.

Development and packaging environment

CoreX uses Swift Package Manager, targets macOS 14, and links IOKit and Metal. The development machine should use a matched Xcode or Command Line Tools installation. Mixing a Swift compiler and macOS SDK from different toolchain releases can produce an “SDK compiled by a different version of Swift” failure. A dependable release pipeline pins Xcode and builds in a clean environment.

cd MacPulse
./scripts/build-app.sh
open dist/CoreX.app

The build script performs a release build, assembles the .app bundle, generates icons, and signs the result. The current download is an arm64, ad-hoc-signed build intended for evaluation and internal distribution. A broad public release should use a Developer ID Application certificate, Apple notarization, and a stapled notarization ticket.

Supported Macs

Item	Current download
Operating system	macOS 14 Sonoma or newer
Processor	Apple Silicon: M1, M2, M3, M4, and M5 families
Intel Macs	Not supported by the current arm64 archive; the source can be extended to a universal build
Network	Not required during operation, except for update checks
Data handling	Monitoring data remains on the device
GPU metric	Availability depends on IOKit fields exposed by the system driver

CoreX is particularly useful for developers, local-LLM users, designers, video professionals, and anyone who wants ongoing visibility into a Mac. It is not a data-center monitoring system, a remote alerting service, or a substitute for Apple Diagnostics.

Download, installation, and security

Download CoreX 1.0 and unzip it.
Move CoreX.app to Applications.
On first launch, right-click the app and choose Open. If Gatekeeper blocks it, confirm Open Anyway under System Settings → Privacy & Security.
Verify the archive if desired:

shasum -a 256 CoreX-1.0-macOS-arm64.zip
# ae116fe638e81e3b2acfa34dd531ebbe4251bfa2b3cae7074a223136a7ea321a

This test build is not Apple-notarized. That limitation must be explicit; users should not have to discover the release model from an unexplained Gatekeeper dialog.

Engineering lessons

First, system monitoring is primarily a semantics problem, not a charting problem. Cumulative counters require deltas, missing metrics must remain missing, and thermal pressure must not masquerade as temperature.

Second, native quality comes from behavioral closure. Windows, Dock policy, the menu bar, login launch, and preferences become features only when they are wired into the application lifecycle.

Third, distribution is part of the product. Pinned toolchains, architecture labels, signing, notarization, hashes, and installation guidance belong in the design—not as release-day cleanup.

Next steps for CoreX include more resilient GPU compatibility, stronger memory-pressure diagnosis, process-level attribution, a universal binary, and full Developer ID signing and notarization. For a local system utility, trust, accuracy, and low interruption matter more than adding another dashboard.