1. 35
  1.  

  2. 17

    Knowing german, I read this way differently than the title is trying to convey initially.

    1. 8

      For the non-german folks here, du is the german personal-pronoun for you so the title reads: Like you but more intuitive :)

      1. 2

        It’s a bit more complex than that: German retained the T-V distinction, which means it has two forms of singular second person pronoun, one for people you’re close to and one for people you’re not close to. Sie is the pronoun for people you’re not close to, du is the one for people you are close to. It also has two forms of the second-person plural pronoun, ihr for people you’re close to and, again, Sie for people you’re not close to.

        1. 2

          Still it translates to the same and I don’t know of any way to preserve that intent in English.

          I always thought the du/Sie distinction makes German very formal but it also seems very ingrained in the culture. The distinction was also in Swedish but it disappeared and is so rare in Denmark I can’t remember when I saw it last. Something I couldn’t imagine happening in Germany.

          1. 3

            Sweden is such a small country that a reform of this type, made in the heady days of the 60s, got traction very easily.

            As a bank cashier in the late 80s I’d sometimes refer to customers using “ni” and occasionally get pushback from people of the “68 generation”.

      2. 5

        Also “dust” means dork or idiot in Norwegian.

      3. 10

        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 du sometimes 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”.

        1. 6

          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 du and other tools like it frequently, I was instantly hooked on dust (ha!).

          1. 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?”

          2. 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 -h for “human readable” units, like 100G or 89k, or with -b for “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 like awk to 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.

          3. 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!

          1. 8

            For what it’s worth, sort has a mode for sorting “human” numbers with the SI-ish suffixes: -h or --human-numeric-sort. Not to say the other reasons for dust aren’t good ones!

            1. 1

              I’ve been doing this kind of thing for more than twenty years, and I’m still learning things like this :)

            2. 2

              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 of du.

            3. 4

              I think @nebkor answers it very well.

              Intuitive is a subjective thing. But here are the reasons I made the tool :

              1. I don’t want to remember that -h is for human readable output.
              2. I don’t want to have to sort and head things. (you need to remember to use -h with sort too)
              3. 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.

            4. 4

              You may also find “duc” interesting/useful — http://duc.zevv.nl/

              It needs pre-indexing (duc index /path) separately from browsing. There’s (at least) three front-ends for browsing the resulting database: via ncurses, X/GUI, or a web front-end.

              1. 2

                This is nice, thanks. It could probably replace about 90% of the cases where I use ncdu. For really big nested trees the interactive ncurses interface of ncdu is nice, but much of the time I don’t actually need that.

                1. 1

                  Like this, but it is a little bit slow:(

                  1. 1

                    Do you only ever use du on one and only one directory? If not, does it take less time using du to look into multiple directories?

                  2. -8

                    @bootandy What exactly is interesting here that you decided to share that with us?

                    1. -3

                      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

                      1. 5

                        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).

                        1. 3

                          du is part of POSIX. coreutils, which includes du, would not accept output format change.

                          1. 2

                            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.

                            1. 0

                              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.

                              1. 4

                                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.

                                1. 0

                                  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.)