Re: [TUHS] Abstractions

Jon Steinhart wrote in <202102151956.11FJuRIh3079869(a)darkstar.fourwinds.com>: |Was thinking about our recent discussion about system call bloat and such. |Seemed to me that there was some argument that it was needed in order to |support modern needs. As I tried to say, I think that a good part of the |bloat stemmed from we-need-to-add-this-to-support-that thinking instead |of what's-the-best-way-to-extend-the-system-to-support-this-need thinking. | |So if y'all are up for it, I'd like to have a discussion on what abstrac\ |tions |would be appropriate in order to meet modern needs. Any takers? Proper program exit integer status codes. Now that "set -o pipefail" is a standardized feature of POSIX shells all that is needed are programs which properly handle errors and also report that to the outside. This is very hard, especially when put over existing codebases. But also new code. For example i use BTRFS (with a long term perspective to switch to ZFS, because of restartable snapshot sends, and also because of ZFS encrypted partitions to replace my several encfs-encrypted on-demand storages, these now can even be shared in between FreeBSD and Linux), (i use it at all because it ships with the Linux kernel, can be compiled-in, is copyright-compatible, that is i wanted to test that coming from over two decades of ext2/3/4 on Linux and of course the default of FreeBSD, and i really drive the entire thing with subvolumes, only the EFI boot partition is truly separate), anyhow, receiving snapshots can fail but the snapshot counts as having been properly received, and no exit status whatsoever will report the failure. (At least in my practical experiences.) Easy scriptability with proper (also meaning automatically interpretable) error reports. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)