3 ms·

I think we are saying the same thing. By disk, i meant disk I/O which is the main practical purpose of the tool. Of course, Linux being Unix, a raw disk is a fi

I think we are saying the same thing. By disk, i meant disk I/O which is the main practical purpose of the tool. Of course, Linux being Unix, a raw disk is a file, so is /dev/null. Of course a file can be everything, which is a kind of the point of Linux. But that doesn't change the fact that 'dd' is for disk (or file) I/O. Also please don't argue semantics, it leads nowhere. But that's not the main point. The main point is the Rust coreutils version of dd is slow. I highly doubt it's impossible to write an implementation in Rust that's as fast as the C one. But the Rust community needs to invest time and energy into finding why that's the case and fixing it. Until that happens the broader Linux community is right to push back on adopting it.

linsomniac 15d ago
>But the Rust community needs to invest time and energy into finding why that's the case and fixing it. As I said in my post, the rust coreutils team HAS fixed this in 0.11. It's just that Ubuntu 26.04 is stuck on the older one. Shipping a coreutils that is version 0.8 in an LTS release seems like an interesting choice.
- torginus 15d ago
  Sorry I didn't see your post. But I guess that shows another weakness of Ubuntu's model of versioning. You can't fix a bug if they don't merge. They have their own bugtracker (and so does every distro?) so you, Mr Dev have to deal with angry users not only on your Github Issues page, but on every distro's own bugtracker as well, and will have to perpetually support whatever old version they decided to shit (times X distro). Does that mean BTW that they'll keep shipping the same broken dd for the next 2(4) years?