Readit News logoReadit News
bkeroack commented on Dop: Distributed Object Protocol   distributedobjectprotocol... · Posted by u/creamyhorror
bkeroack · 7 years ago
Flashbacks to CORBA.
bkeroack commented on Ask HN: Who is hiring? (October 2018)    · Posted by u/whoishiring
bkeroack · 7 years ago
Dollar Shave Club | Los Angeles, CA or Remote (US only) | https://www.dollarshaveclub.com

Dollar Shave Club is looking for an experienced Go (Golang) engineer interested in Kubernetes, Docker and related infrastructure and security-related projects. Get paid to contribute to OSS and help us build our global e-commerce and fulfillment platform to help men be the best they can be.

Send resume to benjamen@dollarshaveclub.com

bkeroack commented on Kaniko: Build container images in Kubernetes   cloudplatform.googleblog.... · Posted by u/dlor
bkeroack · 8 years ago
Interesting! We built and use a service called Furan: https://github.com/dollarshaveclub/furan

That said, Furan isn't suitable for untrusted Dockerfiles (or multi-tenant environments) exactly due to the security implications of access to the Docker engine socket.

The issue I see with Kaniko is drift from upstream Moby/Docker syntax. One of the strengths with Furan is that you have the guarantee that the Docker build you perform locally is exactly what happens by the service. When you can't make this guarantee you get into weird situations where "the build works for me locally" but there's some issue when doing a remote build. That's also why we've resisted putting special build magic into Furan (like injecting metadata into the build context, for example).

bkeroack commented on Beep security update   debian.org/security/2018/... · Posted by u/DyslexicAtheist
cryptonector · 8 years ago
The simplest way to write safe signal handlers is to only ever:

     - write(2) to STDERR_FILENO
     - write(2) to a "self-pipe" (i.e., a pipe where the same
       process is waiting on in its event loop), thus turning
       the async signal event into an async *I/O* event that
       can be handled without any constraints regarding
       async-signal-safety
     - _exit()
Yes, there are other async-signal-safe functions that can be called from a signal handler, but it's generally not worth it. Adhering to my more constrained approach will keep your code safe and will make it easier to always get it right.

ALSO, while we're at it, the only global or thread-local variables you can read from or write to from a signal handler must be of type volatile sig_atomic_t (or else volatile of any other integral or pointer type that you can use with atomic operations). This is very important. E.g., imagine using SIGUSR1/2 to manage verbosity levels...

bkeroack · 8 years ago
Option 2 is very similar to how signal handlers work in Go. When a signal is received, a value is written to a channel and the library user is responsible for reading values from the channel and responding appropriately.

https://golang.org/pkg/os/signal/#example_Notify

bkeroack commented on Ask HN: Who is hiring? (April 2018)    · Posted by u/whoishiring
bkeroack · 8 years ago
Dollar Shave Club | Infrastructure Engineer (Go/Golang SDE) | ONSITE, Full-time | Los Angeles, CA | https://www.dollarshaveclub.com

Want to work on Kubernetes, Docker, GRPC and related ecosystem full-time? Itching to contribute to open source on company time? Do you love distributed systems and solving difficult problems?

DSC is looking for a senior Infrastructure Engineer, experienced in Go and K8s to help us continue to build out systems supporting our international businesses.

We're generally pretty remote-friendly once onboarded, but you will need to be available to be in office when required, so full remote is not an option, unfortunately.

Send CV & GitHub username to benjamen@dollarshaveclub.com. Feel free to reach out with any questions about the role, I'm happy to discuss.

bkeroack commented on What I wish I knew when I became CTO   medium.com/sketchdeck-dev... · Posted by u/edmack
latch · 8 years ago
Tests don't cost time.

Not true 100% of the time, but it's the right "default" mindset, because it's true the majority of the time.

bkeroack · 8 years ago
Tests absolutely cost time, inversely proportionate to the raw ability of the programmer. A 95th percentile engineer can write cowboy code with zero tests that largely works. Enforcing tests could cause up to a 50% slowdown. It’s probably worth it in the long run, but for a time and cash strapped startup its a legitimate cost/benefit analysis.

Deleted Comment

Deleted Comment

bkeroack commented on Intel Responds to Security Research Findings   newsroom.intel.com/news/i... · Posted by u/runesoerensen
rbanffy · 8 years ago
Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)
bkeroack · 8 years ago
That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.

u/bkeroack

KarmaCake day1913May 1, 2014View Original