denormalfloat

With the number of people who go through Google's interview process, this might actually change the industry to think more carefully about the interview process. If Google isn't making whiteboard interviews the norm, who will keep it going?

>I'd love to hear what OP suggests to replace the coding tests with.

Making it easier to fire mishires would probably cover it.

But that's also why BPF doesn't seem to have a place in this world. Anything surfaced by a BPF program should probably be surfaced by a proper kernel module or syscall. As far as I can tell, the utility of BPF tracing is solely between the time a bug comes up, and a few weeks later when a kernel upgrade exposes this info anyways.

That's not how HTTP works. HTTP is a transfer protocol, and is not so opinionated on the semantic meaning of the Data it moves. HTTP, HTTP/2, and HTTP/3 were designed to be backwards compatible. It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. There are a lot of proxies.

I want to like BPF, but so few of my problems are in the kernel. Performance problems are usually at the application layer, either in my code or my dependencies. Even in the rare case that it something outside of my control (like the compiler, or the nature of the data), it's almost never the kernel. Lastly, when it is the kernel's fault, there's usually a sysctl or other knob to turn to fix it. Real kernel problems, such as some missing functionality, are usually better resolved by committing changes to the kernel itself, not so much on demand filters. BPF is a solution in search of problems.

This would not work, too many websites (perhaps wrongly) depend on this string.

There are wrong reasons to sniff the UA string, and less wrong reasons. If a Browser has a bug that gets fixed in later versions, sites have to sniff the UA string to do the right thing. For example, a browser bug may cause people to see an error, and the they are using an old version of the browser. The right thing to do is to upgrade, but how to tell? When you are subject to the bugs of some other code, and which are skewed across different versions of the software, the most reasonable way to work around it is by UA sniffing.

Java does something similar, decaying its HashMap into a binary tree after enough collisions.

That's not what big O notation is about. It represents the growth rate. In a the case of a hash table, the size of the thing you are hashing is not affected by the number of items present in the hash table. Putting a trillion bit integer into a hash table of other integers is still O(1); it's a constant.

Yes, they still need unlimited kernel threads (for liveness reasons). When I asked a few years back about this, go-nuts@ suggested implemented my own rate limiting in application space.

In my case, it was for running Go on a resource constrained Raspberry-PI, where the kernel threads could easily live too long, and use up all memory. The threads were calling read(2) on a network mounted fuse fs, and would last for 30s+.

Disney is in a tough spot since they also pay dividends. Companies typically don't ever reduce their dividends, which leaves Disney unable to spend that cash on their growth.

It's poignant to watch Go slowly realize the why other languages have more powerful, more useful error types. The `error` interface is anemic to the point of uselessness. Making it unwrappable is step forward, but all that does is progress it the level of 1995 Java with their "cause" field. It still can't express suppressed errors (like those from `defer f.Close()`). There is no standard mechanism to include an optional stack trace. Worst of all, rolling your own error type and trying to use it everywhere is near impossible. Every method signature has to use `error` due to lack of covariant return types, and heaven help you if you return a nil struct pointer, which will be auto promoted to a non-nil interface. Perhaps in Go 3 they'll get it right.

I didn't come to appreciate the power of USB-C until I started using it with my laptop. It is a single cable that connects to my monitor, powers the laptop, provides USB access to the keyboard and mouse, and to the hub on the monitor. This is a big enough improvement to the desktop-style workflow, since there is only a single wire, and no docking station. It's trivial to jump between desktop mode and laptop mode. That's usability changing experience with USB-C.

That is a lot of moving parts for a toaster. It seems like even a few crumbs falling into the wrong spot would jam the falling/raising mechanism.