That's why they were cheap before.
Also "Some stupid game", who woke up and made you king of hobbies.
9,549 karma · joined March 24, 2011
That's why they were cheap before.
Also "Some stupid game", who woke up and made you king of hobbies.
Lol no, I've yet to find a model with those properties. Sounds like a fast track to AI psychosis.
The domain I work in doesn't have enough public documentation for these models to be particularly helpful without a lot of handholding though.
Once it can search for factual information online the smaller model size becomes less noticeable
It's actually about the same speed when accounting for how much more responsive my system is to Anthropic's saas infrastructure
Probably the most damning fact about LLMs is just how poorly written their parent companies' systems are.
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.
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.
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.
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.
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.
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.
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.
There's not really any difference between swap on disk being full and swap in ram being full, either way something needs to get OOM killed.
Simplifying the configuration would probably also make it easier to enable by default in most distros. It's kind of backwards that the most common Linux distros other than ChromeOS are behind Mac and Windows in this regard.
Might require AI to generate them all but the device would still be offline
Items weren't displaying prices and it was impossible to add anything to your cart. It lasted from about 2pm to 5pm.
It's especially strange because if a computer glitch brought down a large retail competitor like Walmart I probably would have seen something even though their sales volume is lower.
If I could plug my iPad into that cable to use it as a Mac I would do that all the time and buy a more powerful iPad. It would be an iPad for idle browsing and a Mac for the times I need a real computer.
Even then, most VA/IPS/LED displays have something more like 20ms of latency in game mode due to slow LCD refresh rates. Controllers are also randomly delayed by 2.4GHz interference.
This 8bitdo Pro 2 on my desk has 18ms latency all the time. It actually kind of sucks and it's one of the faster wireless controllers.
The NES and SNES had 1-3 frames of latency depending on the game.
The endpoint in my living room also has a wifi AP so signal is pretty good for laptops and whatnot.
In NYC every channel is congested, I can see like 25 access points at any time and half are poorly configured. Any wired medium is better than the air, I could probably propagate a signal through the drywall that's more reliable than wifi here.
So having something I can just plug into the wall is pretty nice compared to running cables even if it's a fraction of gigE standards.
Right now the sun goes from right to left which is the opposite of how we read most languages.