Mehr über Pico Prozesse (einer der Grundsteine vom Windows Subsystem for Linux): https://blogs.msdn.microsoft.com/wsl/2016/05/23…ocess-overview/
Beiträge von gandro
-
-
Nutze GNOME. Bin kein Anfänger.
-
Mein letzter Stand war, dass die Skylake-Stromsparfunktionen immer noch nicht komplett implementiert sind (und auch Kernel 4.6 auf Dauer nicht von Intel empfohlen ist).
heise erwähnt aber, dass man manuell SATA-Stromsparmodi aktivieren muss, weil Bugs: http://www.heise.de/ct/artikel/Die…-6-3197968.html
-
Hanno Böck bei Golem über Quantenkryptographie: http://www.golem.de/news/verschlue…605-120767.html
-
Ja, hatte ich auch.
-
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 RC6Soweit sieht das gut aus. Ist es aber normal, dass Package nur bis PC2 geht? Klingt grad nicht so positiv?
https://mjg59.dreamwidth.org/41713.htmlGut 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.
-
Ich habe es nicht verstanden. Wie sind efivars rw Pflicht?
Imho dürfte efibootmgr keine Einträge ändern können ohne rw..? Aber vielleicht Irre ich. -
@Coni: Yayz... Top.Wenn man etwas schreiben möchte, sollte man das schon rw mounten (ist jetzt standardmäßig ro)
Um efibootmgr und Freunde benutzen zu können muss man es rw mounten. Ab Kernel 4.5 (für Skylake sowieso fast Pflicht, obwohl immer noch gefährlich) hat sich das aber sowieso erledigt und efivars rw mounten ist kein Problem. -
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/
-
The Algorithm - Brute Force [bandcamp]
Jop, das neue Album gefällt. -
Bleibt On-Topic. Alle weiteren Beiträge die nichts zum Thema beitragen werden gelöscht.
-
Zumindest die ETH schützt die Studis bei der ersten Beschwerde.. erst bei der zweiten geben sie persönliche Daten an Urheberrechtsinhaber raus.
-
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.
-
Wie sind hier nicht im Off-Topic. Alle weiteren Beiträge die nicht zur Problemlösung beitragen werden gelöscht.
-
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. -
Beim T450s vor einem Jahr als es brandneu war hatte ich das Problem mit den Tasten auch. Leider fällt mir der Fix nicht mehr ein, aber war glaube ich dass ich ein anderes Kernel-Modul laden musste, Und mit libinput vs. evdev hab ich auch rumgespielt.
Nachtrag: https://bbs.archlinux.org/viewtopic.php?id=194776 hat ein paar Workarounds von damals.
-
Das für das komplette x86 Instruktionsset findest du eh keine Lernmaterialien, dazu ist es zu umfangreich. Die Referenzen gibts bei Intel, aber das ist nur zum Nachschlagen von Details: https://www-ssl.intel.com/content/www/us…er-manuals.html
In "Computer Systems: A Programmer's Perspective" hat in Kapitel 3 eine gute Einführung in x86 Assembler. Wobei man Assembler sowieso nicht über Syntax und die Befehle lernt, sondern um über das Maschinenmodell, und davon da sind die anderen Kapitel genauso wertvoll, Kapitel 4 erklärt dann z.B. eine mögliche Implementierung.
Selsbt wenn du das Buch ignorierst, als Hands-On-Übung, gerade was Security und Reverse-Engierring angeht, empfehle ich das Bomb Lab dann durch zuspielen wenn du die Basics hast: http://csapp.cs.cmu.edu/public/labs.html
-
Die finale Version 1.9 ist da:
