Hacker Newsnew | past | comments | ask | show | jobs | submit | dmmalam's commentslogin

Could say the same about v1 of OpenRouter which Stripe is acquiring for $7B this week;) [1].

[1]: https://news.ycombinator.com/item?id=49323381


You can't vibecode your way to their market capture.


OpenRouter is valuable because it has a large catalogue of competing providers for a fungible service. This does the opposite (lock in with a specific vendor).


What's the roadmap? Any plans for swarm specific tooling, or an backend marketplace (eg aws, hetzner etc).


Yes, we're building more tooling around fleets, starting with profiles that let you manage named sets of credentials and MCP tools outside of the VM. We're also looking to support more backends and also BYOC.


Looks cool. Can I run on other clouds.


Soon!


Looks super useful, will deploy. I've found context window management the killer limiter / skill in enabling many agents flows. Difference between it being magic, and not working. Looking forward to any solutions here.


Yup, this is exactly the problem we're solving with Director :)


Any upcoming features/ ideas on tool selection. Maybe use sampling?


Congrats on the launch! Will recommend!


I assume SVE [1]/ SVE2 [2] will be implemented in future Apple Silicon processors. Possibly along with ARMv9.

[1] https://community.arm.com/developer/tools-software/hpc/b/hpc... [2] https://community.arm.com/developer/ip-products/processors/b...


SVE is interesting because it gives you forward binary compatibility. i.e. your binary, written for a 128bit wide vector unit, will benefit directly from a newer 256bit wide unit without recompilation.


Who says they don't already support SVE; is it publicly known they support it or not? Especially if the binary doesn't have to be recompiled you'd never know whether they implemented it or not right?


You can just try the instructions with an off-the-shelf assembler. They're not supported.


Unless you have to toggle an MSR, of course…


I’m kind of interested about what happens if you throw random opcodes at processors now!


You might be interested in sandsifter [0], which does precisely that!

[0]: https://github.com/xoreaxeaxeax/sandsifter


I would guess the processor would just cause an exception/interrupt and it would just call an OS level exception/interrupt handler which would probably tell the user what the exception/interrupt was that occured; in this case an unsupported instruction.


I believe most processors have undocumented opcodes. Often used for internal debugging or similar.


Your program will crash with SIGILL.






Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: