CyberRabbi

A link between zeroth powers and the logarithm function is such a simple idea but potentially fruitful. Exponentials and logarithms often translate between additive groups and multiplicative groups. Maybe there are interesting isomorphisms where the logarithm can be generalized as a zeroth power.

Linux also depends on GCC or compilers that share its behavior w.r.t. type aliasing.

C compilers should really refuse to compile code that does blatant type punning like this. Is there a book out there that is teaching people this is okay? Everything I’ve ever learned about C/C++ has explicitly warned against type punning.

I’m not a business. I don’t send mass emails. I never have.

Thanks

> there is nothing you can do about it.

I can speak up about it. Others can too. We don’t have to live under these conditions.

I appreciate the critical thinking in this post. Something every parent should do. We should talk about these issues more openly rather than accept what is being pushed into us.

Completely unique email from a new domain that has never mass emailed anything gets put into the spam immediately. It’s a very small chance anyone has ever clicked spam on my email.

If it’s a matter of the domain being “warmed up” then I basically have no chance. This is unfair.

Yes, it says it has no data on my domain.

Yes, and other domains and other IPs.

I don’t think this is true. The only people I sent email to are my friends or people with whom I do business. This server is for personal use.

Because in the proxy setup you get to keep your TLS private key on your own physical infrastructure. The VPS is just passing opaque packets.

If you value the privacy / integrity of other data then that also is more protected.

I don’t necessarily disagree with you, just wanted to draw a distinction between a blatant failure to manage finances and an excessively aggressive growth strategy that fails to pan out.

It might be hard to believe but that is closer to the norm than not. Unicorn-bound tech startups tend to operate by spending all their cash to grow the business as fast as possible, intending to raise another round once the previous round dries up. An annual cycle is about right.

What happened here isn’t necessarily poor management of finances, instead they failed to grow the business and thus couldn’t attract more investors for a second round.

But in this setup, only a single process can use the logical device provided by the NIC. In kTLS case then multiple processes can share the logical device transparently.

> that can often be accessed directly from userspace, with a lot less kernel complexity.

Can you be more specific? Is this something that could be done with non-root privileges and without explicit coordination? Like normal TCP sockets?

> especially since the article literally addresses this issue explicitly and takes care to avoid that

Can you cite where in the article it addresses the fact that the assembly snippet is not an apples to apples comparison with the C code?

> If you have a specific criticism to make

Pointing out that the assembly is not an apples to apples comparison with the C code is a specific criticism.

Hmm I’m not sure you’re responding to what I’m saying. The C code is not an apples to apples comparison with the custom assembly when comparing the speed of an indirect call to a direct call. Do you deny that?

Unless he uses the same custom assembly except with an indirect call, it’s not a good comparison. We can’t be sure the increase in runtime is due to the indirect call.

It’s not an apples to apples comparison unfortunately. He’s using custom assembly for the direct call benchmark but C code for the indirect benchmark.

The C code contains no optimization annotations either, the compiler could be inlining the indirect benchmark and/or devirtualizing the indirect call itself.

I’ve never left desktop computers and laptops are terrible for your posture.

Are direct calls really all that much faster than indirect calls on current x86 archs? I was under the impression that it’s more or less the same on the current generation of CPUs. Those CPUs do a decent job of branch predicting indirect calls, especially in a micro benchmark loop. The BTB generally works well.

To be fair the hardware in question is not just accelerated crypto operations. From what I’ve read on this topic there are network cards that handle the end-to-end TLS protocol (sans negotiation).

In general you have a point but it’s a judgement call like many things in engineering. Even in the absence of specialized TLS hardware, TLS operations are so common, there is a strong case for pushing it in the kernel if that improves efficiency by a double digit percentage.

SSL_sendfile in particular is an efficiency boon for large static site hosts, it could result in significantly less hardware waste and/or reduced power consumption.

Generally the kernel is involved when it comes to making use of hardware. Specialized hardware emerges when widely applicable bottlenecks are identified, like rendering 3D graphics, decoding video, or in this case TLS encryption. Not everything is destined for the kernel as userspace has generally desirable properties as well.

Due to the phenomenon of Hypergamy this will likely have a negative effect on pairing and fertility.

Wouldn’t it be easier to patch their startup scripts than freezing their kernel?

What makes this a “modern” editor? When does it cease to be a modern editor?

Jason is doing great work here. These aren’t fun to solve problems.

Even if long term he can bootstrap a proper userspace ecosystem of using /dev/*random, will the unification ever be possible if we have to support these old systems?

I am generally in favor of maintaining 100% userspace backward compatibility but in this case I would support changing the behavior since the old shell scripts were exploiting behavior that wasn’t documented and was always incorrect.

> And also again, you can specify as many wireguard interfaces as you want

I don’t have to do this with a normal data link layer, that’s the entirety of the complaint.

Only one peer is allowed to use 0.0.0.0/0 for AllowedIPs