Hallo Mario,
On Fri, Dec 14, 2018 at 11:19:39AM +0100, Mario Blättermann wrote:
> Am Fr., 14. Dez. 2018 um 10:49 Uhr schrieb Helge Kreutzmann
> <debian@helgefjell.de>:
> > > #. type: Plain text
> > > msgid ""
> > > "Note that setting I<KillUserProcesses=yes> will break tools like "
> > > "B<screen>(1) and B<tmux>(1), unless they are moved out of the session scope"
> > > "\\&. See example in B<systemd-run>(1)\\&."
> > > msgstr ""
> > > "Beachten Sie, dass die Einstellung I<KillUserProcesses=yes> Werkzeuge wie "
> > > "B<screen>(1) und B<tmux>(1) beschädigen wird, außer sie werden aus dem "
> > > "Geltungsbereich der Sitzung verschoben\\&. Siehe die Beispiele in B<systemd-"
> > > "run>(1)\\&."
> > >
> > > Die Werkzeuge werden nicht wirklich beschädigt, sie sind hinterher
> > > sicher immer noch gut zu gebrauchen. Hier in diesem Kontext passt
> > > vielleicht »behindern«.
> >
> > Ggf. »die Ausführung der Programme beschädigen«?
> >
> Das »beschädigen« würde ich ganz umgehen, weil es eine Beschädigung
> suggeriert, die man irgendwie reparieren müsste. Vielleicht »die
> Ausführung der Programme behindern«? Der Begriff »break« ist mir schon
> oft im Paketbau in Form von »xxx breaks the build« vorgekommen, und da
> ist es auch so, dass der Bau des Pakets behindert wird (oder gar
> verhindert, würde ich aber global nicht so schreiben wollen), wenn in
> der Toolchain irgend etwas nicht passt oder eine Datei fehlerhaft ist.
Mit dem »breaks«, gerade in letzterem Kontext, habe ich auch so meine
Probleme. Allerdings finde ich schon, dass eine Beschädigung erfolgt.
Die Ausführung (nicht das Programm auf Platte) ist danach defekt, d.h.
sie läuft nicht mehr wie geplant und auch der Bau funktioniert nicht
wei geplant, im Bestfall bricht der Bau ab, im Schlechtfall kommt ein
unerwünschte (»kaputtes«) Programm heraus.
Für mich ist Beschädigung auch erst mal unabhägig von der möglichen
Reperatur, die aber i.d.R. bei den hier diskutierten Fällen einfach
ist: Problematisches Programm deinstallieren, Programm oder Programmbau
neu starten und erledigt.
Das soll nicht heißen, dass ich »behindern« komplett ablehnen würde,
aber das wäre mir erst mal (eigentlich ohne Not) zu frei. Den
Behindern suggeriert, dass das »Hindernis« beseitigt werden könnte und
danach die Ausführung/der Bau *an dieser Stelle* fortfahren könnte -
wie im Straßenverkehr, wenn da ein Hindernis steht - aber in unseren
Fällen muss ich die Aktion (den Bau, das Programm) regelmäßig neu
starten, um korrekte Ergebnisse zu erhalten.
Grübelnd.
Vielen Dank & 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