Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: mercury, Schalentier


 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« vorherige 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 nächste »
erste ungelesene Seite | letzter Beitrag 
GH@NDI

ghandi2
 
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]
09.02.2018 8:19:35  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Mal was anderes
Keinarmiger Linuxbandit
09.02.2018 11:03:56  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
RichterSkala

AUP RichterSkala 31.12.2010
...
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.
09.02.2018 11:17:25  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
Denenenene watman.
09.02.2018 11:33:38  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
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]
09.02.2018 11:59:45  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
 
Wohl ab dem nächsten Release kommen dann schon Fliesskommaskalierung, damit sind dann auch Werte wie 130% oder 170% wählenbar.



pffcht fröhlich
09.02.2018 13:11:43  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
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 peinlich/erstaunt
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 09.02.2018 14:47]
09.02.2018 14:43:29  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
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.
09.02.2018 15:14:22  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
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]
09.02.2018 15:16:15  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
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]
09.02.2018 15:32:15  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
Super, jetzt läuft es auch ohne -Ox gleichschnell fröhlich

Vielen Dank!
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 09.02.2018 16:11]
09.02.2018 16:11:09  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
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]
09.02.2018 16:40:38  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
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]
10.02.2018 10:52:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
Alter.
10.02.2018 13:33:28  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
 
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);
10.02.2018 19:40:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021


-

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]
10.02.2018 19:54:05  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
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]
10.02.2018 20:30:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
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]
11.02.2018 13:58:58  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021


Gutes Feature. Könnte schon etwas länger da sein, weiß ich nicht.





traurig
11.02.2018 22:18:50  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
hat was von
11.02.2018 22:25:15  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
RichterSkala

AUP RichterSkala 31.12.2010
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??
12.02.2018 18:22:00  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
DENIC-WHOIS-Abfrage so:

13.02.2018 14:56:06  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

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??





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]
13.02.2018 16:18:37  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
RichterSkala

AUP RichterSkala 31.12.2010
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?
13.02.2018 16:31:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
 
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]
13.02.2018 17:40:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rufus

AUP Rufus 12.02.2008
 
Zitat von csde_rats

DENIC-WHOIS-Abfrage so:

https://i.imgur.com/segadnPl.png


Das ist simple Utilization-Erfassung im Vorfeld der DSGVO am Horizont. Dass (die deutsche Form von) whois weg muss wissen die nämlich auch.
13.02.2018 20:08:42  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
 
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.
13.02.2018 20:13:02  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rufus

AUP Rufus 12.02.2008
Super, jetzt folgen 7 MB Text über Shelltransparenz..
13.02.2018 20:59:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
Shelltransparenz ist ja OK, aber nicht mit so ner opacity. Willste die shell oder den Text dahinter lesen?
13.02.2018 21:02:27  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
 
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.
13.02.2018 21:37:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« vorherige 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 nächste »

mods.de - Forum » Linux » 

Hop to:  

Thread-Tags:
gnu  linux 
| tech | impressum