|
|
|
|
|
|
|
Der hier ist fuer dich. Ich habe es nachgelesen, sie wollen wohl wirklich nur vier Prozesse oeffnen.
Die vier Prozesse passen sich mit der Anzahl der Kerne und Hauptspeicher nicht weiter an, lediglich per Hand kann man die Zahl insgesamt aendern. Ich denke mal ein Zweikernsystem mit 4 GB verhaelt sich anders als ein 16 Kernsystem mit 16 GB und auf die Art schmiert einem auch immer 1/4 aller Tabs ab. Was bei mir eine ganze Menge sein wuerde.
Die Idee nicht jedes Tab mit einem Prozess zu bedienen ist womoeglich nicht falsch, aber ich wuerde es dynamisch anpassen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 14.06.2017 16:46]
|
|
|
|
|
|
|
|
|
Speicherverbrauch ist eh so eine ganz lustige Sache. Bei den übergewichtigen Runtimes ist es nicht ungewöhnlich allein unter lebenden Objekten >100 % Overhead zu haben. CPython ist da auch ganz groß. 32 Bytes belegen da erstmal 65 Bytes (sauber vorbei — aus unbekannten historischen Gründen sind Python bytes zusätzlich null-terminiert, weil das früher halt deren Strings waren), ein pupsiger int mutiert zu einem 22 Byte-Monster und Hashtable-Datenstrukturen genehmigen sich selbst bei größeren N 50-80 Bytes extra pro Element. Ein kurzer String hat da irgendwas um die 50 oder 60 Bytes.
// Python ist halt nur für Big Data.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 14.06.2017 16:54]
|
|
|
|
|
|
|
|
|
Das mit WhatsApp hat doch schon mal die Runde gemacht? Damit keine boesen Links zu den Nutzer gehen oder sowas 
|
|
|
|
|
|
|
|
|
|
|
|
Vor allem macht es das doch schon länger. Wie sonst soll es schon während dem Tippen den Titel (und favicon) von Seiten anzeigen?
|
|
|
|
|
|
|
|
|
|
|
Aber wozu Googlen, lieber nochmal den Skandal neu erfinden bei Twitter 
|
|
|
|
|
|
|
|
|
|
|
das ist schön, ich nutze und will kein vmware. kvm it is.
war auch nicht so gemeint, als wenn ich aus dem ci dingen die vm kontrollieren will, sondern eher wie ich die system spezifischen builds wie z.b. macos oder windows laufen lassen kann. die kann ich halt nicht so ohne weiteres cross compilen, wenn ich die nativen compiler und co nutzen muss.
| | Zitat von hoschi
| | Zitat von Traxer
cross builds fallen vermutlich einfach mal raus?
| |
Es ist sicher aufwendiger, aber wenn die Buildkonfiguration ohnehin Cross-Plattform ist, dann kann muss Jenkins das auch koennen.
| |
wie hier drüber schon geschrieben, dass problem was ich hier sehe ist, dass ich die nativen libs und compiler für die sachen nutzen muss. damit sind so dinge wie mingw und cygwin ( ) einfach direkt raus.
die MS compiler sachen gibts nicht als cross version die auf linux läuft und das gemurkse via wine will ich mir eher so nicht antun.
das war vielleicht heute morgen eher nicht so sonderlich gut von mir geschrieben. 
was ich eigentlich damit sagen / fragen wollte war, was nimmt man am besten dafür, wenn ich effektiv ne ganze latte an differenziellen VMs aufsetze und dadrin die nativen build tools nutze via cmake.
sind die ci sachen dafür ausgelegt? auf was muss ich da achten? was kann bzw wird da schiefgehen, so aus möglicher erfahrung?
ich hab den ci kram bisher nur in mehr oder weniger fertiger konfiguration genutzt und möchte / muss mir da gerade selber was für mich selbst zusammenstricken, was ich hier als solides ci und co system nutzen kann.
ich kann aus diversen gründen nicht auf irgendwelche cloud anbieter zurückgreifen, was der grund ist, warum ich mir hier gerade eine recht umfangreiche umgebung bastel.
wo wir schon bei der sache für die cross builds sind, die gcc / clang armv7 und aarch64 cross compiler sind ok und tun was sie sollen? da reichts dann, wenn ich die unit tests auf den target sachen laufen lasse? wie integriere ich sowas in eines der CIs?
aktueller stand der dinge ich muss software für die folgenden systeme via ci bauen und testen (unit und performance tests) lassen können:
Linux x86
Linux x86_64
Linux ARMv7
Linux ARMv8 (aka AArch64)
FreeBSD x86
FreeBSD x86_64
FreeBSD ARMv7
FreeBSD ARMv8
(die x86_64 variante hat ein paar spezialfälle für NDA krams )
DragonFlyBSD x86
DragonFlyBSD x86_64
MacOS x86_64 (mehr als eine release version)
iOS ARMv7
iOS ARMv8 (...)
Windows 7 x86
Windows 7 x86_64
Windows 8.1 x86
Windows 8.1 x86_64
Windows 10 x86
Windows 10 x86_64
Windows 10 ARMv7
Windows 10 ARMv8
da wird hoffentlich nicht noch mehr hinzukommen. es kann allerdings sein, dass die windows sachen, wie auch die anderen noch .NET varianten dazubekommen. hier neige ich aber dazu die einfach mit in die standard variante zu integrieren und den grossteil diese sachen dann via containern zu "lösen".
nicht jede platform hat die gleiche priorität und nicht jede davon muss alles bauen bzw. testen können.
es wäre zwar schön, wenn das alles schnell gebaut werden würde, aber realistisch wäre es mir fast lieber, wenn ich da drei bis vier vollständige builds pro tag rausbekommen würde. potentiell, wären auch on-demand sachen nicht ganz so schlecht.
ich werde hier erstmal mit einem etwas älteren hardware system (nein, nicht der P3) arbeiten, ich habe aber die möglichkeit das ganze um ein weiteres etwas stärkeres system zu ergänzen. von daher sollte das ci damit eher weniger probleme haben, wenn ich die VMs dann einfach auf das leistungsfähigere system schiebe...irgendwann.
|
|
|
|
|
|
|
|
|
|
|
Es hat schon nen Grund, warum mit nem CI-Setup mindestens ne halbe Stelle weg ist 
Ich würde sagen, dass du bei der Liste wahrscheinlich Wochen dabei sein wirst das Zeugs zu konfigurieren.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.06.2017 23:34]
|
|
|
|
|
|
|
|
|
Manchmal fällt ja einem so ein kleines Kuriosum auf, und man fragt sich, wie das überhaupt funktioniert, dann sucht man und lernt was neues.
In Borg forkt die Kiste gerne mal einen ssh-Prozess. Jetzt fragt ssh gerne mal nach einem Passwort.
Aber... wie?
logger.debug('SSH command line: %s', borg_cmd)
self.p = Popen(borg_cmd, bufsize=0, stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env)
stdout, stderr und stdin sind ja alles Pipes. Dennoch sieht man einen Prompt von SSH, und beantwortet einen Prompt von SSH, ohne dass der Borg-Prozess was davon bemerken würde.
Ein Blick in den SSH-Code lüftet das Geheimnis. In sshconnect2.c gibt es die Funktion load_identity_file welche die bekannte Frage "Enter passphrase for key" stellt. Der eigentliche Prompt wird an read_passphrase delegiert, definiert in readpass.c. Die wiederum prüft diverse Flags, in unserem Fall landet die Funktion bei readpassphrase (ohne Unterstrich). Die ist nu gar nicht Teil von SSH, sondern gehört zu OpenBSD, und ist entsprechend in libbsd enthalten. Und diese Funktion interagiert in unserem Falle direkt mit /dev/tty, der PTY/TTY des aktuellen Prozesse und somit dem Terminal an dem man gerade sitzt.
|
|
|
|
|
|
|
|
|
|
|
|
Das ist doch auch nur ein Sicherheitsfeature, damit erst gar niemand auf die Idee kommt Passwörter in Shellskripte zu schreiben und die in ssh rein zu pipen. So muss man wenigstens noch die richtige Stelle im ssh Code finden, und ssh selbst kompilieren, aber genau für so Sachen ist es ja Open Source.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [CSF]Omega
Das ist doch auch nur ein Sicherheitsfeature, damit erst gar niemand auf die Idee kommt Passwörter in Shellskripte zu schreiben und die in ssh rein zu pipen.
| |
aha, wirklich?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Es hat schon nen Grund, warum mit nem CI-Setup mindestens ne halbe Stelle weg ist
Ich würde sagen, dass du bei der Liste wahrscheinlich Wochen dabei sein wirst das Zeugs zu konfigurieren.
| |
bei dem umfang den er hier aufzählt würd ich das sogar höher ansetzen.
allein die ganzen kleinen wewehchen auf jedem der systeme können so einige haare kosten...
haben hier "nur" jenkins für "nur" die aktuelle debian stable version am laufen.
aber auch da stösst man relativ schnell an die grenzen von jenkins und den eingebauten plugins, im prinzip verwenden wir den nur noch um jobs zu schedulen und ne übersicht zu haben. gebaut/getestet/usw wird dann mit nem komplett eigenen skript was iterativ stück für stück(!) dem bedarf nach angepasst und erweitert wurde (in der positiven und nicht "das ist so gewachsen"-art).
prinzipiell haben wir da lauter "helper" jobs die die einzelnen aufgaben erledigen und für die einzelnen build jobs wird dann nur noch das git repository konfiguriert, die verbindung zu stash (*würg*), ein paar umgebungsvariablen gesetzt mit infos und dann ne build und post-build dependency auf die passenden helper gesetzt.
bin da eigentlich enttäuscht wie schnell wir an die grenzen und bugs (z.b. vom git plugin "its not a bug, its a feature") von jekins gestossen sind... aber wahrschienlich muss man das ding einfach nur als reinen job scheduler sehen und keinerlei weitere funktionalität zusprechen.
e: achja der vollständigkeit halber.
gebaut wird dann mittels pbuild in chroots (die pro nacht einmal auch mit nem jenkins job aktualisiert werden) auf verschiendenen worker maschinen. viele davon VMs, einige davon auch blech da dort mittels vbox images für virtualisierte server gebaut&getestet werden.
danach gibts noch die üblichen lintian, piuparts, adequate usw tests und wenns vom richtigen branch kommt (master *hust*) wirds auch direkt ins reprepo geschoben, alles in allem schon sehr sexy...
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [KdM]MrDeath am 15.06.2017 2:34]
|
|
|
|
|
|
|
|
|
momentan gerade verzweifele ich ein wenig daran den service startup krams von systemd angezeigt zu bekommen.
sobald ich da das SOL zeugs mit auf die kernel commandline packe verschwindet jeglicher systemd boot output.
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200,n8"
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
es macht keinen unterschied ob da irgendwo auf der cmdline ein "systemd.show_status=[1|true]" steht oder nicht.
es wäre sehr schön, wenn diese informationen nicht einfach im nirvana verschwinden würden. ebenfalls wäre es sehr schön, wenn man dem zeugs irgendwie abgewöhnen könnte es zu versuchen services, die fehlschlagen, immer und immer wieder erneut starten zu wollen. das kommt mit ner knapp 100 GB grossen db nicht so toll, weil einem das mal eben jegliche system ressourcen schluckt.
eins nach dem anderen. als erstes, wie muss die dämliche cmdline da aussehen, damit ich den service startup output auf beide consolen bekomme?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [CSF]Omega
Das ist doch auch nur ein Sicherheitsfeature, damit erst gar niemand auf die Idee kommt Passwörter in Shellskripte zu schreiben und die in ssh rein zu pipen. So muss man wenigstens noch die richtige Stelle im ssh Code finden, und ssh selbst kompilieren, aber genau für so Sachen ist es ja Open Source.
| |
Irgendwo sicher auch, aber andersrum würde man SSH schlicht nicht so universell einsetzen können. Borg ist ja nicht die einzige Anwendung, die SSH als TLS einsetzt, SCP macht das z.B. auch. Das wär echt nervig, wenn man in seinen Protokollen Passwort-Prompts von SSH berücksichtigen müsste.
-
MADV_FREE (since Linux 4.5) The kernel can thus free these pages, but the freeing could be delayed until memory pressure occurs. Once pages in the range have been freed, the caller will see zero-fill-on-demand pages upon subsequent page references.
Waas? Linux kann das jetzt? Geil! Die Möchlichkeiten!
On a swapless system, freeing pages in a given range happens instantly, regardless of memory pressure.
Oh.  Funktioniert also gerade für den interessanten und wichtigen Fall nicht.
Wie man das benutzen würde: Man mmapt sich seinen Cache mit huge Pages (2 MB / 1 GB), man kann den optimistisch groß machen, ohne zu OOM'en. Fehlende Pages sind günstig zu detektieren über z.B. ein Flag-Bit am Anfang der Page. Quasi Page Cache im user mode. Ist enorm nützlich für alles, was sich nicht einwandfrei auf die Page Cache Semantik des Kernels reduzieren lässt (=vieles!). Windows kann das zumindest theoretisch schon länger.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 15.06.2017 11:12]
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
momentan gerade verzweifele ich ein wenig daran den service startup krams von systemd angezeigt zu bekommen.
sobald ich da das SOL zeugs mit auf die kernel commandline packe verschwindet jeglicher systemd boot output.
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200,n8"
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
es macht keinen unterschied ob da irgendwo auf der cmdline ein "systemd.show_status=[1|true]" steht oder nicht.
es wäre sehr schön, wenn diese informationen nicht einfach im nirvana verschwinden würden. ebenfalls wäre es sehr schön, wenn man dem zeugs irgendwie abgewöhnen könnte es zu versuchen services, die fehlschlagen, immer und immer wieder erneut starten zu wollen. das kommt mit ner knapp 100 GB grossen db nicht so toll, weil einem das mal eben jegliche system ressourcen schluckt.
eins nach dem anderen. als erstes, wie muss die dämliche cmdline da aussehen, damit ich den service startup output auf beide consolen bekomme?
| |
hmm mal alles wild durcheinander geantwortet:
GRUB_CMDLINE_LINUX_DEFAULT="quiet console=ttyS0,115200"
GRUB_CMDLINE_LINUX=""
ist das einzige was ich unter debian da bei mir drinstehen hab (/etc/default/grub und den startup krams seh ich auffem bildschirm und wenn ich per virsh console drauf gehen...
auch zu deiner restart problematik. ja das sind die default einstellungen... das lässt sich aber alles konfigurieren, und dass die default einstellungen nicht auf dein szenario mit einer 100gb datenbank passen find ich schon ganz gut 
z.b.
| |
| Code: |
StartLimitIntervalSec=, StartLimitBurst=
Configure unit start rate limiting. By default, units which are started more than 5 times within
10 seconds are not permitted to start any more times until the 10 second interval ends.
|
|
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 15.06.2017 19:42]
|
|
|
|
|
|
|
|
|
eclipse hats ja leider in den letzten sieben jahren echt geschafft ziemlich crappy zu werden
lauter probleme mit ner neuinstallation (aber alter workspace, neues java projekt)
erst nen riesen geschiss da die einzig installierte JRE zum laufen zu kriegen. dann hat er sowas wie crypto extensions nicht und findet die erst wenn man es einmal mit -clean startet....)
da fragt man sich echt wieso man so doof war und nicht gleich das IDEA zeuchs genommen hat...
|
|
|
|
|
|
|
|
|
|
|
Werden, haha. Eclipse war wirklich schon immer der letzte Murks. Das ganze Equinoxökosystem ist so unfassbar für die Tonne. Eclipse verkörpert so genau alles was ich an IBM nicht mag.
Noch viel hassenswerter: Der RTC Server ist ein headless eclipe (mehr oder weniger). Die allerletzte Architekturentscheidung. Jedes auch nur halbwegs moderne Javaprojekt sollte um diesen Clusterfuckscheisshaufen den grösstmöglichen Bogen machen. Sonst lieber die Finger von Java lassen.
|
|
|
|
|
|
|
|
|
|
|
|
JetBrains macht viel richtig, quer durch die Produktpalette.
|
|
|
|
|
|
|
|
|
|
|
Das Problem an dem Eclipse / Equinox Zeug ist ja vor allem, dass es zwar hauptsächlich für eine IDE verwendet wird, aber alles können muss. Das entspricht noch dem maximalen 90er Gedanken, dass jedes Softwaresystem der Eierlegendendewollwilchmonolith sein muss. Und so zieht man sich die Scheisse seit Jahren hinterher und Eclipse wird imemr grösser, fehleranfälliger und beschissener als es von Anfang an eh schon war.
Das sind hauptsächlich die Kritikpunkte, die Leute an Java so haben, aber man ist ja nicht mehr gezwungen das auch selber so zu machen. Eclipse und alle seine verwanten Kumpels gehören aber definitiv einfach abgeschafft.
|
|
|
|
|
|
|
|
|
|
|
Kennt es bei Libreoffice Calc (unter xfce) jemand, dass kopierter Text (mehrerer Zellen) beim pasten als Bild eingefügt wird? Also nur manchmal natürlich. Wenn es auftritt, muss man den Vorgang nur 3-20x identisch wiederholen und irgendwann wird es korrekt als Text gepasted. 
TRH: Ich weiß was für ein unsagbar großer Haufen Müll diese Software ist. Ich brauche hier konstruktive Posts.
Oh, und mit libreoffice-gtk installiert sind manche Graphen zerhackt. Weiß da jemand was zu?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 17.06.2017 0:21]
|
|
|
|
|
|
|
|
|
|
Ich hs mirr +sagen lässt sss Ms office mirvwibe läuft errr fu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nicht dass ich nüchterner wäre, aber das amüsiert mich jetzt doch ganz erheblich.
|
|
|
|
|
|
|
|
|
|
|
|
Wie er ueberhaupt noch "Eintragen" druecken konnte
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wie beta? das heisst danach kann man dem ding seine daten anvertrauen und z.b. sowas wie backups damit machen? 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 19.06.2017 0:48]
|
|
|
|
|
|
|
|
|
Hat jemand hier eine Meinung zu I/O-Schedulern?
Ich hatte das Gefuehl, es geht mehr in Richtung einfacher genersischer Scheduler die nicht so schlau sind, dafuer aber wenig Overhead erzeugen und zuverlaessig reagieren. BFQ scheint wieder in die andere Richtung zu gehen, mit mehr Aufwand, um etwa Leseoperationen und interaktive Anwendungen zu bevorzugen.
Der Erklaerbaer von Heise, laesst durchblicken, dass das irgendwie nicht so auf die einfache Konfiguration mit einer (einzelnen) schnellen SSD (im Desktop oder Laptop) passt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 19.06.2017 12:04]
|
|
|
|
|
|
|
|
|
|
Bei SSDs ist fast alles an Scheduling kontraproduktiv. Linux schafft es natürlich trotzdem nicht akzeptable Latenzen für "interaktive Anwendungen" zu liefern, sobald ein bisschen Last im Hintergrund anfällt.
|
|
|
|
|
|
|
|
|
|
Ich hab mal das eingestellt:
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
Weils irgendwo im Internet stand ¯\_(ツ)_/¯
|
|
|
|
|
|
|
|
|
|
|
Deadline gefaellt mir aber vom Konzept am meisten. Verstehe ich das eigentlich richtig, dass die Write-Requests im Default nur aus der Expiration-Queue geholt werden?
Nach deiner Konfiguration hast du dem Scheduler sowieso gesagt, dass du eine SSD hast und er das generell sein lassen soll.
Ich verstehe dein "weil es irgendwo im Internet stand"
Unbedacht Konfigurationseinstellungen kopieren ist echt boese. Ich hatte einen Kollegen, der hat das wirklich gemacht. Wenn was funktionieren sollte hat der halt einfach die ganze Konfiguraton von irgend jemand anderen kopiert. Ich denke, der hat auch so reagiert wenn irgendwas meachanisches nicht funktioniert hat. Ohne Plan einfach an allem drehen 
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 19.06.2017 15:55]
|
|
|
|
|
|
|
|
|
Gerade purzeln die Local Roots nur so: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
glibc https://lists.debian.org/debian-security-announce/2017/msg00146.html
linux https://lists.debian.org/debian-security-announce/2017/msg00148.html
exim4 https://lists.debian.org/debian-security-announce/2017/msg00147.html
"local-root exploit against Exim",
"local-root exploit against Sudo (Debian, Ubuntu, CentOS)",
"local-root exploit against /bin/su",
"local-root exploit against ld.so and most SUID-root binaries (Debian, Ubuntu, Fedora, CentOS)",
"local-root exploit against /usr/bin/rsh (Solaris 11)",
as well as proof of concepts for OpenBSD, FreeBSD and so on.
- a local-root exploit against Exim (CVE-2017-1000369, CVE-2017-1000376)
on i386 Debian;
- a local-root exploit against Sudo (CVE-2017-1000367, CVE-2017-1000366)
on i386 Debian, Ubuntu, CentOS;
- an independent Sudoer-to-root exploit against CVE-2017-1000367 on any
SELinux-enabled distribution;
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000370) on i386 Debian, Fedora, CentOS;
- a local-root exploit against ld.so and most SUID-root PIEs
(CVE-2017-1000366, CVE-2017-1000371) on i386 Debian, Ubuntu, Fedora;
- a local-root exploit against /bin/su (CVE-2017-1000366,
CVE-2017-1000365) on i386 Debian;
- a proof-of-concept that gains eip control against Sudo on i386
grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);
- a local proof-of-concept that gains rip control against Exim
(CVE-2017-1000369) on amd64 Debian;
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
CentOS;
- a proof-of-concept against /usr/bin/at on i386 OpenBSD, for
CVE-2017-1000372 in OpenBSD's stack guard-page implementation and
CVE-2017-1000373 in OpenBSD's qsort() function;
- a proof-of-concept for CVE-2017-1000374 and CVE-2017-1000375 in
NetBSD's stack guard-page implementation;
- a proof-of-concept for CVE-2017-1085 in FreeBSD's setrlimit()
RLIMIT_STACK implementation;
- two proofs-of-concept for CVE-2017-1083 and CVE-2017-1084 in FreeBSD's
stack guard-page implementation;
- a local-root exploit against /usr/bin/rsh (CVE-2017-3630,
CVE-2017-3629, CVE-2017-3631) on Solaris 11.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 19.06.2017 18:53]
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
