I would love to just be able to have a stable package base where nothing changed for years except security updates, and have special repos for things that needed to change (like firefox or chrome). Eg, like what Ubuntu does with their distro and PPAs.

I personally hate the concept of a rolling distro, which is what the ports tree really is. Except for the things I care about, I don't want random stuff changing out from under me.

Some ports upgrade 15 years ago failing led me to rage-install Linux and run Linux on my desktop for 10 years because I just didn't have the time to deal with upgrade failures and X not working. Thankfully, now that we have ZFS boot environments (making rolling back easier), I'm back running FreeBSD. But just 2 days ago, I was left with a non-function system when a pkg upgrade renamed "startkde" to startplasma-x11 or something, and it took me nearly an hour to work out that it wasn't the nvidia driver crapping out, it was just that my 'exec startkde' in my .xsession was failing.

(Yes, I'm aware of the quarterlies, but that's about 8x too much change for me).

I ran into that same issue with startkde being renamed.

However, that's my fault for not reading the release notes beforehand. I wasn't frustrated with FreeBSD. I was frustrated with myself for not reviewing those release notes. Spending 5-10 minutes checking out those notes would have saved me the hour spent troubleshooting that problem. Now I always read the release notes before running updates/upgrades/etc. As a bonus, it's good for discovery of new/updates features.

IMO, OSS documentation is one of the major areas where there's a large gradient when it comes to quality. When there are projects like FreeBSD and OpenBSD that write good documentation, it's definitely worth it to take advantage of it.

I believe the issues you (and I) have had with ports are not fundamental issues with ports, which is to say that they are actually illegal changes in release repositories and would have been reverted if called out during development and testing.

Always go back and read the UPGRADING document if you encounter something like this in the future. It will save you a lot of time.

You should use Ubuntu LTS if a major release every 6 months is too much for you.

That's my entire point. With FreeBSD ports, we have a rolling release. When I ran Ubuntu, I did run LTS. I could not care less about having the latest KDE. I'd actually be about 100x happier with the KDE from 10 years ago

Why not use this?

[1] http://trinitydesktop.org/

Nice, KDE before it jumped the shark. Sadly, there is no FreeBSD port or pkg for it.

Not sure which of those specifically you're referring but from a benchmark done in Jan 2019, Clear Linux has a decent lead over *BSD https://www.phoronix.com/scan.php?page=article&item=dfly-fre...

I would not put too much weight into those benchmarks. Those micro-benchmarks are useful to detect performance regressions between commits in a same system, not to compare different systems. Aggregating micro-benchmarks is even less sensible.

A better type of benchmark is the more realistic stuff TechEmpower does, but they only test web frameworks, not OSes.

There's a number of fundamental problems with Phoronix benchmarks; one of them is building software in a wrong way (using vanilla sources, without neccessary patches), and often simply measuring compiler and not the operating system itself.

"Das Balkenspiel ist schlechter Stil."

"The bargraph game is lame."

edit: To expand on this, there is/was one person who tried to tackle this in a meaningful way.

[1] https://web.archive.org/web/20070607182125/http://www.coyote...

The bitrotten remains of this can be found here: [2] https://github.com/Acovea/libacovea

I'm aware of academic research regarding HPC and superoptimizing, but no one has applied that to generalized distro testing, so far. (At least not in public.)

I think this should be a hook in some reproducible build system.

But everyboody seems to have caved in against the complexity explosion this would involve. And build times.

OpenOffice, Firefox, Chrome, KDE, Gnome....the HORROR!

> using vanilla sources, without neccessary patches

Why is that a problem? From a 3rd benchmark point of view testing the official tarball is the most relevant point to test for a Linux using audience. Different distros has different patches. Some don't even patch the software.

Because upstream often uses defaults that are fine for Linux, but not necessarily anything else. That’s why one should use official ports/packages, instead of hacking things together like its ‘90s.