Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Qt-Browser Qupzilla wird KDE-Projekt

34 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von Ede am Mo, 14. August 2017 um 11:25 #

Der Konqueror war immer mein Lieblingsbrowser weil er sich elegant auf der Platte, im Firmennetzwerk, in der Cloud, im Internet bewegen konnte. Ich hoffe, dass er Zukunft hat ...

  • 1
    Von MartinF99 am Mo, 14. August 2017 um 12:14 #

    Schwer zu sagen, der konqueror hat nämlich nur einen Entwickler, der den konqueror nur mit dem nötigsten versorgt, weil er anderen Projekten ne höhere Priorität einräumt. Wenn sich also kein anderer findet kann es passieren, dass der konqueror nicht mehr lange gibt. Leider

    1
    Von Geleerter am Mo, 14. August 2017 um 12:17 #

    Ob nun Favorit oder nicht, seine Zeit ist abgelaufen. Er wurde bei KDE bereits beim Wechsel von Version 3 auf 4 als Dateimanager abgelöst und das Gleiche wird ihm auch als Browser widerfahren. Sein Leistungsspektrum ist einfach zu minimalistisch, von Erweiterungen und Möglichkeiten der Anpassungen ganz zu schweigen. Und »Dolphin« ist da um Längen besser, wenn auch nur verwendbar als Dateimanager. Jede Distribution, die KDE als Benutzeroberfläche mitliefert, bietet genug andere Alternativen in dieser Rubrik (»Andromeda«, »Krusader«, …). Altlasten sollten nicht länger als nötig im Depot verbleiben. Es ist also an der Zeit, sich zu verabschieden.

    • 1
      Von Ede am Mo, 14. August 2017 um 12:43 #

      Ja, als Dateimanager wurde er abgelöst, ist aber bis jetzt als solcher verwendbar. Durch Dolphin ist Konqueror nicht schlechter geworden.

      • 0
        Von to_ha am Di, 15. August 2017 um 11:37 #

        Als Dateimanager ist er seit der Entfernung der Profile, u.a. filemanagement, unbrauchbar.

        • 0
          Von nobelium am Do, 17. August 2017 um 23:57 #

          ich habe ja immer noch die hoffnung, dass das nicht á la mozilla entfernt wurde, sondern beim portieren auf qt5 in der warteschleife haengt.
          Ich selbst bin noch ein konqueror-als-filebrowser-user, der es liebt mit gesten das fenster beliebig zu teilen

          0
          Von nobelium am Fr, 18. August 2017 um 00:02 #

          ich habe ja immer noch die hoffnung, dass das nicht á la mozilla entfernt wurde, sondern beim portieren auf qt5 in der warteschleife haengt.
          Ich selbst bin noch ein konqueror-als-filebrowser-user, der es liebt mit gesten das fenster beliebig zu teilen

          0
          Von nobelium am Fr, 18. August 2017 um 00:02 #

          ich habe ja immer noch die hoffnung, dass das nicht á la mozilla entfernt wurde, sondern beim portieren auf qt5 in der warteschleife haengt.
          Ich selbst bin noch ein konqueror-als-filebrowser-user, der es liebt mit gesten das fenster beliebig zu teilen

    1
    Von Anonymous am Mo, 14. August 2017 um 18:07 #

    Ja, zu KDE2- und KDE3-Zeiten war es auch mein Lieblingsbrowser. Man konnte damit z.B. von der Heise-Newsticker-Seite die Meldungen per drag & drop in einen lokalen Ordner kopieren und dort später offline lesen - zwar ohne Bilder, aber auch ohne nervige Werbung.

    Offline lese ich zwar immer noch gern, aber muss das Zeug mühsam mit "speichern unter" und dem Datei-Dialog von Firefox in einen lokalen Ordner verfrachten.

    Auch wenn ich KDE seit dem KDE4-Debakel nicht mehr nutze, vermisse ich das drag & drop von HTML-Seiten immer noch.

    • 1
      Von JochenOffline am Di, 15. August 2017 um 09:45 #

      Dann würde ich Dir ScrapBook als FF-Extension empfehlen. Speichert WEebseiten lokal, Werbung/Navigation lässt sich markieren und löschen, Handling gespeicherter Seiten entspricht "Offline-Lesezeichen". Das Original hat mir immer gereicht: https://addons.mozilla.org/en-US/firefox/addon/scrapbook/

      Erweiterte Fassung, aber keine persönliche Erfahrung: https://addons.mozilla.org/de/firefox/addon/scrapbook-x/

      Jochen

