alifeinbinary

I agree that turning CS into a casino wasn’t a tasteful choice on Valve’s part but as someone who has played CS at least once a week for decades I can understand that they needed to find a way to cover server costs somehow. I paid $15 dollars for CS:GO and have clocked 4,500 hours in the game. I don’t gamble but I’d rather those who choose to fund the server costs than Valve charge a monthly subscription to everyone. Skin sales alone would have accomplished this without having to have loot boxes and keys and that’s where I think Valve went overboard with it. Also, for a game that provides so much revenue I expect better anti-cheat and more VAC bans, which are rare.

I'm developing software in this area right now, so I try a lot of the new models. They're not even close for coding tasks. It basically comes down to 26b parameters vs 1T parameters / quantisation / smaller context sizs, there's no comparison. However, for agentic work, tool calling, text summarisation, local LLMs can be quite capable. Workloads that run as background tasks where you're not concerned about TTFB, cold starts, tok/s etc., this is where local AI is useful.

If you have an M processor then I would recommend that you ditch Ollama because it performs slowly. We get double or triple tok/s using omlx or vmlx, respectively, but vmlx doesn't have extensive support for some models like gpt-oss.

I built a steganography app that embeds encrypted messages into images.

It lives here: https://stegg.alifeinbinary.com

It's as much of an art project as it is a programming project. The images that it generates are visual representations of binary code translated from the text you enter. If you enable encryption it converts it to a hash. You can download the image, send to someone along with the password and they'll be able to decrypt it by uploading it to the app. Or you can post it to the time line and send them the link. All messages are truly private. No raw text text is sent to the server.

It's not vibe coded, I made it with typescript React. The app has a link to the github repo if you want to look under the hood.

I really like LM Studio when I can use it under Windows but for people like me with Intel Macs + AMD gpu ollama is the only option because it can leverage the gpu using MoltenVK aka Vulkan, unofficially. We're still testing it, hoping to get the Vulkan support in the main branch soon. It works perfectly for single GPUs but some edge cases when using multiple GPUs are unsupported until upstream support from MoltenVK comes through. But yeah, I agree, it wasn't cool to repackage Georgi's work like that.

Agreed. I block Reddit, Instagram, Facebook, Twitter on my phone and work computers to avoid impulsive doom scrolling with the time vampires. I never would have seen this announcement. Reddit should not be viewed as a channel for corporate communications.

I appreciate your response and I hope you can understand my initial concern. Looking forward to trying this out :)

All those parameters and it still won't answer questions about Tianenman Square in 1989... :(

i’m in the same boat. I bought mine back in 2021 and honestly I don’t regret my decision. It’s my main software development of music production computer plus every Sunday night I get to play counterstrike with the boys by dual booting into Windows. I’m able to service repair and upgrade it myself and one day when I’m ready to move on I’ll use it as my home server. The crazy thing is that my next upgrade will be going back to a MacBook Pro most likely because the thunderbolt connectivity will be able to handle the Blackmagic 4 camera broadcast capture card and NVME PCIe storage card that are in my Mac Pro right now through some external enclosure.

The only real drawback that I’ve experienced with the Mac Pro has been the lack of support for large language models on the AMD GPU due to Apple's lacklustre metal drivers but I’ve been working with a couple of other developers to port a MoltenVK translation layer to Ollama that enables LLM’s on the GPU. We’re trying to get it on the main branch since testing has gone well.

One thing a lot of commenters in this thread are overlooking is that this is the death nell for repairable and upgradable computing for Mac, which is super disappointing.

Hi, I read throughout your blog post and website but couldn't find a github link, so I gather this project is closed source. Is that likely to change in the future? For something as important as a terminal, considering all the secrets it comes into contact with, I would wish to audit it before blindly installing on my system. Furthermore, your website nor elsewhere within your online presence contains any identifiable information about you the creator, what country you are located in, a LinkedIn etc. There's no name attached and no face to the name. How can we trust this?

How do we know this isn't honeypot software produced by an adversarial state actor trying to conduct industrial espionage or siphon secret keys, databases and file systems? You're expecting a lot of trust from potential users but making no effort to impart it beyond your blog post that outlines how you made it, which looks suspicious if I'm being honest.

Why have you chosen to protect your anonymity and keep the project closed source?

They just need to create a GUI interface with Visual Basic and see if they can track the IP address.

I use my Mac for film scoring and music production, so I have a long-standing practice of keeping my operating system one major version behind for stability reasons. If you want to do the same and at the same time avoid those annoying Tahoe update notifications then simply enable beta updates for OS 15 in settings. I don’t imagine I’ll ever update to Tahoe because I dislike the UI so much but honestly OS 15 is rock solid and it looks great, I’d be very happy sticking with it until EOL for this machine.

While the M5 is impressive, its capacity to compete against enterprise models like Opus, Sonnet etc is off by a couple orders of magnitude. Even the most sophisticated open source models top out at 100-200 billion parameters whereas Claude, OpenAI are north of a trillion parameters.

While SOC is definitely the future or local AI, even if you get an M5 that's jacked to the tits, you still won't be able to store the entire model in unified memory on top of the OS and whatever other applications you have running. 128GB is the upper limit for unified memory on the M5, which on paper could support a model like gpt-oss:120b but still with a nerfed context size and quantised at that. Furthermore, the cost of a maxed out Macbook Pro M5 Max is between $8-10k depending on your storage option, screen size etc., so we can safely assume that the M5 Ultra will be even more. There's also no guarantee that the Ultra will offer double the amount of unified memory, it may only offer more cores but cores aren't the current bottleneck for local AI, memory is.

If you consider what you'd be paying above and beyond your requirements barring local AI, it would be adding $5-6k to the price tag at a minimum. That equates to 5 years worth of a Claude Code subscription! Even if you shouldered that cost with your NFT fortunes you likely wouldn't achieve performance parity with CC.

I'm equally as excited as you are about the future for local AI and I am actively working in this space everyday to improve it but we're still a long way off from being able to match model size, context size, token/sec, TTFB etc. A single H100 is so OP, so hosting thousands in a data centre it's expected that it should remain unrivalled.

The area where I'm having success with local AI is by pairing local models with other supportive technologies like databases and the like to compensate for smaller context size. There are still many in roads to be made in this area and that bodes well for the future of local AI as models become more efficient and sophisticated.

I love working in MacOS but I refuse to buy another new Macbook that has the storage soldered to the motherboard. Non-volatile memory has a limited amount of write cycles and let's be honest, NAND can fail long before its forecasted lifespan is up, which would render a $5k+ computer inoperable. I understand the benefits that come with SOC architecture but I draw the line at storage. This design choice wasn't about "saving space" it was about exploiting the Mac-tax.