jeztek
Joined 18 years ago
Joined 18 years ago
Voltage Park is building a machine learning infrastructure company from the ground up. We purchased 24,000 H100 GPU's and are currently deploying them across the US. We're looking for friendly, highly motivated, execution focused folks to join our small but growing team!
Some reasons to apply:
- Fully remote with WFH stipend to kit out your home office
- 38% of the team are YC alumni
- Comprehensive benefits including 401k w/match, health, dental and vision with premiums covered by the company
Openings:
- Customer Reliability Engineer ($120k-$180k + equity)
- Site Reliability Engineer ($140k-$180k + equity)
- Backend Engineer ($150k-$200k + equity)
Apply: https://voltagepark.com/jobs
Eric here, CEO of Voltage Park. To add some context, we're announcing a new cloud consisting of approximately 24,000 NVIDIA H100s. Each cluster has H100 SXM5 GPU's fully interconnected with 3.2T Infiniband for peak performance. Pricing is as low as $1.89 / GPU / hour.
We think the current market for ML compute is broken, with access only available to the well-resourced. We're on a mission to make machine learning infrastructure accessible to all and will be opening up support for short term leases and hourly billing early next year.
We'd love to hear your thoughts around the ML compute shortage, what needs aren't currently being met, and what we can do to ensure that the AI ecosystem is healthy and accessible to a broad audience of users.
I juggled a day job and side-startup while my child was a toddler. My wife and parents picked the slack on the nights where I had to push towards a hard deadline and I leaned heavily on my team so that I could be present for family time. The company was profitable and we successfully sold it to a private party.
For my current startup, I was very up front with my co-founder about making sure I was around to do school drop-offs and pick-ups. We're fully remote so there's no commute and we predominantly work asynchronously to avoid meetings. I mostly work during school hours and pick up again in the evening after the bedtime routine.
It's not for everybody and doesn't leave a lot of "me" time, but I'm personally finding a lot of fulfillment in trying to build a family-friendly remote-first company.
Most of the tips do reference research findings, and you can find the reference by clicking on the subscript numbers or scroll down to the references section.
Some tips are more common sense and/or geared towards addressing a research finding. In the "arm's length" tip for example, the referenced paper discusses the importance of eye contact in computer mediated communications but doesn't explicitly say you should keep an arm's length to achieve the best eye contact. Was your expectation that the tip should link to research determining the optimal distance from the camera to achieve good eye contact?
We were aiming for something whimsical and easy to read so the tips primarily focus around illustrations that were inspired by IKEA instructions. For people who are interested in delving into the details we put the meat of the advice behind a "Why?" button.
This was also our first foray into writing a responsive site that renders well on mobile and desktop, built using Next.js and Tailwinds CSS.
What are some of your favorite video call hacks or tips?
http://www.macobserver.com/tmo/article/apples-imessage-encry...
User authentication, so someone is not able to impersonate you, is on the todo list but it is assumed that the server is trusted and won't go swapping public keys on you. A chat system that doesn't trust the server would need an entirely different design. You need to trust the server to perform basic actions like broadcast your message to the other users in the room.
deadchat implements the latter option. The secret room key is shared using the RSA key exchange protocol but you're right, there's currently no way to guarantee that you're talking to who you think you are. User authentication is on the todo list.
I think there's still value in hiding the conversation from the server even if you must still trust the server to not behave maliciously. If some three-letter agency contacts the server operator asking for a back channel to listen in, he or she could respond that it's not possible without malicious intent towards a user:
http://www.macobserver.com/tmo/article/apples-imessage-encry...
* No, I am not a cryptography expert. I've had a nascent interest in the field for awhile and this was my way of getting my feet wet while scratching an itch. I thought I'd post it on HN to get feedback and see where I might have screwed up.
* I'm here to learn. *
We all have to somehow right? A disclaimer is a good idea, I'll add it to the README.
* The project was originally motivated because I couldn't find a group chat service that provided an IRC-like experience with end-to-end encryption. The closest I could find was FiSH-irssi, an irc client plugin:
https://github.com/falsovsky/FiSH-irssi
I wanted to try implementing something that was easer to use. I ruled out IRC over SSL because the conversation is cleartext at the server.
* I should have mentioned this in the README and will update it -- The design goal for this system is to enable a group of trusted friends to communicate with each other over an insecure channel without fear of eavesdropping. It is assumed that a member of the trusted group operates the server. Forward secrecy was an additional goal facilitated by changing the room key. It sounds like my implementation did not achieve the design goal. What can I do to make it right?
* My intention was for the secret room key to be securely shared following the RSA key exchange protocol (encrypt secret with requestor's public key and sign with sender's private key, decrypt with requestor's private key and verify with sender's public key). The problem then lies in how to properly exchange users' public keys. If I trust the server but don't want the server operator to read my conversations, is it not okay to facilitate public key exchange through the server?