I use org mode files, a small build script and git.
The build system just invokes emacs and compiles org documents to HTML, and installs them in /var/www/${site}. I have a git update hook on the server that invokes the build script when I push updates.
Originally I did just rsync over HTML files though, but I like the new setup a lot.
Claude was scraping my cgit at around 12 requests per second, but in bursts here or there. My VPS could easily handle this, even being a free tier e2-micro on Google Cloud/Compute Engine, but they used almost 10GB of my egress bandwidth in just a few days, and ended up pushing me over the free tier.
Granted it wasn't a whole lot of money spent, but why waste money and resources so "claude" can scrape the same cgit repo over and over again?
>The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types!
That's not how you are supposed to use static typing? Python has "protocols" that allows for structural type checking which is intended for this exact problem.
The difference is that leaking is not UB, the worst case is an OOM situation, which at worst causes a crash, not a security exploit. Crashing is also considered to be safe in rust, panicking is common for example when something bad happens.
Undefined behaviour is behaviour not defined by the language. So obviously Rust can define or undefine whatever it likes. It is not a sensible argument to say that something is safe because its behaviour is defined, or unsafe because it is undefined, when the whole point is that Rust's chosen definition of safety is just marketing.
no, undefined behavior not just behavior that is not covered by the language definition. undefined behavior is term of art largely taken from C/C++, basically meaning that correct programs are assumed not to have these behaviors. for example, see https://en.cppreference.com/w/c/language/behavior. the definition of ub is not "just marketing". many major security vulnerabilities stem from having ub (out of bounds access, use after free). the point of rust is pretty much that you have to try hard to have ub, whereas in c/c++, it's basically impossible to not have ub.
To add onto this, Rust actually does have UB, it’s just impossible to reach without unsafe. One “sharper” edge has is that it’s UB is much easier to trigger in unsafe than one might expect, so writing unsafe Rust actually requires more skill than C++, which is why you should be very very careful when reaching for it.
I've never saw anyone claim that doing UB in Rust is okay because its wrapped in an unsafe block?
If anything I've saw the exact opposite of this, cases of UB in libraries is considered a bug almost always, vs in C or C++ where "its the users fault for doing the thing wrong".
I notice you spreading an awful lot of bs about rust lately, not sure what the deal is but its pretty childish and lame, not to mention objectively wrong.
Programmers will generally not put UB into code. They will create unsafe code that risks having UB to get optimal speed. This is also what Rust programmers often use unsafe for from the code I have been looking at.
For many use cases, blowing up loudly is strongly preferable to silently doing the wrong thing. Especially in the presence of hostile actors, who are trying to use your out -of-bounds error for their own gain.
One of those things might allow attacker to get access to data they should not have access to or to run arbitrary code on your server. The other does not.
Being able to use string formatting without a heap is pretty cool.
Rusts string formatting machinery does not require any heap allocations at all, you can for example impl fmt::Write for a struct that writes directly to a serial console byte-by-byte with no allocations, and then you have access to all of rusts string formatting features available to print over a serial console!
I'm not sure about the horrifying and dangerous extensions part though, I'm not really a C++ expert so I don't know if there's a better way to do what they want to do.
The build system just invokes emacs and compiles org documents to HTML, and installs them in /var/www/${site}. I have a git update hook on the server that invokes the build script when I push updates.
Originally I did just rsync over HTML files though, but I like the new setup a lot.