1
Von Potz Blitz am Mo, 14. August 2017 um 11:54 #

Wenn der Qupzilla-Browser mit Qt5 gebaut ist, müsste er ja perfekt unter Wayland laufen? Weiß jemand dazu Näheres?

Und wie ist das eigentlich mit Firefox? Der scheint mir unter Wayland immer ein bisschen zu flachern. Liegt das eventuell daran, dass der Firefox noch kein Wayland unterstützt und dann über Xwayland geht?

2
Von NotMad am Mo, 14. August 2017 um 12:54 #

Ein Browser bekommt ja desöfteren ein Update, weil Sicherheitslücken gefunden wurden. Wenn Qupzilla auf Qt aufbaut und dessen Webengine verwendet, wie steht es dann um die Sicherheit? Bei Qt kommen ja nun nicht gerade viele Updates. Eigentlich müsste man davon ausgehen, das bei Qt - zumindest bei der Webengine - ähnlich oft Updates herauskommen, wie bei Chromium/Blink auch. Zwar betreffen nicht alle Updates auch Sicherheitslücken, aber es wurden bei Chromium/Blink bestimmt schon weit mehr Sicherheitslücken gefunden und durch Updates behoben, als dass Qt ein Minor-Update herausgebracht hat.

Gab es nicht letztes Jahr mal irgend einen Bericht, bei dem ein Entwickler oder Sicherheitsforscher genau das an den in Programmenn und Bibliotheken eingebetteten Webengines bemängelt hat? Er hat genau das Problem angesprochen, dass diese eingebetteten Webengines kaum Updates bekommen, und somit hoffnungslos veraltet sind und ein Sicherheitsrisiko darstellen.

