|
|
|
|
| Zitat von RichterSkala
Ich finds überraschend, dass sich das noch lohnt. Oder kommt dabei so viel Rechenleistung rum?
| |
Monero (und seine Ableger) nutzen einen CPU/GPU freundlichen Algorithmus (CryptoNight). Da ist es das Designkonzept, die ASIC-Flut die Bitcoin Mining unrentabel gemacht hat, zu vermeiden (durch Speicherhungrigkeit/CPU-Cache-Affinität, dann muss man nicht nur die CPUs skallieren sondern auch den Speicher).
Aber Proof of Work gehört eh der Vergangenheit an. Proof of Stake gehört die Zukunft.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von GH@NDI am 09.02.2018 8:21]
|
|
|
|
|
|
|
|
|
|
Hier wird sich immer über schlechte Bildschirmauflösung in Thinkpads geärgert, meanwhile wird in meinem Freundeskreis geranted, dass Auflösungen unter FHD nicht mehr zu kriegen sind und HiDPI unter Linux derbe kacke sei.
|
|
|
|
|
|
|
|
|
|
|
| Zitat von RichterSkala
Hier wird sich immer über schlechte Bildschirmauflösung in Thinkpads geärgert, meanwhile wird in meinem Freundeskreis geranted, dass Auflösungen unter FHD nicht mehr zu kriegen sind und HiDPI unter Linux derbe kacke sei.
| |
Hier meine Erfahrung mit einem HiDPI-Monitor:
Software
Mit GNOME 3.26 auf Wayland habe ich keine Probleme mit dem 4K Monitor. Skalierung auf 200%, fertig. Wohl ab dem nächsten Release kommen dann schon Fliesskommaskalierung, damit sind dann auch Werte wie 130% oder 170% wählenbar. Gemischter Zweischirmbetrieb funktioniert ebenso, also ein Monitor mit normaler DPI und einer mit HiDPI.
Wie auf allen System, alte GUI-Anwendung mit Qt4, Gtk2 oder MOTIF skalieren nicht. Klassisches IT-Fehler, es gab schon immer Displays mit mehr DPI (etwa das X220).
Hardware
Grundsätzlich, HiDPI geht erst ab HDMI2.0 (2013), deswegen ist die Situation da auch generell eher mässig. DP 1.1 (2007) kann schon HiDPI, aber nur mit 30 Hz. Ab DP 1.2 (2009) geht dann alles, dafür braucht man aber einen Skylake oder besser. Alle neueren Laptops verwenden intern eDP, nicht mehr LVDS.
Linux & Hardware
- Intel HD3000 (SandyBridge) mit DP 1.1 (max. 30Hz) -> läuft
- AMD RX560 DP1.4 -> läuft
- AMD RX560 HDMI 2.0b -> läuft nicht
Die RX560 kann mit HDMI schon HiDPI, aber dazu muss man ab Kernel 4.15 den neuen AMD-Grafikstack per Option auch für ältere Grafikkarten einschalten. Mit Vega sollte es sofort gehen. Gefrickel gilt nicht, somit gilt läuft nicht.
Theoretisch kann man mit Linux und DP 1.1 und einem X220 mehr als 30 Hz aus dem DisplayPort herausprügeln, am VESA-Standard vorbei. Die PixelClock der Intelchips kann nämlich rechnerisch 4K mit etwa 45 Hz ansteuern. Das sieht natürlich kein Inteltreiber vor, genauso unter Mac und Windows. Irgendwelche Bastler haben aber mit Modelines und XRANDR das "Display Übertakten" ersonnen, tatsächlich wir die Darstellung damit gefühlt wohl flüssiger. Ich lasse es und und werte es nicht, Gefrickel gilt nicht und man befindet sich außerhalb des Standards. Eine HD3000 jappst bei 1366x768 + 3840x2160 sowieso schon nach Luft.
PS: Die Fliesskommaskalierung scheint auch etwas zu sein was Macnutzer haben wollen. Die bemängeln tatsächlich, das 4K auf 27' mit Skalierung nicht zu HiDPI auf dem Laptop "passt", wegen Skalierung und bla. Und so bewerten die Macleute tatsächlich 27' 4K-Monitore auf Amazon als schlecht. Verwöhnte kleine Kinder.
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 09.02.2018 12:20]
|
|
|
|
|
|
| Wohl ab dem nächsten Release kommen dann schon Fliesskommaskalierung, damit sind dann auch Werte wie 130% oder 170% wählenbar. | |
pffcht
|
|
|
|
|
|
|
Moin.
Ich habe angefangen eine Simulation zu schreiben, erstmal für einen ganz einfachen Fall mit bekannter analytischer Lösung.
|
Code: |
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
// #include <omp.h>
#define phillu p2l*d*cos(alpha)
#define phrefl p2l*d*cos(beta)
#define pxlsize 7.56e-6
#define lambda 560e-9
#define p2l 2*M_PI/lambda
int main(int argc, char* argv[]) {
int nbeta = atoi(argv[1]);
int nmirror = atoi(argv[2]);
double alpha = atoi(argv[3]) * M_PI/180.;
printf("#alpha = %.12E\n", alpha);
printf("#b\tbeta\tAmplitude\tRealteil\tImaginärteil\n");
for(int b = 0; b<nbeta; b++) { //Winkel durchlaufen
double R=0, I=0; //Realteil und Imaginärteil
double beta = b * M_PI / nbeta;
for (int i=-2; i<3; i+=2) { //Pixel duchlaufen
for (float j=0.5; j<nmirror; j++) { //Elementarwellen eines Pixel durchlaufen
double d = (i + j/nmirror)*pxlsize;
double phase = phillu + phrefl;
R+=cos(phase);
I+=sin(phase);
}
}
printf("%d\t%E\t%.12E\t%.12E\t%.12E\n",b,beta,sqrt(R*R + I*I),R,I);
}
}
|
|
Dass nbeta und nmirror die Dauer der Berechnung beeinflussen ist ja erwartet, aber bei gleichem nmirror und nbeta dauert die Berechnung immer(?) gleich lang, mit einer Ausnahme:
alpha = 90
Mathematisch wird das Problem dadurch einfacher, aber eigentlich ist meine Erwartung, dass die Berechnung genauso lange dauert. Tut sie aber nicht. Sie wird auch nicht schneller. Sie dauet 4 mal so lange. WTF?
Was habe ich da angestellt?
/e: phillu und phrefl stehen nur aus Spaß als #define drin. Es scheint zu funktionieren und ich muss nicht den Quelltext durchsuchen wenn ich es ändern will
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 09.02.2018 14:47]
|
|
|
|
|
|
Wird wohl an der Implementierung von cos() in der glibc liegen. Mit Optimierungen, -O2 oder so, geht der Unterschied weg. Ich schaue mir gerade die glibc an, aber da sind (wenn ich es richtig sehe) je nach Archiktektur unterschiedliche cos Implementierungen drin, und ich habe jetzt keine Lust, da weiter zu gucken.
|
|
|
|
|
|
|
mit clang scheint es gleich schnell zu sein. Mit gcc -O2 wird es ähnlich schnell, mit -O3 lief alpha = 90 sogar minimal schneller.
Mit gcc -Os wird alpha /= 90 einen Faktor 2 schneller, alpha = 90 nicht.
Also ist es irgendein wilder Compiler-Kram, nichts generell seltsames was da im Code passiert.
Danke!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 09.02.2018 15:17]
|
|
|
|
|
|
sysdeps/x86_64/fpu/s_sincosf.S
|
Code: |
/* Short algorithm description:
*
* 1) if |x|==0: sin(x)=x,
* cos(x)=1.
* 2) if |x|<2^-27: sin(x)=x-x*DP_SMALL, raising underflow only when needed,
* cos(x)=1-|x|.
* 3) if |x|<2^-5 : sin(x)=x+x*x^2*DP_SIN2_0+x^5*DP_SIN2_1,
* cos(x)=1+1*x^2*DP_COS2_0+x^5*DP_COS2_1
* 4) if |x|< Pi/4: sin(x)=x+x*x^2*(S0+x^2*(S1+x^2*(S2+x^2*(S3+x^2*S4)))),
* cos(x)=1+1*x^2*(C0+x^2*(C1+x^2*(C2+x^2*(C3+x^2*C4)))).
* 5) if |x| < 9*Pi/4:
* 5.1) Range reduction:
* k=trunc(|x|/(Pi/4)), j=(k+1)&0x0e, n=k+1, t=|x|-j*Pi/4.
* 5.2) Reconstruction:
* sign_sin = sign(x) * (-1.0)^(( n >>2)&1)
* sign_cos = (-1.0)^(((n+2)>>2)&1)
* poly_sin = ((((S4*t^2 + S3)*t^2 + S2)*t^2 + S1)*t^2 + S0)*t^2*t+t
* poly_cos = ((((C4*t^2 + C3)*t^2 + C2)*t^2 + C1)*t^2 + C0)*t^2*s+s
* if(n&2 != 0) {
* using cos(t) and sin(t) polynomials for |t|<Pi/4, results are
* cos(x) = poly_sin * sign_cos
* sin(x) = poly_cos * sign_sin
* } else {
* sin(x) = poly_sin * sign_sin
* cos(x) = poly_cos * sign_cos
* }
* 6) if |x| < 2^23, large args:
* 6.1) Range reduction:
* k=trunc(|x|/(Pi/4)), j=(k+1)&0xfffffffe, n=k+1, t=|x|-j*Pi/4
* 6.2) Reconstruction same as (5.2).
* 7) if |x| >= 2^23, very large args:
* 7.1) Range reduction:
* k=trunc(|x|/(Pi/4)), j=(k+1)&0xfffffffe, n=k+1, t=|x|-j*Pi/4.
* 7.2) Reconstruction same as (5.2).
* 8) if x is Inf, return x-x, and set errno=EDOM.
* 9) if x is NaN, return x-x.
*
* Special cases:
* sin/cos(+-0) = +-0/1 not raising inexact/underflow,
* sin/cos(subnormal) raises inexact/underflow,
* sin/cos(min_normalized) raises inexact/underflow,
* sin/cos(normalized) raises inexact,
* sin/cos(Inf) = NaN, raises invalid, sets errno to EDOM,
* sin/cos(NaN) = NaN.
*/ |
|
Schon komisch, ich sehe jetzt nicht, wo da irgendwas besonders wäre.
/e: Es liegt am cos(double x), denke ich. Wenn alpha float wird, dann ist es gleich schnell. Hier vielleicht:
| Most of the double routines in libm come from IBM accurate matematical library,
which ensures <= 0.5ulp error. Trigonometric etc. functions are computed using
floating point computations, but if the possible error from that is too high, it
uses slower multiprecision computation to guarantee ultimate precise result.
Guess you just picked some worst-case values.
i386 uses the non-precise hardware instructions instead, so doesn't guarantee
the <= 0.5ulp precision. | |
https://sourceware.org/bugzilla/show_bug.cgi?id=5781
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 09.02.2018 15:45]
|
|
|
|
|
|
Super, jetzt läuft es auch ohne -Ox gleichschnell
Vielen Dank!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 09.02.2018 16:11]
|
|
|
|
|
|
Da Mathe so ein Feind von mir ist, habe ich mal aus Interesse in die Dokumentaiton der Implementierung geschaut:
C++: Falsch weil C
C : Richtig, aber dafür interessiert sich die Dokumentation nicht
Du kannst vielleicht sincos() aufrufen um noch schneller zu werden. Der C-Standard bekommt dann aber Augenpipi. Abgesehen davon finde ich die Dokumentation der LIBSTDC++ in Doxygen recht unübersichtlich, aber die Möglichkeit direkt in die Quellcodeimplementierung reinzuspringen ist nett.
Das bin nicht ich. Ich schwöre!
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 09.02.2018 16:49]
|
|
|
|
|
|
CVE-2018-6791 (plasma-desktop)
When a vfat thumbdrive which contains `` or $() in its volume label is plugged
and mounted trough the device notifier, it's interpreted as a shell command
Junge M(
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 10.02.2018 10:53]
|
|
|
|
|
|
|
|
|
|
| Zitat von csde_rats
CVE-2018-6791 (plasma-desktop)
When a vfat thumbdrive which contains `` or $() in its volume label is plugged
and mounted trough the device notifier, it's interpreted as a shell command
Junge M(
https://i.imgur.com/f1gdidbm.jpg
| |
der patch ist noch scarier...
nein, es wird nicht gefixt indem "externer input" einfach nicht inner shell evaluiert wird (warum, warum?) sondern es wird stattdessen einfach gequotete...
|
Code: |
- mx.expandMacros(exec);
+ mx.expandMacrosShellQuote(exec);
|
|
|
|
|
|
|
|
|
-
Die fragliche Datei bastelt da eine Command-Line aus dem Exec -Eintrag einer .desktop-Datei. Wahrscheinlich also ein freedesktop-Standard. Bestimmt hängt der Pöttering da auch irgendwie mit drin... jedenfalls. Vielleicht sollte jemand bei den anderen Implementierungen nachschauen gehen...
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 10.02.2018 19:54]
|
|
|
|
|
|
CVE-2018-6789
Meh Chang discovered a buffer overflow flaw in a utility function used
in the SMTP listener of Exim, a mail transport agent. A remote attacker
can take advantage of this flaw to cause a denial of service, or
potentially the execution of arbitrary code via a specially crafted
message.
———
OpenBSD tüftelt noch an Meltdown/Spectre-Patches.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 10.02.2018 22:27]
|
|
|
|
|
|
| Zitat von csde_rats
CVE-2018-6791 (plasma-desktop)
When a vfat thumbdrive which contains `` or $() in its volume label is plugged
and mounted trough the device notifier, it's interpreted as a shell command
Junge M(
https://i.imgur.com/f1gdidbm.jpg
| |
Qualifikation fuer den Funthread
Uebrigens ist die Microcodesache ein falscher Pfad von mir gewesen, ja der Microcode wurde geladen und ja, er haette nicht geladen werden sollen. Ich weiss aber nicht warum, den jetzt passiert das nicht mehr.
Dafuer weiss ich jetzt ziemlich genau, was den sofortigen Resume aus dem Suspend ausloest (fast schon ein Klassiker):
Wenn ein Tastatur oder Maus gepaired ist, aber nicht verbunden!
Bluetooth aus hilft. Oder Tastatur bzw. Maus in Reichweite bringen und einschalten. Ich habe da wohl bisher nicht bemerkt, da ich die externe Tastatur und Maus von Logitech noch nicht so lange habe und diese selten gepaired habe.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 11.02.2018 13:59]
|
|
|
|
|
|
Gutes Feature. Könnte schon etwas länger da sein, weiß ich nicht.
|
|
|
|
|
|
|
hat was von
|
|
|
|
|
|
|
Kann ich mit gdb irgendwie den Wert einer Variable speichern? Das Ding gibt einem zwar offensichtlich einen internen Speicher ($n), aber ich hab hier eine Variable, wenn ich die zu einem späteren Zeitpunkt aus dem Speicher wieder ausgebe, hat sicher der Wert verändert??
|
|
|
|
|
|
|
DENIC-WHOIS-Abfrage so:
|
|
|
|
|
|
|
Darüber habe ich mich letzte Woche Donnerstag geärgert. Wollte herausfinden, wer bei uns in der Firma als Kontakt hinterlegt ist.
Zeigt nur, dass die Politik als auch DENIC hier Datenschutz nicht verstanden haben. /usr/bin/whois geht nicht, wegen Netzwerkadmin. Ich sollte einfach immer alles Tunneln.
| Zitat von RichterSkala
Kann ich mit gdb irgendwie den Wert einer Variable speichern? Das Ding gibt einem zwar offensichtlich einen internen Speicher ($n), aber ich hab hier eine Variable, wenn ich die zu einem späteren Zeitpunkt aus dem Speicher wieder ausgebe, hat sicher der Wert verändert??
| |
Ich bin mir nicht sicher, ob ich dich falsch verstehe. Aber mit einer Convenience Variable geht es. Code interessiert nicht, ist eine Lambda-Expression, welche die Variable runterzählt von 5 auf 0. Wie du siehst, die Convenience Variable foo hält den Wert.
// edit
Ich würde weder das eine noch das andere ausschließen.
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 13.02.2018 16:42]
|
|
|
|
|
|
Hatte es statt mit set direkt mit print $3 sozusagen versucht. Kann aber auch daran liegen, dass es sich um stl container handelt und dann der pretty print versagt?
|
|
|
|
|
|
|
| Zitat von hoschi
Darüber habe ich mich letzte Woche Donnerstag geärgert. Wollte herausfinden, wer bei uns in der Firma als Kontakt hinterlegt ist.
| |
Die ausgewählte Option + Lorem Ipsum funktioniert allerdings. Also. Nicht mal Lorem Ipsum. Der Beschreibunstext des ersten Googletreffers für "Lorem Ipsum".
——
Auf mpd-devel geht es gerade wieder hoch her, weil Billy Wright von Cary Audio heftigst am Abbullshitten ist und meint er müsse ja den GPL-verletzenden Code nicht rausgeben, wenn er ihn bis "in nem Monat oder so" hat neuschreiben bereinigen hat lassen.
Ich finde es lässt extrem tief blicken, wie viele von diesen "High End Audio" Herstellern da mit marginaler Eigenleistung und in kompletter Ignoranz jeglicher Lizenzen einen Reibach mit GPL-Code machen. Vor ein paar Wochen war ein anderer Fall auf der Mailingliste, wo ein ähnlicher Hersteller seine proprietären Drecksformate eingebaut hat, aber auch ums Verrecken nicht den Source rausgeben wollte.
Auch richtig schön mit "Oh, wie haben einen GPL-Request für unsere Firmware bekommen? Löscht das mal alles schnell vom FTP!"
So richtig, richtig Scheiße. Kudos für Max Kellermann, dass er da durch diesen Morast von Scheiße wandert.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 13.02.2018 17:51]
|
|
|
|
|
|
Das ist simple Utilization-Erfassung im Vorfeld der DSGVO am Horizont. Dass (die deutsche Form von) whois weg muss wissen die nämlich auch.
|
|
|
|
|
|
|
| Zitat von hoschi
Darüber habe ich mich letzte Woche Donnerstag geärgert. Wollte herausfinden, wer bei uns in der Firma als Kontakt hinterlegt ist.
Zeigt nur, dass die Politik als auch DENIC hier Datenschutz nicht verstanden haben. /usr/bin/whois geht nicht, wegen Netzwerkadmin. Ich sollte einfach immer alles Tunneln.
| Zitat von RichterSkala
Kann ich mit gdb irgendwie den Wert einer Variable speichern? Das Ding gibt einem zwar offensichtlich einen internen Speicher ($n), aber ich hab hier eine Variable, wenn ich die zu einem späteren Zeitpunkt aus dem Speicher wieder ausgebe, hat sicher der Wert verändert??
| |
https://i.imgur.com/iX0pen0.png
Ich bin mir nicht sicher, ob ich dich falsch verstehe. Aber mit einer Convenience Variable geht es. Code interessiert nicht, ist eine Lambda-Expression, welche die Variable runterzählt von 5 auf 0. Wie du siehst, die Convenience Variable foo hält den Wert.
// edit
Ich würde weder das eine noch das andere ausschließen.
| |
Alter die Konsole ist ja der reinste Augenkrebs.
|
|
|
|
|
|
|
Super, jetzt folgen 7 MB Text über Shelltransparenz..
|
|
|
|
|
|
|
Shelltransparenz ist ja OK, aber nicht mit so ner opacity. Willste die shell oder den Text dahinter lesen?
|
|
|
|
|
|
|
| Zitat von Rufus
Super, jetzt folgen 7 MB Text über Shelltransparenz..
| |
Ja das sehe ich auch schon kommen. Aber dafür könnte man das Feature auch locker streichen.
|
|
|
|
|
|
Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |