Static Build
- Ersteller vxk
- Erstellt am
Arjan
Well-Known Member
Ein solches Programm benötigt keine dynamisch nachladbaren Laufzeitbibliotheken, die im Crashfall vielleicht mal nicht zur Verfügung stehen.
Das Binary läuft von überall ganz autonom.
Bestes Beispiel ist das Booten eines Rettungssystems, wenn <fsck> auf einer Partition nicht durchläuft und diese dann nicht gemountet werden kann - aber genau dort die Runtimelibrarys liegen.
Die <csh> von root ist so gebaut als Beispiel - wenn Du von der Installdisk in den Rescuemodus wechselst.
Gruss
Das Binary läuft von überall ganz autonom.
Bestes Beispiel ist das Booten eines Rettungssystems, wenn <fsck> auf einer Partition nicht durchläuft und diese dann nicht gemountet werden kann - aber genau dort die Runtimelibrarys liegen.
Die <csh> von root ist so gebaut als Beispiel - wenn Du von der Installdisk in den Rescuemodus wechselst.
Gruss
P
Paldium
Guest
static / dynamic
Dass die Bibliotheken sich in der Binary befinden, kann sowohl ein Vor- als auch ein Nachteil sein.
Arjan hat bereits geschrieben, dass es in gewissen Situationen vorteilhaft sein kann.
Nachteile ergeben sich, wenn sich in der Bibliothek, die fest eingebunden wurde, was geändert hat. Da fällt mir zum Beispiel dieses Sicherheitsupdate ein. In dem Fall müssen diese statischen Programme neucompiliert werden, sonst befindet sich das Problem immernoch in ihnen (da die eingebundenen Bibliotheken nicht aktualisiert werden).
Das gleiche gilt natürlich auch für neue Funktionalitäten, wobei die wohl nur sehr selten in den Ports-Tree für ein- und dieselbe Version von OpenBSD eingebunden werden.
Wenn die Bibliotheken in der Binary sind, muss kein weiterer Speicher angefordert werden, der sagt, wo welche Bibliothek liegt. Wieviel das ausmacht (speicher- und CPU-mäßig) kann ich nicht sagen, außerdem wird der Unterschied minimal sein.
Da du von Packages gesprochen hattest: Würdest du zum Beispiel die bash nutzen wollen, kommt es drauf an, wie du sie einsetzen willst.
Dem Beispiel von arjan folgend könnte es ja sein, dass du die bash als root-Konsole nutzen willst, da wäre die static-Variante sinnvoll. Wenn du aber bash als Benutzershell einsetzen willst, kannst du auch auf die shared-Variante zurückgreifen, da das System sehr vermutlich korrekt hochgefahren ist, wenn ein Benutzer sich einloggen darf.
Dass die Bibliotheken sich in der Binary befinden, kann sowohl ein Vor- als auch ein Nachteil sein.
Arjan hat bereits geschrieben, dass es in gewissen Situationen vorteilhaft sein kann.
Nachteile ergeben sich, wenn sich in der Bibliothek, die fest eingebunden wurde, was geändert hat. Da fällt mir zum Beispiel dieses Sicherheitsupdate ein. In dem Fall müssen diese statischen Programme neucompiliert werden, sonst befindet sich das Problem immernoch in ihnen (da die eingebundenen Bibliotheken nicht aktualisiert werden).
Das gleiche gilt natürlich auch für neue Funktionalitäten, wobei die wohl nur sehr selten in den Ports-Tree für ein- und dieselbe Version von OpenBSD eingebunden werden.
Wenn die Bibliotheken in der Binary sind, muss kein weiterer Speicher angefordert werden, der sagt, wo welche Bibliothek liegt. Wieviel das ausmacht (speicher- und CPU-mäßig) kann ich nicht sagen, außerdem wird der Unterschied minimal sein.
Da du von Packages gesprochen hattest: Würdest du zum Beispiel die bash nutzen wollen, kommt es drauf an, wie du sie einsetzen willst.
Dem Beispiel von arjan folgend könnte es ja sein, dass du die bash als root-Konsole nutzen willst, da wäre die static-Variante sinnvoll. Wenn du aber bash als Benutzershell einsetzen willst, kannst du auch auf die shared-Variante zurückgreifen, da das System sehr vermutlich korrekt hochgefahren ist, wenn ein Benutzer sich einloggen darf.
vxk
Well-Known Member
Paldium schrieb:
Danke fuer deine ausfuehrliche Erklaerung.
Also wenn ich dich richtig verstanden habe bin ich bei Programmen die ich NICHT im Single-User-Mode beim Hochfahren brauche mit der NICHT-Statischen Variante besser drann. Aus Sicherheitsgruenden wohl. Dann versteh ich z.B. ncht warum es z.B "Screen" statisch gibt. Ich meine wer braucht das schon im Single-User-Mode
P
Paldium
Guest
statische packages
Du führtest "screen" als ein Beispiel an, ich habe mal die Liste aufgestellt, welche Packages für OpenBSD 3.6 als static installiert werden können:
bash-3.0-static
gtar-1.14-static
nslint-2.0.2-static
screen-4.0.2-static
shash-0.2.6-static
star-1.4.3-static
tcsh-6.13.00-static
bash, shash und tcsh sind Shells, das wurde ja schon besprochen.
gtar und star sind Archivierer, wenn man Backups hat, die das mitgelieferte tar nicht lesen kann, ist es schon sinnvoll, sowas zu haben.
nslint hilft beim Überprüfen von DNS-Dateien, wenn du von so einer Installation abhängig bist, um zum Beispiel die /usr-Partition über Netzwerk zu beziehen, bestimmt auch sinnvoll.
Auf der Homepage von screen wird beschrieben, dass screen typische Konsolen zur Verfügung stellt. Ich würde daher mal sagen, dass screen in bestimmten Situationen durchaus für den Single-User-Modus geeignet ist, wenn das Terminal selbst gewisse Funktionen nicht bieten kann. Beispielsweise könnte ich mir da die Nutzung von seriellen Terminals vorstellen, die nicht so arbeiten, wie man es gerne möchte.
Du führtest "screen" als ein Beispiel an, ich habe mal die Liste aufgestellt, welche Packages für OpenBSD 3.6 als static installiert werden können:
bash-3.0-static
gtar-1.14-static
nslint-2.0.2-static
screen-4.0.2-static
shash-0.2.6-static
star-1.4.3-static
tcsh-6.13.00-static
bash, shash und tcsh sind Shells, das wurde ja schon besprochen.
gtar und star sind Archivierer, wenn man Backups hat, die das mitgelieferte tar nicht lesen kann, ist es schon sinnvoll, sowas zu haben.
nslint hilft beim Überprüfen von DNS-Dateien, wenn du von so einer Installation abhängig bist, um zum Beispiel die /usr-Partition über Netzwerk zu beziehen, bestimmt auch sinnvoll.
Auf der Homepage von screen wird beschrieben, dass screen typische Konsolen zur Verfügung stellt. Ich würde daher mal sagen, dass screen in bestimmten Situationen durchaus für den Single-User-Modus geeignet ist, wenn das Terminal selbst gewisse Funktionen nicht bieten kann. Beispielsweise könnte ich mir da die Nutzung von seriellen Terminals vorstellen, die nicht so arbeiten, wie man es gerne möchte.
