Login
Newsletter
Werbung

Thema: Weitere Spectre-ähnliche Prozessorfehler aufgedeckt

95 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von HansiGlaser am Mi, 15. August 2018 um 17:44 #

Welchen Vorteil hat denn hier "grep" gegenüber einem einfachen "cat"?

cat /sys/devices/system/cpu/vulnerabilities/*

Danke
Hansi

[
| Versenden | Drucken ]
  • 0
    Von Unpackbar am Mi, 15. August 2018 um 18:01 #

    Ja Himmel sieh dir doch die Ausgaben von beiden an

    [root@localhost:~]$ grep . /sys/devices/system/cpu/vulnerabilities/*
    /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
    /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
    /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
    /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW

    [root@localhost:~]$ cat /sys/devices/system/cpu/vulnerabilities/*
    Mitigation: PTI
    Mitigation: Speculative Store Bypass disabled via prctl and seccomp
    Mitigation: __user pointer sanitization
    Mitigation: Full generic retpoline, IBPB, IBRS_FW

    [
    | Versenden | Drucken ]
    • 0
      Von Polynomial-C am Mi, 15. August 2018 um 18:07 #

      Wobei mir tail da noch besser gefällt:

      tail /sys/devices/system/cpu/vulnerabilities/*

      [
      | Versenden | Drucken ]
      • 0
        Von coNQP am Mi, 15. August 2018 um 19:19 #

        Ich finde head /sys/devices/system/cpu/vulnerabilities/* noch besser.

        [
        | Versenden | Drucken ]
      0
      Von HansiGlaser am So, 19. August 2018 um 10:34 #

      Ah, der Filename, danke! Danke auch an die weiteren Kommentatoren mit noch besseren Vorschlägen.

      [
      | Versenden | Drucken ]
0
Von Anonymous am Mi, 15. August 2018 um 20:25 #

... und nach Eingabe von l1tf=full auf der Kernel-Kommandozeile (im Grub-Bootmenü) sieht das bei mir so aus:

> grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW


Hyperthreading ist also abgeschaltet. Performance-Einbußen kann ich bei Desktop-Nutzung und in einer VirtualBox-VM bisher nicht feststellen - ist aber noch zu früh, um das sicher sagen zu können.


***
@Polynomial-C: "tail" ist ein guter Tip, ließ sich im Kommentar aber leider nicht richtig darstellen. Danke.

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Do, 16. August 2018 um 14:42 #

    Laut 1) bringt De-aktivierung von EPT den gleichen maximalen Schutz gegen L1TF wie die De-aktivierung von SMT, soll aber einen erheblichen Performance-Verlust bedeuten. Hyperthreading bleibt dabei aktiviert.

    Ich habe EPT mal via Kernel-Kommandozeile de-aktiviert (2)) und kann bei meinen VirtualBox Windows- oder Linux-VMs keine Performance-Einbuße feststellen. Sind allerdings keine Server-VMs, sondern nur für Desktop-Einsatz.

    Scheint also vom Einsatzzweck abzuhängen. Kann ja jeder für sich mal ausprobieren.

    Mit de-aktiviertem EPT sehe ich jedenfalls weder im Host noch in den VMs Performance-Einbußen.


    ***

    1) https://www.kernel.org/doc/html/latest/admin-
    guide/l1tf.html#mitigation-selection-guide

    2) kvm-intel.ept=0

    > grep . /sys/devices/system/cpu/vulnerabilities/*
    /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: EPT disabled
    /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
    /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
    /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
    /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Aug 2018 um 14:58.
    [
    | Versenden | Drucken ]
0
Von Nur ein Leser am Mi, 15. August 2018 um 22:11 #

Wer noch detailliertere Informationen über den Status seines Rechners bzgl. der ganzen Lücken haben möchte:

https://github.com/speed47/spectre-meltdown-checker

[
| Versenden | Drucken ]
  • 0
    Von Verfluchtnochmal-05995bd7b am Mi, 15. August 2018 um 23:38 #

    Nur dass das Teil in der Regel immer hinten nach hinkt, die Details sind schön, aber es fehlen halt Basics bei ganz aktuellen Installationen nämlich genau die Fixes für die ganz aktuellen Dinge

    [
    | Versenden | Drucken ]
    • 0
      Von 1ras am Fr, 17. August 2018 um 01:30 #

      Naja, eigentlich ist es das Teil, welches noch die meisten Informationen in halbwegs verständlicher Weise hergibt.

      [
      | Versenden | Drucken ]
      • 0
        Von Verfluchtnochmal_5987109 am Sa, 18. August 2018 um 06:55 #

        Ja eh nett, wenn du allerdings kernel mit raschen hotfixes wie jetzt einspielst hilft es halt nicht weil es davon noch gar nichts weiss

        [
        | Versenden | Drucken ]
        • 0
          Von 1ras am Sa, 18. August 2018 um 15:12 #

          Von welchem raschen Hotfix sprichst du jetzt genau?

          Wenn du bereits weißt, dass dein Kernel einen "raschen Hotfix" gegen eine bestimmte Lücke enthält, muss es dir das Tool ja nicht mehr unbedingt anzeigen. Das Tool brauchst du, wenn du nicht sicher weißt was in deinem Kernel bereits behoben ist und was nicht.

          Gibt es beispielsweise endlich einen Meltdown-Fix für x86-32 und ist er im laufenden Kernel enthalten?

          Auch der Pro-Linux Artikel mischt ja beispielsweise alte und neue Lücken wild durcheinander ohne wirklich etwas genaues auszusagen.

          Intel listet beispielsweise CPUs auf welche von L1TF betroffen sind ohne jedoch eine Aussage darüber zu treffen, ob nicht aufgelistete CPUs tatsächlich nicht betroffen sind oder ob sie nur einfach von Intel ignoriert werden, so wie beim Microcode für Spectre.

          RedHat erzählt im Video beispielsweise etwas über Software Patches welche das Risiko von L1TF minimieren sollen ohne zu sagen, ob sie jetzt von Microcode-Updates, Kernel-Patches oder Applikations-Patches sprechen.

          In unserer Zeit wirst du leider mit Schlagzeilen zugeschüttet aber wirlich weiter bringen tut dich nichts davon. Da ist so ein Tool wie der Spectre Meltdown Checker hingegen wirklich hilfreich, denn dieser trifft wenigstens konkrete Aussagen. So lange er nicht eine Lücke als behoben ausweist welche es nicht ist, ist auch alles in Ordnung.

          [
          | Versenden | Drucken ]
          • 0
            Von Verfluchtnochmal_5987109 am Mo, 20. August 2018 um 01:00 #

            Rasche hotfixes wie das Thema hier wo das Tool noch nichtmal wusste dass es überhaupt ein neues Problem geschweige denn fixes gibt?

            Die ersten Fedora builds waren unvollständig während CentOS gefixt war, glasklar mit dem grep Kommando aus dem Artikel ersichtlich und schon ist das nächste kernel Update von koji runter geladen und nochmals durchgestartet

            Das Tool hätte dir die Notwendigkeit am 14.08 nicht klar gemacht und ob du lediglich retpoline oder auch die erweiterten instructions der microcode updates benutzt sagt dir der Kernel auch - was glaubst du wen das tool fragt?

            mindestens eine der Lücken braucht ohne wenn und aber microcode updates und somit nach dem update des Pakets auch ein "dracut - f" wenn du nicht bis zum nächsten Kernel update warten willst

            Bei all dem hilft dir das Tool im Zweifel nur bedingt

            ob es ein Update für 32bit gibt sagt dir auch der Kernel alleine

            [
            | Versenden | Drucken ]
            • 0
              Von 1ras am Mo, 20. August 2018 um 01:13 #

              Ich kann dein Problem nicht nachvollziehen, was dieses Tool prüft und wo die Grenzen liegen ist klar beschrieben. Und natürlich führt das Tool keinen Exploit aus um eine Lücke zu bestätigen sondern fragt die Daten des Kernels ab und stellt diese übersichtlich zusammen. Alles das ist deutlich beschrieben.

              [
              | Versenden | Drucken ]
              • 0
                Von Verfluchtnochmal-05995bd7b am Mo, 20. August 2018 um 10:39 #

                Was genau kannst du daran nicht nachvollziehen dass am 14.08.2018 gepatchte Kernel rausgingen wo das Tool weder den Fix noch die Lücke kannte aber das sysfs der Kernel dir sehr wohl den Erfolg anzeigen konnte?

                CentOS:
                grep . /sys/devices/system/cpu/vulnerabilities/*
                /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
                /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
                /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
                Speculative Store Bypass disabled via prctl and seccomp
                /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load
                fences, __user pointer sanitization
                /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full
                retpoline

                Fedora:
                grep . /sys/devices/system/cpu/vulnerabilities/*
                /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
                /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
                Speculative Store Bypass disabled via prctl and seccomp
                /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user
                pointer sanitization
                /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full
                generic retpoline, IBPB, IBRS_FW

                Obwohl das Changelog des betreffenden Fedora Kernels behauptet hat dass der Build das Problem fixt "/sys/devices/system/cpu/vulnerabilities/l1tf" nicht vorhanden

                Das Tool hätte hier nicht geholfen weil es am 14.08.2018 noch gar nicht wusste dass es "/sys/devices/system/cpu/vulnerabilities/l1tf" überhaupt gibt während du davon ausgehen kannst wenn bei so einer neuen Lücke ein Patch daher kommt du das im sysfs siehst und wenn sich nichts geändert hat was nicht stimmt

                [
                | Versenden | Drucken ]
                • 0
                  Von 1ras am Mo, 20. August 2018 um 16:55 #

                  Ich kann deine Kritik nach wie vor nicht nachvollziehen. Das Tool war zum Zeitpunkt 14.08.2018 ausschließlich für Spectre 1-4 und Meltdown vorgesehen was klar und deutlich dokumentiert war. Wenn du es nicht bestimmungsgemäß einsetzt, liegt dies ausschließlich in deiner persönlichen Verantwortung. Dafür kannst du niemand anderen die Schuld geben.

                  Im Übrigen ist die Situation bei Longterm-Kerneln und distributionseigenen Fixes bei weitem nicht so eindeutig wie du es darstellst, da sich die Abfrageschnittstellen teilweise unterschieden oder überhaupt nicht vorhanden waren oder sind.

                  Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Aug 2018 um 17:03.
                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Verfluchtnochmal_5987109 am Mo, 20. August 2018 um 20:19 #

                    Ja war es nicht, erzähl mir was neues! Genau DARAUF habe ich hingewiesen und du willst es warum auch immer nicht kapieren

                    Das Tool ist zusätzlich super aber wenn du brandneue patches für gestern noch nicht bekannte issues einspielst komplett sinnlos weil das falsche Werkzeug - Nicht mehr und nicht weniger habe ich gesagt und mir fehlen leider die Buntstifte um es dir zu erklären

                    Was soll bei LTS Kernel grossartig anders sein?

                    Per sysfs stellen die genauso die Informationen bereit, siehe CentOS mit einem Kernel dessen major Version aus dem Jahre Schnee ist aber trotzdem alles ersichtlich

                    Wenn dir der Kernel irgendwo vulnerable anzeigt hat er entweder einen Bug (siehe erste Fedora builds) oder dir fehlen microcode updates

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von 1ras am Mo, 20. August 2018 um 21:42 #

                      Ja, du hast etwas umständlich darauf hingewiesen, dass dieses Tool nur die Lücken aufzeigt, wofür es zum gegebenen Zeitpunkt entwickelt und die in der Dokumentation aufgezeigt werden. Die Diskussion lässt sich also auf 4 Buchstaben zusammenfassen: RTFM

                      Was soll bei LTS Kernel grossartig anders sein?

                      Die Implementierungen haben sich besonders zur Anfangszeit teils signifikant zwischen den Kerneln und teilweise selbst zwischen den Distributionen unterschieden und sind auch heute noch nicht identisch. So fehlt beispielsweise im 3.16.57 nach wie vor die Anzeige der CPU-Bugs in der /proc/cpuinfo.

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von Verfluchtnochmal_5987109 am Di, 21. August 2018 um 00:49 #

                        /proc/cpuinfo ist in dem Kontext auch völlig wurscht, sysfs wie im Artikel beschrieben ist das korrekte Tool und selbst RHEL6 mit 2.6.x ist hier korrekt

                        Genau auf das wollte ich hinaus als das Tool zur Sprache gekommen ist: im zweifel ist die einzig korrekte Instanz /sys und die passt auch immer zum Kernel den du eben eingespielt hast ganz ohne RTFM

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von 1ras am Di, 21. August 2018 um 03:46 #

                          Das Tool gibt es schon länger als die sysfs-Einträge, eben gerade wegen der uneinheitlichen Lage. Mir fehlen auch die Buntstifte um dir das aufzumalen, aber ich kann immerhin auf hier verweisen.

                          Und ob die sysfs-Einträge nun zuverlässig sind kann ich schwer einschätzen, Kernel 4.9.110 sagt zu einem alten Pentium M zu spec_store_bypass:Vulnerable. Intel listet die CPU hingegen nicht als betroffen.

                          Diese ganzen CPU-Bugs sind nach wie vor ein reines Chaos.

                          [
                          | Versenden | Drucken ]
                          • 0
                            Von Verfluchtnochmal_5987109 am Di, 21. August 2018 um 10:21 #

                            Ändert nichts an der simplen Tatsache dass das tool im Kontext des Artikels und zum Zeitpunkt des Kommentars wenig hilfreich war und auf nicht mehr und nicht weniger habe ich hingewiesen

                            [
                            | Versenden | Drucken ]
                            • 0
                              Von 1ras am Di, 21. August 2018 um 13:17 #

                              Der Artikel mischt alte und neue Lücken wild durcheinander, der Kontext zum Spectre Meltdown Checker sind detailliertere Informationen welche eben sysfs gerade nicht bereitstellt. Sysfs sagt dir nicht warum eine Lücke vulnerable ist. Sysfs sagt dir nicht ob und welche unterschiedlichen Mitigations es zur selben Lücke gibt und ob ein weiterer Schutzlevel verfügbar und wie erreichbar ist.

                              [
                              | Versenden | Drucken ]
                              • 0
                                Von Verfluchtnochmal-05995bd7b am Di, 21. August 2018 um 15:27 #

                                Himmel erzähl mir was neues, es hat halt trotzdem der Hinweis gefehlt dass das Tool meistens nicht aktuell ist und zu neuen Dingen wie der News-meldung eben gar nichts sagt

                                [
                                | Versenden | Drucken ]
                                • 0
                                  Von 1ras am Di, 21. August 2018 um 16:23 #

                                  Du windest dich herum wie ein Aal, zum Zeitpunkt des Hinweises auf den Spectre Meltdown Checker war die initiale Unterstützung für L1TF bereits vorhanden, wie unschwer aus den Commits ersichtlich ist.

                                  Es bleibt also lediglich der Hinweis, vor dem Einsatz eines Sicherheitstools dessen Dokumentation zu lesen. Dies sollte eigentlich eine Selbstverständlichkeit sein.

                                  [
                                  | Versenden | Drucken ]
                                  • 0
                                    Von Verfluchtnochmal-05995bd7b am Di, 21. August 2018 um 19:04 #

                                    Bla - Das Tool ist bei Distributionen in Repos die abgesicherte Kernel zum Zeitpunkt des Artikels ausgelifert haben aber das Tool nicht entsprechend aktualisiert weil völlig unterschiedliche Maintainer

                                    spectre-meltdown-checker-0.39-1.fc28.noarch
                                    kernel-core-4.17.17-200.fc28.x86_64

                                    Und schon fällt deine Argumentation erneut zusammen, deine fucking Dokumentation kann dir nicht Dinge erklären die beim Schreiben selbiger gar noch nicht bekannt waren

                                    [
                                    | Versenden | Drucken ]
                                    • 0
                                      Von 1ras am Di, 21. August 2018 um 21:16 #

                                      Da kann das Tool schlicht nichts für. Beschwere dich bei deiner Distro oder warne meinetwegen vor dem Einsatz deiner Distro oder der veralteten Version wie sie deine Distro ausliefert. Nichts davon hast du gemacht.

                                      Und schon fällt deine Argumentation erneut zusammen, deine fucking Dokumentation kann dir nicht Dinge erklären die beim Schreiben selbiger gar noch nicht bekannt waren

                                      Da fällt überhaupt nichts zusammen. Die Doku listet explizit jede einzelne Lücke auf welche geprüft wird. Wenn deine Lücke nicht dabei ist, wird sie ganz offensichtlich nicht geprüft *facepalm*

                                      [
                                      | Versenden | Drucken ]
                                      • 0
                                        Von Verfluchtnochmal_5987109 am Mi, 22. August 2018 um 03:12 #

                                        Facepalm denke ich mir bei dir die ganze Zeit

                                        Der fucking normale User hat ein Problem wenn irgendwer irgendwas von irgendwo empfiehlt und ist noch nichtmal in der Lage irgendeine technische Doku zu verstehen noch sollte er überhaupt auf die Schnapsidee kommen irgendwas das in den repos ist am package manager vorbei zu installieren

                                        Warum? Weil das ganz schnell überhaupt nicht mehr aktualisiert wird und er 6 Monate später noch nichtmal wüsste wie und woher

                                        Dass ich mit dem allem kein Problem habe und typischerweise security updates in production ausgerollt habe bevor ihr blitzmerker überhaupt wisst das was kommt hilft dem der irgendeinem Trottelpost ohne Warnung folgt genau gar nicht

                                        Der freut sich dann auf ewig ein zweites Arschloch dass das tool sagt "eh alles bestens" und das war es dann auch schon

                                        [
                                        | Versenden | Drucken ]
                                        • 0
                                          Von 1ras am Mi, 22. August 2018 um 03:47 #

                                          Das ist ein simples Shellscript, da muss nichts am Paketmanagement vorbei installiert werden. Ein veraltetes Script welches eine Lücke nicht kennt sagt zu dieser auch nicht "eh alles bestens" sondern es sagt schlicht gar nichts dazu, die Lücke kommt in der kompletten Ausgabe schlicht nicht vor. Der Nutzer erhält keinerlei Hinweise darauf, dass die Lücke behoben sein könnte. Das Verhalten ist exakt identisch mit dem von sysfs, auch hier erfolgt keine Ausgabe zu Lücken, welche dem Kernel nicht bekannt sind.

                                          Aber wer keine Argumente hat muss natürlich auf Kraftausdrücke ausweichen, da erübrigt sich jede weitere Diskussion.

                                          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Aug 2018 um 03:52.
                                          [
                                          | Versenden | Drucken ]
                                          • 0
                                            Von Verfluchtnochmal-05995bd7b am Mi, 22. August 2018 um 12:25 #

                                            Ja nur dass der Kernel eben aus dem Repo kommt und dessen sysfs immer aktuell ist - Keine Ahnung was dein Spatzenhirn nicht daran begreifen will dass der typische User nicht in der Lage ist irgendwas manuell auf Stand zu halten

                                            [
                                            | Versenden | Drucken ]
0
Von tvn am Do, 16. August 2018 um 10:47 #

Ui, da musste scheinbar was in den Kommentaren ganz dringend raus.

Ich beobachte seit einiger Zeit eine etwas toxische Diskussionskultur hier in den Kommentaren. Diese Art von Kommentaren und Äußerungen meine ich vor ein paar Jahren hier nicht gelesen zu haben, und ich bin mir nicht sicher ob diese Kommentare nun representativ für die Leserschaft dieser Seite sind. Daher meine Bitte:

Könntet ihr in der nächsten Umfrage mal nachfragen "Was ist die Wikipedia"? Sollte sollten solche Äußerungen von der Redaktion willkommen sein, bin ich auch dazu bereit das Feld zu räumen.

[
| Versenden | Drucken ]
  • 0
    Von 404namenotfound am Do, 16. August 2018 um 13:44 #

    Bei solchen Anfragen hat die "Redaktion" bisher immer darauf verwiesen, dass so etwas über die Community geregelt werden soll. Es gibt ja durchaus die Möglichkeit, Kommentare schlecht zu bewerten. Diese rutschen dann unterhalb der Schwelle und werden mehr oder weniger ausgeblendet. Das Modell finde ich eigentlich auch gut.

    Dieses Verhalten ist auch nicht neu hier. Im Gegenteil. Vor einem Jahrzehnt gab es hier noch ganze Kommentarschlachten bei jedem Thema zu GNOME oder KDE.

    Zugegeben in den letzten Wochen wird hier häufiger getrollt. Das ist evtl. saisonal bedingt. Schließlich sind ja Ferien. :P

    [
    | Versenden | Drucken ]
    • 0
      Von tvn am Do, 16. August 2018 um 14:35 #

      Bei solchen Anfragen hat die "Redaktion" bisher immer darauf verwiesen, dass so etwas über die Community geregelt werden soll. Es gibt ja durchaus die Möglichkeit, Kommentare schlecht zu bewerten. Diese rutschen dann unterhalb der Schwelle und werden mehr oder weniger ausgeblendet. Das Modell finde ich eigentlich auch gut.

      Auch wenn ich die Tendenz gut finde, sehe ich nicht wie hier eine unadministrierte Community derartige Probleme gelöst bekommt.

      Dieses Verhalten ist auch nicht neu hier. Im Gegenteil. Vor einem Jahrzehnt gab es hier noch ganze Kommentarschlachten bei jedem Thema zu GNOME oder KDE.

      Ich muss zugeben, dass ich damals damit besser klar kam. Auch wenn mir diese "Diskussionskultur" noch nie wirklich zugesagt hatte war es mir bei emotionalen Diskussionen zu technischen Themen relativ egal, auch wenn es natürlich kein gutes Leitbild für den Neuzuwachs war und ist.

      Zugegeben in den letzten Wochen wird hier häufiger getrollt. Das ist evtl. saisonal bedingt. Schließlich sind ja Ferien. :P

      Irgendwie habe ich meine Zweifel, dass es bei dieser Platform Schüler sind die sich hier so artikulieren. Aber du magst schon recht haben, es gibt ja auch einige weitere Faktoren wie Trockenheit, Wärme und Urlaub :shock:.


      Abschließend möchte ich dir, 404namenotfound, für einen unaufgeregten Beitrag und Kommentar danken :up: :)

      [
      | Versenden | Drucken ]
      0
      Von Anonymous am Do, 16. August 2018 um 16:02 #

      >Diese rutschen dann unterhalb der Schwelle und werden mehr oder weniger ausgeblendet. Das Modell finde ich eigentlich auch gut.

      Ich nicht. Denn das Modell geht davon aus, dass die "Community" (auch nur jeweils diejenigen, die eine Bewertung abgeben) immer richtig liegt. "Richtig" hier im Sinne eines Code of Conduct. Es besteht aber die Gefahr, dass einfach nur mißliebige Ansichten raus-bewertet werden.

      Ohne eine Patentlösung bieten zu können: Vielleicht wäre es geschickter, eine "ignore"-Option anzubieten, also die Möglichkeit, die Kommentare bestimmter Leute erst gar nicht zu sehen. Man weiß ja recht schnell, auf wessen Meinung/Beitrag man auch gut verzichten kann. Und was ich nicht weiß, macht mich nicht heiß.

      Edit: Mir fällt gerade noch ein, dass man dem user jedesmal eine Nachricht zukommen lassen müsste, wenn er/sie wieder einmal auf "ignore" gesetzt wurde. Dieses Feedback wäre sicher wertvoll im Sinne einer Verhaltensänderung.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Aug 2018 um 16:17.
      [
      | Versenden | Drucken ]
      • 0
        Von tvn am Do, 16. August 2018 um 20:15 #

        Hat durchaus gute Ansätze. In dem Punkt, dass die Sterne vlt. ein schlechter Indikator für schlechtes Verhalten sind.

        Wenn ich eine freundliche technische Antwort auf eine Frage gebe, deren enthaltene Informationen falsch sind wäre eine schlechte Bewertung sicher auch angebracht.

        Ich muss ja zugeben, dass mir das Reddit Modell hierbei gefällt auch wenn mir die Platform an sich nicht zusagt. Aber ist vermutlich auch eine zu starke Veränderung, allgemein wäre ich ja schon froh wenn "neue Kommentare" und "neue Artikel" sinnvoll einsetzbar wären. Das sind aber auch Probleme außerhalb des Verhaltensproblem. :D

        [
        | Versenden | Drucken ]
    0
    Von Anonymous am Do, 16. August 2018 um 14:56 #

    >Ich beobachte seit einiger Zeit eine etwas toxische Diskussionskultur hier in den Kommentaren. Diese Art von

    Dieses Phänomen ist praktisch überall zu beobachten. Das Einfachste ist vielleicht, solche Threads nicht zu beachten und sich auf die zu konzentrieren, die auf das Thema bezogen sind.

    Ist ja zum Glück meist schnell zu erkennen. ;)

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung