Just on a technical note, TLS 1.3 only uses AEAD ciphers where the nonce is determined by the record numbers, so it actually is in principle possible to decrypt the packets even if they are received out of order by trial decrypting with different record numbers. You don't do this in TLS (as opposed to DTLS) because it runs over TCP and therefore you are guaranteed in-order delivery.
I would agree with you that DTLS is a misnomer; that it does not provide the layer-4/transport-layer -like interface that regular TLS provides.
(It isn't quite a layer-3/internetwork-layer -like interface; from the UDP that it sits on, it has a multiplexing component that is "half" of a layer 4 interface.)
Virtual threads, generational GC, manual memory management, all things .NET has had for ages. Too bad it can’t shake the “MS tech is boring” reputation
I don't think .NET has virtual threads (async/await doesn't count), and it definitely doesn't have anything similar to ZGC/Shenandoah — two garbage collectors that provide sub-millisecond pauses with heaps up to the multiple terabyte range. You can also go completely pause-less on commercial JVMs from Azul.
ZGC is a concurrent GC, both the marking phase and the evacuation phase are done concurrently with the program running. A generational ZGC is a generational concurrent GC.
Well, yeah, that's been Java's explicit philosophy for decades. Let other languages evaluate cool new features first, then learn from their mistakes and promise backward compatibility "forever".
Linux support is bad on MS tech. Poor ecosystem and VM isn’t that great. JVM with ZGC is fast on Linux. Biggest lack is Value Types.
And I’m not deploying to Windows. That’s right out.
But lots of people find it useful, so more power to them. For me, it must deploy on Linux. That’s a dealbreaker. It’s not enough if some bare functionality is on Linux. I don’t want to be experiencing the equivalent trouble of trying to have a musl-only build.
JNI story is great. Can bind easily with rust-jni on Linux.
But need value types and some longer primitives (i128 and u128 would be nice).
Thank you for the clarification. I should have searched around a bit more for an explanation before complaining about it here.
As soon as I have a little free time I'll do my best to update the relevant Wikipedia pages in hopes fewer people are confused by the nomenclature in the future.
To give some more detail: hydrogen to helium fusion (even with intermediate steps) is extremely unlikely to happen. That's part of why the sun will last for billions of years. And that's also why first human attempts at fusion are not trying to use straight up hydrogen as the fuel.
Good old Wikipedia has this gem:
> The large power output of the Sun is mainly due to the huge size and density of its core (compared to Earth and objects on Earth), with only a fairly small amount of power being generated per cubic metre. Theoretical models of the Sun's interior indicate a maximum power density, or energy production, of approximately 276.5 watts per cubic metre at the center of the core,[63] which is about the same power density inside a compost pile.
Another fun fact: there's a decades old design for a gadget that fits at the top of your desk and does nuclear fusion. You could build one yourself, if you are sufficiently dedicated. Unfortunately, no one has ever worked out how to run one of them as a power plant. Ie how to get more useful energy out than you have to put in.
> And that data-stream the interface that TLS provides
That’s exactly the problem. You might lose a UDP packet. That would corrupt data encrypted with stream cipher.
With DTLS, each packet is encrypted individually.
https://en.m.wikipedia.org/wiki/Datagram_Transport_Layer_Sec...