Yes for example Python implements them using semaphores.
Yes for example Python implements them using semaphores.
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]);
}
}
You can use udev to make a symlink with a consistent name
It’s not trivial on Fedora due to SELinux; you’ll need to use https://github.com/DeterminateSystems/nix-installer
They were very clear it was for research in my memory. That was the reason I did it.
I’ve never had an issue using banking apps from Lineage. I use 3 different pretty mainstream ones
deleted by creator
This is not necessarily true.
For example, consider the case of a 1Password vault falling into the hands of an attacker. They do not have the option to just crack your password, as the password is mixed with a randomly generated value to ultimately derive the key. They would need to simultaneously brute force your password and that random value. This should almost be impossible. However, given access to a client that already has knowledge of the secret value, it would fall back to brute forcing the password.
1Password is a solid service if you’re OK with the proprietary aspect. I use it personally and we use it at work (I’m an infosec consultant)
A lot of weird hate for 1Password on Lemmy the past couple days. I highly recommend reading their white paper, I think most of the hate comes from ignorance of what they are actually doing.
https://1passwordstatic.com/files/security/1password-white-paper.pdf
They don’t have your password in any form. The random key is generated with a CSPRNG, we don’t know how to crack those. They aren’t hiding behind secrets: it’s all documented right here https://1passwordstatic.com/files/security/1password-white-paper.pdf
1Password is quite good.
Not sure if you’ve read this but it might help get started.
https://1passwordstatic.com/files/security/1password-white-paper.pdf
This doesn’t seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has
go.sum
, Rust has Cargo which hasCargo.lock
, Python haspip
which gives a few different ways to pin versions, JavaScript hasnpm
andyarn
with lock files. I’m sure there are tons of others. I’m actually surprised this doesn’t happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say “look Rust bad Debian doesn’t like it”.This seems like a big issue if you want your code to be packaged by Debian, and it doesn’t seem easy to resolve if you also want to use the modern packaging tools. I’m not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian’s model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it’ll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they’ll likely all run fine on Debian).