Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Debian 9.0 »Stretch« freigegeben

59 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Andre am So, 18. Juni 2017 um 13:29 #

Danke an die Entwickler - Debian ist seit Jahren eine tolle GNU/Linux Distro :)

  • 0
    Von Abnicker am So, 18. Juni 2017 um 17:43 #

    Toll? Bestimmt nicht, dafür aber mit der heißen Nadel gestrickt. LVM unter aller sau, Lightdm zerlegt sich im Betrieb von zwei Monitoren nach einer gewissen Zeit selbst, nach einen banalen Update steht die Kiste einfach ca. 2 Sekunden nach dem grub2 seinen Dienst gemacht hat und nichts geht mehr. Nach der Installation von xorg und XFCE geht keine Tastatur, weder am Notebook noch per USB angeschlossen oder per Bluetooth. Das sind alles Dinge die reproduzierbar sind, im Netz bereits zum Teil in Form von gemeldeten Bugs seit 2016 bestehen.Sorry, so geil ich das Debian Ökosystem finde, aber das hier geht mal gar nicht. Dann die Geschichte mit mySQL - professionell wäre es gewesen durch ein Script beim Upgrade zu fragen ob MariaDB eingeführt werden soll. Der User/Admin hätte durch ein ja bzw. nein die Richtung bestimmen können wo es mit der Installation lag geht.

    • 1
      Von HCIJra am Mo, 19. Juni 2017 um 07:55 #

      Sei froh, gibt es überhaupt eine Möglichkeit ein Upgrade zu fahren. Bei CentOS/RH ist das überhaupt nicht möglich!

      Ich habe gestern Nachmittag 47 Server (keine produktiven!) einem Upgrade unterzogen. Bis auf ein paar Kleinigkeiten, hatten wir überhaupt keine Probleme damit. Manchmal liegt das Problem eben halt zwischen Tastatur und Bildschirm... :huh:

      • 0
        Von Abnicker am Mo, 19. Juni 2017 um 14:51 #

        Es gibt keinen offiziellen Upgradeweg aber es gibt ihn. Zumal der fast unsinnig ist, bei 10 Jahre Pflege.

        Zitat: Manchmal liegt das Problem eben halt zwischen Tastatur und Bildschirm...

        Passt nicht ganz, das was ich anspreche sind echte Bugs die du so nicht gelöst bekommst. Zumal ich persönlich nichts gegen Debian habe, trotzdem soviel Platz muss für Kritik sein.

0
Von MySQL-User am So, 18. Juni 2017 um 16:31 #

