4 ms·

Hi Erik. I don't have the "it works on my machine" problem often, because I mostly work on my own or with very few other people, so I may not be your target aud

Hi Erik. I don't have the "it works on my machine" problem often, because I mostly work on my own or with very few other people, so I may not be your target audience. I do have the "my laptop's hardware is not enough" problem, and my current approach is simply spinning up an EC2 instance with the desired resources and ssh into it and then cloning the git repo I'm working on. Normally, I set up the instance once (I have to add the ssh keys to my github account), and (if it's an expensive instance) start/stop it so I don't leave it running over night. Not a big pain point as of how I currently work. I could see myself using Booste if it allowed me to, with a single command, spin up and sync bigger instances that would run for a short period of time (eg, for ML model training) and then intelligently stopping/terminating it. Also, if you integrate more than one cloud provider, I could switch to the cloud provider best fit for my needs (cost, spin up time, latency, cpu/gpu, etc). A couple thoughts on the current implementation (you might be already addressing): - I generally have more than one ongoing project at a time. Having everything in ~/Booste sync'ed with every box doesn't work for me (aside from the fact I'd use a different location) - I sometimes do need to work with big data files, and even if I don't want them syncing all the time, I do want a way to retrieve them easily. - I also often work with jupyter notebooks, so I'd need a way to tunnel (like I do with ssh) Hope this helps and good luck!

edunteman 6y ago
Super helpful, thanks for touching on what does and doesn't have an immediate need for you. re: ~/Booste directory, just pushed and update yesterday that allows you to move your filesync directory around to wherever you want. It's not quite perfect yet, as I haven't built a way to clean old project files out of the codebox. But your new repo will overwrite anything that'd get int the way, so functionally, you're good to go there. There's a "booste upload bulk" command, which takes a .boosteignored "bulk/" directory, for hefting code up to the codebox without bogging down filesync. Haven't get built a "booste download bulk" command, since customer pull recently has been more web-dev oriented, but I'll get on that once more ML folks play with Booste. Codeboxes have auto-spindown. Default four hours live, but could make a command to monitor processes and spindown once done. Like a flag "booste --stop-when-done python3 train.py" Nothing for Jupiter notebooks yet, and it's frankly going to be a tough technical nut to crack. Interested in exploring though. (Edit: added below) As for cloud flexibility, I'm sure more enterprise scale companies would absolutely require to host Booste on their own infrastructure. Like a bring-you-own-server model. Bring-you-own-server and multi-cloud not in the works in the near future, but perhaps mid-long term.

edunteman 6y ago

Super helpful, thanks for touching on what does and doesn't have an immediate need for you. re: ~/Booste directory, just pushed and update yesterday that allows you to move your filesync directory around to wherever you want. It's not quite perfect yet, as I haven't built a way to clean old project files out of the codebox. But your new repo will overwrite anything that'd get int the way, so functionally, you're good to go there. There's a "booste upload bulk" command, which takes a .boosteignored "bulk/" directory, for hefting code up to the codebox without bogging down filesync. Haven't get built a "booste download bulk" command, since customer pull recently has been more web-dev oriented, but I'll get on that once more ML folks play with Booste. Codeboxes have auto-spindown. Default four hours live, but could make a command to monitor processes and spindown once done. Like a flag "booste --stop-when-done python3 train.py" Nothing for Jupiter notebooks yet, and it's frankly going to be a tough technical nut to crack. Interested in exploring though. (Edit: added below) As for cloud flexibility, I'm sure more enterprise scale companies would absolutely require to host Booste on their own infrastructure. Like a bring-you-own-server model. Bring-you-own-server and multi-cloud not in the works in the near future, but perhaps mid-long term.