Beiträge von gandro

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:

https://mojang.com/2016/02/minecraft-19-combat-update/

Zitat von Alpha

Und wie gehts jetzt weiter?

DosAmp und ich stehen in Kommunikation..

Zitat von Xaar

der gesamte Inhalt in Anführungszeichen sagen will. Sprich: was heißt %{+b bk}, was %-Lw usw. Bzw. welche Variablen (%irgendwas) es gibt, die dort eingefügt werden können.

Achso.. nicht ganz sicher ob es das ist was du suchst, aber Section 9.6 Caption verlinkt auf https://www.gnu.org/software/scree…#String-Escapes

Zitat von Xaar

Hat jemand 'ne Quelle, wo die einzelnen möglichen Variablen für die Datei /etc/screenrc bzw. ~/.screenrc beschrieben sind? Hab' zwar 'n bisschen was im Ubuntuusers-Wiki gefunden, aber die ~/.screenrc, die ich hier in grml habe, enthält 'n Variablen, die da nicht aufgezählt sind. Außerdem funktioniert die .screenrc bei mir unter Debian 9 Testing nicht richtig, daher würd' ich das gern mal anpassen.

https://www.gnu.org/software/scree…Command-Summary

Bleibt On-Topic. Jegliche weitere Diskussionen, die nicht im Interesse des Threaderstellers sind, werden gelöscht.

Gratulation, DosAmp!

Zitat von mrshadowtux

Mach mal eins auf, ich nehm teil.

Ups, sorry. Ich hab nicht vor teilzunehmen. Das mit dem Doodle war ein Vorschlag dass einer der Teilnehmer ein Doodle organisiert

Doodle?

Zitat von TAL

Datum der Anmeldung in diesem Forum?

Ja. WHF-Spezifischer Hack für die Aluhüte hier. https://github.com/winhistory/whf…extras.php#L413

Normalerweise zeigt das MyBB auch bei Geistern die letzte Aktivität zuverlässig an.

Wie vor längerer Zeit angekündigt, möchte ich meinen Posten als WHF-Admin stückweise abgeben.

In dem Thread haben sich als potentielle Kandidaten für Admins mit notwendigen Fähigkeiten herauskristallisiert: winfreak, Wynton und DosAmp.

Für den Wechsel wünsche ich mir eine (1) verantwortliche Person als meinen Nachfolger, darum soll es in dieser Wahl gehen. Alles weitere, wie der Wechsel etc ablaufen soll, was sich hier technisch was ändert etc, welche Co-Admins sie sich wünschen, etc, entscheidet dann die hier gewählte Person. Allen drei traue ich zu, dass sie in der Lage sind, den Wechsel hier stemmen zu können. Alle drei haben damals einen kurzen Text verfasst, wie sie sich das grob vorstellen:

1. DosAmp
2. winfreak
3. Wynton

Wohlgemerkt, es ist nicht so, dass das hier zwingend eine "Entweder-Oder" Wahl ist. Wynton z.B. hat klar gemacht, dass er gerne mit DosAmp zusammenarbeiten würde, das können die beiden dann untereinander ausmachen, aber all diese Details kann man nachher noch klären. Ich möchte für den Anfang aber eine klare Verantwortlichkeit haben, eine Person der die Community zutraut, das Forum zu administrieren.

Die Umfrage dauert 8 Tage (bis Sonntag, 21.02.16, 19 Uhr).

Zitat von Arnulf zu Linden

Bei Videoschnitt werden große Datenmengen bewegt. Also spielt die RAM-Performance eine Rolle. shared memory für die On-Die-Grafik ist dafür nicht gerade förderlich. Außerdem sind nur 8 GiB RAM vorgesehen. Davon noch was für shared memory abzuzwacken ist suboptimal.

Wenn das eine ernsthafte Sorge ist, würde ich halt einfach noch mehr RAM einbauen, anstatt einer dedizierten Grafikkarte.

Zitat von Alpha

Wie genau meinst du das? Ich habe eine initramfs im Einsatz, weil LUKS. Gibt zwei Optionen. Entweder direkt in den Kernel miteinkompilieren oder im UEFI mitübergeben. Ich mache ersteres.. zweiteres sollte aber kein Problem sein. Mit efibootmgr einfach diese angeben:

Code

efibootmgr --create --disk sda --part 1 --label "Gentoo Linux" --loader '\efi\gentoo\boot\kernel.efi' -u initrd='\efi\gentoo\boot\initramfs.img'

Oder worauf willst du hinaus?

Ah okay, wusste nicht dass UEFI auch die initramfs laden kann, danke für die Info.

Stellt sich aber die Frage, wie das mit dem Signieren der initramfs aussieht, und wer die Signatur davon prüft..?

Weil in der initramfs eine Backdoor einzubauen ist vermutlich der einfachste Angriffsvektor überhaupt. Einfach ein Shellscript rein was den den Passwort-Prompt von LUKS simuliert und schon hab ich dein Passwort, ich brauch deinen signierten Kernel nicht mal anfassen (abgesehen davon, dass Backdoor im Kernel einbauen auch etwas mehr Können und Aufwand benötigt).

Nachtrag: Die imho einfachste Alternative, wenn man auf einem System mit Microsoft-Keys was booten will ist HashTool. http://blog.hansenpartnership.com/linux-foundati…ystem-released/

On-Topic: Wie machst du das mit der Initramdisk?

Zitat von mrshadowtux

Man sieht hier schön, wie kompliziert es Microsoft dem Nutzer systematisch macht, seinen PC mit Linux einzurichten. Zum Glück kann man das noch im BIOS abschalten, die Frage ist halt wie lange noch. Wenn es die Abschaltoption in Zukunft nicht mehr gibt, kann dieses Tutorial durchaus nützlich sein.

