Which also seems to imply the client software will expose your laptops filesystem to wherever docker is hosting the serverside piece of Offload.

"Some people think that the magic of something wondrous is diminished when it's understood. I feel bad for those people." -- Shanemhansen

Just thought I'd extract the part I found interesting as a performance engineer.

Request the amount of memory needed to be healthy, you can potentially set the limit higher to account for "reclaimable cache".

Another way to approach it if you find that there are too many limiting metrics to accurately model things: is you let the workers grab more segments until you determine that they are overloaded. Ideally for this to work though you have some idea that the node is approaching saturation. So for example: keep adding segments as long as the nth percentile response time is under some threshold.

The advantage of this approach is you don't necessarily have to know which resource (memory, filehandles, etc) is at capacity. You don't even necessarily have to have deep knowledge of linux memory management. You just have to be able to probe the system to determine if it's healthy.

I can even go backwards with a binary split mechanism. You sort of bring up a node that owns [A-H] (8 segments in this case). If that fails bring up 2 nodes that own [A-D],[E-H], if that fails, all the way down to one segment per node.

A bit of googling indicates that actually you can use performance monitoring instur to generate an interrupt every n instructions. https://community.intel.com/t5/Software-Tuning-Performance/H...

Which is part of the solution. Presumably the remainder of the solution is then deciding what to schedule next in a way that matches erlang.

Disclaimer: this is based off some googling that makes it seem like hardware support the desired feature exists, not any actual working code.

When I started that job I didn't know the difference between Tcl and TCP. I spent a couple months studying Phillip Greenspuns books. It also made me a better engineer because unlike PHP I couldn't just Google how to do basic web server stuff so I had to learn from first principles. That's how I ended up building my first asset minification pipeline that served the "$file.gz" if it existed with content-encoding: gzip.

Nearly 20 years later and I'm basically a http specialist (well, CDN/Ingress/mesh/proxy/web performance).

Tcl is still kind of neat in a hacky way (no other language I've run across regularly uses upvars so creatively).

Shout-out to ad_proc and aolserver.

having dgsh output a graphvis file in dry-run mode would be a neat feature.

Use their library in your application to evaluate policies.

Run it from the cli.

Embed it in some service like nginx.

The language itself is pretty focused on some prolog-ish describing of what constitutes an allow/deny decision.

1. Kernel bypass combined with DMA and techniques like dedicating a CPU to packet processing improve performance.

2. What I think of as "removing userspace from the data plane" improves performance for things like sendfile and ktls.

To your point, Quic in the kernel seems to not have either advantage.

Initially I thought it might be related to the alternator.

I still don't know why I perceive these headlights as having an annoying flicker or why. I'd love it if some (informed) commenter could clear it up for me. Am I imagining it?

https://docs.openssl.org/1.0.2/man1/s_client/

Or maybe socat, I don't use it but I'm pretty sure I've seen people use it.

Very open to have someone explain why I'm wrong or why they should be handled separately.

I understand at work I have a job to do, but I choose how to do it and I choose to do it in a humane way.

I don't want to put words in your mouth but it sounds like you're warning against being a people pleaser, in which case I so agree.

Doubt. Specifically about the call for managers to have highly conditional empathy and the assertion that making your team feel good is not close to if not the top priority in the list of managerial duties.

We're working with people and whatever the official chain of command says, unhappy people generally deliver shitty work, so even if you short sightedly believe happy teams aren't your job, you'll soon understand why happy teams are a critical component to delivering for "the business".

If not, your competitors will.