util-linux VS gimp

> 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.

GIMP: C, not C++

GIMP - https://gitlab.gnome.org/GNOME/gimp

GIMP

How are they implement? https://gitlab.gnome.org/GNOME/gimp https://github.com/figma

As u/schumaml said already, we have an issue tracker: https://gitlab.gnome.org/GNOME/gimp/

The former might be something you want to report as an issue at https://gitlab.gnome.org/GNOME/gimp, with the XCF file used for your cover image - or a mockup exhibiting the same issue - attached.

As Gimp is open source, I already had a look in the source code but it's written in C, which is different enough from C++ or C# that I have a rather difficult time understanding it, at least in terms of project structure. I'm pretty sure I found the handling of the tool itself in gimpoperationcolorize.c but I don't know where to go from here.

> Gotta be real, Gimp's not that far off from just one guy (https://github.com/GNOME/gimp/graphs/contributors)

GitHub only shows people with an email address linked to a GitHub account in that chart; the last time I checked it was 4 or 5 people working on it regularly, which is still a very small team (none are working on it full-time) so your point still stands (it's a point I've made myself a few times before when people compare GIMP to Photoshop or the like).