Das Debian-Repository ist relativ groß. Man kann das sicher nicht 1:1 anhand der Paketanzahl vergleichen, weil die auch zum erheblichen Teil Software in mehreren Paketen gesplittet haben und so. Aber die haben immerhin fast 60.000 Packages im Repository (bei FreeBSD sinds etwas mehr als 46.000 Ports). Insofern können Linux-Distributionen schon so einigermaßen mithalten. :-)
Wichtiger als die Anzahl ist ja auch die Relevanz. Ein volles Repository nützt einem ja nicht viel, wenn da nur Kram drin ist den keiner braucht. Ich sag nicht, das die Ports nur unnützen Kram enthalten. Man kriegt da sehr viel. Hin und wieder fehlt aber doch was wie z.B. Android Studio.
Insofern: Ja. Die Situation ist nicht schlecht. Aber man muss auch aufpassen, das man das nicht überbewertet.
Sorry, aber Debian kann nicht mal im Ansatz mithalten. Die Pakete sind nicht nur deutlich weniger, und ja Dinge, die man braucht. Sie sind auch für gewöhnlich komplett out of date, selbst wenn man unstable Branches nutzt.
In der Debian und Ubuntu Welt, ist es sowohl als Privatanwender, als auch im professionellen Umfeld üblich, für diverse Software, quasi dem "Unternehmensstack" Third Party Repositories hinzuzufügen. Fast jedes Projekt muss die deshalb bereitstellen. Und das betrifft Basics, wie Postgrest/PostGIS, nginx, Programmiersprachen, etc.
Und was soll unnützer Kram in dem Zusammenhang sein? Es wird sich niemand den Aufwand machen ein Port zu maintainen, ohne einen Nutzen zu haben und FreeBSD ist ziemlich aktiv darin obsolete Pakete zu entfernen.
Ein weiteres Problem ist wie du ja schon gesagt hast, dass man Paketzahlen nicht so einfach vergleichen kann. Debian dröselt Dinge teilweise extrem auf, da werden einzelne Pakete in 5 zerteilt, weil es ja sein könnte, dass man irgendwas nicht haben will (Header Files, Dokumentation oder ganze Teile der Software).
Zudem hat Debian eine Geschichte darin Dinge kaputtzupatchen und das betrifft nicht nur RNGs. Immer mal wieder funktioniert von Debian gepatchte Software nicht und teilweise ist das auch der Grund warum man als Projekt dann extra ein Repository anlegt, damit man Software in einer halbwegs aktuellen Version und wie sie gedacht ist nutzen kann. Das wird auch getan, damit man als Softwareprojekt nicht von debianspezifischen Bug-Reports geflutet wird. Ist ja ganz üblich, dass da dann steht man solle entweder deren Repository nutzen oder selbst kompilieren bevor man einen Bug reported, eben damit nicht was aufkommt, was seit mehreren Jahren gefixed ist oder einfach ein Bug im Debian-Paket ist.
Debian und dessen Abkömmlinge scheiden da deutlich schlechter ab als diverse andere Linuxdistributionen und sind sicher ein Mitgrund, dass Leute meinen sie müssen zu irgendwelchen Hacks greifen um das sinnvoll zu nutzen. Entweder es sind eben zusätzliche APT-Repositories, dann hat man schön mal Konflikte oder das Problem, dass Pakete für das neue Release noch nicht existieren oder man nimmt am Server Docker her, damit man aktuelle Abhängigkeiten für die Software im Unternehmen hat oder man nutzt vorwiegend am Desktop so Dinge wie Snap und Flatpat und sagt dem jeweiligen Softwareprojekt die sollen das bereitstellen, damit man den Murks umgehen kann.
Und ja, jede Software ist nicht drin. Aus unterschiedlichen Gründen. Android Studio ist da ein schönes Beispiel. Trotzdem sehe ich nichts was da auch nur annähernd ran kommt, wenn man nicht eben zum Beispiel APT-Quellen dazuzählt, die aber ihre eigenen Probleme mit sich bringen. Das ist definitiv ein Grund dafür dass Docker als das Allheilmittel gepriesen wird. Damit umgeht man die Probleme des Paketmanagers komplett, hat aktuelle Software, die so verwendet werden kann, wie vom Maintainer gedacht und man hat keine Probleme, dass die hälfte des Systems aus uralten Libraries besteht und deshalb erst wieder nichts richtig funktioniert.
Egal welchen Weg man geht, wenn man so Third Party Hacks/Lösungen nutzt hat man einen nicht unerheblichen Mehraufwand was Maintainance angeht und die Zeit/das Geld bekommt man als Unternehmen nicht wieder.
Darüber hinaus kann man sich wahrscheinlich ganze Wochen an Kosten ersparen, wenn man zum Beispiel nginx mit einem bestimmten Satz aus Modulen braucht. Da helfen einem weder offizielle Docker-Quellen noch third Party Quellen viel, wie die kommen vielleicht mit ihren Patches (sagen wir mal Passenger, das im Rails-Umfeld üblich ist) oder man muss generell selbst was bauen.
Jetzt kann man argumentieren, dass man wenn man auf Linux zugeschnittene Software nutzen möchte oder muss, womöglich erst dort wieder Mehraufwand hat. Und dem stimme ich zu. Wenn man nicht gerade einen Standard nginx/apache, postges, Python/Go/Node.js/Ruby/Perl/PHP... Stack nutzt kann das sein. Aber genau hierum geht's mir. Wenn's auch nur was annähernd vergleichbares in der Linux-Welt gibt hätte ich in manchen Situationen auf Linux gesetzt. Das ist aber nicht der Fall. Da geht die Kosten/Nutzen-Rechnung dann nicht auf.
Hoffe das geht jetzt nicht zu weit off-topic sonst können wir ja wenn du möchtest einen Thread dazu aufmachen.
FreeBSD 13 mit KDE5 läuft und läuft und läuft......
ALSA wurde 1998 eingeführt. Und naja, PulseAudio und PipeWire laufen auch unter FreeBSD und sind so nichts Linux-spezifisches. Und gerade erst vor ein paar Beiträgen wurde FreeBSDs doch eher schlechtes / rudimentäres Soundsystem kritisiert, was ich auch persönlich bestätigen kann. Ich finde z.B. Pipewire auch eines der besten Open Source Projekte der letzten Jahre.