jeztek

Voltage Park (voltagepark.com) | US REMOTE | Full-Time | SRE, Backend Engineer

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

Hi HN community,

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.

It's not easy but it's definitely possible, especially if you can stack the deck in your favor -- line up childcare and appropriately configure your company's work culture.

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.

Ah, okay I'm trying to understand your recommendation. Is it because not every tip has a research finding tied to it, which seems incongruous with the title? Or is it that the research finding doesn't explicitly tie to the recommendation?

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?

Hey supermatt, thanks for the feedback, that's good to know! Is there an alternative wording you would suggest? We meant to imply that the tips were primarily derived from findings from published research.

It’s been a whole year since the pandemic started and video calls are still terrible. We've been doing a lot of research into how to make them better and wanted to share what we've learned.

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?

I've had good luck with Alpine Linux:

https://wiki.alpinelinux.org/wiki/Raspberry_Pi

More details here: http://www.paragonsdc.com/stratex/

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...

You can vet who joins the channel by denying unauthorized users the room key. Users who don't have the key cannot post messages to the room.

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.

In response to kba:

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...

That's fair, I modeled some aspects of the system after FiSH-irssi, which also doesn't have user authentication or MITM attack mitigation. That'll teach me to post to HN prematurely. Both SSL with proper endpoint authentication (and session keys) and user authentication are on the todo list.

Hey all, great discussion. Apologies for not chiming in earlier, I posted this to HN in the morning and left for 4th of July activities, certainly not expecting it to make the front page. Here're some thoughts and clarifications:

* 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?

Sometimes the hardware meets the minimum specs but other issues like buggy drivers lead us to have to blacklist a device.

We considered publishing a list of minimum requirements but we encountered phones that for whatever reason wouldn't work even though the hardware met the minimum requirements. For example, the Nexus One and HTC Evo both had low frame rates despite adequate hardware.

Yeah, we wanted to support the Nexus One, and the hardware meets the minimum requirements but we encountered weird performance issues likely related to the graphics driver.

We haven't blacklisted the Droid X. Can you let us know what kind of problems you're seeing?

We ran into performance issues on the N1 that made for a very poor experience. In testing, the N1 oddly worked fine when we replaced the stock firmware with Cyanogen. That would have really confused users though so we had to blacklist the N1.

Yep, that's correct, critical sections of the pipeline are coded in assembly. Also, Word Lens only works with Android devices that have NEON support.

Yep, we were sad about that one. The hardware is up to spec but there's something about the GPU driver that's causing the N1 to perform poorly.

Hi s_henry_paulson, check the app store for an update, we released 1.2 last night, which should include Italian.

We've been short-staffed until very recently, stay tuned for more languages!