Moin,
On Sun, Feb 10, 2019 at 12:18:57PM +0100, Mario Blättermann wrote:
> vorab noch eine Anmerkung: Wenn du schon größere po-Dateien zerlegst, dann
> ergibt es meiner Meinung nach wenig Sinn, einfach nach Anzahl der Strings zu
> teilen. Gerade in diesem Teil wird deutlich, dass er durch sehr lange Absätze
> ziemlich groß wird. Mit moderaten 42 Strings, aber dafür 550 Zeilen ist er fast
> doppelt so groß wie die Teile, in die ich meine Dateien immer zerlegt habe.
> Ich weiß, du arbeitest da mit Skripten, aber könntest du das entsprechende
> Skript nicht etwas anpassen, dass es bei etwa 300 Zeilen teilt?
Größe ist etwas, was ich nicht im Auge habe. Ich werde aber versuchen,
drauf zu achten und ggf. neu zu zerlegen.
Und was mir ganz wichtig ist, ich freue mich über jede Rückmeldung,
aber sie muss nicht (sofort) sein. Bei größeren Korrekturleseblöcken
mache ich es dann so, dass ich einfach die E-Mail postpone und später
erneut weiter dran arbeite, dann dauert es einfach länger.
> #. type: Plain text
> #: archlinux debian-unstable
> msgid ""
> "This setting is supported only if the unified control group hierarchy is "
> "used and disables I<MemoryLimit=>\\&."
> msgstr ""
> "Diese Einstellung wird nur unterstützt, falls die vereinigte Control-Gruppen"
> "hierarchie verwandt wird und deaktiviert I<MemoryLimit=>\\&."
>
> Hier stimmt was nicht: Nach »Control-Gruppen« kommt ein dynamischer
> Zeileumbruch und dann geht es mit »hierarchie« klein geschrieben weiter.
> Fehler in Gettext? Sollte es »Control-Gruppenhierarchie« heißen oder eher mit
> Bindestrich wie weiter unten in »Control-Gruppen-Attribut«?
Ist ok, das war nur aus der letzten Korrektur und ich wollte nicht
mitten im Korrekturlese neu umbrechen (lassen).
> #. type: Plain text
> #: archlinux debian-unstable
> msgid ""
> "Specify the best-effort memory usage protection of the executed processes in "
> "this unit\\&. If the memory usages of this unit and all its ancestors are "
> "below their low boundaries, this unit\\*(Aqs memory won\\*(Aqt be reclaimed "
> "as long as memory can be reclaimed from unprotected units\\&."
> msgstr ""
> "Legt den größtaufwandsmöglichen Speicherbenutzungsschutz für die in dieser "
> "Unit ausgeführten Prozesse fest\\&. Falls der Speicherverbrauch dieser Unit "
> "und sämtlicher seiner Nachkommen unter der unteren Grenze sind, wird der "
> "Speicher dieser Unit nicht zurückgefordert, solange Speicher noch nicht "
> "geschützter Units zurückgefordert werden kann\\&."
>
> größtaufwandsmöglichen → mit vertretbarem Aufwand möglichen
> (sofern ich das Verfahren richtig verstanden habe; »größtaufwandsmöglich«
> klingt jedenfalls wie ein mit dem größten möglichen Aufwand konstruiertes Wort)
:-))
Deine Variante wäre aber eher »good effort«.
Legt fest, dass der Speicherbenutzungsschutz für die in dieser Unit
ausgeführten Prozesse mit größtmöglichem Aufwand realisiert werden soll.
> # out-of-memory killer besser?
> #. type: Plain text
> #: archlinux debian-unstable
> msgid ""
> "Specify the absolute limit on memory usage of the executed processes in this "
> "unit\\&. If memory usage cannot be contained under the limit, out-of-memory "
> "killer is invoked inside the unit\\&. It is recommended to use "
> "I<MemoryHigh=> as the main control mechanism and use I<MemoryMax=> as the "
> "last line of defense\\&."
> msgstr ""
> "Legt die absolute Grenze der Speicherverwendung durch den ausgeführten "
> "Prozess in dieser Unit fest\\&. Falls der Speicherverbrauch nicht unterhalb "
> "dieser Grenze gehalten werden kann, wird der Speicherknappheits-Killer "
> "innerhalb der Unit aufgerufen\\&. Es wird empfohlen, I<MemoryHigh=> als "
> "Hauptsteuermechanismus und I<MemoryMax=> als letzte Verteidigungslinie zu "
> "verwenden\\&."
>
> der Speicherknappheits-Killer innerhalb der Unit
> →
> ein in der Unit eingebauter Mechanismus zur Abwendung von Speicherknappheit
> (klingt nicht unbedingt besser, aber deine Variante ist auch nicht intuitiv begreifbar)
Das gefällt mir (leider) aber auch nicht wirklich, das »to kill« (was
wir noch nicht diskutiert haben) geht bei Deiner Variante unter.
> letzte Verteidigungslinie → letzten Ausweg
> (ist dir sicher zu frei)
Ja, da es was ganz anderes suggeriert: Verteidigung und Flucht sind
zwei diametral entgegengesetzte Mechanismen bei Angriffen.
> #. type: Plain text
> #: archlinux debian-unstable
> msgid ""
> "Turn on task accounting for this unit\\&. Takes a boolean argument\\&. If "
> "enabled, the system manager will keep track of the number of tasks in the "
> "unit\\&. The number of tasks accounted this way includes both kernel threads "
> "and userspace processes, with each thread counting individually\\&. Note "
> "that turning on tasks accounting for one unit will also implicitly turn it "
> "on for all units contained in the same slice and for all its parent slices "
> "and the units contained therein\\&. The system default for this setting may "
> "be controlled with I<DefaultTasksAccounting=> in B<systemd-system."
> "conf>(5)\\&."
> msgstr ""
> "Schaltet Prozessbuchführung für diese Unit ein\\&. Akzeptiert ein logisches "
> "Argument\\&. Falls aktiviert, wird der Systemverwalter die Anzahl der "
> "Prozesse in der Unit nachverfolgen\\&. Die Anzahl der auf diese Art "
> "buchgeführten Prozesse enthält sowohl Kernel-Threads als auch "
> "Benutzerprozesse, wobei jeder Thread einzeln zählt\\&. Beachten Sie, dass "
> "das Einschalten der Prozessbuchführung für eine Unit dies implizit auch für "
> "alle Units, die in der gleichen Scheibe enthalten sind und für alle "
> "Elternscheiben und die darin befindlichen Units einschaltet\\&. Die "
> "Systemvorgabe für diese Einstellung kann durch I<DefaultTasksAccounting=> in "
> "B<systemd-system.conf>(5) gesteuert werden\\&."
>
> Hier würde »Verfolgung« statt »Buchführung« passen. Schreibt Systemd eigentlich
> diese Buchführung ins Journal? Dann ginge auch »Protokollierung«.
Verfolgung ist »tracing«, ein anderes Konzept. Zur zweiten Frage:
Keine Idee, da müsste ich mal die Handbuchseiten zu studieren :-))
Aber es steht dort definitiv nicht logging, wieder ein anderes
Konzept.
> Elternscheiben → übergeordneten Scheiben
Das ist zu unscharf. Eltern sind genau die direkten Vorfahren, während
»übergeordnet« auch Vorfahren zweiter und höherer Generation sein
können (z.B. Großeltern).
Alles nicht weiter kommentierte übernommen.
Vielen Dank, auch und gerade ob des sehr drögen Textes.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature