4 ms·

Well, if you're seasoned enough, you start to read df output from right to left. Find the mountpoint you're looking for, read to left to see the stats. When yo

Well, if you're seasoned enough, you start to read df output from right to left. Find the mountpoint you're looking for, read to left to see the stats. When you're managing a storage box, no amount of tmpfs entries can create the noise stated in the blog post. P.S.: If you know the device names like your name, you can quickly skim that list, too.

rollcat 3y ago
I prefer, in this order: 1. For the computing device to do the more reasonable thing; 2. For the computing device to adapt to and serve my needs, not the other way around.
- backendanon 3y ago
  You want the mount points first? In school we were taught to think in what then where order. That's how the df -h command works on Linux, the way most people think. When you want to eat, most of us think what do I want to eat, then where.
- bayindirh 3y ago
  I think Linux is doing the more reasonable thing. The features are implemented with the existing facilities and extended to the bare minimum as required. On top of that the commands are adaptable, and you can always write the tools you need. There are no hidden/forbidden interfaces. I commend BSDs for what they are, but blindly praising any OS is wrong IMHO. Is Linux perfect? Heck no. Is BSDs are squarely better at everything, again no. These are different OSes shine at different things. We use all of them, but they are not that interchangeable.
  - rollcat 3y ago
    My praise is far from blind; OpenBSD lacks a modern filesystem, FreeBSD still uses /usr/local/etc for some configuration, and all of them suffer to a various degree from simply not being x86 Linux with glibc and systemd. What you do get in return though is some sanity. When I type "df -h", what I mean is: "show me the remaining free space on the internal disks and attached media". It's not a big ask for that information to not be littered with half a dozen lines of useless noise?
    - derefr 3y ago
      You have a point, but I don't think you have the point you think you have. It seems like df(1) as a tool should be about showing you "free space, on things where the amount of free space might ever be a concern." (Otherwise you'd just use mount(1)!) So df(1) itself, should be filtering the mounts list for only devices capable of having free space.
      - rollcat 3y ago
        That is exactly my point. But my other point is that keeping things simple (what is /dev/shm? I thought /dev is already a synthetic FS?) helps avoid the problem in the first place.
        derefr 3y ago
        > what is /dev/shm? I thought /dev is already a synthetic FS? /dev/shm is a tmpfs mount. It's not synthetic. It's basically "/tmp but it uses your RAM so it's not essentially-unbounded, so we didn't put it on /tmp because then stupid legacy programs might OOM the kernel." It's mounted under /dev presumably because you can think of "a tmpfs mount" as a system facility for "named shared-memory allocations" — in the same way that e.g. /dev/audio is a system facility, or /dev/random is a system facility. It's a facility that presents itself as a virtual filesystem, but it's still fundamentally a "low level system API" meant for consumption by the systems programmers writing e.g. glibc, rather than something the user is meant to see and browse into as part of the filesystem abstraction. (I believe that /dev/mapper is another thing that ended up under /dev for this reason.) Also, /dev was a synthetic FS for a little while — devfs — but this long post-dates the creation and conventional-ization of these other mountpoints inside /dev. Until 2009, /dev was just a directory in the rootfs, with special-device inodes created manually during rootfs creation with mknod(8). These days, under udev, /dev is once again "just a directory" — just one with a daemon that automatically creates and destroys the special-device inodes in it to match what's actually available on the system.
        rollcat 3y ago

rollcat 3y ago

I prefer, in this order: 1. For the computing device to do the more reasonable thing; 2. For the computing device to adapt to and serve my needs, not the other way around.

backendanon 3y ago
You want the mount points first? In school we were taught to think in what then where order. That's how the df -h command works on Linux, the way most people think. When you want to eat, most of us think what do I want to eat, then where.
bayindirh 3y ago
I think Linux is doing the more reasonable thing. The features are implemented with the existing facilities and extended to the bare minimum as required. On top of that the commands are adaptable, and you can always write the tools you need. There are no hidden/forbidden interfaces. I commend BSDs for what they are, but blindly praising any OS is wrong IMHO. Is Linux perfect? Heck no. Is BSDs are squarely better at everything, again no. These are different OSes shine at different things. We use all of them, but they are not that interchangeable.
- rollcat 3y ago
  My praise is far from blind; OpenBSD lacks a modern filesystem, FreeBSD still uses /usr/local/etc for some configuration, and all of them suffer to a various degree from simply not being x86 Linux with glibc and systemd. What you do get in return though is some sanity. When I type "df -h", what I mean is: "show me the remaining free space on the internal disks and attached media". It's not a big ask for that information to not be littered with half a dozen lines of useless noise?
  - derefr 3y ago
    You have a point, but I don't think you have the point you think you have. It seems like df(1) as a tool should be about showing you "free space, on things where the amount of free space might ever be a concern." (Otherwise you'd just use mount(1)!) So df(1) itself, should be filtering the mounts list for only devices capable of having free space.
    - rollcat 3y ago
      That is exactly my point. But my other point is that keeping things simple (what is /dev/shm? I thought /dev is already a synthetic FS?) helps avoid the problem in the first place.
      - derefr 3y ago
        > what is /dev/shm? I thought /dev is already a synthetic FS? /dev/shm is a tmpfs mount. It's not synthetic. It's basically "/tmp but it uses your RAM so it's not essentially-unbounded, so we didn't put it on /tmp because then stupid legacy programs might OOM the kernel." It's mounted under /dev presumably because you can think of "a tmpfs mount" as a system facility for "named shared-memory allocations" — in the same way that e.g. /dev/audio is a system facility, or /dev/random is a system facility. It's a facility that presents itself as a virtual filesystem, but it's still fundamentally a "low level system API" meant for consumption by the systems programmers writing e.g. glibc, rather than something the user is meant to see and browse into as part of the filesystem abstraction. (I believe that /dev/mapper is another thing that ended up under /dev for this reason.) Also, /dev was a synthetic FS for a little while — devfs — but this long post-dates the creation and conventional-ization of these other mountpoints inside /dev. Until 2009, /dev was just a directory in the rootfs, with special-device inodes created manually during rootfs creation with mknod(8). These days, under udev, /dev is once again "just a directory" — just one with a daemon that automatically creates and destroys the special-device inodes in it to match what's actually available on the system.
        rollcat 3y ago