Ich nutze ja kein Debian. Und wenn ich mir die Release-Notes durchlese, weiß ich auch warum. MySQL durch MariaDB zu ersetzen ist mMn. ziemliche Frechheit, wenn man sich ganz bewusst für MySQL entschied. Es gibt nämlich immer noch Tools die nur MySQL zusammenarbeiten und nicht mit MariaDB (zB. MySQL-Workbench).

  • 0
    Von Pittiplatsch der Liebe am So, 18. Juni 2017 um 16:37 #

    Es steht Dir doch völlig frei MySQL auch weiter zu nutzen oder neu zu installiere.
    Im übrigen haben andere Distributionen diesen Schritt teilweise um Jahre vorweg genommen. Hast Du bei SUSE auch so gemosert?

    • 0
      Von MySQL-User am So, 18. Juni 2017 um 19:55 #

      Soweit ich weiß belässt SUSE die Einstellungen. Wenn du MySQL gewählt hast, ist nach einem Upgrade auch MySQL geblieben. Somit gibt es für mich kein Grund zu Mosern.

      • 0
        Von HCIJra am Mo, 19. Juni 2017 um 07:57 #

        UND genau das ist auch bei Debian so!

        • 0
          Von MySQL-User am Mo, 19. Juni 2017 um 08:44 #

          Nein, laut Release Notes von Debian und Pro-Linux nicht.

          • 0
            Von jueshire am Mo, 19. Juni 2017 um 13:24 #

            Die Release Notes nennen die Standard-Applikationen. Wenn Du upgradest und MySQL installiert hattest, wird auch MySQL upgegraded und nicht MariaDB.

            • 1
              Von MySQL-User am Mo, 19. Juni 2017 um 14:04 #

              Nein.

              Laut Debian wird es durch MariaDB ersetzt, siehe veröffentlichunshinweise für Stretch

              Punkt 2.2.3 MariaDB ersetzt MySQL

              Das steht überall im Netz.

              • 1
                Von Missjö am Di, 20. Juni 2017 um 10:59 #

                Finde dieses Gebaren auch nicht so dolle. Aber ein Problem der Debianer scheint nun mal der glühende Fanatismus zu sein, welcher keine pragmatischen, für den Endanwender nachvollziehbare und gangbare Lösungen zulässt. Ich erinnere mich noch gut an die Story um die CdrTools. Plötzlich bekam man von den Debian-Leuten eine völlig verkrüppelte, schnell zusammen gezimmerte und kaum funktionale Ersatzlösung untergeschoben. Es folgte der Iceweasel & Co.-Quatsch. Nun diese Kiste, die mich aber nicht mehr tangiert.

                Bis Woody habe ich Debian gerne verwendet aber im Anschluss waren mir pragmatische Lösungsansätze wichtiger.

                0
                Von jueshire am Di, 20. Juni 2017 um 14:41 #

                Du kannst unter https://www.debian.org/distrib/packages#search_packages gern nachschauen: MySQL ist in den Repositories.

    0
    Von Pschikologe am So, 18. Juni 2017 um 17:18 #

    Eine Frechheit ist einzig dein Kommentar.

    Der Schritt war schon lange überfällig, zum einen wegen Oracle und zum anderen weil MariaDB inzwischen in vielen Bereichen deutlich weiter ist als MySQL.

    Warum sollte MySQL Workbench mit MariaDB funktionieren? Oracle hat doch kein Interesse daran einen Konkurrenten zu unterstützen. Gibt andere Tools für MariaDB. Kannst dich bei Oracle beschweren.

    Wenn du tatsächlich immer noch MySQL anstelle von MariaDB haben willst, dann installiere es halt einfach nach. ist doch kein Problem.Hauptsache motzen!

    0
    Von Fishermen am So, 18. Juni 2017 um 17:19 #

    Nimm doch einfach Oracle SQL.
    Da ist alles besser dokumentiert und Support ist käuflich.
    Welch ein Segen für dich.

    Und du hast keine Probleme mehr mit dem bösen MariaDB und MySql-verwandten Umgebungen.

    Ich jedenfalls bleibe bei Montys MariaDB.

    Das ist halt wie Fishermen's.

    Ansonsten ist Debian Stretch ein Genuß.

    Achso.
    Ja, Polaris-Gpu wird unterstützt.

    ;)

    0
    Von Abnicker am So, 18. Juni 2017 um 17:56 #

    Du hast ein Stück weit Recht. Das eigentliche Problem ist doch das Ersetzen, nicht das Angebot MariaDB bereitzustellen, das ist ja ok. Tatsache ist doch das gerade in Unternehmen mySQL sehr weit verbreitet ist. Aufgrund der Tools durch Drittanbieter ist es nicht immer möglich eine Migration nach MariaDB durchzuführen. Da interessiert es auch nur zweitrangig das MariaDB bessere Einstellungen in Sachen Sicherheit hat. Ganz bitter das ganze.

    • 0
      Von Horrorclown am So, 18. Juni 2017 um 18:28 #

      Die Migration auf PostgreSQL ist hier in vollem Gange. Ich will nicht behaupten dass MySQL oder MariaDB schlecht sind, im Gegenteil, sind beides super Datenbank(systeme), aber sobald irgendjemand anfängt ein Fork von irgendetwas anderem zu bauen (was MariaDB mittlerweile nicht mehr ist, die Syntax wurde jedoch beibehalten, siehe mysql_secure_installation) fängt es langsam an lächerlich zu werden, denn die Argumente, dass der Fork sicherer, stabiller, oder was auch imemr wären, ist schlicht eine Lüge, denn es kommt immer auf den Nutzungszweck an und wie die Umgebung aufgebaut ist. In unserem Fall bietet MariaDB eher Nachteile.

      0
      Von MySQL-User am So, 18. Juni 2017 um 20:02 #

      Genau das meine ich. Neuinstallation kritisiere ich nicht, sondern das Upgrade. Es verursacht unnötig Probleme. Falls ich mich für MariaDB entscheide, dann wann ich es denke und nicht weil es der Distributor wünscht.

0
Von Horrorclown am So, 18. Juni 2017 um 18:19 #

