The correct phrasing of the title: The bugs Rust won't catch.
Bugs Rust won't catch
361–370 of 395 posts
Re: Bugs Rust won't catch
#362Earlier quoted context omitted.
First of all, thank you for presenting a succinct take on this viewpoint from the other side of the fence from where I am at. So how can I learn from this? (Asking very aggressively, especially for Internet writing, to make the contrast unmistakable. And contrast helps with perceiving differences and mistakes.) (You also don’t owe me any of your time or mental bandwidth, whatsoever.) So here goes: Question 1: How com…
> Question 2: > Does throughput really matter more than latency in everyday application? IME as a user, hell yes Getting a video I don't mind if it buffers a moment, but once it starts I need all of that data moving to my player as quickly as possible OTOH if there's no wait, but the data is restricted (the amount coming to my player is less than the player needs to fully render the images), the video is "unwatchable…
What's every day?
Exactly, lots of different things.
When I alt-tab I care about latency.
When I ssh I care about latency.
When I download a 25GB game I care about throughput for the download to a certain extent that is probably mainly ISP bound rather than local system bound. I don't care if the download takes 10 or 11 minutes as long as I can still use my system with zero delays meanwhile. And whether it takes 11 minutes of 3 hours depends on my ISP mostly. But being responsive to me while it downloads is local latency bound.
The Youtube example you have makes sense, sure.
Re: Bugs Rust won't catch
#363Earlier quoted context omitted.
I'm unaware of any Rust rewrites outside of coreutils, so: sudo apt install coreutils-from-gnu https://computingforgeeks.com/ubuntu-2604-rust-coreutils-gui...
There aren't true 1:1 clones, but there's ripgrep (inspired by GNU grep) and fd (inspired by GNU find). Those two I like, though. I think they're thoughtfully designed and in ripgrep's case at least (I just haven't read posts/comments by fd's author), it was developed with some close study of other grep implementations. I still use GNU grep and GNU find as well, but rg and fd are often nice for me.
[deleted]
Re: Bugs Rust won't catch
#364Earlier quoted context omitted.
In short, NFS has a terrible data model and only pretends to be a file system.
No, any remote system would have the same problem if one expected to use it as if it were local.
Not quite. For persistence latency, yes.
For read-only access there could be way better caching, especially for common use cases like listing the contents of a filesystem directory. But stuff like this was excluded on purpose.
NFS is really stupid.
NFS made the assumption that a distributed system with over 100 times the latency of a local system could be treated like a local system in every single way.
Re: Bugs Rust won't catch
#365Earlier quoted context omitted.
Accurate a.k.a. "correct" implementation of ACID needs a single (central) source of truth and temporal serializability (or something close to that). In practice this always "impacts" performance. If I understand it correctly, then in physics this is called an event horizon.
Not necessarily. Most race conditions violate the `A` in ACID, but the finicky thing about atomicity is that N > 1 sequential actions that in and of themselves are atomic violates atomicity. So any atomic store is possible to misuse if you can compose multiple atomic operations on it. In addition ACID isn't always provided by the floor beneath your programs but by designing the programs on top to uphold it and/or not…
Firstly, atomicity and/or thread-safety not composing is where the Consistency and Isolation come in.
The "application layer" always has to enforce its own consistency guarantees. If the lower layers are total garbage, then the system is garbage. And the "speed" of the lower layers can be infinitely fast and it doesn’t matter, if the application has a latency floor. So optimize it all you want.
Re: Bugs Rust won't catch
#366Earlier quoted context omitted.
Hell no. Linux desktop (and the kernel) felt awful for such a long time because everyone was optimizing for server and workstation workloads. Its the reason CachyOS (and before that Linux Zen and.. Licorix?) are a thing. For good UX, you heavily prioritize latency over throughput. No one cares if copying a file stalls for a moment or takes 2 seconds longer if that ensures no hitches in alt tabbing, scrolling or mouse…
When Kon Colivas introduced a scheduler optimized for desktop latency, about 15 years ago, the amount of abuse he got from Linux developers was astonishing, and he ended up quitting for good. I remember compiling it on my laptop and noticing how it made a huge improvement in the useability of X and desktop environment.
This also really bugs me. To be fair, the gcc people are unkind to both servers and laptops.
Re: Bugs Rust won't catch
#367Earlier quoted context omitted.
Probably a dumb question, but is GNU Core utils interested in / planning on doing its own rust rewrite?
At the current moment I would be against it. The language and library is changing too fast. Also, Rust has some other things that make it hard to use for coreutils. For example, Rust programs always call signal (SIGPIPE, SIG_IGN) or equivalent code before main(). There is no stable way to get the longstanding behavior of inheriting the signal action from the parent process [1]. This is quite annoying, but not unique…
I think the concern is that the writing may be on the wall for (the current memory-unsafe version of) Coreutils. Despite the bugs and incompatibilities, Canonical seems to have decided that the memory safety of uutils is worth it. And those two downsides, the bugs and incompatibilities, will likely attenuate quickly, compelling the other distros to follow suit in adopting uutils before long.
So the continued popularity of Coreutils might, I think, depend on Coreutil's near-term publicly announced and actual memory safety strategy. As I suggested in my other comment, there are (somewhat nascent) options for memory safety that do not require a rewrite of the code base. (For linux x86_64 platforms, depending on your requirements, that might include the "fanatically compatible" Fil-C.) And given the high profile of Coreutils, there are likely people willing to work with the Coreutils team to help in the deployment of those memory safety options.
Re: Bugs Rust won't catch
#368Earlier quoted context omitted.
Could you find one such person on this thread? Someone making ridiculous claims about what Rust offers. I’ll tell you what I think you’ve seen - there are hundreds of threads where you’ve seen people claim they’ve seen this everywhere. That gives you the impression that it is universal.
This one probably covers it: https://news.ycombinator.com/item?id=45921143
Perfect. Because that’s exactly what I’m saying.
The comment you linked says something specific about a specific kind of bug being eliminated - memory safety bugs. And they’re not making a claim, they’re repeating the evidence gathered from the Android codebase. So that’s a fact, memory safety bugs truly did not appear in the Rust parts of Android.
The comment you linked is not claiming Rust code is bug-free. That’s a strawman I’ve seen many, many times. Haters will claim that this happens all the time, but all I see are examples of the haters claiming this. You had to go back 5 months and still couldn’t find anything similar to the strawman.
> This one probably covers it
No, probably not.
Re: Bugs Rust won't catch
#369Earlier quoted context omitted.
No, any remote system would have the same problem if one expected to use it as if it were local.
Not quite. For persistence latency, yes. For read-only access there could be way better caching, especially for common use cases like listing the contents of a filesystem directory. But stuff like this was excluded on purpose. NFS is really stupid. NFS made the assumption that a distributed system with over 100 times the latency of a local system could be treated like a local system in every single way.
I am not sure why this means why "NFS is really stupid" if the user assumes that a distributed file system can be treated just like a local system. That is provides the same interface is what makes NFS extremely useful.
Re: Bugs Rust won't catch
#370Earlier quoted context omitted.
NFS is more annoying on Linux than just using Samba though, at least for the NAS use case. With Samba on my server I can just browse to it in KDE's file manager Dolphin, and samba configuration is a relatively straight forward ini style file on the server. A pair of ports also need to be opened in the host firewall. Contrast that with NFS, which last I looked needed several config files, matching account IDs between…
NetApp has NFS support and is widely used.
First thing I have heard about NetApp. Seems to be some enterprise focused company, with more than one product. Not sure which product of theirs you refer to.
Synology, TrueNAS and Proxmox probably also have NFS support I would assume, and they definitely have Samba. Those are more relevant to me personally.
I just run a normal headless Linux distro on my NAS computer, I don't see the point of a specialised NAS distro. It too could have NFS if I wanted it, but it currently has Samba, because it is easier and works better.
So in conclusion, I'm not sure what your point is? Doesn't NetApp support anything except NFS?