util-linux VS procps

> Again I understand, most people don't seem to care about that, because they were born into cloud culture and have no clue what they are doing in terms of efficiency money/resource-wise.

They have no clue about how computers work, full stop. Sure, they know programming languages, but generally speaking, if you ask them about IOPS, disk or network latency, NUMA, cache lines, etc. they’ll tell you it doesn’t matter, and has been abstracted away for them. Or worse, they’ll say sub-optimal code is fine because shipping is all that matters.

There is certainly a difference between sub-optimal and grossly un-optimized code. Agonizing over a few msec outside of hot loops is probably not worthwhile from an efficiency standpoint, but if it's trivial to do correctly, why not do it correctly? One recent shocking example I found was `libuuid` in its various forms. util-linux's implementation [0] at its most recent tag is shockingly slow in larger loops. I'm fairly certain it's due to entropy exhaustion, but I haven't looked into it enough yet.

MacOS uses arc4random [1] (which for Linux, is in glibc as of v2.36, but you can get it from libbsd-dev otherwise), and it's much, much faster (again, on large loops).

I made some small C programs and a shell runner to demonstrate this [2].

[0]: https://github.com/util-linux/util-linux/blob/stable/v2.40/l...

[1]: https://man7.org/linux/man-pages/man3/arc4random.3.html

[2]: https://gist.github.com/stephanGarland/f6b7a13585c0caf9eb64b...

There are su and runuser in util-linux (GPL-2.0) [1].

[1]: https://github.com/util-linux/util-linux/tree/master/login-u...

>It remained in the "getty" process for some time, well into the {Free,Net,Open}BSD era.

Still there in agetty: https://github.com/util-linux/util-linux/blob/master/term-ut... And, I imagine in other getty implementations.

Huh, I will try this later. Bit confused by the instructions on the Archwiki but I think I can figure it out. Thanks so much for the help. Btw, it seems you were right on what was wrong. Good eyes.

So, this script serves as a pretty good wall replacement (wall will strip all escape/control sequences other than \007, by the way).

The login program (used for terminal logins) is part of the util-linux project: https://en.wikipedia.org/wiki/Util-linux

if anbody actually at Canonical is reading this and wants me (and others) to take snaps seriously, please consider submitting pull requests to some of the core cli tool projects impacted by the way you guys abuse the loop device mechanism. Something simple like the ability to export HIDE_SNAP_MOUNTS=1 that gets picked up by the impacted tools in util-linux (lsblk, mount, blkid, fdisk, etc) and gnu coreutils (du, df) and simply hides the lines related to loop device mounts would go a long way - preferably only the ones added by snap but even an option to hide all of them would be better than nothing.

Pick a different filesystem, or wait for this feature to land in util-linux.

Per https://github.com/opentrack/opentrack/issues/1453 , it looks as though bookworm is affected by the badly-thought-out https://gitlab.com/procps-ng/procps/-/commit/d974f064b5a269fe8bd009d1430d17218aaf07b7

The ps you have on Linux (almost certainly from procps-ng) tries to be compatible with about half a dozen different Unix versions of ps. This is why it has so many different ways of requesting the same information. The output format produced by these methods corresponds to the ways those other pss worked.

FYI sysctl is already implemented in C and it is very legacy at this point: https://gitlab.com/procps-ng/procps/-/blob/newlib/sysctl.c

But not pgrep as it's a binary from procps-ng to find processes by name.

They fixed this like 7 years ago.