Issue with unconstrained template-based approaches: Only static dispatch is possible which means, the compiler has to duplicate the procedure for all actual type-combinations and a procedure cannot return objects of different types, even though your are only interested in the interface they implement.
Well, you could if you either ensure, that the layout of the inherited part of a structure is the same for all structures, that inherit the same structure. Or you could return a tagged enum. However, with interfaces or traits, you just have to ensure that the table of interface/trait-methods of different types, that implement the same interface/trait. This table is constant and therefore a reference to it can be shared by every instance of the interface/trait.
Yes, it might be slower, because instead of direct method-calls, you have a layer of indirection, but you only need one copy of the method, not one for every type-combination. If all copies of this method have to fit in the L1-cache simultaneously but cannot, it might actually be faster.
There is also another term for this: ADHD. Even though ADHD does not really have anything to do with attention, it is more of a motivation-issue, which can led to starting new, promising projects instead of finishing projects, because you find more and more obstacles.
And he is talking about the diesel effect. This implies the presence of an oxidiser like oxygen. Yes, CH₄ + 2 H₂O does react to CO₂ and 4 H₂, but not under high pressure and it is endothermic, so nope. And this pipeline has an diameter of more than a metre, so this plug must be quite large. Yes, the pressure was 105 bar which is more than enough for the creating of these clathrates but this must be a lot of water o.o…anyway, I am not an expert, but this articles sounds a lot like he took a lot of knowledge from here: https://petrowiki.spe.org/Hydrate_plug_removal. But I like the idea. An deliberate attack is somewhat unsound for me, I do not see a reason for Russia to destroy both pipelines. NS1: ok, Russia tried to pressure Germany to open NS2 anyway. All 4 of them at different spots? At almost the same time? And if they maintained them all simultaneously (Why so fast? They have time now.), if one broke, they should have stopped anything on the other one, which exploded 17 h later. And this articles assumes a lot of incompetence on the Russian side…I do not buy this.
KOH is not soap, it is used in the production of soap and KOH will make your skin to soap. Destroying anything organic by cooking it in strong lye at 120 °C with quite polar solvent is not something unexpected. It might be optimised with crown ethers or other phase-transfer catalysts, but I cannot see how this is a milder treatment than simple heating it until decomposition. To make this reaction affordable one has to extract/purify these forever-chemicals first. Otherwise, mostly other stuff will be destroyed. Lime (Ca(OH)₂) is somewhat cheaper in this quantities, maybe this reaction can be done with it. This will also bind any fluoride ions, which would make this way less toxic.
RSA is bad, because developers do not implement it as specified and ECC is good, because most developers will not implement it themself, because they do not understand ECC and therefor use libraries? IMHO a huge advantage of RSA over ECC is it is easy to explain. After you have explained the different kinds of elliptic curves and their pitfalls, you have to explain the integrated encryption scheme to actually use it for encryption. But ok, you want hybrid encryption with RSA too, but in theory, you do not have to.
So, a RegEx (melody syntax) to RegEx (unspecified syntax) compiler? I mean, the syntax is nice, but 1. please specify which kind of regular expression it compiles to, 2. are those really regular expressions or a language higher in the chomsky hierarchy? 3. I suggest to add a graphical output of the state machine, e.g. with graphviz.
Do you like teapots? Fine, let us talk about the teapot currently orbiting the sun on the opposite side, so small, we cannot see it, but it is obviously there, ancient books and the elder says so. You do not believe me? Then where is your evidence for its not-existence? You cannot prove it? See: The teapot exist!
Btw. as you can see in the figure about blood type distributions, »I am more likely to have a common blood type than a rare one"« is actually false. It is more likely to have any other type than A. But fair enough, neither of the blood types are very rare.
The number of CVEs is for the most part a function of how-often-does-someone-look-at-it and only for a tiny part a function of safety. If I remember correctly, sometime ago a lot of CVEs appeared for OpenBSD, because someone seemed to have started looking for vulnerabilities and found a lot of quite trivial but severe ones. Therefore I am somewhat concerned about the the OpenBSD-libc, but neither have I looked at the code nor am I an expert. I see the point that the wrappers are probably safe, but yet the full libc is loaded and available for malicious code.
But to be fair: The libc is able to handle – either by caching or by implementing the functionality – some syscalls without actually invoking a syscall and such a library allows to have an unstable API for syscalls and might allow other mitigation tactics.
As a compromise: Why not multiple libraries (libc, libgo?, librs?) that are allowed to do syscalls? Yes, a larger code base to maintain but imho enforcing a single library is worse.
And where is the advantage then to have a `call syscall_wrapper` over `mov rax, syscall_number; syscall` if the ROP was able to return just before the call?
https://lwn.net/Articles/806776/ says, system-call-origin verification is for mitigation of ROP. ROP is (always?) a result of stack buffer overflows, which are a result of bad programming in asm/C/C++, but usually not a thing at all with modern languages like Go, Rust, Swift, Haskell, etc. while C/C++-programs usually use the libc already. This enforces programs written in such languages to use another layer, written in C, that is not really necessary but might introduce new vulnerabilities. Do I miss something?
is not valid Rust, but this is: