shanemhansen

I think they are really pulling a "no true Scotsman".

"No true normie would be dissatisfied with this unhelpful response, really it's exactly what a true normie wants"

Just an interesting observation I had about this once when I noticed that kernel quic implementations weren't very fast.

KTLS is mostly useful if paired with sendfile (I'm ignoring io_uring because I'm not as up to date on that). Otherwise you have to context switch back to userspace constantly.

They said bind mounts would still work. I didn't think those worked with remote engines.

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

I've thought of this quote a bunch and I came up with my own addon.

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

Going to write a real banger of a paper called "latency numbers considered harmful is all you need" and watch my academic cred go through the roof.

> AV1 streaming sessions achieve VMAF scores¹ that are 4.3 points higher than AVC and 0.9 points higher than HEVC sessions. At the same time, AV1 sessions use one-third less bandwidth than both AVC and HEVC, resulting in 45% fewer buffering interruptions.

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

This actually seems like a simple example of memory request vs limit.

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.

I'd think something like Rump Kernel's is a closer analogue: https://en.wikipedia.org/wiki/Rump_kernel

You nerd sniped me a little and I'll admit I'm not 100% sure what a reduction is but I've understood it to be a measurement of work for scheduling purposes.

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.

The unreasonable effectiveness of profiling and digging deep strikes again.

Tcl was my first "general purpose" programming language (after TI-basic and Matlab).

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.

The closeness of this syntax to graphviz dot is very interesting.

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

Fundamentally it's a programming language so all the normal ways of running it apply:

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.

You are right but it's confusing because there are two different approaches. I guess you could say both approaches improve performance by eliminating context switches and system calls.

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.

I had this for a reverse proxy I developed that did some transformations. At about two critical points if there was an error there was literally nothing we could do except 500 barf.

I've wondered about PWM flicker when I started trying to figure out why so many modern car headlights seem like they are strobing to me.

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?

You don't do a HTTPS handshake by hand. That's what openssl s_client is for.

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.

To me traces (or maybe more specifically spans) are essentially a structured log with a unique ID and a reference to a parent ID.

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

I don't believe them. I believe that as we exit zero interest rates, companies have to cut back and "we are doing AI" is easier to sell the investors and even their own employees than "yeah we want to spend less on people".

I agree. Sometimes doing good work feels like a curve fitting problem where the objective function is a function not only of "value" but value to <manager, skip level, .... , CEO, business value>.

I learned this the hard way.

You're probably right. There are certain literal statements I react strongly to.

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.

> As a manager, your empathy needs to be highly conditional. Your job is to get to the truth of a matter in a respectful way, not make your team feel good.

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.

Well it absolutely muddles your mind when you're on it and it causes constipation. It can also depress your respiratory system.

Science News is a big part of my childhood. My stepdad's dad was a subscriber and every issue was handed down to us gently used. I have thousands of back issues.

I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map.

In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization.

In general I think channels are great for connecting a few large chunks of your program together. Concurrency is great but also not every function call benefits from being turned into a distributed system.

I think that it would be a great idea to develop more concurrent go data structures with generics and I suspect inertia is what's keeping the community from doing it.

My credentials such as the are: been writing go since 1.0. worked at Google and taught go classes as well as owned some of the original go services (the downloads server aka payload server).

"I don't endorse this paper. Therefore you should take it down. I won't tell you why. Trust me bro."

Whether MIT is right or wrong, the arrogance displayed is staggering. The only thing more shocking is that obviously this behavior works for them and they are used to people obeying them without question because they are MIT.

Not answering your question, but my understanding is that it's well known that this is one of those paradoxical correlations.

Granted I have no source for this other than I feel like I've read it somewhere, but you're definitely not the only one to have this idea.

For me personally tests have a positive ROI within hours.

Even if I was doing a one day hackathon I'd probably have some sort of test feedback loop.

I've dealt with P1 bugs that cost the company 100k/minute and still took the time to write a test for the fix because you really don't have time to get the fix wrong and not find out until it is deployed.

I think Tcl as it was back then especially would have been a terrible DOM manipulation choice. I love the language but the hacks frameworks like openacs used to use to imitate basic stuff like a list of database records are among the ugliest upvar/up level hacks I've seen.

But that being said it's an incredibly adaptable language and I have zero doubt it could have been adapted to make DOM manipulation ergonomic.

If I remember correctly early HTML specs actually used Tcl as an example for script tag content.

It was definitely possible that Tcl could have ended up the web sripting language.