booty
Joined 14 years ago
Joined 14 years ago
Turns out running chips hard 24/7 causes them to burn out
I don't have direct experience running CPUs or GPUs 24/7, but when I was looking into acquiring used GPUs I looked into this and it seemed like "burning out GPUs" was almost entirely related to the thermal paste cooking off and other heat-related issues. The tribal wisdom seemed to be that GPUs could run pretty much indefinitely if you kept their thermals under control and reapplied the thermal paste every N months.Hopefully somebody with direct experience can correct me if I'm wrong...
It's more "software & gear discussion" than "use cases", admittedly, I think because the people looking for software/gear discussion already have use cases in mind that they're trying to achieve.
- The general consensus seems to be that the frontier models are kind of (understandably) "benchmaxxed" towards coding benchmarks and have suffered in some other areas like writing, art, etc. Lot of tweaked/specialized models on huggingface
- Getting around the censorship in commercial models
- While local models don't match frontier coding agents, you can run them for multiple 24/7 with a long running goal (The fans in Macs are presumably not built to run 24/7, but this can be mitigated to a considerable extent IME by simply pointing a desktop fan at it, and you can throttle things in software. On the discrete GPU side of things, you can usually get big power savings without much performance impact by throttling the GPU clock; things are usually bottlenecked on memory)
- Even small 27B/35B models are getting darn good, definitely more than powerful enough for classification etc... you don't need 128GB to run them
- Right now, providers like OpenAI are running at huge losses. At some point, they are going to need to turn a profit, at which point they may get significantly more expensive, and "hosting your own" may make more economic sense than it does today -- and be a valuable professional skill, even.
- Even more speculative: perhaps the future for many applications is training and running your own hyper-specialized models. Right now, training your own is nowhere near cost effective on self-hosted hardware vs. renting GPUs
Note: whether any of these use cases are "worth it" is up to the individual. I'm not trying to sell anybody on the idea. I don't personally do much local LLM stuff at the moment, but it's attractive and I've been close to pulling the trigger...
Of course, there's the extremely common case of keyboard support being half-assed or missing from GUI apps. But that's not mouse affordances making things worse, that's developers just not having the time or inclination to have great keyboard support.
Whereas, touch affordances seem like they'll be a lot more disruptive.
simulation becomes real enough
There's also all the ancillary activities.Riding a real horse isn't just about the horse ride, right? It's about the trip to the horse farm. The small but real danger. If you're doing it on some sort of multi-day trip, it's about the memories you make with others, the romantic time spent with your partner at night, or if you're single maybe the hope of meeting a romantic partner. For some maybe it's even about doing things like cleaning the stables, which isn't intrinsically fun, but probably adds to the feeling of bonding with the horses.
(I've never ridden a horse. I'm surely wrong about some of those things)
There's also the "abundance issue" with simulations. Have you ever looked at your unplayed games on Steam, or a folder full of ROMs, and just had a hard time choosing or enjoying anything, because (a) there's so much there, nothing feels special and (b) even when you're enjoying one game, part of you is thinking that perhaps the next game is even better?
If things truly progress to Matrix-style simulation, I guess a lot of that is "solvable" by "just" manipulating/injecting memories. But I think that's how far a simulation would need to go in order to supplant real life experiences entirely.
Or, there's the even darker route, also explored by much scifi -- reality gets so shitty that nobody can really even aspire to an actual horse ride anyway, so simulations are all anybody has. A lot of people already live some kind of version of this anyway due to lack of funds.
Sorry for no coherent point. Just rambling!
As long as they're clear about the comparisons they're making ("X% more battery life than Y" as opposed to simply ("X% more battery life") I'm good with it.
Not that I blame Apple here, for once. Seems like they're trying to cope with the limited quantity of RAM they can procure. And with the paltry bandwidth (170GB/s) of these CPUs they're a bad choice for anything but tiny local models anyway.
What's the appeal there? Doing big-RAM-requirement stuff that just won't run on a laptop?
the iMac returned to its roots as the “family computer” or “grandma email box” kind of machine.
And receptionists! Don't forget receptionists. :)24" is a good size for casual users which is the main market. You can have two roomy-ish GUI apps (two web pages, etc) side by side.
I stopped assuming I had to work the way people
said I should. [...] I get to own everything but
the typing that way
I think this gets to the heart of my disconnect with the "I miss coding" crowd. I still get to do most of the stuff I found fun w.r.t. creating software.Typing the actual lines of code was fun, sometimes, but it was never the goal. I feel like I'm still solving the same problems.
"Graphics Processing Unit" was purely a marketing term at the time. I mean, there's no lies there. It was a unit, and it processed graphics. It doesn't claim any specific sort of processing capability. If Nintendo had invented that term in 1985 I wouldn't have seen anything wrong with them calling the NES' video chip a "GPU."
Of course today "GPU" has a pretty specific meaning. It basically inherited the meaning from the clunky outdated term "GPGPU."
https://en.wikipedia.org/wiki/General-purpose_computing_on_g...
bespoke micro-explainers
Thank you for calling this out. There are certainly a lot of legitimate gripes with LLM generated code, but also a lot of never-before-practical solutions to manage code as well.FWIW, I haven't seen the Gemini 4 explainers, but Codex and (particularly) Claude have been pretty decent at this for a while.
- Basic style/linter rules (so you don't get 200-line functions, etc) paired w/ instructing your agent how to use them goes a long way (e.g., a sane rubocop.yml in your repo, plus a note in AGENTS.md telling the agents how to run rubocop, or whatever makes sense for your language) - I have a code review skill that specifically calls out human-readability concerns such as making sure that identifier names represent their contents and intended use
The other key IME is that you need to make readability/refactoring passes outside of a particular pull request. When working on a specific branch the LLMs will be somewhat myopic, and do stuff that looks pretty good in isolation, but when you zoom out and look at the bigger picture it's kind of a mess - for example, often they'll duplicate some code that existed elsewhere.
The LLMs are also pretty good at generating Mermaid charts and tracing execution flows, which is a great way to understand code. It doesn't help them to produce more readable code but it helps me to understand code I'm unfamiliar with.
edit: damn, seems legit https://en.wikipedia.org/wiki/Milk