Das ist zumindest das erste was mir durch den Kopf geht, wenn ich Browser sehe, die eingebettete Webengines verwenden.

  • 1
    Von Nur ein Leser am Mo, 14. August 2017 um 13:20 #

    +1

    Der Sinn von eingebetteten WebEngines in ToolKits ist meines Erachtens der, das man (Programm-)Oberflächen darstellen kann, die in HTML geschrieben wurden. Also relativ statische, eher lokale Inhalte.

    Auf dieser Basis einen Webbrowser zu schreiben, halte ich für einen gefährlichen Irrweg.

    1
    Von #! am Mo, 14. August 2017 um 14:01 #

    Ja, solange die Chromium-Engine nicht separat paketiert ist und Qt (QtWebEngine) davon abhängt oder Qt die QtWebEngine regelmäßig updatet ist das nicht besonders sicher.

    0
    Von schmidicom am Mo, 14. August 2017 um 14:36 #

    Ich meine mal irgendwo gelesen zu haben das qtwebengine nur der eine Teil von Chromium ist welcher den HTML-Code "rendert", ungefähr so wie der GCC seinerseits eben C oder C++ kompiliert. Die meisten Sicherheitsprobleme sollen aber im Gebilde drum herum (Sandbox, Plugins, Dateizugriffe auf Daten im restlichen System, und so weiter...) entstehen.

    Ob das stimmt weiß ich nicht aber ich finde es auch nicht ganz abwegig...

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Aug 2017 um 15:42.
    1
    Von ,-.,-.,-.,-.,-.,-.,-. am Mo, 14. August 2017 um 21:33 #

    Qupzilla kann dann, wenn er in einer Distribution an eine bestimmte Qt-Version einer ganz bestimmten KDE-Version gekoppelt ist, IMO nicht mit regelmäßigen Sicherheitsupdates versorgt werden, wenn man nicht gerade eine Bleeding Edge-Distro wie Fedora benutzt oder eine Rolling Release-Distro wie Archlinux. Auch Qupzilla stellt zwar immer die neueste Version bereit, meist basierend auf dem neuesten QT, die sich dann aber in eine Stable-Distro meist nicht mehr backporten lässt. Dieses Problem stellt sich für langzeitunterstützte Distros wie Ubuntu LTS oder Debian mit teilweise alten KDE- und Qt-Versionen.

    Dabei geht es u.a. um Folgendes:
    Ich meine, wer backportet denn aktuell irgendwelche Sicherheitsupdates aus dem brandneuen Qupzilla 2.x für das in vielen aktuellen Distros enthaltene Qupzilla 1.8.9, das noch Qt4 benutzt?
    Eben, niemand.

    Wie könnte man hier trotzdem Nutzern das Surfen mit unsichern Webbrowsern ersparen? IMO mit Flatpaks, die alle Abhängigkeiten einfach mitbringen. Man würde also Qupzilla 1.8.9 deinstallieren und an seiner Stelle ein Qupzilla 2.x-Flatpack installieren, wobei das Flatpak aufgrund seiner KDE-, Qt- und weiteren Abhängigkeiten durchaus Größen um 500 bis 1000 MB erreichen kann.

    Das wäre auch ideal für Debian, dann könnten die Nutzer wieder mit sicheren Midori-, Epiphany-, Konqueror- und Qupzilla-Browsern surfen.

    • 1
      Von Leszek am Mo, 14. August 2017 um 23:12 #

      Beispiel hinkt jedoch daran, dass die alte Qupzilla Version auf QtWebkit basiert und da macht Qt meines Wissens nach fast gar nix mehr dran.
      Man muss sich also Dritthersteller bedienen die versuchen QtWebkit wiederzubeleben.

      • 1
        Von -.,-.,-.,-.,.-,-.-,. am Di, 15. August 2017 um 00:06 #

        Das wird nicht passieren. Leider. Qupzilla 1.8.x in Debian und in Ubuntu benutzt man somit auf eigenes Risiko.

        Debian garantiert Sicherheitsunterstützung ohnehin nur für Firefox und Chromium (solange bis dies widerrufen wird) und Canonical supportet ja Ubuntu Universe, wo sich Qupzilla 1.8.x befindet, überhaupt nicht.

        Fedora und Opensuse-Versionen werden demgegenüber ohnehin kaum älter als ein Jahr, weshalb man hier mit dem nächsten Distro-Update eine ziemlich neue Version von Qupzilla zwangsläufig mit dabei hat.

        Da davon auszugehen ist, dass die meisten Webkit-Sicherheitslücken nur bei aktiviertem Javascript getriggert werden, sollte man Qupzilla 1.8.x halt am Besten ohne Javascript benutzen und keinesfalls für wichtige Dinge wie Online-Banking u.ä.

        Qupzilla an sich ist ein hervorragender Webbrowser, er sieht unter Linux so aus, wie man sich einen Firefox wünschen würde, nämlich modifizierbar und einstellbar, so wie man es selbst gerne möchte.

      0
      Von André Ramnitz am Mi, 16. August 2017 um 23:17 #

      Es gäbe seitens des Projekts einen möglichen Upgradepfad für QtWebEngine. Allerdings müssen die Packager der Distros dann auch den entsprechenden Aufwand betreiben, die Pakete ggf. neu zu bauen.

      Quelle s. Abs. "Relationship to Chromium"

    1
    Von da-real-lala am Mo, 14. August 2017 um 21:39 #

    Qupzilla gibt's als Appimage. Eine eventuelle Lösung des Problems?

    • 0
      Von NotMad am Di, 15. August 2017 um 14:22 #

      Nein, das ist keine Lösung. Denn selbst wenn die Qt-Lib mit ausgeliefert werden wird, so besteht noch immer dasselbe Problem, dass Qt - selbst in der aktuellsten Version - nie die neuste Chromium/Blink Engine beinhaltet. Ob Qupzilla nun Qt als Systembibliothek oder die im AppImage ausgelieferte Version verwendet, spielt da kaum eine Rolle.

      Das Problem liegt vielmehr an Qt selbst. Die müssten eine neue Version der WebEngine herausbringen, sobald eine Lücke in Chromimum/Blink behoben wurde und die ein neues Release herausgebracht haben. Natürlich könnte man hier nach der Schwere der Lücke eventuell auch mehrere kleinere Lücken mal zusammenfassen. Aber dennoch wäre dies IMHO der einzig richtige Weg. Dann würde ich auch einen Browser für den Internetzugriff akzeptieren, der auf Qt aufbaut.

      Qt ist da aber beileibe natürlich nicht die einzige Bibliothek mit diesem Problem. Das gilt ebenso für GTK-Webkit und andere Programme/Bibliotheken.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung