u/Ethan045627

I've been wondering about something before I start using my MacBook heavily for local LLM inference.

If I regularly run large LLMs locally for several hours at a time, potentially putting sustained load on the CPU/GPU and using most of the unified memory, does this meaningfully reduce the lifespan of the MacBook?

Can heavy use of unified RAM cause it to wear out faster?
Is SSD wear from model loading and especially swap a significant concern?

For people who have been running local LLMs heavily on Apple Silicon for 1 to 3+ years, have you actually noticed any hardware degradation?

Let's say I have a python project A and python project B. Last month i worked on project A and now i don't need it and i just work with project B. But lsp-describe-session shows both of them, so does it mean when lsp-mode is indexing files present in project A even when I am just using project B?

https://reddit.com/link/1sy965x/video/i4jrkj0s3zxg1/player

Hi everyone,

I've been using uv for a while and got tired of dropping to the terminal every time I wanted to add a dependency or sync my environment. So I wrote a small Emacs package that wraps uv with a transient UI.

Video shows: initialising a project, creating a venv, adding some deps, and the output buffer at the end.

The most interesting part is how it's structured. Instead of hardcoding a transient definition per subcommand (which is the obvious approach and also how I started), the whole thing is driven by a single data structure called uv-command-spec. Every subcommand like add, sync, run, build, publish, etc., is just a plist entry describing its flags, groupings, and how to read positional arguments. The transient UI is generated at runtime, and the command dispatcher reads from it.

The main reason for this dynamic architecture was to make it uv-version agnostic. When uv adds a new flag or subcommand, you extend the spec i.e. you don't dig through generated transient boilerplate scattered across the file. If something breaks in a future uv release, the scope of the fix is one data entry.

There's also an escape hatch (`x` in any subcommand transient, or M-x uv-raw) that lets you pass raw args directly, so you're never blocked by a missing flag.

Fair warning: I am not a seasoned elisp programmer. This is probably not idiomatic in places, and I built this architecture because it seemed like it would work well, not because I had deep experience doing this kind of thing in Emacs. It's genuinely experimental so there are likely bugs, and I haven't tested it exhaustively across different setups. Use it with that expectation.

Requires Emacs 30.2+ and transient 0.7.2.2+.

Source: [link]

Happy to hear if the architecture approach makes sense to people who know elisp better than I do, or if there's a more standard way to do this kind of data-driven transient generation.