Login
Newsletter
Werbung

Thema: Debian GNU/Linux 10.1 und 9.11 freigegeben

10 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Bert am Di, 10. September 2019 um 05:50 #

Es ist noch viel schlimmer. ;-)

Debian 10 Buster schafft es nicht, eine etwas ältere Radeon-Karte für FullHD anzusteuern (6450). Sparky schafft das. Also die Buster-Variante. Wer LXQt oder KDE Plasma nutzen möchte für einen FullHD-Monitor, sollte besser mit dieser Distribution beginnen. Oder
etwas anderem
.

Ich finde das aktuelle LXQt sehr interessant. KDE Plasma sollte man m.A.n. auch nicht nutzen, wenn man weniger wie 3GB Hauptspeicher hat. KDE geht zwar inszwischen mit dem Hauptspeicher etwas genügsamer um, aber KDE cached so wahnsinnig viel, und saugt deswegen reichlich Speicher an sich. Weshalb man mit 2GB oder weniger besser LXQt nutzen sollte.

Buster selber ist schon ganz okay. Aber es ist leider immer noch der Selfmade-Bastelbaukasten, wenn man eine Desktop-Distribution sucht. Gefühlt wird der Abstand zu Ubuntu auch eher größer, wenn ich mir die Versionen unterschiedlicher Programme anschaue. Das fällt sehr gut bei KDE Plasma auf. Und da ist es dann doch ein "Killerkriterium". Eine jetzt schon veraltete KDE-Version fünf Jahre am Leben zu halten - alle Achtung, da hat man sich aber was vorgenommen! Ob die dafür genügend Manpower haben? Ich habe meine Zweifel.

  • 0
    Von Ghul am Di, 10. September 2019 um 06:57 #

    Eine jetzt schon veraltete KDE-Version fünf Jahre am Leben zu halten - alle Achtung, da hat man sich aber was vorgenommen! Ob die dafür genügend Manpower haben? Ich habe meine Zweifel.

    Gibt's bei Debian eigentlich irgendwo eine Gruppeneinteilung, wo man sehen kann, wie viele Debianentwickler an der Pflege der Pakete von bestimmten Desktop Environments arbeiten?

    Also so ne Art n Debian Entwickler gucken, das Gnome gescheit unter Debian läuft. Und m Debian Entwickler gucken, das KDE gescheit unter Debian läuft. usw.

    • 0
      Von klopskind am Di, 10. September 2019 um 12:24 #

      Kurz: Ja, die gibt es.

      Mögen Sie die lange Version? Oder schaffen Sie das eigenständig zu recherchieren?

      • 0
        Von Ghul am Mi, 11. September 2019 um 02:39 #

        Ich möchte die lange Version. Danach habe ich ja auch gefragt.

        • 0
          Von klopskind am Mi, 11. September 2019 um 14:02 #

          Nun, ohne Anspruch auf Vollständigkeit gebe ich Ihnen ein paar Anhaltspunkte für weitergehende Schritte:

          Mit Internetsuchen nach Wortgruppen wie etwa "debian desktop", "debian teams", "debian gnome maintainers", "debian gnome team" oder "debian qa gnome" ("gnome" entsprechend ersetzen) kommen Sie direkt oder indirekt auf die jeweiligen Wikis der Teams, deren QA Seiten oder auf eine Liste aller Debian Teams, welche Sie in gängigen Browser per Strg+F durchsuchen können.

          Von dort kommen Sie direkt oder indirekt auch auf die QA-, Salsa-Schnittstellen, Fehlerberichtseiten, Mailinglisten oder die Paketseite samt Angabe der Maintainer, worüber Sie wieder auf die QA- & Fehlerberichtseiten, Mailinglisten oder die Entwicklerinformationen samt Verweis zum Quellverzeichnis landen können.

          Die changelogs der Debianpakete, die commit logs der Quellverzeichnisse und die Mailinglisten, könnte man nach Beitragenden durchsuchen.

          Am praktischsten finde ich die Gruppenübersicht in der Debian Infrastruktur namens Salsa. Dort können Sie nach einschlägigen Namen wie GNOME, KDE, Xfce, LXQt, MATE, Cinnamon, i3 usw. suchen. Es werden die Anzahl der Gruppenmitglieder angezeigt. Nach Klick auf die jeweilige Gruppe und dann auf "Members" werden in Listenform weitere Details präsentiert. Reichen die?

          Hinweis: Noch nicht jedes Projekt ist auf Salsa umgestiegen, soweit ich weiß. Da muss man sich dann alternativ behelfen (Ansätze siehe oben). So könnte man die ganzen Browserschnittstellen der Debianinfrastruktur nutzen, um andere Teams, Pakete, Maintainer, Quellverzeichnisse, Mailinglisten zu finden.

          Falls Sie dennoch Fragen haben, können Sie sich ja gerne zurückmelden.

          p.s.: Eins würde mich dennoch interessieren: Trauen Sie es sich nicht zu, selbstständig zu recherchieren?

          • 0
            Von Ghul am Do, 12. September 2019 um 02:53 #

            Danke, hab's gefunden.

            Für den, den es auch interessiert, hier der Link:
            Qt KDE Team Debian

            Mit 26 Mitgliedern ist das allerdings leider recht klein für so ein großes Projekt. Zumal da noch Qt usw. zusammengelegt ist.

            p.s.: Eins würde mich dennoch interessieren: Trauen Sie es sich nicht zu, selbstständig zu recherchieren?
            Die Frage ging ja überwiegend an Debian's KDE Enthusiasten, da ging ich davon aus, dass die die Frage gleich beantworten können.

            • 0
              Von klopskind am Do, 12. September 2019 um 10:47 #

              Ja klar, die Ressourcen sind in diesem Umfeld sehr rar. Was haben Sie erwartet?

              Aber welche vergleichbare Distribution hätte an dieser Stelle "mehr" zu bieten als Debian? Etwa Distros, die Ihren Fokus auf KDE/Qt legen? Welche wären das? Kubuntu, KDE neon, KaOS, Chakra Linux, Q4OS, Netrunner, Mageia, OpenMandriva, ROSA, Slackware(?), openSUSE(?), ...?
              Davon sind Kubuntu, KDE neon, Q4OS und Netrunner direkte oder via Ubuntu indirekte Derivate Debians, sowie KaOS und Chakra Abkömmlinge von Arch Linux. Die Entwickler jener Distributionen, die sich um KDE/Qt kümmern, helfen oftmals auch in der Paketierung in den jeweiligen Upstream-Distros mit, sodass diese Downstream-Distros in der Regel weniger menschliche Ressourcen zur Verfügung haben.

              Beispiel an aktuellen, personellen Überschneidungen:
              - Kubuntu/Debian: Jonathan Riddell & Simon Quigley

              Über die jeweilige absolute Anzahl effektiver Arbeitsstunden, die in der Paketierung einer jeden Distro stecken, können wir nur spekulieren. Auch bedeutet dabei Quantität nicht immer auch Qualität, womit sich ohne tiefergehende Erfahrungen nur schwerlich belastbare Urteile über die einzelnen Resultate bilden lassen.


              Sieht die Situation anderer DEs für Linux wesentlich besser aus? Ich denke nicht, außer vielleicht für GNOME.

    0
    Von Andy_m4 am Di, 10. September 2019 um 10:59 #

    Eine jetzt schon veraltete KDE-Version fünf Jahre am Leben zu halten - alle Achtung, da hat man sich aber was vorgenommen! Ob die dafür genügend Manpower haben? Ich habe meine Zweifel.
    Genau das ist das Problem, bei Distributionen die feste Releasezyklen haben.
    Man muss immer wahnsinnig viel Aufwand betreiben, um alte Versionen zu pflegen. Manchmal nimmt einem das Projekt selbst ab, wie beim Firefox wo es halt den Firefox ESR als long-term-Version gibt.
    Aber oft ist das eben nicht der Fall.

    Und man braucht im Optimalfall Maintainer, die sich ähnlich gut im Code auskennen, wie die Entwickler.
    Besonders tückisch kann das halt z.B. beim backporten von Security-Fixes sein.

    Außerdem bindet das alles Ressourcen.
    Und nicht zu guter Letzt rennt man auch schnell mal in Probleme bei Upgrades.
    Bei kleinen Versionswechseln können Probleme auftreten. Es sind dann aber meist vereinzelte kleine Probleme die sich leicht und schnell lösen lassen.
    Beim großen Upgrade hast Du schnell mal eine Vielzahl größerer Probleme.

    Ich versteh den Bedarf an größeren Releasezyklen. Aber auch das ist halt nicht ohne Probleme.

    Vielleicht ist es gar nicht so verkehrt, wie es FreeBSD macht. Dort hat man ein Basis-System was auch im typischen Releasezyklen aktualisiert wird. Und darauf aufsetzende Applikationen aus der Ports-Sammlung sind üblicherweise "Rolling" und damit dicht am Upstream.

    Und das funktioniert in der Praxis sehr gut.

    • 0
      Von klopskind am Di, 10. September 2019 um 12:47 #

      Zum letzten Absatz sollte man allerdings Folgendes erwähnen:

      1. Man muss bei FreeBSD auf dem "Desktop/Laptop" ggü. Linux andere bzw. weitere Einbußen hinnehmen - Stichwort Qualität, Aktualität und Breite der Hardwareunterstützung, Ausreizung von Energisparmechanismen, nochmals erhöhte Kompatibilitätshürden zu üblichen Anwendungen oder Performance-/Featureeinschränkungen (teils durch durch technische Eigenheiten von Linux und in Erweiterung Windows/macOS und/oder Unachtsamkeit der Entwickler von Drittsoftware bzgl. der Portierbarkeit.

      2. Auch wenn die Softwareabdeckung über das Ports/PKGng-System von FreeBSD vorbildlich ist, ist derzeit immer noch kein aktuelles TeXLive verfügbar. Der Prozess diesbezüglich zieht sich schon lange hin - leider.

      Ich habe schon häufiger mit FreeBSD als Alternative für den Desktop geliebäugelt, bin aber immer wieder von der Idee abgekommen. Jedenfalls überrascht es mich immer wieder, wie viel im FreeBSD-Lager gestemmt wird (klare Verwaltungsstrukturen, ernstzunehmendes und kompetentes Sicherheitsteam (reaktiv, leider weniger proaktiv à la OpenBSD) mit informativen Sicherheitsankündigungen, solider Infrastruktur, Ports/PKGng), obwohl zu Debian, Ubuntu, Fedora, openSUSE, RHEL vergleichsweise wenig Ressourcen zur Verfügung stehen. Und die teilen sich auch noch die Entwicklung/Pflege des Basis-Systems.
      Der monolithischere Entwicklungsansatz der BSDs ist offenbar wesentlich effizienter und konsistenter, vor Allem wenn es um grundlegende/weitreichendere Änderungen am Basis-System oder im Ports-Baum geht.

      • 0
        Von Andy_m4 am Di, 10. September 2019 um 15:40 #

        1. Man muss bei FreeBSD auf dem "Desktop/Laptop" ggü. Linux andere bzw. weitere Einbußen hinnehmen
        Ist nicht falsch was Du sagst. Aber das war gar nicht mein Punkt.
        Es ging nicht darum zu sagen: Nimm FreeBSD und alles wird besser.
        Sondern: So wie es dort gehandhabt wird, scheint es nicht so schlecht zu sein. Unabhängig davon, das es in der Konkreten Umsetzung auch da und hier Stolpersteine wegen Personalmangel usw. gibt.

        Jedenfalls überrascht es mich immer wieder, wie viel im FreeBSD-Lager gestemmt wird
        Das stimmt. Die vorhandenen Resourcen werden sehr effizient eingesetzt. Evtl. ist das aber zumindest teilweise auch eine Folge des Resourcenmangels.
        Wenn Du 1 Mio Euro hast, dann spielt es kaum eine Rolle ob Du jetzt 10.000€ oder 11.000€ für ne Sache ausgibst.
        Wenn Du nur 100€ hast, merkst Du den Unterschied zwischen 10€ und 11€ schon eher.

        Der monolithischere Entwicklungsansatz der BSDs ist offenbar wesentlich effizienter und konsistenter, vor Allem wenn es um grundlegende/weitreichendere Änderungen am Basis-System oder im Ports-Baum geht.
        Natürlich gibt es da sicherlich mehr Optimierungsmöglichkeiten wenn man ein System quasi aus einer Hand entwickelt.
        Aber es ist meiner ansicht nach vor allem eine Mentalitätsfrage.

        Wenn man bei BSD irgendein Problem hat oder eine neue Funktion einbauen möchte, dann setzt man sich zusammen und überlegt sich eine gute, nachhaltige und sich auch gut ins System einfügende Lösung.
        In der Linux-Community (die sehr viel heterogener ist) arbeiten mehrere Gruppen unabhängig voneinander an einer Lösung. Auch noch vielleicht mit dem Druck die ersten zu sein und vor dem Konkurrenten etwas bieten zu können. Deswegen hat man für viele Probleme oft mehrere Lösungen, die sich sicher auch in einigen Punkten unterscheiden aber halt auch oft Gemeinsamkeiten (damit quasi auch Arbeiten doppelt gemacht werden) haben. Wenn sich dann von zehn Lösungen eine als "gut" durchsetzt, haben halt 9 Teams letztlich umsonst gearbeitet. Oder es existieren dauerhaft mehrere Lösungen für ein Problem nebeneinander, was ja auch zusätzlicher Pflegeaufwand bedeutet.

        Der Unterschied ist jetzt natürlich etwas plakativ dargestellt. Natürlich läuft bei Linux nicht alles planlos. Genauso wie bei den BSDs immer alles wie geplant läuft. Aber so in der Tendenz ist das halt schon so, das Du da einen solchen Mentalitätsunterschied hast.

Pro-Linux
Gewinnspiel
Neue Nachrichten
Werbung