They're being downvoted because it's a silly comment that is basically unrelated and also extremely unhelpful. Everyone can agree that C has footguns and isn't memory safe, but writing a kernel isn't memory safe. A kernel written in Rust will have tons of unsafe, just look at Redox: https://github.com/search?q=repo%3Aredox-os%2Fkernel%20unsafe&type=code That doesn't mean it isn't safer, even in kernel space, but the issues with introducing Rust into the kernel, which is already written in C and a massive project, are more nuanced than "C bad". The religious "C bad" and "C good" arguments are kinda exactly the issue on display in the OP.
I say this as someone who writes mostly Rust instead of C and is in favor of Rust in the kernel.
This is not true at all. https://en.wikipedia.org/wiki/Post-quantum_cryptography good place to start if you're genuinely interested. Most password managers that are worth while will be using symmetric cryptography which just requires longer key lengths to survive in the quantum age. AES256 should be fine for the foreseeable future.
The important point there is that they don't care imo. It's not even worth the effort to try.
You can likely come up with something "good enough" though yea. Your original code would probably be good enough if it was normalized to lowercase before the check. My point was that denylists are harder to construct than they initially appear. Especially in the LLM case.
Nobody who matters judges new shoes, but you can also extend the life of your shoes by resoling them before they get torn up. https://rockandresole.com/ does mail in resoling, but there could be a place near you. Huge savings considering the cost of shoes these days. I have a few pairs I rotate through while some are being resoled
It doesn't violate any rules.. Imagine both the "speaker" and the "text" are being updated by separate threads. A program that would eventually display the behavior in this meme is simple, and I'm a bit embarrassed to have written it because of this comment:
#include <pthread.h>
#include <stdio.h>
char* speakers[] = {
"Alice",
"Bob"
};
int speaker = 0;
void* change_speaker(void* arg)
{
(void)arg;
for (;;) {
speaker = speaker == 0 ? 1 : 0;
}
}
char* texts[] = {
"Hi Bob",
"Hi Alice, what's up?",
"Not much Bob",
};
int text = 0;
void* change_text(void* arg)
{
(void)arg;
for (;;) {
switch (text) {
case 0:
text = 1;
break;
case 1:
text = 2;
break;
case 2:
text = 0;
break;
}
}
}
int main(int argc, char* argv[])
{
pthread_t speaker_swapper, text_swapper;
pthread_create(&text_swapper, NULL, change_text, NULL);
pthread_create(&speaker_swapper, NULL, change_speaker, NULL);
for (int i = 0; i < 3; ++i) {
printf("%s: %s\n", speakers[speaker], texts[text]);
}
}
I'm relatively qualified. Studied physics all through college and spent a couple years working in quantum computing. I'll chime in here because Schrodinger's cat jokes are a pet peeve.
You are correct that, as far as we understand, it is literally impossible. There has been a competing theory for decades, but I'm not really up on the specifics https://en.wikipedia.org/wiki/De_Broglie%E2%80%93Bohm_theory. The reason it is generally rejected is that it appears to violate relativity.
Anyway.. the cat thought experiment is such a fun thought experiment to me because it specifically makes us think about a very practical issue with respect to quantum computing: decoherence. If you take his thought experiment to an extreme, it actually should be theoretically possible to create a state in which a macroscopic object (the cat) and a quantum object (the radioactive source) are indeed entangled. But that is absurd according to everything we've ever seen. So what's up? The missing concept here is decoherence -- while this state may theoretically exist, it'd decohere on timescales so small we can't even imagine. The fun connection here is that decoherence is the exact thing we're trying to fight in quantum computing. Essentially we're trying to make this thought experiment a reality for a much less complex system.
Async features in almost all popular languages are a single thread running an event loop (Go being an exception there I believe). Multi threading is still quite difficult to get right if the task isn't trivially parallelizable.
This has always been a weird take, what do you think attracts people to that kind of SAR work? Generally a love for the outdoors and activities like this. You'll have a hard time finding someone capable of high angle rescue that doesn't enjoy or understand climbing as a sport.
This is Arnaud Petit and Stéphanie Bodet, two professional climbers with far more experience than you. They are doing the second ascent of a 900 meter 8a on Angel Falls (Rainbow Jambaia, 31 pitches) which is about the same height as El Capitan in Yosemite National Park. Here is a story about it. You almost never plan to climb routes this long in a single day, especially not on the second ascent. They most definitely planned to sleep on the wall and brought the proper equipment. This is called big wall climbing
Just be happy for people doing what they love and do what you love: your life will be better. We're all motivated by different things.
Most responsible climbers bring something with them to pack it out, but there are some irresponsible ones that do what the comment above mentioned. That is the exception, not the rule though.
They're being downvoted because it's a silly comment that is basically unrelated and also extremely unhelpful. Everyone can agree that C has footguns and isn't memory safe, but writing a kernel isn't memory safe. A kernel written in Rust will have tons of unsafe, just look at Redox: https://github.com/search?q=repo%3Aredox-os%2Fkernel%20unsafe&type=code That doesn't mean it isn't safer, even in kernel space, but the issues with introducing Rust into the kernel, which is already written in C and a massive project, are more nuanced than "C bad". The religious "C bad" and "C good" arguments are kinda exactly the issue on display in the OP.
I say this as someone who writes mostly Rust instead of C and is in favor of Rust in the kernel.