Da haben alle Pakete im Repository einen offiziellen Maintainer, der für das Paket zuständig und verantwortlich ist. Grundsätzlich gilt der Support für alle Pakete im Repository, es werden theoretisch also alle supported. Sollte das mal nicht passieren, weil der Maintainer z.B. seine Arbeit nicht macht oder ein Paket nicht repariert werden kann, dann kann man das zumindest im Debian Package Tracker einsehen und sich somit darauf einstellen. Man weiß also zu jeder Zeit, welches Paket eine bekannte Sicherheitslücke hat, die noch nicht in Debian gefixt wurde. Für Pakete, bei denen der Support zu wünschen übrig lässt, wird ein neuer Maintainer gesucht und der alte ersetzt oder das Paket entfernt. Letzteres gleiche gilt für Pakete, die nicht reparierbar sind.
Insofern hat man hier in jeder Hinsicht eine wesentlich bessere Grundlage als bei Ubuntu.
Bei Ubuntu ist für die universe und multiverse Pakete keiner zuständig und es gibt auch keinen Paket Tracker, außer vielleicht den allgemeinen Bugtracker, wo man nachsehen könnte, welche jetzt Sicherheitslücken enthalten oder nicht. Der Bugtracker von Ubuntu hat aber das Problem, das da erstens alles mögliche eingetragen wird und zweitens halt nur die Sicherheitslücken als Eintrag drin stehen, die irgendwer mal gemeldet hat. Aktiv getracked auch unter Verwendung von CVE Meldungen, wie bei Debian, werden die Pakete da nicht.
Die halbjährlich erscheinenden STS-Releases oder eine andere Distro. Das Problem betrifft übrigens auch andere Distributionen mit eingefrorenen Paketquellen wie Debian. Auch wenn alle Pakete Sicherheitsaktualisierungen erhalten und die Maintainer schnell alles einpflegen, so lassen sich längst nicht alle upstream gefixten Sicherheitslücken in reine Sicherheitsupdates zurückportieren.
Aus diesem Grund ist die Anzahl der in RHEL/CentOS oder SLE verfügbaren Pakete auch sehr viel kleiner als bei Debian oder Fedora, weil Red Hat bzw. SUSE den Support nicht für jedes noch so exotische Paket garantieren kann. Außerdem gibt es "Minor Releases" bzw. "Service Packs", die dann doch einige Pakete auf eine neue Upstream-Version aktualisieren. Sonst wäre der Aufwand gar nicht zu stemmen.
Es gibt zusätzliche Repositories wie EPEL, RPMFusion und ELRepo, die aber von der Community gepflegt werden, bei SLE gibt es den PackageHub, der Pakete aus openSUSE enthält. Die Pakete in offiziell unterstützt und nicht unterstützt aufzuteilen ist also nichts neues für "LTS-Distros". Der Unterschied: bei Ubuntu sind alle Repos standardmäßig aktiviert und man weiß u.u. gar nicht, das man ein nicht unterstütztes Paket installiert, wenn man das nicht explizit überprüft.
Debian unterstützt theoretisch das ganze Repository, und für jedes Paket gibt es einen Maintainer. Es kann aber sein, dass während der Laufzeit einer Debian-Version einzelne Pakete aus dem Repository plötzlich entfernt (!) werden können, wenn der Maintainer den Support nicht leistet, oder das Paket wird mit einer Markierung versehen, wenn andere Pakete davon abhängen (apt install debian-security-support, dann check-support-status aufrufen). Das kann aber auch dauern, bis das jemand bemerkt.
us diesem Grund ist die Anzahl der in RHEL/CentOS oder SLE verfügbaren Pakete auch sehr viel kleiner als bei Debian oder Fedora, weil Red Hat bzw. SUSE den Support nicht für jedes noch so exotische Paket garantieren kann.
Das liegt einfach daran, weil diese Distris jeweils von einem privatwirtschaftlich agierenden Unternehmen betrieben werden und somit die Unternehmen in der Gewinnzone bleiben müssen.
Bei Debian ist das nicht so, da sind es Freizeitentwickler. Debian benötigt somit nur mehr davon. Daraus folgt dann auch, Debian wird umso besser, je mehr Nutzer es hat. Denn es wird immer mal den ein oder anderen Nutzer geben, der später dann zum Debianmaintainer wird.
Es wäre also im Interesse aller Debianer, dass die Distribution durch bspw. eine bessere Usability Marktanteile gewinnt. Aber das scheinen leider noch nicht alle Debianer verstanden zu haben, weswegen es in den letzten Jahren Marktanteile an Ubuntu & Co abgegeben hat.
Da rennst du bei mir offene Türen ein. Thema proprietäre Firmware, warum nicht das non-free-ISO zum Standard machen (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/)? Wenn man keine Hardware hat, die proprietäre Firmware benötigt, wird diese sowieso nicht installiert, und wenn doch, dann muss man diese sowieso installieren um vernünftig arbeiten zu können. Wer trotzdem keine proprietäre Firmware will, benutzt halt weiterhin das free-ISO.
Nächster Punkt: Paketbau. DEB-(und auch RPM-)Pakete zu bauen ist unnötig kompliziert. Arch Linux macht vor, wie es richtig geht, mit makepkg und den PKGBUILD-Dateien - anhand des umfangreichen Angebots der AURs sieht man, dass die User damit zurecht kommen, man muss sich schon anstrengen, um eine Software zu finden, die *nicht* im AUR ist. Und wenn man etwas mehr Erfahrung hat und sich mehr einbringen will ist es leicht zum Trusted User oder Developer aufzusteigen.
Was also stattdessen nutzen?
Debian Stable.
Da haben alle Pakete im Repository einen offiziellen Maintainer, der für das Paket zuständig und verantwortlich ist.
Grundsätzlich gilt der Support für alle Pakete im Repository, es werden theoretisch also alle supported.
Sollte das mal nicht passieren, weil der Maintainer z.B. seine Arbeit nicht macht oder ein Paket nicht repariert werden kann, dann kann man das zumindest im Debian Package Tracker einsehen und sich somit darauf einstellen.
Man weiß also zu jeder Zeit, welches Paket eine bekannte Sicherheitslücke hat, die noch nicht in Debian gefixt wurde.
Für Pakete, bei denen der Support zu wünschen übrig lässt, wird ein neuer Maintainer gesucht und der alte ersetzt oder das Paket entfernt. Letzteres gleiche gilt für Pakete, die nicht reparierbar sind.
Insofern hat man hier in jeder Hinsicht eine wesentlich bessere Grundlage als bei Ubuntu.
Bei Ubuntu ist für die universe und multiverse Pakete keiner zuständig und es gibt auch keinen Paket Tracker, außer vielleicht den allgemeinen Bugtracker, wo man nachsehen könnte, welche jetzt Sicherheitslücken enthalten oder nicht.
Der Bugtracker von Ubuntu hat aber das Problem, das da erstens alles mögliche eingetragen wird und zweitens halt nur die Sicherheitslücken als Eintrag drin stehen, die irgendwer mal gemeldet hat. Aktiv getracked auch unter Verwendung von CVE Meldungen, wie bei Debian, werden die Pakete da nicht.
Die halbjährlich erscheinenden STS-Releases oder eine andere Distro.
Das Problem betrifft übrigens auch andere Distributionen mit eingefrorenen Paketquellen wie Debian. Auch wenn alle Pakete Sicherheitsaktualisierungen erhalten und die Maintainer schnell alles einpflegen, so lassen sich längst nicht alle upstream gefixten Sicherheitslücken in reine Sicherheitsupdates zurückportieren.
Aus diesem Grund ist die Anzahl der in RHEL/CentOS oder SLE verfügbaren Pakete auch sehr viel kleiner als bei Debian oder Fedora, weil Red Hat bzw. SUSE den Support nicht für jedes noch so exotische Paket garantieren kann. Außerdem gibt es "Minor Releases" bzw. "Service Packs", die dann doch einige Pakete auf eine neue Upstream-Version aktualisieren. Sonst wäre der Aufwand gar nicht zu stemmen.
Es gibt zusätzliche Repositories wie EPEL, RPMFusion und ELRepo, die aber von der Community gepflegt werden, bei SLE gibt es den PackageHub, der Pakete aus openSUSE enthält. Die Pakete in offiziell unterstützt und nicht unterstützt aufzuteilen ist also nichts neues für "LTS-Distros". Der Unterschied: bei Ubuntu sind alle Repos standardmäßig aktiviert und man weiß u.u. gar nicht, das man ein nicht unterstütztes Paket installiert, wenn man das nicht explizit überprüft.
Debian unterstützt theoretisch das ganze Repository, und für jedes Paket gibt es einen Maintainer. Es kann aber sein, dass während der Laufzeit einer Debian-Version einzelne Pakete aus dem Repository plötzlich entfernt (!) werden können, wenn der Maintainer den Support nicht leistet, oder das Paket wird mit einer Markierung versehen, wenn andere Pakete davon abhängen (apt install debian-security-support, dann check-support-status aufrufen). Das kann aber auch dauern, bis das jemand bemerkt.
Das liegt einfach daran, weil diese Distris jeweils von einem privatwirtschaftlich agierenden Unternehmen betrieben werden und somit die Unternehmen in der Gewinnzone bleiben müssen.
Bei Debian ist das nicht so, da sind es Freizeitentwickler. Debian benötigt somit nur mehr davon.
Daraus folgt dann auch, Debian wird umso besser, je mehr Nutzer es hat.
Denn es wird immer mal den ein oder anderen Nutzer geben, der später dann zum Debianmaintainer wird.
Es wäre also im Interesse aller Debianer, dass die Distribution durch bspw. eine bessere Usability Marktanteile gewinnt. Aber das scheinen leider noch nicht alle Debianer verstanden zu haben, weswegen es in den letzten Jahren Marktanteile an Ubuntu & Co abgegeben hat.
Da rennst du bei mir offene Türen ein. Thema proprietäre Firmware, warum nicht das non-free-ISO zum Standard machen (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/)? Wenn man keine Hardware hat, die proprietäre Firmware benötigt, wird diese sowieso nicht installiert, und wenn doch, dann muss man diese sowieso installieren um vernünftig arbeiten zu können. Wer trotzdem keine proprietäre Firmware will, benutzt halt weiterhin das free-ISO.
Nächster Punkt: Paketbau. DEB-(und auch RPM-)Pakete zu bauen ist unnötig kompliziert. Arch Linux macht vor, wie es richtig geht, mit makepkg und den PKGBUILD-Dateien - anhand des umfangreichen Angebots der AURs sieht man, dass die User damit zurecht kommen, man muss sich schon anstrengen, um eine Software zu finden, die *nicht* im AUR ist. Und wenn man etwas mehr Erfahrung hat und sich mehr einbringen will ist es leicht zum Trusted User oder Developer aufzusteigen.