This is correct. Win9x did have memory protection, it just made an intentional choice to set up wide open mappings for compatibility reasons.
WSL9x uses the same Win9x memory protection APIs to set up the mappings for Linux processes, and the memory protection in this context is solid. The difference is simply that there is no need to subvert it for compatibility.
doslinux is some tricky sleight of hand where it looks like Linux is running inside DOS, but it's actually the other way around (even though DOS boots first).
WSL9x takes quite a different approach. Windows boots first, but once Linux starts both kernels are running side-by-side in ring 0 with full privileges. They are supposed to cooperate, but if either crashes then both go down.
I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.
It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up
You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.
XOR encryption is cheap and effective. Make the key the static string "IfYouCanReadThisYourCodeWillBreak" or something akin to that. That way, the key itself will serve as a final warning when (not if) the key gets cracked.
Symmetric encryption is computationally ~free, but most of them are conceptually complex. The purpose of encryption here isn't security, it's obfuscation in the service of dissuading people from depending on something they shouldn't, so using the absolutely simplest thing that could possibly work is a positive.
XOR with fixed key is trivially figure-out-able, defeating the purpose. Speck is simple enough that a working implementation is included within the wikipedia article, and most LLMs can oneshot it.
Yes, XOR is a real and fundamental primitive in cryptography, but a cryptographer may view the scheme you described as violating Kerckhoffs's second principle of "secrecy in key only" (sometimes phrased, "if you don't pass in a key, it is encoding and not encryption"). You could view your obscure phrase as a key, or you could view it as a constant in a proprietary, obscure algorithm (which would make it an encoding). There's room for interpretation there.
Note that this is not a one-time pad because we are using the same key material many times.
But this is somewhat pedantic on my part, it's a distinction without a difference in this specific case where we don't actually need secrecy. (In most other cases there would be an important difference.)
Encoding a type name into an ID is never really something I've viewed as being about performance. Think of it more like an area code, it's an essential part of the identifier that tells you how to interpret the rest of it.
> That repository ID (010:Repository2325298) had a clear structure: 010 is some type enum, followed by a colon, the word Repository, and then the database ID 2325298.
It's a classic length prefix. Repository has 10 chars, Tree has 4.
Not sure what this post has to do with Rust, but people do use static analysis on C and C++. The problem is that C and C++ are so flexible that retrofitting static verification after the fact becomes quite difficult.
Rust restricts the shape of program you are able to write so that it's possible to statically guarantee memory safety.
> Does it require annotations or can it validate any c code?
If you had clicked through you would see that it requires annotations.
Ok, but you do realize that you're now deep in the realm of real time Linux and you're supposed to allocate entire CPU cores to individual processes?
What I'm trying to express here is that the spinlock isn't some special tool that you pull out of the toolbox to make something faster and call it a day.
It's like a cryogenic superconductor that requires extreme caution to use properly. It's something you avoid doing because it's a pain in the ass.
Gaming and high frequency trading are the most obvious examples where this is desirable.
If you adjust the multimedia timer to its highest resolution (1ms on windows), sleeping is still a non-starter. Even if the sleep was magically 0ms whenever needed, you still have risk of context switching wrecking your cache and jacking up memory bandwidth utilization.
Even outside of such, if your contention is low and critical section short, spinning a few rounds to avoid a syscall is likely to be a gain not just in terms of latencies but also in terms of cycles waste.
It’s a poetic end, considering that the very same scraping activity without regard for cost to site operators is how these models are trained to begin with.
WSL9x uses the same Win9x memory protection APIs to set up the mappings for Linux processes, and the memory protection in this context is solid. The difference is simply that there is no need to subvert it for compatibility.
reply