Off-Topic: Ich finde, Microsoft verdient hier eher Lob. Es ist Microsoft zu verdanken, dass man auf ausnahmsweise jedem UEFI die Microsoft-Schlüssel löschen und eigene einbauen kann. Damit man Geräte mit Windows-Aufkleber verkaufen darf, muss man dem User erlauben, seine eigenen Secureboot-Zertifikate zu installieren.

Jede Wette, dass wenn Microsoft diese Klausel nicht hätte, dass viele Hersteller solche Funktionen selber gar nicht einbauen würden. Und würde Microsoft Secureboot nicht erzwingen, glaube ich hätten wir das auch nicht.

Kurzum: Würde Microsoft die Secureboot-Regeln den Herstellern überlassen, wäre die Situation vermutlich noch viel schlimmer.

Leute, wir sind hier nicht im Off-Topic. Letztendlich ist es Michales Entscheidung, ob er seine Gehversuche im Internet macht oder nicht. Er wurde hinreichend darauf hingewiesen, warum das vielleicht eine dumme Idee ist. Wenn er nicht auf euch hören will, will er nicht auf euch hören. Kann man okay finden oder nicht, ist aber kein Grund hier den Thread vollzustammen. Entweder helft ihr ihm, oder ignoriert den Thread hier kommentarlos.

Zitat von tk1908

Gibt es bei BTRFS irgendetwas wichtiges zu beachten?

Ich persönlich will von btrfs wieder wegkommen, es nicht kompatibel mit meiner Anwendung:

Bist du ein User wie ich, der die Platte immer ziemlich voll hat und ab und auch mal komplett ausfüllt, dann rate ich davon ab, da btrfs nur funktioniert wenn es ein paar Prozente zum rumscheffeln hat. Bei mir läuft der entsprechende Kernelthread dann auch auf 100%, wenn ich mal wieder keinen Plattenplatz habe, was essentiell jegliches I/O massiv ausbremst.

Ausserdem haben einige Anwendungen andere Annahmen über die Konsistenzgarantien vom Dateisystem als das was btrfs bietet.

Zitat

Something to note here is that while btrfs’s semantics aren’t inherently less relaible than ext3/ext4, many more applications corrupt data on top of btrfs because developers aren’t used to coding against filesystems that allow directory operations to be reordered (ext2 is perhaps the most recent widely used filesystem that allowed that reordering).

http://danluu.com/file-consistency/

Ich kann es auf meinem btrfs fast zuverlässig reproduzieren, dass wenn bei mir die Platte voll ist, Firefox seine Cookie-Datei danach zerschossen ist.

Zitat von thosch97

Das sind noch zu wenig verwirrende Layer, pack doch noch ein bisschen md-RAID und nochmal ne Paritionstabelle dazwischen.

Unter Arch würde ich davon abraten, btrfs direkt im LUKS zu fahren. Erstens gibt es dann kein verschlüsseltes Swap, denn waren die mkinitcpio Hooks vor einem Jahr nicht darauf ausgelegt zwei Container mit einem Schlüssel zu entschlüsseln. Ausserdem bin ich mir nicht sicher, ob die Hooks mit den Subvolumes automatisch klarkommen.

Der Thread ist nicht im Off-Topic, persönliche Geplänkel sind zu unterlassen.

Zitat von Der Doktor

Welche Desktopumgebung eignet sich am besten für HiDPI?

Hab so ein paar Probleme mit meinen VMs, die haben einfach eine sehr kleine UI auf dem Surface. Gnome scheint da nicht so toll zu sein, hab zwar mit dem Tweaking Tool rumhantiert, aber das Window Scaling ließ sich auch per Konsolenbefehl nicht auf was ungerades (aka 1.2 oder so) umstellen. Konnte nur auf 1 oder 2 stellen und 2 war viel viel zu groß. Oder ich habe irgendetwas ziemlich falsch gemacht. System ist Debian 8 mit Gnome 3.
Hab gehört das Xfce ein HiDPI Setting hat. Hat da einer Erfahrung oder sieht was ich vielleicht bei Gnome falsch mache?

Meiner Erfahrung nach nicht, nein. Ausser eben du hast dermassen hohe Auflösung dass 2x Skalierung Sinn macht. Ich hab mir unter GNOME beim Tweak-Tool unter "Fonts" den "Scaling Factor" etwas erhöht. Ändert aber nichts an den Pixeln. Leider erzwingt GNOME, soweit ich weiss, inzwischen eine fixe DPI-Einstellung. Früher konnte man die DPI vom X11-Server einstellen, kann sein dass das mit anderen Window-Managern noch geht, dann skaliert GTK etc auch die Icons mit.

Zitat von Der Doktor

Aber gibt es nicht eine Möglichkeit dem System einfach zu sagen, dass es wenn etwas bei VGA angeschlossen wird automatisch Mirroring statt zweiten Desktop macht?

Die meisten Desktops speichern die Konfigurationen die du über das Controlpanel setzt in der Regel auch ab. Wenn das nicht klappt, bräuchten wir schon etwas mehr Infos was für ein Panel, Distribution etc du verwendest.

Ansonsten kannst du versuchen deine Settings händlisch beim Starten setzen:
https://wiki.ubuntu.com/X/Config/Resol…es_persistently

Scheint mir ein Treiberproblem zu sein, alle Desktops verwenden an sich das xrandr Protokoll fürs Setup. Schau ob du alternative Treiber findest, notfalls evtl mesa.