> So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow.
`openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to expose. While I can understand that this may not be straight forward for a cross-platform API, I have to disagree with your statement that Rust's stdlib is mistake prone because it's so low-level. It's more mistake prone than POSIX (in some aspects) because it is missing a whole family of low-level syscalls.
There are lots of unstable things in Rust that have been unstable for many years, and the intentional segregating of unstable means that it's a nonstarter for most use cases, like libraries. It's unstable because there's significant enough issues that nobody wants to mark it as stable, no matter what those issues are.
As long as it's unstable it's totally fair to say Rust's stdlib does not expose them. You might as well say it's fixed because someone posted a patch on a mailing list somewhere.
There are lots of unstable things in Rust that have been unstable for many years, but this isn't one of them. openat() was added in September, and the next PR in the series implementing unlinkat() and removeat() received a code review three weeks ago and is currently waiting on the author for minor revisions.
> As long as it's unstable it's totally fair to say Rust's stdlib does not expose them. You might as well say it's fixed because someone posted a patch on a mailing list somewhere
Agreed. My comment was intended to be read as "it's planned and being worked on", not "it's available".
They're not missing, Rust just ships them (including openat) as part of the first-party libc crate rather than exposing them directly from libstd. You'll find all the other libc syscalls there as well: https://docs.rs/libc/0.2.186/libc/ . I agree that Rust's stdlib could use some higher-level helper functions to help head off TOCTOU, but it's not as simple as just exposing `openat`, which, in addition to being platform-specific as you say, is also error-prone in its own right.
The parent was asking for access to the C syscall, and C syscalls are unsafe, including in C. You can wrap that syscall in a safe interface if you like, and many have. And to reiterate, I'm all for supporting this pattern in Rust's stdlib itself. But openat itself is a questionable API (I have not yet seen anyone mention that openat2 exists), and if Rust wanted to provide this, it would want to design something distinct.
> Why can I easily use "*at" functions from Python's stdlib, but not Rust's?
I'm not sure you can. The supported pattern appears to involve passing the optional `opener` parameter to `os.open`, but while the example of this shown in the official documentation works on Linux, I just tried it on Windows and it throws a PermissionError exception because AFAIK you can't open directories on Windows.
I took parent's message to be asking why the standard library fs primitives don't use `at` functions under the hood, not that they wanted the `at` functions directly exposed.
> why the standard library fs primitives don't use `at` functions under the hood
In this case it wouldn't seem to make sense to use `at` functions to back the standard file opening interface that Rust presents, because it requires different parameters, so a different API would need to be designed. Someone above mentioned that such an API is being considered for inclusion in libstd in this issue: https://github.com/rust-lang/rust/issues/120426
You can but you have to go through the lower level API: NtCreateFile can open a directory, and you can pass in a RootDirectory handle to following calls to make them handle-relative.
The correct comparison is to rustix, not libc, and rustix is not first-party. And even then the rustix API does not encapsulate the operations into structs the same way std::fs and std::io do.
The correct comparison to someone asking for first-party access to a C syscall is to the first-party crate that provides direct bindings to C syscalls. If you're willing to go further afield to third-party crates, you might as well skip rustix's "POSIX-ish" APIs (to quote their documentation) and go directly to the openat crate, which provides a Rust-style API.
If I have to use unsafe just to open a file, I might as well use C. While Rustix is a happy middle that is usually enough and more popular than the open at crate, libc is in the same family as the "*-sys" crate and, generally speaking, it is not intended for direct use outside other FFI crates.
I agree it is an exaggeration in that of course you could write a wrapper. The point was that if everyone had to write their own FFI wrappers, Rust wouldn't go far and openat is not an exception.
There is code available at the right level of abstraction (the rustix or openat crates), and while it's not managed by the Rust team, uutils already have many third party dependencies. Bringing up libc just because it's first party, instead, is comparing apple to oranges.
It contributes to it, because now you're behind the same public IP address as X other people. You're then X-times more likely to get flagged as suspicious and need to enter a CAPTCHA X-times more frequently.
It's not a direct cause, but if an IP is hitting my website with spam, I don't care if it's a spam bot or a CGNAT exit point. The only way to stop the spam is to take action against the IP address. For CGNAT customers, that means extra CAPTCHAs or worse.
You can ask your ISP for your own IPv6 subnet if you don't want to be lumped in with the people whose computers and phones are part of a scraping/spamming botnet.
This may make sense if the extended warranty is limited to defects introduced by the remote change. I.e., if they remotely break your device, they should be responsible for fixing the damage. A full warranty extension doesn't seem reasonable to me, though.
With regards to your last sentence, I think a good first step would be to require at least security and other critical updates to be provided within the full warranty period. And this would make sense even without the (limited) warranty extension, and I actually consider it more important.
if the extended warranty is limited to defects introduced by the remote change
yes, of course. it may be hard to distinguish though. the device getting hot may create additional stress on the mainboard or RAM or other parts causing it to break faster.
Doesn't Facebook require users to verify the email address with a confirmation email? If so, the only Facebook spam you should be able to get would be such confirmation emails. Or what am I missing?
I can't speak about facebook but I am in the case of having a gmail address[1] with my first name initial followed by my last name and I am in the case of having people with same last name and first name initial using my email address to register. That box is polluted by regular confirmation emails followed by spams from the same many websites. It turns out that more often than not the confirmation email is made to protect the companies running the websites (I guess to limit bots and password that can't be reinitialized), not promotionnal mail registration. You still receive all the promotionnal and automated email regardless if the user is active. Different table in the database I guess. Also there websites/services that don't use confirmation emails as well as processes initiated through physical office/point of sale.
[1] now pretty much abandonned but I mostly keep it to avoid anyone obtaining it and impersonating me. I still need to do some housekeeping and make sure I am not registered anywhere with that address anymore.
In my experience, surprisingly few services nowadays require email confirmation, I suppose in the name of increasing conversions or something.
I've had a number of accounts opened in my address but with different dots (eBay, Spotify, Shutterstock) that didn't require confirmation.
I usually reset the password, inform customer service (who generally don't care, or don't want to do anything because it's not my account), and then I close the account.
Oh I wish that were true, I've been receiving email for years for someone who signed up to facebook with my email address. It's a horrible pain, you can't contact facebook without a facebook account, and I can't create one because someone already has one with my email address.
Do a password recovery, log in and simply delete the account.
I had to do this once when someone signed up to FB with my email address. It actually was an eye opening experience as to how much data FB collects from everyone.
Now keep in mind that:
1) I don't have a FB account myself
2) This person signed up with my email address (which is <something-generic>@gmail.com), but their name is completely different from mine
3) They didn't even speak the same language, when I logged in to the new account the whole thing was in Swedish or something like it.
So nothing at all linking the account to me, except a misspelled e-mail address. When I logged in, FB was happy to suggest I friend a whole bunch of people I know IRL. Including people that do not know the e-mail address used. Absolutely crazy. How were they able to link me to these people when I was signed in to a complete stranger's account?
Well I sort of did, didn't want to delete the guy's stuff, so I made a dummy gmail account, switched it to that and deleted the gmail account after weeks of spam emails and trying to contact facebook I figured he could do some of the hard work to get his account back.
Of course it backfired, after he stopped using his account facebook and a couple of weeks facebook started sending begging emails to my email account again (don't believe them when they say they delete anything), I still get the occasional "what you've missed on FB" emails and about once a year the guy tries to recover his account and I get an email, I'd drop him a note, but the only email address I have for him is mine
Many retail AM4 motherboards support ECC with retail Ryzen CPUs. At least on Linux it works as expected. ECC UDIMMs can be difficult to find but it shouldn't be necessary to buy a TR Pro for ECC if memory capacity, I/O lanes and the performance of AM4 Ryzen CPUs suffice.
I haven't looked into deeply but I've heard stories from others with Ryzen boxes that ECC features of the RAM are turned off with Ryzen CPUs installed. Supposedly you can see this in Linux w/dmidecode or other tools. I'd appreciate good links if anybody has them.
Ryzen APUs (i.e., Socket AM4 CPUs with with integrated AMD graphics) do _not_ support ECC UDIMM, _unless_ they carry a "Pro" in their name.
Ryzen CPUs without an iGPU _will_ support ECC UDIMM, _unless_ the mainboard specs specifically tell you that it won't support ECC, or simply omit mentioning ECC UDIMM at all.
Fwiw, I've enjoyed proper ECC on an ASRock Fatal1ty B450 Gaming-ITX/ac with a Ryzen 5 3600 for more than two years now (using GNU/Linux; I am not sure how Windows would fare).
> 1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler.
There have been at least two cases where Firefox build broke due to having a too recent version of Rust installed. The stability guarantees may be fairly strong but it's definitely not perfect.
Use of uninitialized memory is Undefined Behavior. So in a sense, that code never worked properly, but authors didn't know about it until Rust caught it explicitly.
It's undefined behavior. Anything can happen, by definition.
I understand what you're saying, but anyone who knowingly relies on undefined behavior deserves whatever pain they get, and anyone who didn't know they were relying on undefined behavior, needed to know about it.
Yes, but my point is that they won't be used every day. I used to work in a dev shop that had to compile 20+ applications every month or so. Our automated mac/build box, would require poking and resurrecting every other time it was used. This would have saved us a fortune.
`openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to expose. While I can understand that this may not be straight forward for a cross-platform API, I have to disagree with your statement that Rust's stdlib is mistake prone because it's so low-level. It's more mistake prone than POSIX (in some aspects) because it is missing a whole family of low-level syscalls.