I'm finding qwen 27b is comparable to sonnet but my self hosting has about 5 more 9s than whatever Anthropic's vibe coding. I also don't have to worry about the quality of the model I'm being served from day to day.
Probably the most damning fact about LLMs is just how poorly written their parent companies' systems are.
The soundtracks for SimCity 3000, 4, and the 5th one titled just "SimCity" are written specifically to be played while doing some fiddly micromanagement tasks.
No because as far as we know 26.04 won't enable zswap or zram whereas Windows and MacOS both have memory compression technology of some sort. So Ubuntu will use significantly more memory for most tasks when facing memory pressure.
Apparently it's still in discussion but it's April now so seems unlikely.
Kind of weird how controversial it is considering DOS had QEMM386 way back in 1987.
It's really funny that after going through all those fonts it landed on Ubuntu Mono for me which is what I use anyways to code in my terminal.
I wonder if it's Stockholm syndrome or if I really do prefer it. It's a totally fine font, I've never felt the need to change it. All the default open source mono fonts seem completely adequate I suppose.
> The Chinese models are open source because they are not state of the art
I think geohot is burying the lead in this text in his post with a lot of speculation.
It's not not that these specific models will become closed it's that the hardware/hosting vendors have an incentive to train models where inference is custom tuned to their chip's dimensions and VRAM.
The Chinese models do a great job of showing what's capable on consumer/prosumer hardware because of export restrictions but anyone entering the hardware space has the same incentives to undercut the frontier labs so they can sell more hardware.
It's also not clear if being at the forefront of inference quality really matters. The open source models appear to be doing a fine enough job of keeping up even if they're a few months behind. So it seems like there's not much of a technology moat for these labs other than the capital costs of training/serving.
Because that's probably how long it took for someone to prioritize it.
Even if it's not fixed by the dupe ticket, the volume of bug reports makes it almost certain another ticket for the same issue will come up. And if it doesn't then it probably wasn't that relevant to anyone.
You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company.
Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps.
But sometimes that duplicate marking is wrong or some subtly different issue so they ask you if it still reproduces in whatever version contains the fix before closing it.
Yes I understand that. ~50000 engineers aren't conspiring to close all tickets that way. It's a stupid line of thinking.
More than likely your steps to reproduce are too laborious to receive attention relative to the value fixing the bug would provide. That's why they're asking you to verify it still happens. Seems pretty simple right?
There's also a strong chance your ticket was linked as a duplicate of some other issue that was fixed in the beta and they want you to verify that's the case but they won't expose their internal issue to you for a variety of reasons.
Back when I worked at Apple I would just try it in whatever I had installed. If it didn't reproduce I'd write "Cannot reproduce in 10.x.x" and close it. Maybe a third were like that, duplicates of some other issue that was resolved long ago.
Anyone that attached a repro file to their issue got attention because it was easy enough to test. Sometimes crash traces got attention, I'd open the code and check out what it was. If it was like a top 15 crash trace then I'd spend a lot longer on it.
If the ticket was long and involved like "make an iMovie and tween it in just such and such a way" then probably I'd fiddle around for 10-15 minutes before downgrading its priority and hope a repro file would come about.
There were a bunch of bug reports for a deprecated codec that I closed and one guy angrily replied that I couldn't just close issues I didn't want to fix!
Guess what buddy, nobody's ever going to fix it.
The oldest bug like that I ever fixed was a QuickDraw bug that was originally written when I was 8 years old but it was just an easy bounds check one liner.
But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.
That's why they were cheap before.
Also "Some stupid game", who woke up and made you king of hobbies.