-
you had a problem with the output format of du, so you rewrote the whole thing in a different language and your version is 4x slower
free software exists for the exact reason that people can improve upon it and change the bits they don’t like
don’t get me wrong, i like the final product, it looks very nice and human friendly
it just feels like you wrote it in rust for the sake of it, instead of trying to achieve a better design or fix some flaw deeply rooted in the fundamental design of the existing implementation
by doing so you threw away all the work that others made available for free, and ended up with something with sub-par efficiency
-
I did write it rust for the sake of it. I like working in rust I dislike working in c.
I also contributed several fixes to the rust port of du in coreutils. The rust port of du is also a lot slower than the original c du. I do not know why. This is something I want to look in to without starting a c vs rust speed flamewar.
I guess to me du and dust are different tools and adding the dust features to du wouldn’t be accepted (the point of dust is to remove the need for - h flag and to autosort for you).
-
-
Not to mention that large, mature projects, like coreutils, are not super easy to augment with functionality like what dust provides, not to mention the social challenges of actually contributing a change to such a project.
The whole assumption of @izabera’s comment, that people need to not write whatever software they want and instead only contribute to existing projects, is incredibly stuck up its own ass.
-
I don’t think that’s what izabera is saying. What is argued is that it is better to contribute to du than to write dust. It is like saying helping the poor is better than enjoying the beach; that does not mean people shouldn’t enjoy the beach.
When you hear such things, replying that people can do whatever they want, while true, is unproductive. My reply is more akin to pointing out why donating to certain charity will not actually end up helping the poor.
-
When you hear such things, replying that people can do whatever they want, while true, is unproductive.
izabera’s comment in the first place is unproductive. I had some asshole say the same thing to me in the past. They can bugger off. Free software very clearly does not exist just for the sake of small iterative improvement. There are many reasons and benefits of free software, and picking a single one and lambasting folks for it is… Well… @nebkor got it right: stuck up its own ass.
-
Yeah… I disagree with lambasting, but I still think it is a fair game to discuss strategic aspect. Say, if your goal is to help users, is it better to contribute to existing popular C implementation, or to start Rust one? As bootandy already said that the goal was to write Rust, and since that goal can’t be fulfilled by contributing to C implementation, it is a moot. But if the goal was to help users, it would be relevant.
As another example, the goal of Mozilla is much closer to “help users” than to “write Rust”. So the strategic aspect of what is the best way to achieve that goal, whether it is to work on existing C++ codebase or to rewrite it in Rust, is a very real question. For another, if someone’s goal is to, say, improve the security of world’s computational infrastructure, it is a very real question whether it is best to improve C++ or to work on Rust. And if and only if two people agree on the goal, it is legitimate to argue by one to the other that “you are wasting your time with Rust”. (I believe this is roughly why Daniel Micay is now working on Copperhead OS instead of Rust. I tend to agree that if one’s goal is to improve security, Rust is currently not the best bet. I work on Rust because my goal is not to improve security.)
-
-
-
-
-
-
Question:
What about it is more “intuitive”? Programmers tend to use that term a lot and assume that it will be clear what they mean. I use
dusometimes but not often. It’s not clear to be what about Dust is more intuitive. When you have time, I’d suggest updating that first paragraph to explain more fully rather than hoping folks understand what you mean by “intuitive”.-
Great point. @bootandy is the author of the tool, and was gracious enough to accept some of my PRs for it a little while back (my laptop is named “djin”, if you look closely at the readme).
I’m posting this here because it’s the point of jumping off for what follows; I’ll probably add it to an issue or PR or something, but really, Andy’s the author and has the best ideas about what it’s for. But as someone who happens to use
duand other tools like it frequently, I was instantly hooked on dust (ha!).-
I use du and friends when I notice, for some reason (hopefully because my eye caught a number that was not yet too small), that a partition is not as empty as I thought it should be, or something like that; maybe I’m really just curious. But the fundamental mystery to be solved is, “What is eating all my disk?”
-
du has a number of ways of showing you what it finds, in terms of disk consumption, but really, there are only one or two ways you invoke it: with
-hfor “human readable” units, like 100G or 89k, or with-bfor “bytes”. The former is used for a quick survey of a directory with a small number of things in it, and the latter for when you have a bunch and need to sort the output numerically, and you’re obligated to either further pass it into something likeawkto turn bytes into the appropriate human-friendly unit like mega or gigabytes, or you just do some rough math in your head and use the ordering to sanity check. Then once you have the top offenders, you recurse down into the largest one and repeat the process until you’ve found your cruft or gems and can move on. -
dust assumes that’s what you wanted to do in the first place, and takes care of tracking the largest offenders in terms of actual size, and showing them to you with human-friendly units and in-context within the filetree. Huzzah!
-
-
-
Those are awesoe reasons for using
dust. I think something like that should be front and center. It would certainly get my attention as a only occassional user ofdu.
-
-
I think @nebkor answers it very well.
Intuitive is a subjective thing. But here are the reasons I made the tool :
- I don’t want to remember that -h is for human readable output.
- I don’t want to have to sort and head things. (you need to remember to use -h with sort too)
- Once I have found a big directory I usually want to look inside it straight away to see why it is so big.
I’ll add some more text to the reader.
-
-
Fixing up my sql tutorial so it worked better on mobile and adding a few more questions. http://www.windowfunctions.com/
Trying to finish an update for my regular expression game, since people have been mentioning that it’s too easy.
Already got rid of 1000 (out of 1900) lines of code over the last few days.
Your project homepage link gives me a 403 from the github README.
^^ Well, I am still working on it. I’m going to set the homepage up as soon as I have a more or less stable version I can properly document.
Until then, the old README might help.