Yes! Both of us prefer Haystack to other IDEs; for me it feels a lot less "restricting" than VSCode. Developing in Haystack also helps us find issues early.
> use by individual hobbyists, students, universities, non-profit organizations, or businesses with less than 200 employees is allowed, and all other usage is considered commercial and thus requires a business relationship with Anaconda
Wow this is so deliberately ambiguous about universities with more than 200 employees. Shameful.
TLDR - we are working to clean up this language to leave it clear that educational institutions are exempt, and that these commercial terms do not apply to third-party channels hosted at anaconda.org (which includes conda-forge).
You’ve had the existing language up for years. Your licensing regime is a dark pattern torpedoing anything Good about Anaconda. Anaconda is threatening academic researchers for back usage in something those researchers thought was free.
Show us don’t tell us. I’d love to not have to continue the rip and replace job ahead.
Edit: this linkedin response sums it up well. Not certain what guarantee you will make to research institutions’ leaders that is going to lift those blocks.
However, please tell this to your sales/legal teams: the nature of their approaches has been somewhat poisoning the well. If leadership’s first encounter with a piece of software is: "you are in legal trouble", the reaction you're going to get is: "remove and block that legally dangerous piece of software at once", rather than "oh yes we should license it". We do buy licenses for software, we view it as giving back, but how the offering is first presented matters.
(The above might not work with runpod, since their execution environment is locked down. However it works with other clouds like Lambda, Hyperstack, etc.)
Ah, yeah, I misspoke, sorry. I was aware of that feature, but everyone I've talked to said it's so annoying to use they basically never use it, so I didn't think it was worth mentioning.
The big reason it's annoying is because (I believe) Colab still only lets you connect to runtimes running on your computer - which is why at the end at the end of that article they suggest using SSH port forwarding if you want to connect to a remote cluster. I know at least one company has written a hacky wrapper that researchers can use to connect to their own cluster through Colab, but it's not ideal.
I think Moonglow's target audience is slightly different than Colab's though because of the tight VSCode/Cursor integration - many people we've talked to said they really value the code-complete, which you can't get in any web frontend!
Interesting idea. I'm not very well-versed in training models or LLMs or even Jupyter Notebooks, but the comment about port forwarding SSH caught my eye since I work on a free, open source zero-trust overlay network (OpenZiti). I tried to find some information about moonglow under the hood / how it worked but didn't succeed.
If you're interested, you might find embedding OpenZiti into Moonglow a pretty compelling alternative to port forwarding and it might open even crazier ideas once your connectivitiy is embedded into the app. You can find the cheapest compute for people and just connect them to that cheapest compute using your extension... Might be interesting? Anyway, I'd be happy to discuss some time if that sounds neat... Until then, good luck with your launch!
Cool! We actually don't do port forwarding over SSH, we do it over an ngrok-like solution that we forked/modified. I looked at a few options while we were designing this, including Tailscale and ngrok, but none of them exactly suited our needs, and the pricing would have been prohibitive for something that's a pretty core part of our product.
OpenZiti looks really cool though - I'll take a look!
At a glance, the RunPod's serverless and pod options would probably work well with OpenZiti. I didn't explore their vLLM option.
Using OpenZiti w/ Serverless probably means integrating an OpenZiti SDK with your serverless application. That way, it'll connect to the OpenZiti network every time it spawns.
The SDK option works anywhere you can deploy your application because it doesn't need any sidecar, agent, proxy, etc, so it's definitely the most flexible and I can give you some examples if you mention the language or framework you're using.
The pod option says "container based" so it'll take some investigation to find out if an OpenZiti sidecar or other tunneling proxy is an option. Would you be looking to publish something running in RunPod (the server is in RunPod), or access something elsewhere from a RunPod pod (the client is in RunPod), or both?
I poked at it a bit but there was no free trial period. I know a bunch of people are using OpenZiti and zrok for Jupyter notebooks in general... Here's a blog I saw not long back that might help but I wasn't able to prove/test/try it... (sorry)
> I think Moonglow's target audience is slightly different than Colab's though because of the tight VSCode/Cursor integration - many people we've talked to said they really value the code-complete, which you can't get in any web frontend!
At the risk of repeating the famous Dropbox comment
I like the idea and that the ease of usage is your selling point. But I don't know if that is actually a reasonable reason. People who are entrenched that much in VSCode ecosystem wouldn't find it a problem to deploy dockerized Nvidia GPU container and connect to their own compute instance via remote/tunnel plugins on VSCode which one can argue does make more sense.
Congratulations on the launch and good luck with the product.
Thanks! I think the "deploy and connect" workflow is itself not super painful, but even if you're invested in VSCode, doing that again and again every day is pretty annoying (and it certainly was for me when I used to do ML), so hopefully the ease of use is valuable for people.
We don't right now, but it's something a lot of people have asked for, so we're rolling out a file sync feature next week. (It will basically be a nice wrapper over rsync.)
The laws are more nuanced than you suggest. Here is a government website [1] that mentions dogs and says “Dogs must be under control at all times. Dogs can harass, stress, injure or kill wildlife; annoy fellow hikers and introduce disease. Some wilderness areas require dogs be leashed at all times.”
I have recently been in Mount Baker’s wilderness where dogs off leash away from trailheads are fine and also in Mount Shasta wilderness where pet dogs are not allowed even on leash. There is latitude for local tweaks to the rules in specific wilderness areas across the US. The US also has vast swaths of BLM and other lands where all kinds of fun recreation (hunting, dogs off leash, OHV’s, and all kinds of other things are allowed).
reply