Beiträge von gandro


    Das Programm erfüllt sehr wahrscheinlich seinen namentlichen Zweck nicht, da dieser sich nur irgendwo 1 GiB virtuellen Speicher her besorgt und mit einem fixen 8-Bit-Muster (0100 0001) vollschreibt. Man müsste schon mit Inline-Assembler (z. B. CLFLUSH-/MFENCE-Instruktionen auf x86) dafür sorgen, dass die Muster tatsächlich im RAM landen. Ein "intelligenter" C-Compiler könnte vielleicht sogar die memset-Aufrufe völlig aushebeln, da der von der einen Funktion beschriebene Speicher ausschließlich von der anderen ausgelesen und sonst nicht benutzt wird - mit clang unter FreeBSD scheint laut dem Thread z. B. das gesamte Gigabyte einfach auf eine einzige Speicherseite gemappt zu werden, die mit diesem Muster gefüllt ist.


    Ja, gute Punkte. Die Compileroptimierungen kriegt man mit volatile und Compiler-Barriers raus, wenn sie überhaupt greifen. Die Prozessoptimierungen sind schwieriger, Cache einerseits, insbesondere Prefetcher andererseits. Was wir damals für die Messung von Speicherlatenz in NUMA-Systemen gemacht haben, ist den Speicherbereich mit Pointern auf sich selber füllen und dann zufällig shuffeln. Und dann ein paar Millionen Iteration einfach den Pointern folgen. Den Cache kriegt man in der Regel durch genügend grosse Blöcke vergiftet, und der Prefetcher kann die zufälligen Muster nicht unendlich vorhersagen.


    Leute, ein letztes Mal: Gusch wer nix beizutragen hat. Lest EURE alten Beiträge und seid in genierter Form noch mehr Gusch..jeder fängt als DAU an. Besser so als gar nicht.


    Was freaked sagt. Wir sind hier nicht im Off-Topic, Derailment könnt ihr woanders machen.


    Btw, wie muss man die Stromsparmodi mit powertop unter Skylake deuten?

    Bei Package ist maximal PC2 angesagt.
    Core 0+1 geht aber bis CC7 runter
    Einzelne Kerne 0-3 bis runter C10-SKL
    GPU ebenfalls nach RC6

    Soweit sieht das gut aus. Ist es aber normal, dass Package nur bis PC2 geht? Klingt grad nicht so positiv?


    https://mjg59.dreamwidth.org/41713.html

    Gut ist das sowieso alles nicht, aber PC3 müsste schon gehen.

    Nachtrag: Die Kommentare diskutieren auch PC2.

    Windows Subsystem for Linux Overview

    Sehr schöner, kurzer Überblick von Microsoft wie das WSL intern funktioniert. Wie schon klar war, handelt es sich um Kernel-Treiber die Linux System-Calls übersetzen oder implementieren (also nichts, was die OpenSource-Community hätte machen können). Interessantes Detail: Die Linux-Prozesse sind als Pico-Prozesse implementiert. Wer das nicht weiss, Pico-Prozesse sind eine Art Container (von bevor Container cool waren) aus Zeiten wo Microsoft mal Windows als Library-OS implementiert hat ("DrawBridge"), was auch unter Barrelfish lief. Kurzum: Das Windows Subsystem for Linux basiert in Teilen auf Technologie, die von damals stammt als Microsoft mal sein eigenes WINE geschrieben hat (das ist Verschwörungstheorie von mir, aber ich vermute dass die Drawbridge auch mal mit Linux haben laufen lassen, dass es mal auf Barrelfish lief ist öffentlich).

    Achso, habe ich etwas missverständlich formuliert, Skylake und UEFI sind zwei komplett separate Problematiken; ich wollte nur darauf hinweisen dass man mit Skylake sowieso einen möglichst neuen Kernel haben will, und die als Nebeneffekt weil sie so neu sind den UEFI-rw-Schutz bereits implementiert.


    Wobei sich die Frage stellt, ob es Windows eh gebraucht hätte. Es ist ein offenes System, hätte jeder nen Wine für Linuxanwendungen für Windows schreiben können. Ist mir aber nicht bekannt, eher werden Multiplattformprogramme kompiliert. Hatte einmal nen cooles Linuxprogramm, wo ich traurig war, dass es das nicht für Windows gab. nur vergessen welches.


    Das stimmt so nicht ganz. Der Hauptunterschied zwischen Windows und vielen Unix-Kerneln ist, dass Windows nie eine stabile Systemcall-Schnittstelle hatte (abgesehen von einem kleinen Teil genannt "Native API", was aber dafür undokumentiert ist). Der Windows-Kernel hat seine Systemcall-Schnittstelle teilweise sogar zwischen Service-Packs geändert, weswegen Windows-Programme immer kernel32.dll und andere User-Space Bibliotheken verwenden müssen um mit dem Kernel zu sprechen (die Details soll ein Windows-Entwickler hier einfüllen, dazu kenne ich mich zu wenig aus).

    Das erlaubt es überhaupt, dass Wine komplett im User-Space implementiert ist, es muss bloss die kernel32.dll und Freunde so implementieren, dass sie mit dem Linux- anstatt dem Windows-Kernel sprechen.

    Bei Linux hingegen ist das Systemcall-API stabil und es mehrere konkurrierende Systembibliothek-Implementierungen (musl, glibc), oder ganze Programmiersprachen wie Go die direkt Systemcalls in den Kernel absenden, ohne jegliche Bibliotheken. Das heisst für Linux-Support in Fremd-Systemen wie Windows oder BSD muss man das auf Kernel-Ebene machen. Wie anderswo schon erwähnt, die BSDs machen den Linux-Support schon länger so: Die BSD-Kernels tun einfach so als wären sie ein Linux-Kernel. Der Windows NT Kernel hat mit seinem Subsystem-Support dafür auch eine geeignete Architektur, wo der NT-Kernel einfach so tut als wär er ein Linux-Kernel. Sowas kann aber nur von Microsoft stammen, das können Dritthersteller nicht machen.

    Kurzum: Windows hat ein stabiles ABI auf Bibliotheksebene, d.h. Windows-Kompatiblität kann man mit einer nachgebauten Bibliotheksammlung wie Wine erreichen. Linux hat ein stabiles ABI auf Kernel-Systemcall-Ebene, d.h. Linux-Binärkompatiblität kann man nur erreichen in dem man ein Linux-kompatibles Kernelinterface schreibt..

    Nachtrag:

    Die schwarze gepunktete Linie markiert die Stelle wo ein stabiles ABI garantiert ist. Bilder gestohlen von http://slideplayer.com/slide/2513940/

    Die Tastaturbeleuchtung ist (zumindest unter Linux) nicht automatisch.

    Nachtrag: Die E-Serie ist traditioneller eher Consumerware, die T-Serie die professionelle Variante. Hat stabilere Gehäuse was auch wartbar ist, generell bessere Verarbeitung, Kühlung, besseres Display, mehr Akku, Fingerprint-Sensor, mehr und bessere Garantieoptionen etc.


    Ist nen anderer Bug. Beim T450s gingen sie mit alten Kerneln gar nicht. Beim T460 gehen sie. Man kann klicken. Aaaber man kann nichts markieren bzw während des klickens den Zeiger nicht bewegen. Ich habe mir den neuesten Kernel direkt aus dem git kompiliert, einen 4.5er. Nutzt leider nichts.


    Ne, ich hatte schon den von dir beschrieben Bug mit dem seltsamen Verhalten.. probier das mit dem Protokol unten mal aus.