Login
Newsletter
Werbung

Thema: Ubuntu 18.04.2 LTS erschienen

4 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Tamaskan am Sa, 16. Februar 2019 um 14:51 #

Debian schließt den Support für bestimmte Pakete explizit aus, z.B NodeJS und diverse Webkit-Browser. Am besten das Paket debian-security-support installieren - das beinhaltet ein Skript, das überprüft, ob nicht unterstützte Pakete installiert sind. apt führt das Skript auch automatisch aus, sodass man mitkriegt, falls die Unterstützung nachträglich für ein Paket eingestellt wurde.

Es kann bei Debian auch passieren, dass einzelne Pakete nicht gepflegt werden, weil der Maintainer sich nicht kümmert/verschollen ist, irgendwann werfen die das Paket auch raus, VirtualBox z.B gibt es zurzeit nicht in stretch, nur über stretch-backports, worüber man die Version aus buster/testing bekommt. NitroShare wäre auch so ein Paket, dass verwaist ist, aus Testing ist es schon rausgeflogen, in Sid und Stable liegt noch eine alte Version.

Was du über Ubuntu gesagt hast, stimmt. Für einen Server sollte man nur main benutzen. Auch bei openSUSE habe ich die Erfahrung gemacht, das man überprüfen sollte, ob ein Paket auch in SLES angeboten wird, dann kümmert sich eine SUSE-Mitarbeiter um die Patches und die werden dann nach openSUSE weitergereicht, ansonsten kommt es auch auf die Community an.

CentOS/RHEL/Scientific pflegen all ihre Pakete richtig gut, besser als allen anderen Distributionen. Dafür haben sie insgesamt recht wenig Pakete im Vergleich z.B mit Debian. Für den Desktop würde ich daher Fedora empfehlen, die updaten auch den Kernel, sodass man auch bei brandneuer Hardware nicht bis zum nächsten Release warten muss.

[
| Versenden | Drucken ]
  • 0
    Von Ghul am Sa, 16. Februar 2019 um 18:35 #

    Es kann bei Debian auch passieren, dass einzelne Pakete nicht gepflegt werden, weil der Maintainer sich nicht kümmert/verschollen ist, irgendwann werfen die das Paket auch raus, VirtualBox z.B gibt es zurzeit nicht in stretch, nur über stretch-backports, worüber man die Version aus buster/testing bekommt.

    Ja, das kann vorkommen, am Ende sitzt da halt immer ein Mensch und wenn der keinen Bock oder keine Zeit mehr hat, dann ist er nicht der richtige Mann für die Pflege eines Pakets.
    Dann sollte man ihn gegen jemand anderen ersetzen, wenn man denn kann und genug Manpower dafür hat. Und letzteres könnte bei Debian, beachtet man die Anzahl der Pakete, ein Problem sein.
    Die Gesamtsituation ist bei Debian aber dennoch besser als bei Ubuntu.

    Und interessanterweise scheint Jessie und Testing auch besser gepflegt zu werden als Stretch, was mich zu der Hypothese bringt, dass viele Leute bei Jessie geblieben sind oder gleich zu Testing gewechselt sind.
    Sicherlich ist auch da die Verkürzung des Releasezyklus verantwortlich.
    Wenn dem so ist, dann dürften zukünftig ab Jessie gerechnet, die gerade Versionen von Debian besser unterstützt werden, als die ungeraden. Mit Buster stable dürfte die Lage also wieder besser werden.

    CentOS/RHEL/Scientific pflegen all ihre Pakete richtig gut, besser als allen anderen Distributionen. Dafür haben sie insgesamt recht wenig Pakete im Vergleich z.B mit Debian.

    Das ist gut zu wissen und für den Server daher sicher eine gute Sache. Auf dem Desktop brauche ich aber die Auswahl von Debian.

    Bezüglich Fedora habe ich zwar gutes gehört, konnte mich anderseits aber damit noch nicht anfreunden.

    [
    | Versenden | Drucken ]
    0
    Von Ghul am Sa, 16. Februar 2019 um 18:40 #

    Debian schließt den Support für bestimmte Pakete explizit aus,
    ...
    apt führt das Skript auch automatisch aus, sodass man mitkriegt, falls die Unterstützung nachträglich für ein Paket eingestellt wurde.

    Ja, diese Politik ist besser als bei Ubuntu, weil man so wenigstens weiß, was definitiv keine Fixes mehr bekommt und dann kann man sich darauf einstellen.
    Bei Ubuntu ist das bei den universe und multiverse Paketen nämlich gar nicht klar, zwar schließt Canonical den Support für diese Pakete generell aus, aber da die Community mitfixen kann, kann man nie genau wissen, woran man da jetzt bei einem spezifischen Paket jetzt genau ist. Wird es gefixt oder nicht, das ist einfach völlig unklar und sehr schwammig.
    Debian sagt wenigstens, das was regelmäßig gefixt wird, hat einen Maintainer und bei den Maintainern, die nicht mehr zuverlässig fixen, dafür haben wir das Skript wo der Support dann als derzeit nicht supported markiert ist.
    So etwas ist viel besser, weil man dann bei Bedarf auch weiß, welches Paket gerade ein Problem hat.

    [
    | Versenden | Drucken ]
    0
    Von klopskind am Mo, 18. Februar 2019 um 10:30 #

    Genau so sieht es nämlich aus.

    Fakt ist doch, dass es der Zeit fähiger Personen bedarf. Das geschieht in den allermeisten Fällen jedoch nur, wenn jemand tatsächlich die Verantwortung für ein Projekt oder eine Software übernimmt. Das sagt auch Urgestein und Dinosaurier Poul-Henning Kamp: "Quality happens only when someone is responsible for it." (wirklich lesenswerter Artikel).

    Natürlich ist das in Community-Distributionen so eine Sache. Bei Debian gehört nach Richtlinie zu jedem Paket mindestens ein Maintainer. Allein das bedeutet aber bei Weitem nicht, dass Maintainer (und Upstream) jederzeit wirklich fähig und verantwortungsvoll mit der Aufgabe der Betreuung ihrer Pakete/Software/Projekte umgehen.

    Sicherlich gibt es im Debian-Projekt eine Menge fähiger und verantwortlicher Entwickler und Maintainer. Man kann sich allerdings nicht so sicher sein. Im Allgemeinen muss man davon ausgehen, dass die nötige Arbeit in deren Freizeit verrichtet wird. Nur vereinzelt sind die Personen tatsächlich in einer Position (beruflich als Support oder Beratung tätig), die deren übernommene Verantwortung auch signifikant belohnt, was leider immer noch kein Garant für Qualität bedeutet.

    Wo Community-Distributionen in der Regel ebenfalls schwach aufgestellt sind, ist die übergreifende Koordination und Kommunikation, da dort die Hierarchien sehr flach sind.
    Als Beispiel für eine Community-Distribution, die das meiner Meinung nach vergleichsweise guten Eindruck macht, sei hier das FreeBSD-Projekt genannt. Dort verfügen die Entwickler mit dem einzelnen Quelltextverzeichnis einen besseren Überblick über das gesamte Projekt und dessen Entwicklung. Das hilft natürlich nichts für die Pakete und Ports, sondern nur für's Basissystem. Wenigstens ist es leichter neue Paketierungsrichtlinien einheitlicher zu verwalten und umzusetzen. Ich bin immer wieder beeindruckt, mit wie wenigen Personen die FreeBSD-Ports so effizient verwaltet werden.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung