mount(8) and the linux usability disaster

 "mount", as a utility, is not defined by POSIX.  I don't know if it has been defined by a previous version of POSIX, or what versions of Unix, back when versions of Unix were specified, had it defined.  As a traditional Unix user, I would like it to tell me what  devices are mounted where in the system's filesystem namespace, that thing that starts at "/" and goes from there.

For the currently-running system, then, this would look something like:

/dev/mapper/sda2_crypt on / type ext4 (rw,relatime,errors=remount-ro)

My main quibble with this is that the device Debian are calling "sda2_crypt" is actually the unencrypted map of the underlying device, not the encrypted one as the name suggests.  The FDE, the way this relates to block-device naming, this "mapper" thing, and how it's manipulated, from the user perspective, could all do with some design, and design is not something linux does, but I would still be more or less happy with the above.  The above is not what we get.  The above is not even still on the screen, after all the garbage, dumped there by one proud "developer" after another leaving their mark, has scrolled past:


sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

udev on /dev type devtmpfs (rw,nosuid,relatime,size=32915464k,nr_inodes=8228866,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6587500k,mode=755)

/dev/mapper/sda2_crypt on / type ext4 (rw,relatime,errors=remount-ro)

securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)

cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)

pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)

bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)

cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)

cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)

cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)

cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)

cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)

cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)

cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)

cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)

cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)

cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)

mqueue on /dev/mqueue type mqueue (rw,relatime)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2491)

debugfs on /sys/kernel/debug type debugfs (rw,relatime)

sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)

/dev/sdb1 on /boot type ext4 (rw,relatime)

/etc/auto.direct on /scan0 type autofs (rw,relatime,fd=6,pgrp=19435,timeout=3600,minproto=5,maxproto=5,direct,pipe_ino=628934230)

tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6587496k,mode=700,uid=1000,gid=1000)

gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

This is unacceptable.

Comments

Post a Comment

Popular posts from this blog

the persistent idiocy of "privileged ports" on Unix

TCP and UDP have ports.  These are 16 bit; there are 65535 or so per IP address. These protocols don't care to differentiate between the ports.  Elsewhere, IANA presumes to operate a process to allocate "well-known" ports in the range 1-1023, "registered ports" in the range 1024-49151, and to reserve the remainder, 49152–65535, for "ephemeral" ports.  The caller end has to have a port, which is how replies get back within the virtual connection, and these are conventionally picked from the ephemeral range by the OS's networking stack. The whole idea of ports is ridiculous, because it allows ISPs to arse around presuming to decide which services they will "not allow".  Anything that allows IPSs to do anything other than shift opaque packets will allow ISPs to meddle and break things, and due to the Law of Meddling, if they can, they will.  I am currently working around an issue with Claro, a pretend ISP, blocking port 5060, allocated to SI
Read more

google is giving more and more 500 errors

Image
Total state capture and moral bankruptcy are not the only problems facing Google.  They are also giving an increasing rate of 500 Internal Server errors.  This is the sort that means they've messed up, but not in a way that they should have messed up.  On the other hand, they have drawn a lovely picture of a robot falling apart. Today's example is from Google Calendar under calendar.google.com.  I was trying to make an appointment, and now I'm doing this. I remember, in 2018, a friend trying to convince me that 500 Internal Server Errors no longer happened, or if they did it was my fault, and that they hadn't seen any for years, and some other things.  They assured me that they would love to see screenshots of such a rare specimen, which I bored them with for a while.  That friend happens to be a Google employee. Well, there are plenty of others posting about Google Calendar on twitter today, including screenshots of 500 Internal Server errors, so I doubt this one is en
Read more

Guernsey Waste in incorrect bag-rejection horror May 6th, 2024

Image
The rubbish collection folk at my new place seem pickier than at other places on Guernsey. Last week, they removed some card packaging that I'd included in the card and paper (plastic) clear bag, and left it on the lane.  This week, they have attached a rejection label entitled "Polite Notice".  Just like modern software-engineered error messages (see attached tag "extremely_general_error_handling"), this does not give a specific reason why the bag was rejected, but instead lists miscellaneous possible "reasons", leaving the victim guessing, or perhaps trying to follow a process of elimination. In this case, some possible reasons, which the label does not claim to be exhaustive ("was most likely because ..."), and of which none apply, are: (i) "did not have the required payment sticker" -- no, I applied to 90 litre sticker; or  (ii) (a) "too heavy" -- no, I estimate it was 3kg, and I easily supported the bag's weight o
Read more