iirc there was a sectionin Qwen’s paper where they talked anout how they post-trained flash or 3.8 to work just as well regardless of the harness or eval used. I think that used to be true but not sure if it is any longer
I have no clue why you are mentioning OPT. Almost no one uses it during their school years because it makes no sense to and reduces your post-grad time. That’s what CPT is for. They’re requiring programs to have mandatory internships which most dont and probably wont require it. You obviously have to be enrolled to get CPT, you just cant use it to work full-time during the school terms.
I didn’t mention anything about OPT? It effectively makes it near impossible because most programs dont require an internship. And I’m definitely familiar with the process
How is using CPT for a summer internship circumventing program pf study? To get CPT, the experience has to related to your degree, not just a random job. And you can only do it in over school breaks
The new directive requires that the course requires the internship. Most programs (especially CS/economics etc) dont. This effectively removed any pathway for international cs students interning. It’s far from a narrow restriction
Much of the code was certainly written by agents, as is most of the code now. That said, there's a big difference between "vibe coding" and "agentic coding". The latter requires careful and thoughtful design and review. I've invested heavily in different kinds of guardrails to ensure conformance. An effort like this would not be reasonably feasible without agents or would take significantly longer(act has been around for 5+ years and is still maybe about 70% or so compatible with the official protocol). We'll keep improving it. I hope we'll earn your trust eventually.
If you want something cross-platform, smolvm or microsandbox are great options(built on top of libkrun vmm)! If you are looking for linux-only, the typical choices are firecracker-based solutions.
Thanks! Yours looks good too! What would you say is the difference with Slack connect? I find slack connect to be pretty painful once you have n > 50 channels
right, that part makes sense. The part i'm a little confused on is what the utility is for actually routing across harnesses. Is the point that most harnesses have been co-trained with models thus perform the best in the native harnesses?
Agree. I'm always surprised Github still uses huge fat VMs. I imagine this is one of the things that make it much painful at scale. The tricky part with microvms are getting them to run cross-platform. We use an awesome project called smolvm that builds on libkrun and makes this alot easier. As an aside, how have forgejo actions worked for you in practice?
mind trying https://github.com/preloopdev/preloop? We follow the official runner protocol 100% so we should hopefully have more workflow-compat.we also run in cross-platform microvms, not docker containers.
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop
Thanks! On the runner/control plane side, most of what is left is adding support for the latest's runner advanced features/fixes. Things like deferred/dynamic matrices, background steps, some edge cases in the old AZDO protocol, step-count expression evaluation etc. On the overall product side, there's quite abit more missing that's planned: support for macos/windows runners, a pass-through cache, an actually nice TUI, a bunch of refactors to make it more extensible, better general observability/logs and alot more work on reliability/performance, and the scheduler.
thanks for the feedback! Was it mostly the font, structure or content or everything? I’ll make sure to use a more minimal/standard docs site. For now I have them in /docs in the repo.
Yes! You could effectively use the official runner against preloop or our (almost) drop-in rust equivalent which is a 10x smaller binary and has far lower idle rss. The control plane currently is unfortunately coupled with the data plane, but a refactor is one of my top priorities soon.
hmm, the pricing table shows it bills per-CPU hours. why did you specifically chose sprites.dev vs an alternative or making your own?Anything they do particularly better than others?
Thanks! Here's a more detailed comparison: https://github.com/preloopdev/preloop/blob/main/docs/preloop.... The TLDR is act(much like Forgejo/Gitea) try to behaviorally emulate how your workflows run in docker containers. Preloop uses the exact same protocol the official runner does and runs each job in microvms. I try to match not only te request/response bodies, but down to the job/step log/annotations/conclusions level, so you could essentially use the official runner against preloop, and it would work as it would communicating with Github. Preloop is also designed to be agent-native from the ground up so an agent can drive the entire CI in real-time and debug like we do. Forgejo has the closest compatibility among the three in practice, and if you are fully off Github, I think it's a good enough choice. Here's a more detailed description of some things we do to ensure compatibility: https://github.com/preloopdev/preloop/blob/main/docs/conform...
Thanks! I'm glad it resonates. Still pretty beta, but I'm hoping this can be a good alternative when Github goes down, which unfortunately has been a bit too often, with as minimal of a lift from the user side. And of course, making it easier for agents to fully drive ci.