Und wieder einmal ein neues Release wo nicht alle Pakete durch den Security Support abgedeckt sind, beispielsweise webkit oder gtk ...
Schade Debian, ich hatte gehofft dass sich endlich mal etwasändert, aber so werde ich wohl doch lieber zu BSD gehen ...

  • 1
    Von zxy am So, 18. Juni 2017 um 21:15 #

    Die nicht supporteten oder supportbaren Khtml- und Webkit-Engines (Chromium ist in Debian ja davon nicht betroffen, wohl aber u.a. Epiphany-Browser (i.e. das "Web"-Etwas von Gnome3), Midori, Qupzilla und Konqueror) müssten halt allesamt aus Debian Stable entfernt werden. Nur traut sich das Debian offenbar nicht, weil das bedeuten würde, dass man wichtige Teile von KDE Plasma und Gnome3 nicht mehr ausliefern könnte. U.U. würden dann z.B. auch Gimp oder Evolution fehlen.

    Man sieht, dass der Umstieg vieler freier Softwareprojekte auf die Webkit-Engine vor einigen Jahren und die damalige Abkehr von der Gecko-Engine (weil diese ja schon damals offenbar zu oft aktualisiert wurde, weshalb man immer wieder seine eigenen Anwendungen anpassen musste) in sicherheitstechnischer Hinsicht eine einzige Katastrophe erzeugt hat: Die meisten Linux-Distros sind nun allesamt mit unsicheren Browser-Engines vollgepackt.

    • 0
      Von Andre am So, 18. Juni 2017 um 21:19 #

      ...unglaublich...

      • 0
        Von zxy am So, 18. Juni 2017 um 21:39 #

        Es gibt Hoffnung. Fedora und einige Rolling Release-Distros sind davon nicht betroffen.

        Zudem ist man ja lernfähig.

        Siehe z.B. hier:
        https://bugzilla.redhat.com/show_bug.cgi?id=1375809

        Hatte Debian in Wheezy noch die Webkitgtk-Abhängigkeit zu Webkit 1.0.0 (!) als Strict Dependency enthalten, hat sich das mittlerweile geändert. Hoffentlich kommt ab Gimp 3.x niemand mehr auf die Idee, die ganze unselige Geschichte mit einer etwas moderneren Webkitgtk-Engine zu wiederholen, die würde mit der Zeit genauso u.a. in Debian vor sich hinverrotten.

        Wer nun aber anfangen möchte, über Debian herzuziehen, der sollte seine gerade benutzte Distro einmal auf derartige Abhängigkeiten abklopfen. Einfach in der Paketverwaltung nach Webkit suchen und dann einmal versuchen, diese Engines zu deinstallieren (falls kein Sicherheitssupport für diese bestehen sollte). Aber bitte erst schauen, was dann sonst noch so deinstalliert würde.

        Debian hat dieses Problem schon verstanden, nur deshalb weist man so vehement auf Firefox und Chromium als sichere Webbrowser in Debian hin.

        • 0
          Von Andre am So, 18. Juni 2017 um 21:45 #

          ich sehe sowas eher als fundamentales gnu/linux sicherheits-problem in den meisten distros.
          es wird immer von hoher sicherheit gesprochen, wenn man jedoch tiefer ins system schaut wird es schnell gruselig.

          https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

          • 0
            Von Andre am So, 18. Juni 2017 um 21:47 #

            gleiche frage gilt wenn Firefox ESR zb nicht mehr offiziell weiter gepatcht wird. Ich habe schlichtweg kein gutes Gefühl wenn dann die Distros selbst anfangen sicherheitsupdates manuell nachzufriemeln. M.E. gehöhrt dann eher die nächste ESR-Version Distroseitig angeboten.

            • 0
              Von tijuca am Mo, 19. Juni 2017 um 13:08 #

              Und was machst Du bei Paketen die keine ESR oder Security Fixes anbieten?

              Die Aussage man nehme bitte die nächste neue (größere) Version funktioniert leider nur sehr selten. Neue Versionen bringen in der Regel auch neue Abhängigkeiten mit sich deren Auswirkungen durch das Securityteam nicht prüfbar sind.
              Aber einen oder mehrere Diff(s) für einen Security Fix einspielen der sich relativ leicht aus den Upstream Commits holen lässt ist das deutlich kleinere Übel. Für neuere Versionen gibt es Backports, hier ist aber auch der Admin verantwortlich dafür, dass es auch dem Updaten wieder rund läuft.

              Ich kann jeden der sich über die Problematik mit Security Fixen im Bezug zu Debian beschwert ganz herzlich dazu einladen mal an einem Sprint teilzunehmen und zu versuchen seine Meinung dort zu vertreten. Man wird schnell merken das es kein schwarz/weiß gibt sondern ein vielschichtiges Bunt mit einer klaren konservativen Linie. Im Mittelpunkt steht der Benutzer und die Stabilität.

              • 0
                Von Andre am Mo, 19. Juni 2017 um 16:18 #

                Hallo,
                mir ist das Problem durchaus bewusst.

                Der Browser ist jedoch m.E. im Desktop-Betrieb mit die für Angriffe empfindlichste Komponente. Ich frage mich wie man hier ernsthaft von neueren ESR-Versionen SecurityBugs auf alte ESR-Versionen sinnvoll Backporten will ohne ggf. neue Security-Probleme zu öffnen.

                Ich fänd es gut wenns für Debian eine einfache Möglichkeit gäb wenn Firefox+Thunderbird in zwei Versionen Verfügbar wäre. Einmal in der Stablen Version wie bisher, und einmal als "mozilla-firefox-new" Package, welches immer ein offiziell supportetes ESR-Package beinhaltet.
                Ich weis das das insbesondere bei internen+externen Libs und Plugins etc. ggf regressionen nach sich ziehen würde.

                Hier geht es um die Desktop-Sicherheit. Wir wissen inzwischen alle das Geheimdienste und Co die Sicherheit massiv zu unterminieren versuchen - daher sollten solche eventuellen Bugs/Probleme nicht mehr unter den Teppich gekehrt werden.

                >> Für neuere Versionen gibt es Backports
                Meine Erfahrung mit Debian vor einigen Jahren: Backport für Firefox bzw IceWeasel aktiviert. Firefox/Iceweasel wurden aktualisiert. Thunderbird nicht - Der Debian-Howto gefolgt - es musste ein anderer Backport-Server aktiviert werden - es wurden andere im system inkompatible libs ausgetauscht - bullshitt-bingo-scheisse - wir reden hier von einem "Desktop" - da möchte ich mir frickelkram ersparen.
                Und wer garantiert mir dann das die Backports regelmaessig gewartet werden? - wohl niemand mehr.

                Dann fahr ich bald besser Firefox/Thunderbird der Distro runterzuwerfen und mir in /home/foobar/bin/ eigene aktuelle Binarys abzulegen
                Übrigens - unter Ubuntu14.04 oderso gabs in diesem Fall (manuell installierter Firefox) reproduzierbare adobe-flash-crashes - wenn man das flash-video auf vollbild gestellt hat, sonst nicht - Frickelei hoch 3!

                • 0
                  Von tijuca am Mo, 19. Juni 2017 um 21:57 #

                  Firefox und Thunderbird gibt es nicht im Backports Repository sondern "nur" über die Securityupdates. Dies ist eine Besonderheit da beide Pakete im eigentlichen Sinne neue Versionen sind und somit eigentlich nicht in den Security Zweig gehören.

                  Du hast scheinbar ein anderes Verständnis von Mozilla ESR Versionen wie mir scheint. Es gibt da nicht mehrere Versionen, es gibt immer nur eine und diese Version ist die von Mozilla unterstützte Version. Insofern benutzt Du diese oder lässt es. Diese wird übrigens alle 6 Wochen sehr regelmäßig veröffentlicht.

                  Welche zwei Versionen soll es denn geben? Es gibt beim Firefox die ESR Versionen die faktisch nur Security und Regression Updates, beim Thunderbird gibt es in Anlehnung der Firefox ESR Version einen ähnlichen Releasezyklus. Und zusätzlich gibt es noch die normalen Entwicklungsreleases. Vom Securityteam werden aber nur die ESR Version vom Firefox bzw. an dessen Anlehnung die Thunderbirdversion eingepflegt. Für mehr Sachen sind auch keine Ressourcen da. Wer trotzdem Bleeding Etch benutzen will kann gerne auf Versionen von Upstream zurück greifen. Wer bei der Pflege der Pakete (und nicht "nur" einen Fix) helfen will ist gerne eingeladen mitzuwirken. In den letzten fünf Jahren ist dies aber nicht einmal in vorgekommen.

                  Und noch etwas was Du vermutlich nicht gerne hören wirst, Backports gehört genauso wie contrtib oder non-free nicht zum offiziellen Debian, das es das doch gibt ist eine freiwillige Zusatzleistung der Maintainer. Man kommt nicht umhin sich mal mit dem Wesen und der Philosophie von Debian zu beschäftigen bevor man Kritik üben will.

                  Ach ja, Ubuntu != Debian

                  • 0
                    Von Andre am Di, 20. Juni 2017 um 00:09 #

                    beschäftige Dich einfach mit den Release Zyklen von Firefox ESR und Du wirst feststellen das in 1-2 Jahren neuere Firefox ESR versionen von Mozilla betrieben werden als die jetzt in Debian 9 mitgelieferte. Die Frage ist ob dann noch die dann veraltete Firefox ESR version sinnvoll gepatcht werden kann, oder ob es nicht sinnvoller wäre ein neues Package für die dann aktuelle Firefox-ESR version anzubieten.
                    m.e wäre dann aus sicherheitssicht ein upgrade auf firefox esr 58.x sinnvoller - und zwar offiziell und nicht via 'freiwilligem' backport gefrickel.

                    ---------

                    Schön das du die aus Sicherheitssicht fragwürdigen Backport-Qualität hier bestätigst.

                    ---------

                    Das Ubuntu != Debian ist mir nichts neues - das Beispiel zeigt mir dennoch das Linux nach wie vor frickelig im Desktopbdtrieb sein kann.

              0
              Von zxy am Mo, 19. Juni 2017 um 21:28 #

              In Debian Wheezy LTS ist das nun so, hier wird nun Firefox 52.x ESR ausgeliefert:
              https://lists.debian.org/debian-lts-announce/2017/06/msg00019.html

              Debian-Entwickler möchten nicht unbedingt das Rad neu erfinden, zudem, wenn man sich mit Upstream ganz gut versteht.

            0
            Von zxy am So, 18. Juni 2017 um 22:01 #

            Ja manchmal wird es wirklich gruselig.

            Ich wollte gerade Midori 0.5.11 in Debian Stretch nachinstallieren. Synaptic blendet mir dann als zu installierende Abhängigkeit u.a. libwebkitgtk-1.0.0 ein.

            Was soll man dazu noch sagen? Ein Midori-Browser wie derjenige in Debian, der libwebkitgtk-1.0.0 zum Webbrowsen benötigt, muss aus Sicherheitsgründen komplett aus dem Main-Repo entfernt werden, zusammen mit libwebkitgtk-1.0.0.

            Da haben wir das Webkit-Problem. Absolut grausig.

    0
    Von Fritz am Mo, 19. Juni 2017 um 07:31 #

    Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.

    • 1
      Von tijuca am Mo, 19. Juni 2017 um 13:15 #

      Eine derartige Liste gibt es nicht da das Security keine Ausnahmen macht was Softwarepakete angeht. Wenn CVEs bekannt werden dann ordnet das Security Team dies den Paketen zu und bittet zunächst die Paketmaintainer die CVEs zu fixen. Sollte des Paket aber keinen Maintainer besitzen dann springen gerne auch mal andere Maintainer ein und erst ganz zuletzt werden manchen Pakete durch das Security mit Fixes versorgt.

      Gibt es für ein Paket keine Fixes und die Sicherheitsprobleme sind gravierend wird das Paket aus der Distribution entfernt.

      0
      Von zxy am Mo, 19. Juni 2017 um 21:37 #

      Die gibt es. Du musst das Paket debian-security-support nachinstallieren und danach check-support-status in einem Konsolenfenster ausführen. Etwaige installierte und nicht betreute Pakete werden dann angezeigt.

      Ich erhalte unter Debian Stretch folgende Ausgabe:
      joeuser:~$ check-support-status
      Eingeschränkte Versorgung mit Sicherheitsaktualisierungen für eines oder mehrere Pakete

      Leider war es nötig, die Versorgung mit Sicherheitsaktualisierungen
      für einige Pakete einzuschränken.

      Davon sind die folgenden auf diesem System gefundenen Pakete betroffen:

      * Quelle:qtwebkit-opensource-src
      Einzelheiten: No security support upstream and backports not feasible, only for use on trusted content
      Betroffenes Binärpaket:
      - libqt5webkit5:amd64 (installierte Version: 5.7.1+dfsg-1)

      • 0
        Von tijuca am Mo, 19. Juni 2017 um 22:06 #

        Nun ja, dies heißt aber immer noch nicht das es keine Fixes geben wird. Der Hinweis weißt darauf hin das es von Upstream keinen Support für dieses Paket gibt. Andere Distributionen haben dieses Problem auch und Fixes machen dann gerne mal die Runde.

    0
    Von Fritz am Mo, 19. Juni 2017 um 07:32 #

    Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.

    0
    Von Fritz am Mo, 19. Juni 2017 um 07:32 #

    Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.

    • 0
      Von Horrorclown am Mo, 19. Juni 2017 um 11:00 #

      Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.

      0
      Von Horrorclown am Mo, 19. Juni 2017 um 11:00 #

      Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.

      0
      Von Horrorclown am Mo, 19. Juni 2017 um 11:00 #

      Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.

      0
      Von Horrorclown am Mo, 19. Juni 2017 um 11:01 #

      Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.

      0
      Von Horrorclown am Mo, 19. Juni 2017 um 11:01 #

      Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.

    0
    Von da-real-lala am Di, 20. Juni 2017 um 08:08 #

    Übersetzt:
    „Und wieder hat mal jemand ne Web Engine gemacht, die sich nur sehr schwer auf stabilen Distri updaten lässt, weil kompliziert mit GTK vernetzt. Die Schuld gebe ich aber Debian, nicht WebkitGTK/Qt. Ach, wie schade.“

    • 0
      Von zxy am Mi, 21. Juni 2017 um 23:52 #

      Derjenige, der die Distribution anbietet, steht primär in der Verantwortung. Mein Posting bezog sich nicht nur auf Debian.

      Was hindert Debian, Ubuntu, OpenSuse oder Mint daran, Konqueror, Qupzilla, Epiphany-Browser oder Midori beim Bekanntwerden von remote ausnutzbaren Sicherheitslücken aus einer Debian-Distro mit dem nächsten Point-Release herauszunehmen, wenn man diese Lücken nicht patchen kann oder der Aufwand dafür zu groß ist?

      Bei Owncloud in Ubuntu war es ja auch möglich, mit Rekonq verfuhr Debian aus anderen Gründen geradezu knallhart.

      Ein remote ausnutzbares Sicherheitsloch? Keiner kann oder will patchen? Mein lieber Maintainer, dort ist die Tür für Dein Paket. Raus damit!

      • 0
        Von zxy am Do, 22. Juni 2017 um 00:19 #

        Der Text stimmt natürlich so nicht, ich habe mich oben an einem Punkt verschrieben.

        Natürlich ist jede Distro für sich selbst verantwortlich ist und Webbrowser mit Sicherheitslücken, die remote ausnutzbar sind, sollten am Besten aus einer Distribution herausgenommen werden.

        Debian ist davon nicht alleine betroffen.

        OpenSuse z.B. hat gerade Seamonkey mit im Angebot, obgleich Seamonkey mehrere Versionen hinter einer sicheren Firefox- oder Firefox-ESR-Version hinterherhinkt. Mit Epiphanybrowser hat OpenSuse genau das gleiche Problem wie Debian.

        Die Beispielliste über die meisten Distros hinweg ist hier riesengroß und keinesfalls auf Debian beschränkt.

        Das umrissene Problem ist real. Mit "Mir doch egal, ob überhaupt gepatcht wird." kommt man da nicht weiter.

        • 0
          Von da-real-lala am Fr, 23. Juni 2017 um 09:31 #

          Ich habe nicht gesagt, dass es mir egal ist. Aber wenn jemand eine Web Engine baut, die den halben GTK Stack neu haben will bei einer neuen Version, wie soll Debian das dann patchen?
          Aber du hast Recht, sie hätten das Ding einfach entfernen sollen. Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen.

          • 0
            Von zxy am Sa, 24. Juni 2017 um 16:03 #

            "Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen."

            Genau das ist das Hauptproblem. Man ruft ein Programm auf und weiß gar nicht, dass eine solche unsichere Webkit-Engine mitbenutzt wird.

            Die Distribution müsste dann KDE- oder GTK-/Gnome-Programme so kompilieren, dass diese Webkit- oder Khtml-Engines nur lokale Inhalte anzeigen. Gnomes Epiphany-Browser z.B. dürfte IMO unter Debian gar nicht ins Internet gelangen, zumal sich hier noch nicht einmal mehr Javascript in der GUI abschalten lässt.

            Und da fängt dann eine mögliche Bevormundung des Nutzers an, die Debian eher ablehnt. Was bleibt, ist dem Nutzer zu sagen, dass er unter Debian machen kann, was er will, auch mit unsicherer Software im Internet herumsurfen, wenn er das so möchte, nur hat es Debian vorher immerhin deutlich gesagt, dass das in punkto Sicherheit ganz großer Mist ist.

            Das ist etwa so, als würde man mit dem alten Internet Explorer oder einem alten T-Online-Browser auf einem noch "unterstützten" Windows im Internet herumsurfen.

            Keine Distribution bekommt es momentan hin, die Webkit- und Khtml-Engines etwas älterer KDE- und Gnome-Desktops so anzubieten, dass man mit diesen sicher im Internet surfen kann. Die einzige Ausnahme sind regelmäßig aktualisierte Distributionen wie Fedora oder Rolling-Release-Distros.

            Nur: Man weiß, dass Webkit-Upstream ältere Webkitversionen nicht mehr supportet. Wieso ruft man dann für das Anzeigen von Internetinhalten unter Debian nicht einfach erst einmal standardmäßig Firefox oder Chromium auf (was natürlich als Option überschreibbar bzw. veränderbar bliebe)?

