> What makes this unique just because it’s AI instead of whatever else?
I'd say the notion that expensive acts of sabotage (that can be cheaply neutralized) are a worthwhile pastime and anything other than virtue signaling is somewhat perplexing. (Not in a good way.)
This is great. We also need a tool to expose source jars to agents so they don’t need to compress. There’s a lot of Compose overloads that Claude just guesses at. I built something internally but it needs polish and Claude really struggled with the deep Gradle integration.
I had an idea like this a year ago. Super interested how it goes if this is real. The problem right now is that it’s hard to get your hands on hardware in the first place.
Hi! Yes this is quite obvious on the outside isnt it? All it needs is execution we have helped multiple companies with cloud exits to significantly better performance. The hardware isnt difficult at all, one of our favourite bare-metal providers to use is Hetzner who has great deals on hardware.
> When using a custom kernel collection with Apple Silicon, there are some unfortunate downsides. The biggest being that streamlined OS updates are no longer available.
Tart is an amazing tool, and I have been very grateful for it. There's almost no other way I've found to stand up ephemeral CI/CD macOS VMs for self-hosted Git forge solutions. I really hope this doesn't mean that Tart will eventually die the death of unmaintained projects (e.g. Realm post-Mongo-acquisition.)
Yes but most people are not dropping down to Metal support unless they're doing custom effects or developing a game engine. Most apps could be developed outside of Xcode just fine.
Sometimes people add to the discussion by sharing esoteric knowledge because the uncommon aberrations are interesting.
That aside, there was a larger point I was making that was lost in the forest because you poking at a tree. iOS apps are more than Swift. Metal was one example, there are plenty of other tooling components that absolutely suck to use in vim, or just missing support entirely. Bundle management, plist files, custom build phases, code signing, asset previews, canvas previews, interface builder, profiling, and unit testing UI is a bunch of stuff that has nothing to do with swift, sucks in vim, and integral to application development.
Part of the issue is that they don't actually advertise what the token limit is. Just some vague, "this is 5x more than free, and 5x more than pro". They seem to be free to change the basis however they please, because most of us are more than happy to use what they give us at the discounted subscription pricing.
How much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it's not secure? I've got to admit, it's got me nervous to use Python or Node.js these days, but it's really a universal problem.
> it’s got me nervous to use Python or Node.js these days
My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.
I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.
I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.
It almost doesn't matter, because you can get pwned by a transitive dependency. If someone doesn't have the same scruples as you have, you're still at risk.
PNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one & what it does, I go look it up before approving it.
(Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)
I suppose you would have to commit your node_modules, or otherwise cache your setup so that all prerequesite modules are built and ready to install without running post-install scripts?
Kind of is doing a lot of work there. This might be THE most misleading title I heard. Jumping into this thread I expected they went from 30% to 0% not 20% so I appreciate your comment for giving me more context.
Can Dang or HN moderation team fix the title to better reflect the true state and not be misleading as it currently is?
“Did you hear? On Red Square they’re giving away cars.”
“Not quite. First, it’s not on Red Square but on Dzerzhinsky Square. Second, they’re not cars but bicycles. And third, they’re not giving them away, they’re stealing them.”
reply