Source?
edit: damn, seems legit https://en.wikipedia.org/wiki/Milk
431 karma · joined June 4, 2012
edit: damn, seems legit https://en.wikipedia.org/wiki/Milk
Turns out running chips hard 24/7 causes them to burn out
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
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.
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
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
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.
Do you really think that's what they meant?
I.T. was just less well funded in general back then, I think, and hardware was relatively more expensive.
There was also just much less understanding of "hey, developers need somewhat beefy setups"
I remember at my first professional job, I had a 100mhz or 120mhz Pentium I. The receptionist had a 133mhz Pentium I with, I think, more RAM as well. (I remember because it pissed me off...)
There were also a lot more in-house development jobs. Some small non-tech company would grow to the point that the underfunded IT guy was writing all these little scripts and VB apps. And then he'd finally fight and fight and the company would hire a second person as programmer, so the IT guy could focus on fixing people's printers and reinstalling Windows, and management would not understand why they'd need to spend an extra $2000 buying a nice desktop and monitor for the $40K/year programmer they just begrudgingly hired for their company where the average salary was $27K/year.
Shit, even in the late 2010s, in a lot of places would still look at you like your hair was on fire if you asked for a second monitor... there was a stretch there where I'd just bring one of my own... also I remember I had a job where I had a second company-provided monitor and they took it away because they were hiring more engineers and it wasn't "fair" for me to have 2 because they didn't have the budget to give everybody 2 lmao
VB/VBScript is almost like writing shell scripts, in one sense. You can write really maintainable, even elegant stuff. It's just that nobody else is, and the language is almost pathologically constructed to discourage it.
(Although, at least shell scripting was never really intended for big apps, so, it has an excuse)
(Especially the way it looked ~12 months ago -- it's gotten more cluttered since then. Perhaps unavoidably, as the breadth of their offerings has grown)
But over time it's begun to feel like unsettling cognitive dissonance as their ambitions grow and the stuff to worry about has piled up.
Also, trust me, the VB6 interface hits a lot different (which is to say: worse) on a cramped 800x600 or 1024x1768 monitor than whatever spacious thing you're probably viewing it on. =)
Makes it that much more absurd that tooling on modern
platforms isn't anywhere near this level of discoverability
and developer-friendliness.
1. The VB6 UI element palettes work well because there's essentially a 1:1 correlation between the icon and the thing it produces when you drop it onto the canvas. That works well for visual elements but less well for things that don't have visual analogs.
2. Toolbars/palettes don't scale well past a few dozen items, whereas a VSCode-style command palette or text command autocomplete can scale nearly infinitely.
3. The way HTML works is a totally different paradigm than VB6's fixed grids. Obviously (as this demo shows) you can do that in HTML, as long as you're willing to ship stuff that kind of works like a VB6 app.
It doesn't really matter what the AI companies
want, if they misjudge the market somebody will
just start a competitor and take it.
Even if you made the US the freest market ever, you have the small problem of your free-market hero startups needing to compete with state-sponsored models from China.
(Also, free markets depend on savvy consumers to function properly. We assume that consumers will not choose lemonade that poisons them, for instance. This works well for lemonade stands -- one assumes consumers will steer clear of the lemonade stand ringed by corpses -- but works less well when the product is more complex and people don't understand it. You know, like AI.)
From the bottom of my heart, I hope that's the future.
I'm not convinced that will be the case. The AI companies don't want you to have local control. They want you to subscribe to a service that they can change at any time.
I grit my teeth when I type this, but (god help us) I think Apple is maybe the best (least bad?) hope here. They are the only big player with the hardware chops and without a current vested interest in getting you addicted to monthly AI subscriptions. I'm not saying this is highly likely... I'm just saying that out of the current major players, they're the ones with the ability and motivation to move in this direction in the near future.
The next best hope is probably just nVidia or AMD catering to the consumer market once again, after the AI bubble bursts or the datacenter market reaches saturation.
The outside hope is that some startup makes a business out of burning open weight LLMs to silicon like ChatJimmy... although ChatJimmy was bought up by AMD AFAIK.
That's certainly common!
I think ASICS' running shoes were a fun example of where this was probably not the case.
- I certainly didn't notice a difference in that time, though I'm admittedly not much of an actual runner
- Serious runners might notice small technical differences, but the negative user reviews didn't seem to indicate those were the people making the complaints
- The overall user reviews remained positive
- The competition in the shoe market is incredibly fierce; I'm not sure a brand could tank their quality and survive for long
- Let's not forget the other big variable: the wearers' bodies, particularly their feet. Now, those definitely do change over time -- most often for the worse, sadly!
- I doubt anybody was blind A/Bing a pair of Nimbus 20 against a pair of Nimbus 21 or 22 or 23 or 24. At best, a longtime Nimbus buyer is probably comparing a brand new pair of e.g. Nimbus 24 against their degraded but broken-in Nimbus 23 and their memory of how the Nimbus 23 felt when new. (And their body is a year or two older at that point..)
- Because it's such a long-running line of shoes, there could certainly be year-to-year variations... but it's hard to imagine there was an actual 5 or 10 or 25 year downward slope. I mean, otherwise at that point the shoes would just be instantly injuring you or falling apart in a week
- Also because it's such a long-running product line and (aside from bleeding-edge professional marathon/track shoes) sneaker manufacturing in general kind of seems like a solved problem... it seems like all of the possible cost optimizations have already been optimized. I don't really think there's much of a manufacturing or bill-of-materials cost difference between $20 running shoes and $200 running shoes anyway -- I'd be pretty surprised if "quality shrinkflation" was really much of a viable way for ASICS to save a few pennies.
I don't really see a lot of public chargers here in the NE USA, but it's also highly likely I'm simply not looking for them either.
Taking an hour out of my day a few times per week to charge an EV someplace public also sounds like a huge PITA. However, I agree that it's worth it for environmental reasons. I would probably also learn to like it. It's like going to the laundromat. Nobody likes it... but it's also an excuse to chill out and read a book for an hour or two! (or whatever)
I was like, wow, I guess the shoes must be literal torture devices full of MRSA-covered broken glass at this point. They've been getting continuously worse for 24 consecutive years!
Of course, what was really happening is that they were not getting worse, but naturally every year there was some small percentage of vocal dissatisfied users, while the silent majority simply enjoyed their shoes and didn't have much to say about them.
(The sorta-opposite happens in sneaker reviews as well. People will gush about how cushy the sole in some particular new sneaker is. Well, yeah, of course it's cushy -- you're comparing a new sneaker to your old sneaker where the foam had lost its bounce...)
Whoa, you're leaving out some pretty big demographics.
There are also a lot of people (the majority of people?) for whom EV charging is inconvenient or impossible -- apartment dwellers and people without driveways.
(Yes, yes, some apartments offer EV charging and some people without driveways can just run a charger out to the street)
From a non-economic standpoint: Aside from ensuring we don't destroy this planet, what is more important than finding out if we're alone in the universe? Not much, if you ask me.
(I realize finding algae on Saturn's moon doesn't definitively answer that question but it's certainly a uh... pretty big data point)
For smaller projects or short-lived projects, "AI without talented engineer" is a viable choice already.
But a lot of projects are big and long lived.
The difference in complexity between 1K lines of code and 10K lines of code isn't merely 10x. It's usually more like 100x.
So even if AI becomes 10x better than today (which seems reasonable) there's going to be a level of complexity beyond which you still need some kind of talented engineer-type(s) steering the AI.
- LLMs struggle, or at least burn oodles of tokens, on big complex codebases. Managing tech debt helps the agents as well IMO. - If you ask an LLM to review a non-trivial pull request, it nearly always seems to find at least 10 issues. Many of which are not worth pursuing. Often, they would introduce a lot of extra complexity to harden the code against scenarios we don't care about or can never happen. So there's a lot of room for human judgement there. Typical scenario - the LLM reviewer finds 10 issues and I judge that 2-3 are worth pursuing - As you said, often the architectural approach sucks even with frontier LLMs. Usually from a lack of problem space / usage scenarios more than a lack of technical chops - LLMs tend to err on the side of overengineering the shit out of everything
I do not see how LLMs will be able to manage huge, hairy polygot codebases without humans-in-the-loop in the near future.
Given the pace of progress, I'd be a fool to bet against LLMs in the medium term future. But I think it's far from a given. LLMs themselves, and large codebases, are essentially many-to-many problems approaching something like O(n^n).