emlop VS gentoo

My oldest remaining emerge.log started in 2007. That desktop went thru some hardware upgrades, that you can spot them in the build time logs. Would love to see [emlop](https://github.com/vincentdephily/emlop) s -st -gy and emlop s -gy -e gcc from your machine.

Genlop is indeed slow, but qlop is comfortably fast, and emlop is even faster. I encourage you to check them out.

Happy to help. The size and number of packages is what's important, not whether you're installing or updating. I tend to only use emerge -j2 if I have 10 or more packages that can each build in a minute or less. You can always stop an emerge and restart it with emerge -rO -jN if you feel you made the wrong choice. You can use emlop p to get an estimate of how long the current emerge will take (current release is a bit outdated, I suggest installing from git: cargo install emlop --git https://github.com/vincentdephily/emlop).

Emlop is much faster than genlop, gives better estimates, has fewer bugs, and more features.

That's a huge variation in merge times, things are usually a bit more predictable than this. They might just get progressively slower as new package versions get bigger.

On the positive side, it inspired me to implement display of the current merge phase in emlop:

emerge -rOp|emlop p can tell you how long the currently running merge will take, if it's something you've merged on that machine before. You could also suspend your laptop instead of shutting it down.

emlop

While genlop works, I highly recommend emlop instead, as it is much faster (emerge -rOp | genlop -c is unusably slow) and featureful. The version in the GURU overlay is outdated at the moment, so either get it from the moltonel overlay or using cargo install emlop.

There are a handful of commits that take especially long, for example cc8fa62c which updates many lines of a 5Mb test file. I've observed similar issues with the vim import. It seems that large diffs slow pijul down greatly, import time is not linear to diff size.

Whilst Firefox may support hardware video decoding, Mesa since March 2022 disables patent encumbered codecs by default[1], and distributions such as Fedora and OpenSuse do not explicitly enable these patent encumbered codecs to avoid possible legal problems. Even Gentoo (built from source code by the user) requires the user to explicitly enable a USE flag (proprietary-codes) to use patent encumbered codecs.[2]

The thought process is that AMD, NVIDIA, Intel and the likes are not providing a patent license with their hardware.[3] They are instead just supplying part of an overall system that together with operating system kernel, display manager software, video player software, etc allows the decoding and encoding of patent encumbered video files. Open source software projects and distributions are concerned they'd be found to be infringing patents by enabling a complete solution out-of-the-box. Hence they put some hurdles in place so that a user has to go out of their way to separately piece together the various parts to form a complete system capable of encoding and decoding patent encumbered codecs.

[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15...

[2] https://github.com/gentoo/gentoo/commit/1265a159743d7f07185a...

[3] https://lists.fedoraproject.org/archives/list/[email protected]...

Thank you! I don't live in git and this helps! Normally under gentoo I shouldn't have to. This actual git https://github.com/gentoo/gentoo (as opposed to the gentoo browser view) plus this "checkout the commit" should get me much further. ... And probably deserve some space in the gentoo docs.

You choose - here's a list

(pending) gentoo/gentoo #30595 sys-cluster/kubescape: new package, add 2.2.6

profiles/targets/desktop/make.defaults: