Fedora Linux 40 Looks To Replace iotop With iotop-c

[geearf]

htop introduced disk usage meters as a separate screen some time ago. Version 3.0.3 if I had to guess based on the changelog.

I never realized that, thank you!

edit: actually with this I don't know if I'll need any iotop anymore. Is there the same for network? Currently I use bandwich for that.

[RealNC]

Is there a way to see on which storage device I/O is actually happening? I have three of them, and just seeing an overall number doesn't mean much to me. I'd like to see the numbers for each storage device.

[cynic]

Is there a way to see on which storage device I/O is actually happening? I have three of them, and just seeing an overall number doesn't mean much to me. I'd like to see the numbers for each storage device.

have you already tried `atop` ?

[JEBjames]

Michael

Typo

"alternative the the common iotop program" should be "alternative to the common iotop program"

[Jumbotron]

iotop-ada

There...fixed it for everyone. The speed of C and Rust. Safer than C. As safe as Rust. Easier to read and maintain than either one.

[Nth_man]

iAs safe as Rust.

Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates.
Developed at the Georgia Institute of Technology, Rudra is a static analyzer able to report potential memory safety bugs in Rust programs. Rudra has been used to scan the entire Rust package registry and identified 264 new memory safety bugs.

CVEs (Common Vulnerabilities and Exposures) in Rust programs:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

"If I programmed in Rust, would I need a sound static analyzer?
Yes, the advantages of a sound static analyzer are needed for reasons that are similar to those in the C or C++ case. A C++ borrow checker (or a Rust one) does not bring the aforementioned advantages."

[S.Pam]

I never realized that, thank you!

edit: actually with this I don't know if I'll need any iotop anymore. Is there the same for network? Currently I use bandwich for that.

There is just overall network tx/rx of the system. At least my htop doesn't have network meters per process.

[Eberhardt]

Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates.

Which just proves the point that we need safe Rust. It's not surprising that unsafe Rust leads to memory safety issues because it deliberately disables most compiler checks to give programmers more freedom. Somehow people don't understand that difference.

[stormcrow]

Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates.
Developed at the Georgia Institute of Technology, Rudra is a static analyzer able to report potential memory safety bugs in Rust programs. Rudra has been used to scan the entire Rust package registry and identified 264 new memory safety bugs.

CVEs (Common Vulnerabilities and Exposures) in Rust programs:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

"If I programmed in Rust, would I need a sound static analyzer?
Yes, the advantages of a sound static analyzer are needed for reasons that are similar to those in the C or C++ case. A C++ borrow checker (or a Rust one) does not bring the aforementioned advantages."

from the linked article:

It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement.

"In C/C++, getting a confirmation from the maintainers whether certain behavior is a bug or an intended behavior is necessary in bug reporting, because there are no clear distinctions between an API misuse and a bug in the API itself. In contrast, Rust's safety rule provides an objective standard to determine whose fault a bug is."

And I might add, it also gives people a point to add additional scrutiny once you see the [unsafe] keyword. It's supremely interesting that out of 43k crates, they only found 264 problems worth a closer look. The article didn't follow up to ask how many of the resulting reports were accepted as valid by the crate maintainers (ie: there's a deliberate trade off for some reason - and whether or not there's a memory violation in practice). I'd hate to see how many valid memory safety issues would be discovered in an equal LOC count of C++ libraries. Even after triaging the numbers down to unintended behavior while ignoring only theoretical problems in isolation, I'm sure it'd end up higher.

Yes, just because "written in rust" doesn't carry a guarantee of strict safety. No one that's had formal schooling in computer science believes that as much of the basis of course work deals with how to scientifically verify the correctness of a system (regardless of language used). Rust is a tool (languages are tools as well as your debugger and memory analysis) that's a big step in the right direction. It keeps the foot guns it gives you under tighter scrutiny. Where as assembly, C, C++, and some older languages tend to not only give you a foot gun, they load the gun and cock the hammer as well. In the realm of programming, everyone is a Barney Fife bar none. This is why we have analysis tools like Rudra & Valgrind (with the caveat that false positives are almost always going to occur with any sufficiently complex software), formal verification, logic analysis, various simulators and emulators, profiling tools, and on and on. It's also why even well thought out tools like Ada have restricted constraint sub tooling like Spark - because sometimes even the original guarantees aren't good enough in all domains.

[Nth_man]

[...] unsafe Rust leads to memory safety issues because it deliberately disables most compiler checks to give programmers more freedom.

Mmm... "bugs in a number of packages, including the Rust standard library and the Rust compiler as well as the 30 most popular crates based on their downloads."