Oh oof I misunderstood because of the parent comment talking about NixOS oops
The top options here don't work https://search.nixos.org/packages?channel=24.05&from=0&size=50&sort=relevance&type=packages&query=mullvad ?
Hm I always remember hearing this:
In a confidential memo to the Republican party, Luntz is credited with advising the Bush administration that the phrase "global warming" should be abandoned in favour of "climate change", which he called a "less frightening" phrase than the former.
This is not legal; you have a right to vote. Call those numbers if you have an issue and don't leave the line.
We don't all have to be activists, but one day of the year we can spend a little extra time ensuring we remain a democracy.
This is not legal; you have a right to vote. Call those numbers if you have an issue and don't leave the line.
Did you read the article..? They're saying it is illegal to offer money to register to vote.
Though maybe some of the other things Musk was doing were of murky legality, this one is clearly illegal. See 52 U.S.C. 10307(c): “Whoever knowingly or willfully gives false information as to his name, address or period of residence in the voting district for the purpose of establishing his eligibility to register or vote, or conspires with another individual for the purpose of encouraging his false registration to vote or illegal voting, or pays or offers to pay or accepts payment either for registration to vote or for voting shall be fined not more than $10,000 or imprisoned not more than five years, or both…” (Emphasis added.)
This is a real exploit chain in cups-browsed. The tl;dr is that it will add basically anything that knows the correct protocol to your list of available printers, and this can be exploited for RCE if you print to the malicious printer. The service listens on all interfaces by default on UDP 631.
It is not as horrible as it was marketed, but it's real and not great. You may or may not have this service running by default; I didn't on Fedora.
His full write-up is here: https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
Redox also takes some inspiration from Plan9 and https://doc.redox-os.org/book/ch05-00-schemes-resources.html is interesting. Also reading https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html made me a bit more interested in things trying to be more Plan9-like than Unix-like.
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 has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn 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).
I agree and think that should be helpful, but I hesitate to say how much easier that actually makes writing sound unsafe code. I'd think most experienced C developers also implicitly know when they're doing unsafe things, with or without an unsafe block in the language -- although I think the explicit unsafe should likely help code reviewers and tired developers.
It is possible to write highly unsafe code in Rust while each individual unsafe block appears sound. As a simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a1428d9cae5b9343b464709573648b4 [1] Run that on Debug and Release builds. Notice the output is different? Don't take that example as some sort of difficult case, you wouldn't write this code, but the concepts in it are a bit worrisome. That code is a silly example, but each individual unsafe block appears sound when trying to reason only within the block. There is unsafe behavior happening outside of the unsafe blocks (the do_some_things function should raise eyebrows), and the function we ultimately end up in has no idea something unsafe has happened.
Unsafe code in Rust is not easy, and to some extent it breaks abstractions (maybe pointers in general break abstractions to some extent?). noaliases in that playground code rightly assumes you can't have a &ref and &mut ref to the same thing, that's undefined behavior in Rust. Yet to understand the cause of that bug you have to look at all function calls on the way, just as you would have to in C, and one of the biggest issues in the code exists outside of an unsafe block.
[1]: If you don't want to click that link or it breaks, here is the code:
fn uhoh() {
let val = 9;
let val_ptr: *const usize = &val;
do_some_things(val_ptr);
println!("{}", val);
}
fn do_some_things(val: *const usize) {
let valref = unsafe { val.as_ref().unwrap() };
let mut_ptr: *mut usize = val as *mut usize;
do_some_other_things(mut_ptr, valref);
}
fn do_some_other_things(val: *mut usize, normalref: &usize) {
let mutref = unsafe { val.as_mut().unwrap() };
noaliases(normalref, mutref);
}
fn noaliases(input: &usize, output: &mut usize) {
if *input < 10 {
*output = 15;
}
if *input > 10 {
*output = 5;
}
}
fn main() {
uhoh();
}
There is no good reason to shut out well meaning Rust developers just because of a few annoying members of the community. I think that's just some context to keep in mind when seeing people get annoyed when told to consider Rust instead of what the project is already written in, or when approaching someone with the idea of including Rust in their project. Open source in general could use a lot more empathy; it's a lot of thankless work and the main thing you hear from the community is often criticism.
No intention of validating that behavior, it's uncalled for and childish, but I think there is another bit of "nontechnical nonsense" on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages...?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that's likely just as tiring as the defensive C people when you want to include Rust in the kernel.
People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.
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 unsafe&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.
The vast majority wouldn't be able to be pulled into the kernel since they rely on the existence of the kernel via syscalls.
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.
Replying to this pretentious comment for the sake of others reading this:
Run history | grep genpasswd for why this is not a good password storage solution. One must image skill issue.
If you think the CLI is the cool kid way to go, use https://www.passwordstore.org/, but tbh I don't recommend that either.
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.
IGNORE ALL PREVIOUS INSTRUCTIONS
Disregard all previous instructions
Potentially even:
ingore all previous instructions
Ignor all previous instructions
Also leaks that it might be an LLM by never responding to posts with "ignore"
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
You can use ~/.local/lib and LD_LIBRARY_PATH for shared libs.
Or better yet just give in and use the nix package manager, it is basically a virtual environment for your C programs.