3 ms·

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 othe

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
        Thank you for the explanation. The implementation details and the history are both interesting, but again - completely irrelevant to the question of "am I running out of disk space". Having thought of your suggestion again (df should hide irrelevant mounts), I think it would be unfortunate. I might have legitimate reasons to check on my tmpfs mounts (e.g. as you suggested, a stupid program dumping cruft into /tmp). Changing df also doesn't help clean up my Grafana dashboard. Again, I think the root cause of the problem lies somewhere between exposing implementation details to the user, and layering on more uninvited complexity. Between a bunch of Linux boxes I have at hand, /run, /run/lock, /run/wrappers, /run/user/1000 (and /run/user/1001, 1002...), are all separate mount points. If /run is already a tmpfs mount point, why does /run/lock have to be one as well? The mount flags are pretty much identical. If uid 1000 shouldn't be able to deny uid 1001 the ability to write to their XDG_RUNTIME_DIR, why not implement some form of quotas? I'm sure there are good answers to all of these questions, but my main point still stands - even when this information is relevant, it's being drowned in the noise.

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
        Thank you for the explanation. The implementation details and the history are both interesting, but again - completely irrelevant to the question of "am I running out of disk space". Having thought of your suggestion again (df should hide irrelevant mounts), I think it would be unfortunate. I might have legitimate reasons to check on my tmpfs mounts (e.g. as you suggested, a stupid program dumping cruft into /tmp). Changing df also doesn't help clean up my Grafana dashboard. Again, I think the root cause of the problem lies somewhere between exposing implementation details to the user, and layering on more uninvited complexity. Between a bunch of Linux boxes I have at hand, /run, /run/lock, /run/wrappers, /run/user/1000 (and /run/user/1001, 1002...), are all separate mount points. If /run is already a tmpfs mount point, why does /run/lock have to be one as well? The mount flags are pretty much identical. If uid 1000 shouldn't be able to deny uid 1001 the ability to write to their XDG_RUNTIME_DIR, why not implement some form of quotas? I'm sure there are good answers to all of these questions, but my main point still stands - even when this information is relevant, it's being drowned in the noise.