0
Von Ede am So, 18. Juni 2017 um 19:44 #

Über die gesamte Testingphase hatte ich Stretch auf einem Thinkpad und auf einem Desktop. Ich bin einfach nur zufrieden damit. Debian bekommt eine kleine Belohnung dafür ...

0
Von tool am So, 18. Juni 2017 um 21:42 #

ist es möglich nvidia treiber und neues wine unter debian 9 zu installieren ? dann ist debian 9 nützlich auch für mich.

0
Von manjaroo am So, 18. Juni 2017 um 22:00 #

und bei Manjaro 32 bit ist es so, dass es nur cpu s ab sse2 unterstützt, so amd athlon cpus mit nur sse1 sind raus. das war eine schlechte idee von amd millionen athlon cpus zu produzieren und verkaufen ohne sse2.

  • 0
    Von sse4 am So, 18. Juni 2017 um 22:15 #

    ganuso ist es schlimm, wenn man cpu hat 64 bit ohne sse4.2 und popcount, zb nur sse4.1 hat.

    0
    Von zxy am Mo, 19. Juni 2017 um 00:25 #

    Das hat wohl eher etwas damit zu tun, dass AMD zu jener Zeit nicht zu wirtschaftlich sinnvollen Konditionen Intels SSE2-Patente lizenzieren konnte. Schließĺich war der SSE2-PentiumIV damals der direkte Konkurrent des Athlons.

    Erst später ergab sich eine Möglichkeit zum Cross-Licensing mit Intel im Hinblick auf für AMD zur Zeit der Entwicklung des AthlonXP noch nicht nutzbare 32bit-x86 CPU-Patente Intels, als Intel die AMD64-Patente von AMD lizenzieren musste.

    • 0
      Von 3D now am Mo, 19. Juni 2017 um 13:18 #

      ist eigentlich 3Dnow gleichwertig mit sse2 ? nur eben die anwender programme, die compiler, unterstützen wohl kein 3Dnow von amd alt ...

    0
    Von sse2 cpu am Mo, 19. Juni 2017 um 19:42 #

    hab heute festgestellt, dass Xbuntu 17.04 keine Probleme mit einer SSE1 CPU hat. thanks Ubuntu.

0
Von Lars Otte am Mo, 19. Juni 2017 um 08:37 #

Habe schon eine ganze Weile Debian Stretch und Raspbian Stretch am laufen, grundsolide Software, habe die Rückkehr zu Debian nicht bereut.

0
Von Release Management am Di, 20. Juni 2017 um 21:24 #

Hallo,

toll das Debian Linux Version 9 noch vor der Debian Linux Conference (debconf17) in Kanada fertig wurde.


Wer online teilnehmen und mitmachen will:

"official events will be streamed live over the Internet to promote remote participation"

https://debconf17.debconf.org/cfp/


Wer beim Verbessern von Debian Linux helfen will, findet hier einen grafischen Bug Report und Möglichkeiten Bugs zu melden und Patches einzubringen:


Debian Release Critical Bug Reporting:
https://bugs.debian.org/release-critical/


"Wie werden Fehler in Debian mit Reportbug berichtet?"
https://www.debian.org/Bugs/Reporting


Vielleicht gibt es auch noch weitere Helfer für die Long Term Support Service Teams.

https://wiki.debian.org/de/LTS

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung