|
|
|
|
Hm ok. Ich bin offensichtlich nicht nerdy genug für diesen Gag
|
|
|
|
|
|
|
Siehe Eintrag unter recursion
|
|
|
|
|
|
|
Das ist halt keine Rekursion.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 03.05.2019 20:14]
|
|
|
|
|
|
| Zitat von Rufus
Das ist halt keine Rekursion.
| |
why not?
|
|
|
|
|
|
|
|
|
|
|
Was hast du denn da für eine Seite gefunden?
|
|
|
|
|
|
|
Das ist halt der erste Treffer zu "iteration vs rekursion".
|
|
|
|
|
|
|
Boah
|
|
|
|
|
|
|
| Zitat von Oli
Das ist wie das Naturgesetz, dass man Lösungen für ein Problem immer kurz nach dem Verfassen von stackoverflow posts findet.
| |
Kenne ich so nicht. Meine Probleme sind vermutlich zu einfach oder rudimentär, bis jetzt habe ich immer mehrere Lösungen auf Stackoverflow gefunden und bin nie in die Verlegenheit gekommen, eine neue Frage stellen zu müssen. Me so dumb.
|
|
|
|
|
|
|
Ich kenn das größtenteils auch nur als "man stellt mal eine SO-Frage im Jahr, die allenfalls zwei Jahre später ne Antwort oder nen Kommentar kriegt, wo die Frage falsch verstanden wird".
e: Meine letzten drei SO-Fragen:
2016: "[jenkins] Run command on slave shutdown", keine Antworten, erster Kommentar: "Have no idea what are you asking. Please add more details"
2015: "Why is `io.BytesIO` not a `io.BufferedRandom` implementation?", Antwort: Weil es was anderes erbt ¯\_(ツ)_/¯
2014: "Hooking framework (Detours-like)" mit einer Gold-Antwort
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 04.05.2019 0:35]
|
|
|
|
|
|
|
|
|
|
Ich auch. Von 27 Fragen habe ich auf 25 eine Antwort bekommen, bei 17 davon habe ich eine Antwort als Loesung angenommen.
Wobei meine Fragen meist in Richtung "Was macht der Sprachstandard oder Compiler in der Situatuation?" oder "Welche Loesung ist optimal?" gehen und ein paar ein Bezug Gtk.
Es kommt sicher auf die Art der Frage und die Formulierung an.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 04.05.2019 19:28]
|
|
|
|
|
|
Wieso kann Mozilla nicht einfach ein neues intermediate cert ausrollen und fertig?
|
|
|
|
|
|
|
| Zitat von Rufus
Wieso kann Mozilla nicht einfach ein neues intermediate cert ausrollen und fertig?
| |
Bin jetzt kein Crypto-Experte, aber da die "End-Zertifikate" auf einem bestimmten Intermediate basieren, muss alles neu ausgestellt/signiert werden. Soweit ich weiss, haben sie ein neues erstellt, es muss nur grade alles nochmal durch den Prozess.
|
|
|
|
|
|
|
Was exakt das ist, was sie getan haben als Update. Gleicher Key, gleicher Name, längere Gültigkeit, fertig.
| Zitat von APC|G-o-C
| Zitat von Rufus
Wieso kann Mozilla nicht einfach ein neues intermediate cert ausrollen und fertig?
| |
Bin jetzt kein Crypto-Experte, aber da die "End-Zertifikate" auf einem bestimmten Intermediate basieren, muss alles neu ausgestellt/signiert werden. Soweit ich weiss, haben sie ein neues erstellt, es muss nur grade alles nochmal durch den Prozess.
| |
Nö, im X.509-System refenzierst du Zertifikate per Namen (nicht Fingerprint), ergo kannst du einfach ein Intermediate erneuern indem du den gleichen Namen mit dem gleichen Key einfach nochmal ausstellst.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 05.05.2019 20:14]
|
|
|
|
|
FreeSync
|
Es ist schlecht dokumentiert von AMD, generell. Sowohl fuer Windows und Linux und die Nutzer sind auch alle verwirrt. Und es funktioniert nicht automatisch.
Warum nochmal FreeSync?
- Wenn die Grafikkarte zu schnell ist, bekommt der Monitor halbe Frames untergeschoben, also Tearing. Wahrnehmung ist je nach Spiel und Mensch unterschiedlich.
- Dagegen hilft VSYNC mit Double-Buffering, dass erzwingt die Einhaltung der Monitorfrequenz. Wenn die Grafikkarte jetzt aber nicht schnell genug Frames liefert, muss die Grafikkarte auf den Monitor warten und wir bekommen starke Einbrueche der Framerate.
- Dagegen hilft VSYNC mit Triple-Bufferung, aber noch mehr Buffer fuehr zu noch mehr Latenz. Fuer mich fuehlt sich zum Beispiel CS so schwammig an.
Die Antwort darauf ist GSYNC von Nvidia und FreeSync von AMD. GSYNC hat sich erledigt, weil es ein proprietaere Loesung von Nvidia ist und kompatible Monitore somit teurer sind, waehrend FreeSync bereits in DisplayPort eingeflossen und die kompatiblen Monitore auch nicht sonderlich mehr kosten - obendrein wird Intel FreeSync womoeglich mit der naechsten CPU/GPU-Generation endlich unterstuetzen. Seltener Fall, ein oeffener Standard hat gewonnen, obwohl spaeter am Markt
Und wie funktioniert es unter Linux? Ihr braucht eine neuere AMD-Grafikkarte mit FreeSync kompatiblen Monitor, angeschlossen ueber DisplayPort. Es geht nicht mit HDMI! Dazu die passende Software:
- Linux >= 5.0
- MESA >= 19.0
- Quelloffenen Xorg Videotreiber xf86-video-amd fuer den Userspace
Es geht noch nicht mit Wayland, also muesst ihr unter X11 arbeiten. Fedora 30 verwendet bei mir den 08/15 Modesettingtreiber, also muesst ihr da den Userspaceteil von AMDGPU nachinstallieren mit dnf install xorg-x11-drv-amdgpu oder unter Archlinux mit pacman -S xf86-video-amdgpu .
Datei /etc/X11/xorg.conf.d/20-amgpu.conf anlegen und eintragen:
|
Code: |
Section "Device"
Identifier "AMD"
Driver "amdgpu"
Option "DRI" "3"
Option "VariableRefresh" "true"
EndSection
|
|
Hier habe ich nostalgische Gefuehle bekommen, sollte besser automatisch funktionieren.
Jetzt mit X11 einloggen und pruefen, xrandr --props | less
|
Code: |
TearFree: auto # soll auf on oder auto stehen
supported: off, on, auto
vrr_capable: 1 # soll auf 1 stehen
range: (0, 1)
|
|
Bei mir hat es zuerst nicht geklappt, weil die neuen HiDPI-Displays mit USB-C und FreeSync und Schlagmichtot kompliziert geworden sind. Achtet darauf eine moegliche Option fuer Display-Port >= 1.x eingeschaltet zu haben und ebenso eine speziellen Option fuer FreeSync. Letztere versteckt sich bei LG in den Game-Settings* und die war noch ausgeschaltet.
Und was mach ich jetzt mit der VSYNC-Option, sicher AUS oder?
Die veraltet Dokumentation von AMD bezieht sich auf die quellgeschlossen AMDGPU-Pro Treiber, schlaegt aber vor VSYNC eingeschaltet zu lassen. Das hat mir nicht gefallen. Sind von FreeSync ist doch den Behelf VSYNC los zu werden?! Und dann wird es auch verwirrend und komisch. Das Chilldingsbums oder EnhancedSync macht vermutlich unter Windows, was man auch per Hand in einem Spiel machen kann und - fuer mich - die sinnvollste Konfiguration darstellt:
- FreeSYNC AN im System
- VSYNC AUS im System und/oder Spiel
- Framerate der Spielengine auf die Monitorfrequenz oder Monitorfrequenz -1 begrenzen
Fuer CS:GO also fps_max 60 bei einem 60 Hz Monitor, bei mir geht es mit 60. Butterweich, keine Einbrueche der Framerate und keinen schwammiges Gefuehl mehr.
Ich hoffe es hilft hier jemand. Bei Gelegenheit sollte ich das in ein Wiki (also bei Archlinux) packen.
* Dabei habe ich dann auch gelernt, dass es mittlerweile mehrere Firmwareupdates fuer meinen Monitor gibt. Ein Changelog habe ich nicht gefunden.
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 06.05.2019 0:34]
|
|
|
|
|
|
Sweet, ich danke dir für den Input.
Das steht bei mir demnächst auch alles an.
|
|
|
|
|
|
|
Ich hätte ja gerne mal, dass mein Browser Videos ohne Tearing anzeigen kann, aber das ist vermutlich zu viel verlangt? Vermutlich ja, solange der Browser nicht mal seine Certs im Auge behalten kann...
Und warum geht das nicht über HDMI?
|
|
|
|
|
|
|
frag mal die leute, die auf x schwören, warum sie immer noch code aus den späten 70ern nutzen.
|
|
|
|
|
|
|
| Zitat von RichterSkala
Und warum geht das nicht über HDMI?
| |
Variable Refresh Rate ist wohl erst seit HDMI 2.1 in der Spezifikation.
|
|
|
|
|
|
|
Japp. Der ursprüngliche Quellcode würde vor zwei Jahren bereitgestellt, dürfte das vorläufige Fehlen von Wayland und HDMI erklären. AMD wird DisplayPort priorisiert haben, weil so ziemlich jeder FreeSync fähige Monitor DisplayPort hat und schon viel länger HiDPI kann. HDMI kommt sicher noch, hängt aber in allen Bereichen hinterher, weil es aus dem Unterhaltungsbereich kommt. Bei der Einbettung in USB-C hängt HDMI eben so hinterher.
Ich bevorzuge DP sowieso, mein neuer Monitor in der Arbeit hat kein HDMI mehr
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 06.05.2019 21:49]
|
|
|
|
|
|
Ich hab dafür einen, der hat zwar FreeSync, aber nur HDMI (und VGA, lol)
|
|
|
|
|
|
|
Wenigstens kannst du eine alte Möhre aus Nostalgiegründen anstecken
|
|
|
|
|
|
|
Ich soll ein (C/C++) Programm schreiben, welches ein anderes Programm aufruft und überwacht, wie lange das andere Programm läuft. Es geht darum, beim Start eine Lizenz auszuchecken und wieder zurück zu geben, sobald die Software beendet wird.
Es geht um VMWare Lizenzen.
Im Idealfall funktioniert mein Programm als wrapper um VMWare. Wie löse ich es am elegantesten, dass mein Programm mitkriegt, wenn das mit system() oder popen() gecallte VMWare beendet ist? Gibt's da irgendwelche advanceden sandboxing features in Linux oder so?
/e: ich schätze, fork() und execvp() sind am sinnvollsten.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 07.05.2019 15:14]
|
|
|
|
|
|
du möchtest dir gerne wait angucken.
|
|
|
|
|
|
|
pid = fork();
switch(pid) {
case -1:
perror("fork");
return 1;
case 0:
return exec...();
}
waitpid(pid, &child_status, 0);
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 07.05.2019 20:38]
|
|
|
|
|
|
Ja, so habe ich es gemacht. Ich teste es morgen mal mit VMware, ich schätze es kann problematisch werden, wenn das Programm irgendwelche Prozesse spawned, die keine children meines tools sind?
|
|
|
|
|
|
|
problematisch in bezug worauf?
|
|
|
|
|
|
|
Du kannst den Parent eines Prozesses nicht ändern. Der Prozesseintrag vom Parent kann erst gelöscht werden, wenn a) alle Kindprozesse terminiert haben und b) er von seinem Parent gewaitet wurde. Ergo wird dein waitpid() blockiere, bis die gesamte Prozesshierarchie, die durch den fork + exec entstanden ist, terminiert hat.
|
|
|
|
|
|
|
Mit Kernel 5.1 wird Linux asynchrone I/O Operationen direkt unterstützen. War das nicht ein fehlendes Feature das Rats oder Traxer immer vermisst haben
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 08.05.2019 11:02]
|
|
|
|
|
Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |