3 ms·

Thanks! The big difference is that Google Colab runs in your web browser, whereas Moonglow lets you connect to compute in the VSCode/Cursor notebook interface.

• williamstein 2y ago
  > Colab only lets you connect to compute provided by Google. That is no longer true - you can use remote kernels on your own compute via colab: https://research.google.com/colaboratory/local-runtimes.html https://research.google.com/colaboratory/local-runtimes.html There is also the same feature in CoCalc, including using the official colab Docker image: https://doc.cocalc.com/compute_server.html#onprem https://doc.cocalc.com/compute_server.html#onprem Cocalc also supports 1 click use of vscode. (The above might not work with runpod, since their execution environment is locked down. However it works with other clouds like Lambda, Hyperstack, etc.)
  • bblcla 2y ago
    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!
    • elashri 2y ago
      > 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.
      • tmychow 2y ago
        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.
    • dovholuknf 2y ago
      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!
      • williamstein 2y ago
        Is it possible to use OpenZiti with Runpod? Their execution environment is very locked down, which might make ssh the only option.