Beiträge von Agnes

    @tomfa-ng Jetzt hast du mich aber wirklich neugierig gemacht.
    Also schnell Firefox 58 installiert und ein leeres Profil, und siehe da: alles paletti.

    Wenn ich ganz genau hinschaue, sind die Scrollbalken um Haaresbreite schmaler als in GTK2, aber das war's auch schon.
    Greybird sieht zwar deutlich schmaler aus, aber die ganze Scrollleiste ist im GTK3-Theme genauso breit, wie der reine Scrollbalken im GTK2-Theme. Unterm Strich ist es das Selbe.


    @tomfa-ng Du hast Recht: Die automatische Ein- und Ausblendung der Scrollleiste in GTK3 ist bei Firefox-GTK3 ausgeschaltet. Das würde aber auch eher stören, weil es normalerweise eh nur ein Browserfenster gibt. Aber bei Anwendungen, die ein oder mehrere kleine Scrollfenster haben, ist der animierte Scrollbalken in GKT3 einfach super!


    @Berichtigung Tut mir leid, aber ich kann hier wirklich kein Problem erkennen. Firefox 52 & 58 reagieren auf die GTK+-Themes einwandfrei — genau so wie es sein soll.
    Man kann sich natürlich auch ein eigenes GTK+-Theme erstellen.

    Ja, mein Fehler, drüber hatte ich nicht so wirklich nachgedacht. Ergibt schon Sinn.

    Ich musste auch 2 Mal nachfragen, bis ich den Unterschied verstanden habe. Linux ist schon ein Riesenfeld. Und ich stehe immer noch irgendwo am Anfang.


    Firefox basiert zwar auf GTK+, bringt sein eigenes komplett mit. Damit ist jeder Versuch via den normalen GTK - Einstellungen etwas ändern zu wollen sinnlos.

    Für MS-Windows ist das richtig.


    Unter Linux lässt sich das Ausehen des Firefox-GTK-Fensters incl. Scrollbalken über die GTK-Themes ändern. Das hatte ich oben schon einmal geschieben.
    Wenn das unter KDE ein Problem ist, dann hat das nichts mit Firefox, GNOME oder den GTK-Themes zu tun.

    Was hat der request damit zu tun, auf welcher gtk Version das basiert? Könnte man genauso einfach implementieren wie die Schriftgröße.
    Man kann Dinge auch unnötig kompliziert machen.

    An wen soll sich @caroline wenden? Firefox? GNOME? Die GTK-Themes-Programmierer?
    Ich verwende das GTK3-Theme Vertex-Light und bin sehr zufrieden damit. Aber da gibt's noch ganz andere.


    O.K. GNOME ist hier im Forum nicht so stark vertreten wie KDE.

    Hängt wohl an den immer höher werdenden Auflösungen. Am besten mal nen bug report an den Hersteller der Software erstellen. Kann ja nicht so schwierig sein das zu implementieren.

    Firefox ist in GTK+ geschrieben. Bis FF52 GTK+V2 und ab FF53 GTK+V3.
    Hier gibt's eine Demonstration auf YouTube, da sieht man auch die Scrollbalken, sobald die Maus in das aktive Feld geschoben wird. GTK+ Widget Factory
    Hilfe: help.gnome.org/users

    Mit PTI als Schutz vor Meltdown hast du Glück.
    Im openSUSE Leap Kernel seit Version 4.4.104 wird KAISER verwendet, was eine Vorgängerversion von PTI mit viel mehr Leistungseinbußen darstellt.


    Da ich einen AMD habe, ist der Meltdownschutz bei mir aber eh deaktiviert.
    Und für Spectre (v2) Branch Target Injection gibt es einen Angriff für AMD-CPUs bisher nur theoretisch auf dem Papier, also immer noch nicht praktisch nachgewiesen.
    Retpoline gegen Spectre v2 steckt noch nicht im Leap-Kernel 4.4.104 und wahrscheinlich auch noch nicht im Leap-Kernel 4.4.112.


    Statt sich an einen fehlerhaften CPU-Microcode von Intel festzuklammern, der derzeit rein gar nichts bringt, außer vielleicht Problemen, sollten Intel-CPU-Besitzer besser auf einen neueren Linux-Kernel umsatteln.
    Wäre schön, wenn sich da noch ein Gesprächspartner hier im Forum findet.


    Lesetipp: https://www.pro-linux.de/news/…der-meltdown-patches.html

    Ich hoffe doch? Ich musste aber gerade feststellen, dass uname -r mir "4.14.15-1-default" sagt. Installiert sind 4.14.15-1.5 und 4.14.15-1.6. Ich hoffe mal er verwendet dann also letzteren.

    Es passen doch beide Kernel. Ab Kernel 4.14.14 ist Retpoline implementiert.
    Schaue doch einfach mal nach, wie es hier beschrieben ist und poste die Ausgabe: https://www.pro-linux.de/news/…meltdown-und-spectre.html
    grep . /sys/devices/system/cpu/vulnerabilities/*


    Ohne passenden Intel-Patch-Code ist der Intel-CPU-Microcode witzlos. Aber will man den überhaupt haben, nach dem was Linus Torvalds dazu schreibt?

    Keine Linuxdistribution liefert irgendwelche Firmware Updates für das BIOS oder UEFI.

    Das habe ich mit keinem Wort geschrieben.


    Intel will die Ursache abstellen, was ihnen so einfach nicht gelingen wird. Nicht auf die Schnelle, und nicht für alle betroffenen Prozessoren.
    Das sind zwei verschiedene Dinge. Auch wenn sie miteinander natürlich verschränkt sind.


    Und wie die wirklich zusammenhängen, kann niemand von uns sagen.

    Das kann man schon seit 1 Woche im letzten Absatz nachlesen. https://www.pro-linux.de/news/1/25529/intel-rät-von-microcode-update-ab.html


    Das können nur ein paar Leute bei Intel und AMD selbst. (Was ich auch schon geschrieben hatte, dass das für uns letztlich alles nur Blackbox ist, weil es die am strengsten gehüteten Firmengeheimnisse sind.)
    Die Leute, die bei Linux selbst Einblick in diese Dinge haben, testen natürlich auch alle Firmware Updates von Intel und AMD, da sie ja ihren Teil im Linuxkernel anpassen müssen. Sie basteln aber derzeit eher Würgarounds, und sind damit so beschäftigt, dass sie für unsere Fragen keine Zeit haben.

    Hier kann man nachlesen, was man mit den 3 neuen CPU-Befehlen (IBPB, STIBP und IBRS), die im neuen Intel-CPU-Mircocode stecken, programmieren kann, um einen Schutz vor Sprectre Variante 2 Angriffen zu bekommen: https://lkml.org/lkml/2018/1/22/598


    Und hier kann man nachlesen, was Intel mit diesen neuen CPU-Befehlen da für Linux Kernel 4.16 als Patch eingereicht hat, und mit welch scharfen Worten Linus Torvalds diesen Intel-Code kritisiert hat: http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html


    Das ist alles nicht geheim oder eine Blackbox.


    Dieser Hype nervt einfach, und verleitet den durchschnittlichen User zu sehr bedenklichen Aktionen.

    So that's where the problem is.


    Der neue Intel CPU-Microcode stellt für sich allein Null Schutz vor Sprectre Variante 2 Angriffen dar. Und der neue Intel-Code, der auf den CPU-Microcode aufbaut, kommt eher nicht in den Kernel 4.16.


    Es gibt außerdem schon seit Anfang Januar eine Lösung, die von Google kommt und keine neuen CPU-Befehle benötigt: Return Trampoline (Retpoline).
    https://www.pro-linux.de/news/1/25508/retpoline-unterstützung-für-gcc-7.html
    Dieser Retpoline-Code steckt im jetzt erschienenen Linux Kernel 4.15, sowie 4.14.14 und 4.9.77.
    Er steckt aber leider nicht im Linux Kernel 4.4.112. Das kann man hier nachlesen: https://www.heise.de/ct/artike…4-15-3900646.html?seite=3


    Ich denke und hoffe doch, dass der zypper dup-Befehl für Tumbleweed keine sehr bedenkliche Aktion darstellt :| (Unter Annahme, dass man seinen Repositories Vertrauen schenkt)

    Du hast jetzt wieder den Intel-CPU-Microcode aus 2017 laufen. Was soll daran bedenklich sein? Du hat doch bestimmt einen Kernel laufen, der Retpoline schon implementiert hat.
    Der Nachteil von Retpoline ist halt, dass alle Anwendungen mit dem neuen GCC neu compiliert werden müssen. Unter Linux ist sowas aber doch kein Thema.