Login


 
Newsletter
Werbung

Thema: KDE SC 4.9 Beta2

21 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von lucas am Do, 14. Juni 2012 um 13:03 #

Dafür gibts jetzt Nepomuk, Strigi & Akonadi. Toll nicht? :P

  • 0
    Von Christoph Thielecke am Do, 14. Juni 2012 um 13:45 #

    > Nepomuk & Strigi
    Das ist für die meisten Benutzer uninteressant. Gerade da es in der Vergangenheit stark den Rechner ausgelastet hat (ist wohl mittlerweile besser geworden), haben es viele Nutzer deaktiviert. Die Entwickler hatten wohl alle eine SSD :(

    Bezüglich Performance würde ich den Entwicklern raten, als Hardwareanforderung 1GB RAM, 1GHz Taktfrequenz und hardwarebeschleunigtes 2D (kein 3D!) vorauszusetzen und das System so zu optimieren, dass es dort schnell läuft.

    > Akonadi
    Schöne Sache, die viele Vorteile (asynchrones Abholen von Mail, viele verschiedene Datenquellen, etc), aber auch eine Menge Nachteile (Preformance, Platzverbrauch, benötigt externen SQL-Server, etc.) hat.

    Am schlimmsten waren die neu eingeschlichenen Fehler (die mittleriweile behoben sind), die sogar eingefleischten KDE-Fans das Wasser in die Augen trieb. So z.B. dass Zugangsdaten plötzlich nicht mehr vorhanden waren (da die Konfiguration nicht konvertiert wurde), Abstürze, langsame Ladezeiten, etc. Ich weiss sogar von jemand, der die Firmenrechner auf thunderbird umgestellt hat, nachdem bei KMail Daten verloren gingen (ist mir unter KMail von KDE3 nie passiert).

    Persönlich brauche ich von dem allen neuen (akonadispezifisches) nichts. Die E-Mails kann ich mit KMail von KDE3 bzw. Thunderbird genauso gut verwalten (ein paar POP3-Konten und ein paar (grosse) IMAP-Konten, ca. 5,2G Mailgröße).

    • 0
      Von Andre am Do, 14. Juni 2012 um 13:55 #

      ... und das alles nachdem KDE 1.x-3.x bereits etwa 10Jahre beim Kunden gereift war...

      0
      Von xk am Do, 14. Juni 2012 um 16:52 #

      > Bezüglich Performance würde ich den Entwicklern raten, als Hardwareanforderung 1GB RAM, 1GHz Taktfrequenz und hardwarebeschleunigtes 2D (kein 3D!) vorauszusetzen und das System so zu optimieren, dass es dort schnell läuft.

      Das wird sogar gemacht. Das Vivaldi Tablet hat auch nicht mehr Leistung und da läuft Nepomuk drauf. Auf dem Desktop wird wahrscheinlich kaum mehr mit so einem System entwickelt. Immerhin sind entsprechende Systeme um die 10 Jahre alt.

      Ich denke mal die Zeiten ohne 3D Beschleunigung sind bald vorbei. Unity und Gnome setzen ja bereits darauf und spätestens mit Qt 5 brauch das auch KDE OpenGL 2. Als Alternative bleibt dann noch llvmpipe.

      • 0
        Von crissi am Do, 14. Juni 2012 um 17:14 #

        > Ich denke mal die Zeiten ohne 3D Beschleunigung sind bald vorbei. Unity und Gnome setzen ja bereits darauf
        Das finde ich nicht gut, es als zwingende Veraussetzung zu machen.

        > und spätestens mit Qt 5 brauch das auch KDE OpenGL
        Das ist der falsche Weg...

        0
        Von jkkjkjkj am So, 17. Juni 2012 um 16:30 #

        "Ich denke mal die Zeiten ohne 3D Beschleunigung sind bald vorbei."

        Das gilt nur für die meisten Nutzer von Radeon- und Intel-Grafikchips unter Linux und für Radeon-Nutzer auch nur dann, wenn sie unfreie Kernelfirmware benutzen.
        Für Nvidiagrafikkartennutzer und Nouveau gilt das nicht. Nouveau ist als "Wir müssen wegen fehlender Hardware-Specs alles neu machen"-Projekt noch nicht einmal in der Lage, flächendeckend hardwarebeschleunigtes 2D anzubieten. Sehr oft erhält man nur dann einen stabilen Desktop, wenn man mit nouveau.noaccel=1 startet, was dann auf ein reines Vesa-Niveau hinausläuft, bei alten wie bei neuen und nagelneuen NVidia-Grafikkarten. Für Nochanwender von alten Nvidiagrafikkarten (älter als NV30) bieten die meisten Distros die Nouveau-Mesa-3D-Treiber schon gar nicht mehr an, weil sie von Upstream nicht mehr gewartet werden.

        Deine Aussage ist also ein schwerer Irrtum.

        Die Auswirkungen siehst Du schon bei Distros, die es sich auf die Fahnen geschrieben haben, ausschließlich freie Software zu benutzen (z.B. Trisquel), da hier alle Radeon-Grafikchips (eben weil die unfreie Kernel-Firmware fehlt) und die meisten Nvidia-Grafikchips keine bzw. keine stabile 3D-Hardwarebeschleunigung anbieten.

        Auch Debian wird darüber diskutieren müssen. Man kann nicht auf der einen Seite stolz darauf sein, in Debian Main nur freie Software anzubieten und gleichzeitig einen 3D-Desktop zum Standarddesktop erklären, der für viele Nvidia- und für alle Radeonnutzer die Installation von unfreier Software bzw. unfreier Kernelfirmware zwingend notwendig macht.

        Die Llvmpipe ist in dieser Hinsicht nur ein Feigenblatt, hinter dem man sich als 3D-Desktop-Befürworter versteckt, da die Llvmpipe nur flüssig auf neuen Rechnersystemen (Quadcore- und neuere Dual-Core-Systeme) funktioniert. Viele Linuxnutzer stehen dann also in punkto 3D im Regen.

        • 0
          Von mgraesslin am So, 17. Juni 2012 um 17:33 #

          Deine Aussage ist also ein schwerer Irrtum.
          Das denke ich nicht. Ich denke dein Vorposter hat das genau richtig erkannt. OpenGL ist die Zukunft auch auf dem Desktop.

          Entwickler werden sich kaum dafür interessieren, dass es auf > 5 Jahren alten Rechnern nicht funktioniert und auch die Anzahl der Pragmatikern, denen die unfreie Firmware egal ist, ist bedeutend größer als die Anzahl der fundamentalistischen FLOSS-Verfechtern. Und für die gibt es ja immer noch llvmpipe und nein das ist kein Feigenblatt sondern eine wertvolle Alternative um den Code wartbar zu halten. Ich hatte mal einen Blog Post dazu geschrieben, wie teuer für uns die Unterstützung von legacy hardware ist.

          Aktuell ist ja bereits die Situation, dass man für GNOME Shell, Cinnamon und Unity zwingend OpenGL benötigt. KDE Plasma lässt sich nur aus historischen Gründen noch ohne OpenGL Beschleunigung starten. Anwendungen werden da mehr und mehr nachziehen und ich vermute mal sehr stark, dass als erstes die Webbrowser zwingend OpenGL verwenden werden.

          Und bei allem frei ist toll, wenn man nur noch mit ungepatchten Browsern ins Web kommt, dann muss man halt die unfreien Komponenten temporär in Kauf nehmen. Für wen es wirklich wichtig ist, wird ja dann am reverse engineering der Firmware teilnehmen.

          • 0
            Von kjkjkjkjkj am So, 17. Juni 2012 um 19:08 #

            "und auch die Anzahl der Pragmatikern, denen die unfreie Firmware egal ist, ist bedeutend größer als die Anzahl der fundamentalistischen FLOSS-Verfechtern."

            Das gilt vielleicht für Dich (?), nicht aber für viele Leute, die die Linuxbasissoftwareinfrastruktur bereitstellen. Außerdem bleibt das Nouveau-Problem trotzdem bestehen. Der zur Zeit angebotene 3D-Support existiert nur für wenige Nvidia-Grafikchip-Reihen. Dieses Problem ist schon einmal nicht mehr nur mit dem Einsatz unfreier Kernelfirmware lösbar, sondern nur mit unbestreitbar unfreien Nvidia-Grafiktreibern. Ist Dir das auch egal?


            "Und bei allem frei ist toll, wenn man nur noch mit ungepatchten Browsern ins Web kommt"

            Warum sollten z.B. Midori und Qupzilla nicht unter nagelneuen Linuxen auf alter Hardware laufen? Niemand setzt auf alter Hardware nicht gepatchte, uralte Browserversionen ein. Wenn Firefox zu schwergewichtig wird für ältere Hardware, dann gibt man ihn auf.


            "Und für die gibt es ja immer noch llvmpipe und nein das ist kein Feigenblatt sondern eine wertvolle Alternative um den Code wartbar zu halten."

            Doch, das ist es, ein Feigenblatt für allzu oft noch fehlende, funktionierende 3D-Treiber. Die Llvmpipe ist auch eine gute Möglichkeit, seinen Notebook-Akku viel schneller als geplant zu entleeren. Theoretisch klingt die Llvmpipe sehr gut, bedeutet aber nichts weniger, als dass man seine Grafikkarte praktisch umsonst gekauft hat, eben weil funktionierende Grafiktreiber fehlen. Also ein typisches Feigenblatt.

            • 0
              Von mgraesslin am So, 17. Juni 2012 um 19:33 #

              Das gilt vielleicht für Dich (?), nicht aber für viele Leute, die die Linuxbasissoftwareinfrastruktur bereitstellen.
              Fassen wir noch mal zusammen aus aktuellem Linux Umfeld:

              • GNOME Entwicklern ist das egal - siehe GNOME Shell

              • Ubuntu ist das egal - siehe Unity/Compiz

              • Mesa Entwicklern ist das egal - siehe Mesa

              • Wayland Entwicklern ist das egal - siehe Mesa

              • X Entwicklern ist das egal - siehe Unterstützung für Umstellung auf Wayland

              • Toolkit (GTK/Qt) ist das egal - siehe Wayland

              • Qt ist das egal - siehe OpenGL basierter SceneGraph für QML

              • Clutter Entwicklern ist das egal - siehe Clutter

              • und so weiter und so fort

              Sorry, aber die aktuelle Situation ist, dass es anscheinend niemanden interessiert, der am Stack arbeitet.

              sondern nur mit unbestreitbar unfreien Nvidia-Grafiktreibern. Ist Dir das auch egal?
              Mal überlegen: zum Zeitpunk als KWin OpenGL Compositing einführte, funktionierte das nur richtig mit den proprietären NVIDIA Treibern. Und hmm aktuell schließen wir nouveau spezifische Bugs als "bitte proprietären Treiber verwenden". Hmm ja, scheint mir egal zu sein.

              Warum sollten z.B. Midori und Qupzilla nicht unter nagelneuen Linuxen auf alter Hardware laufen?
              Ah da hast du was falsch verstanden. Wenn die Rendering Engine OpenGL erzwingt, dann braucht Midori und Qupzilla als WebKit Browser auch OpenGL. Dumm aber auch, dass es nur zwei moderne engines gibt...

              Theoretisch klingt die Llvmpipe sehr gut, bedeutet aber nichts weniger, als dass man seine Grafikkarte praktisch umsonst gekauft hat, eben weil funktionierende Grafiktreiber fehlen.
              Wenn du aus ideologischen Gründen den Treiber nicht verwenden willst, dann ist das dein eigenes Problem. Dann machst du aber auch den Akku leer, weil die GPU in der höchsten Taktstufe läuft.

              Und dafür ist die llvmpipe auch nicht gedacht, sondern eher für nicht OpenGL 2 taugliche Hardware und für virtuelle Maschinen. Da ist das dann auch überhaupt kein Unterschied. Man kann ja über OpenGL schimpfen wie man will, aber irgendwie muss man ja zeichnen. Und es ist doch unstrittig besser eine hochoptimierte CPU basierte Zeichenlösung wie llvmpipe zu verwenden statt eine schlechte CPU basierte rendering API. Nicht OpenGL zu verwenden, heißt immer, dass du auf der CPU zeichnest. Mit OpenGL hast du zumindest die Chance auf der GPU zu zeichnen.

              • 0
                Von kjkjkjkjkjkj am So, 17. Juni 2012 um 20:44 #

                "Mal überlegen: zum Zeitpunk als KWin OpenGL Compositing einführte, funktionierte das nur richtig mit den proprietären NVIDIA Treibern. Und hmm aktuell schließen wir nouveau spezifische Bugs als "bitte proprietären Treiber verwenden". Hmm ja, scheint mir egal zu sein."

                Gut, dann brauchen wir auch nicht mehr über das Für und Wieder von freier Software zu diskutieren.
                Es ist mitunter ganz schön, wen man wichtige Themen so schnell abschließen kann.

                • 0
                  Von mgraesslin am So, 17. Juni 2012 um 23:06 #

                  Es gibt nicht nur Schwarz und Weiß. Aktuell sind wir noch nicht in einer Situation in der alles frei sein kann - hätte ich auch gerne und hab mir vor ein paar Wochen eine AMD Grafikkarte gekauft, weil mich die proprietären NVIDIA Treiber angenervt haben.

                  Fakt ist, dass wir aktuell keine freie Hardware haben und keine komplett freien Treiber. Das ist Schade, aber wir müssen dennoch das Beste draus machen. Stecken wir den Kopf in den Sand und warten bis alles frei ist, hat die proprietäre Welt gewonnen, nehmen wir die aktuelle Situation aber so hin wie sie ist und arbeiten daran, dass langfristig alles frei ist (vergleiche Situation von AMD Grafikkarten von vor fünf Jahren mit heute), dann können wir auch die freie Architektur wie OpenGL nutzen und mehr Leute für freie Software gewinnen.

                  Lieber heute mehr Nutzer mit einem fast freien Stack, als in ein paar Jahren komplett in der Bedeutungslosigkeit zu versinken und alles ist unfrei.

                  Wenn wir den Stack nicht pushen mit Anforderungen, wird er auch nicht mit freien Lösungen nachziehen. Gerade die Erfahrungen mit radeon und nouveau zeigen doch, dass es richtig war temporär in Kauf zu nehmen, dass Anwender unfreie Komponenten verwenden - wobei zumindest bei KDE immer die Option bestand dies zu deaktivieren.

                  • 0
                    Von kjkjkjkjkkj am So, 17. Juni 2012 um 23:51 #

                    Ich weiß.
                    Wenn ich mir meine Rechner hier anschaue, so wird natürlich unfreie Firmware benutzt, die sich meist auf Mainboard und Controllern und im Bios befindet. Die Softwareversionen solcher unfreien Firmware sind halt ein Sonderfall. Auch fällt es mir nicht im Traum ein, wegen der unfreien Radeon-Kernelfirmware einen "Monpolisten" wie Intel zu unterstützen.

                    Das hat mich aber auch nicht daran gehindert, sämtliche Nvidiakarten aus meinen Rechnern zu werfen. Eine Zumutung hoch drei. Auf solchen Karten befinden sich dann einfach irgendwelche unbekannten Mikrocontroller, die zwar geschwätzig mit dem Nvidia-Blob kommunizieren, aber mit Nouveau ohne abgeschaltete Hardwarebeschleunigung nach kurzer Zeit freezen. So geht das nicht weiter. Ich bin Kunde und keine Bezahlsklave. Nvidia will nicht, o.k., ich will auch nicht mehr.

                0
                Von kjkjkjkj am So, 17. Juni 2012 um 21:05 #

                "Fassen wir noch mal zusammen aus aktuellem Linux Umfeld:

                GNOME Entwicklern ist das egal - siehe GNOME Shell

                Ubuntu ist das egal - siehe Unity/Compiz

                Mesa Entwicklern ist das egal - siehe Mesa

                Wayland Entwicklern ist das egal - siehe Mesa

                X Entwicklern ist das egal - siehe Unterstützung für Umstellung auf Wayland

                Toolkit (GTK/Qt) ist das egal - siehe Wayland

                Qt ist das egal - siehe OpenGL basierter SceneGraph für QML

                Clutter Entwicklern ist das egal - siehe Clutter

                und so weiter und so fort"


                Und so weiter und so fort stimmt so nicht.
                Linus Torvalds passt jedenfalls nicht in dieses Schema.
                Hier, das wird Dich auch etwas erheitern:
                http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc
                "Linus Torvalds Calls NVIDIA The Worst Company Ever"
                Linus Torvalds ist halt doch - wie hat man das hier so oft tituliert - "pragmatisch". :-)
                Vor allem der Stinkefinger gefällt mir irgendwie, da es IMO genau den Richtigen trifft.
                (Obgleich ich hier oft Nouveau kritisiere, weiß ich natürlich, wer die wahre Schuld an der ganzen Treibermisere trägt.)

                • 0
                  Von mgraesslin am So, 17. Juni 2012 um 23:09 #

                  und auch wenn das sehr Medien-wirksam ist, war es vielleicht nicht klug. Man muss ja auch sehen, dass NVIDIA gerade der Linux Foundation beigetreten ist und ganz ehrlich hatte ich persönlich viel bessere Erfahrungen in der Interaktion mit den Entwicklern sowohl der proprietären NVIDIA als auch AMD Treibern als mit den Mesa Entwicklern.

                  Ich sehe Hoffnungen, dass auch bei NVIDIA sich was bewegt, wenn man die aktuellen Entwicklungen verfolgt. Da kann so eine Äußerung von Linus sich sehr negativ auswirken - aber das muss er selber wissen.

                  • 0
                    Von kjkjkjkjkjkjk am Mo, 18. Juni 2012 um 00:06 #

                    Es geht ja ausdrücklich um das "dealt with".
                    Irgendetwas muss da im Hinblick auf den Kernel vorgefallen sein, was auch mit Nvidia-Nichtgrafikkartenhardware zu tun haben kann.
                    Ich tippe auf einen Hardwarebug in irgendeinem Stück Nvidiahardware und die mutmaßliche Weigerung Nvidias, beim Fixen bzw. Anpassen des Linux-Kerneltreibers auch nur einen Finger krumm zu machen.

Pro-Linux
Gewinnspiel
Neue Nachrichten
Werbung