Tbf they (Moonshot) claim it’s not as good as Fable overall. Fable is also held back by US government mandated guards. Anthropic could well be ahead by a lot in terms of research and maybe we just don’t have the full picture. But that puts them in an even worse spot because it would mean they’re already at the limit of what they can compete with in the market.
One thing that sometimes trips people up with 常用漢字 is that it’s not just a list of kanji, it also includes readings. For example, 人参 are both 常用 but the second character is only listed with readings サン (as in 参加) and まい-る (参る). The ジン in にんじん is not on the list.
We can all click on your name and see your other comments, I suspect that’s what they’re referring to. There is a really strong correlation between the number of downvotes you received for past comments and whether or not they contain language like “fuck off retard” or similar.
I think they hit the nail on the head, and there is no point in botting downvotes on this platform in the first place, since there is no karma.
My client tells me I’ve downvoted you before as well, though I don’t remember where.
Why not. I have a 2020 M1 MBP with 64 GB too. But you don’t need that much for the models in the article.
It’s really not surprising that it’s so fast, since you can easily get newly created repos and repos made public from a github API (the “list public events” one at /events). Makes sense that people are polling this and feeding it to TruffleHog.
I’m not sure about specializing, but there’s a lot of stuff you can learn in the AI field that was useful before the current hype bubble and will remain useful going forward. Traditional ML is huge and doesn’t move quite as fast as e.g. LLM applications.
Some of these are arguably much more important for LLMs because of limited context sizes. The more of the code in the context window follows good practice, the more likely the LLM is to align with it. Any nonsense in the context window will multiply and beat that one document with the style guide that the LLM might not even see.
If the only problem is that your code is slop and nobody can work with it without AI, then it’s probably not that bad. Text models I can run locally on my five year old Macbook are maybe a year behind in terms of coding assistance. So AI for coding is probably never going away. The worst case for someone in this scenario is just that it gets a bit slower and dumber and that they have to hire more engineers again. It’ll suck but I think it’s survivable. Someone would have to make a new Stackoverflow though if we’re going to google stuff again.
Now if you integrated multiple AI services into all your business workflows and into the products you sell, on the other hand, that might be a different story. In a way the risk is the same as with cloud providers. You get locked into a stack and then your product literally dies if the provider decides you’re not paying enough, because you have no feasible way out. Tbh I would much prefer working at a post-bubble era software company fixing the codebase to working at a random company now extracting their IT from a hyperscale cloud. But in reality, most companies that bet on AI are in this scenario. Nobody only installed Claude and called it a day.
We used to use completely separate tools for code review (in our case because the process was older than git). Some of them might be doing something similar.
I understand the sentiment, if you don’t like AI code generation you’re probably thinking you’re on the same side. But what happens if this person finds something else they hate that you don’t hate, and finds a way to sabotage that? They’ve already demonstrated a willingness to be destructive. And you’re running their code so they don’t need anything even remotely as dumb as some AI agents to exploit, they can just write destructive code normally.
I personally wouldn’t blame MCP, it’s just a protocol. My theory is the feature was vibe coded in the vulnerable tools and nobody thought about it much.
GPT Researcher is a research agent, just one of many AI tools.
I think the idea is that these tools let users configure mcp servers, and because mcp doesn’t necessarily use the network but can also just mean directly spawning a process, users can get the tool to execute arbitrary commands (possibly circumventing some kind of protection).
This is all fine if you’re doing this yourself on your computer, but it’s not if you’re hosting one of these tools for others who you didn’t expect to be able to run commands on your server, or if the tool can be made to do this by hostile input (e.g. a web page the tool is reading while doing a task).
I use Codeberg for public stuff. I also run a self hosted forgejo on coolify on a Hetzner cloud instance but realistically that’s overkill.
Swift is a modern language that offers good performance paired with a lot of safety features you’d otherwise go to Rust for (type safety, memory safety, concurrency safety,… although memory safety based on ARC is slower than Rust’s approach, and Swift makes it easier to disable safety features). Personally I like it more than Rust because the syntax is a bit cleaner and it has exceptions.
The problem is, using it on e.g. Linux is a completely different experience from using it on Apple platforms and it doesn’t really transfer over. Apple devs will use Xcode and all the Apple tooling and will get used to Apple APIs. On Linux you don’t have Xcode, you rely more on Swift Package Manager for dependencies than on Apple platforms, you suddenly have to learn what part of the libraries you’ve been using are Swift standard library and what parts are Apple only or are from the Objective C runtime that’s not used on Linux, and the ecosystem is much smaller.
A lot of things that also mean that code written for Apple doesn’t often work on Linux unchanged, not because of Swift as such, but e.g. before Swift had Regex you’d use the one from Objective C, which just works on Apple, but isn’t there on Linux.
I haven’t tried it for Android development but I imagine it’ll have similar issues.
I set up Forgejo with runners on Coolify on a Hetzner instance for myself, and it’s great. But I use Codeberg for code I want to publish.
As far as I know Tears of the Kingdom is capped at 30 fps and 900p on Switch 1 in docked mode. This update gets you this Switch 1 docked mode experience on handheld, so it should not get you 60 fps or any of the other improvements of the switch 2 upgrade pack.
Why? It’s an optional feature, if you don’t need your Octave programs to interact with Java you can disable Java support at build time. Loses some of the MATLAB compatibility (since MATLAB has this feature too) but you’re not required to use it.
I basically do option 2, but I’d never mount all my configuration. If I want an isolated environment, I’m not making all my ssh keys available to it. So some things have to stay outside for me.
Emacs :)
Ok joking aside there were these things: https://en.wikipedia.org/wiki/Lisp_machine
There also are modern examples but they tend to be for specific niches like Mirage.
They use their own Ascend NPUs. They’re weaker individually than Nvidia’s chips, so they emphasize connecting many more of them together to compensate. It’s not about replacing individual pieces; the product is basically the complete system (think rack-scale AI supercomputer). It’s an alternative to Nvidia’s system level products like NVL144, not necessarily in terms of performance but also because it’s produced 100% domestically in China.