1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Linux: Systemd lädt Container…

Spawn a namespace container for debugging, testing and building

  1. Thema

Neues Thema Ansicht wechseln


  1. Spawn a namespace container for debugging, testing and building

    Autor: fuzzy 17.02.15 - 13:26

    Klingt jetzt nicht so, als wäre das was besonders tolles (für Endanwender oder Produktivbetrieb i.A.). Eigentlich mehr so LXC light.
    Was wiederum die Frage aufwirft, warum eine Basiskomponente wie Systemd sowas können muss...?

    Baumansicht oder Zitieren oder nicht Posten - die Wahl ist eure!



    1 mal bearbeitet, zuletzt am 17.02.15 13:28 durch fuzzy.

  2. Re: Spawn a namespace container for debugging, testing and building

    Autor: spiderbit 17.02.15 - 14:17

    hmm systemd ist keine componente, es ist eher eine Art Ueberschrift fuer eine Sammlung von Compententen, so bisschen wie GNU nur mit weniger oder anderer mir nicht bekannter (hier gibts sicher leute die glauben die stark erkennen zu koennen :) ) Ideologie.

  3. Re: Spawn a namespace container for debugging, testing and building

    Autor: RipClaw 17.02.15 - 21:51

    spiderbit schrieb:
    --------------------------------------------------------------------------------
    > hmm systemd ist keine componente, es ist eher eine Art Ueberschrift fuer
    > eine Sammlung von Compententen, so bisschen wie GNU nur mit weniger oder
    > anderer mir nicht bekannter (hier gibts sicher leute die glauben die stark
    > erkennen zu koennen :) ) Ideologie.

    Ich finde Sammlung trifft es nicht ganz. Im Grunde eine Suite ähnlich wie das bei KDE ist. Einzelne Programme die aber teilweise (starke) Abhängigkeiten untereinander haben.

    Bei einer Sammlung denke ich eher an sowas wie die coreutils oder netpbm.



    1 mal bearbeitet, zuletzt am 17.02.15 21:57 durch RipClaw.

  4. Re: Spawn a namespace container for debugging, testing and building

    Autor: spiderbit 17.02.15 - 22:09

    starke abhaengigkeiten seh ich nicht, es ist halt schwer eine art abstraktionsschicht zu bauen wenn es fuer eine Komponente eben nur eine Implementierung gibt, dort wo es schon vorhandenes gab wurde das immer sauber optional angebunden.

    Als beispiel kann man ja den alten Syslog oder wie der hiess einbinden ohne Probleme.

  5. Re: Spawn a namespace container for debugging, testing and building

    Autor: RipClaw 18.02.15 - 10:44

    spiderbit schrieb:
    --------------------------------------------------------------------------------
    > starke abhaengigkeiten seh ich nicht, es ist halt schwer eine art
    > abstraktionsschicht zu bauen wenn es fuer eine Komponente eben nur eine
    > Implementierung gibt, dort wo es schon vorhandenes gab wurde das immer
    > sauber optional angebunden.
    >
    > Als beispiel kann man ja den alten Syslog oder wie der hiess einbinden ohne
    > Probleme.

    Ja und nein. Im Grunde werden die Ausgaben des systemd-journald in Kopie an den syslogd weitergeleitet. Der journald selbst legt trotzdem noch ein eigenes Binärlog an.

    Wenn man z.B. systemd-logind ohne den Rest laufen lassen will dann verweisen viele immer auf systemd-shim. Das ist aber kein Teil von systemd sondern ein Fork, von Gnome Entwicklern, der die nötigen Schnittstellen für den logind zur Verfügung stellt, und es gibt keine Garantie das die Kompatiblität immer erhalten bleibt. Und ohne dbus läuft bei systemd sowieso nichts.

  6. Re: Spawn a namespace container for debugging, testing and building

    Autor: spiderbit 18.02.15 - 15:19

    ja gut das man prinzipiel irgendwelche abhaengigkeitne hat ist halt so, das ist normal, X hat auch abhaengigkeiten Wayland auch... das meiste hat libc als abhaengigkeit.

    Zu syslogd soweit ich weiss kann man journald dann deaktivieren wenn man syslogd eingebunden hat. diese zusaetzliche funktion die du beschreibst ist also soweit ich weiss auch nur optional.

  7. Re: Spawn a namespace container for debugging, testing and building

    Autor: RipClaw 18.02.15 - 21:58

    spiderbit schrieb:
    --------------------------------------------------------------------------------
    > ja gut das man prinzipiel irgendwelche abhaengigkeitne hat ist halt so, das
    > ist normal, X hat auch abhaengigkeiten Wayland auch... das meiste hat libc
    > als abhaengigkeit.

    Das schon aber bei den von mir beschriebenen Paketen sind die Programme selber nicht voneinander abhängig. Die Abhängigkeiten von Libs sind eigentlich normal wenn man nicht jede Funktion immer selber implementieren will.

    Bei systemd ist es ein Verbund von Programmen die zumindestens teilweise untereinander kommunizieren und daher nicht vollständig unabhängig voneinander laufen können.

    Die Funktionen die systemd bietet sind nicht zu verachten aber gleichzeitig nimmt das ganze immer mehr die Züge von einem Subsystem an wie man es von Windows kennt.
    Die Komplexität wächst mit der Zunahme der Funktionen und das wird irgendwann zum Problem.

  8. Re: Spawn a namespace container for debugging, testing and building

    Autor: fuzzy 18.02.15 - 22:18

    Naja, lieber ein komplexes Init-System als 200 Init-Scripts wo keiner mehr kapiert was abgeht. :D

    Baumansicht oder Zitieren oder nicht Posten - die Wahl ist eure!

  9. Re: Spawn a namespace container for debugging, testing and building

    Autor: RipClaw 18.02.15 - 22:50

    fuzzy schrieb:
    --------------------------------------------------------------------------------
    > Naja, lieber ein komplexes Init-System als 200 Init-Scripts wo keiner mehr
    > kapiert was abgeht. :D

    Im Moment befinde ich mich noch in der Phase ein komplexes Init System mit 200 Konfigurationsdateien wo ich nicht weiß was abgeht.

    Ich muss mich erst noch ordentlich in systemd einarbeiten.

    Shellskripte kann ich lesen aber bei den Konfigurationsdateien von systemd fehlt mir noch der Überblick über alle Parameter und was man alles damit machen kann.
    Es ist einfach zu viel auf einmal.

  10. Re: Spawn a namespace container for debugging, testing and building

    Autor: fuzzy 19.02.15 - 09:26

    Naja gut, wenn man mit den Standardeinstellungen nicht so ganz zufrieden ist, macht es vermutlich nicht so viel Spass. Ich stelle nur journald darauf um, auch auf tty12 zu loggen und das war’s. Mit der Dokumentation bin ich aber recht zufrieden.

    Mir fällt es schwer die Skripte anderer Init-Systeme noch zu verstehen. Nicht, weil es Shell-Skripte sind, sondern weil da aus tausenden Zeilen „Libraries“ Funktionen und Dinge nachgeladen werden, dass es einem die Fußnägel aufrollt.
    Selbst bei FreeBSD, was ja vergleichsweise wirklich einfach ist, finde ich die normale Anleitung zum Schreiben von Init-Scripts unnötig kompliziert und nervig. Und wenn man sieht was es da in freier Wildbahn gibt... oh weh.

    Baumansicht oder Zitieren oder nicht Posten - die Wahl ist eure!

  11. Re: Spawn a namespace container for debugging, testing and building

    Autor: spiderbit 19.02.15 - 10:39

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > fuzzy schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Naja, lieber ein komplexes Init-System als 200 Init-Scripts wo keiner
    > mehr
    > > kapiert was abgeht. :D
    >
    > Im Moment befinde ich mich noch in der Phase ein komplexes Init System mit
    > 200 Konfigurationsdateien wo ich nicht weiß was abgeht.
    >
    > Ich muss mich erst noch ordentlich in systemd einarbeiten.
    >
    > Shellskripte kann ich lesen aber bei den Konfigurationsdateien von systemd
    > fehlt mir noch der Überblick über alle Parameter und was man alles damit
    > machen kann.
    > Es ist einfach zu viel auf einmal.

    Das schoene ist das es Distributionsunabhaengig ist, also soweit eben die distries schon auf Systemd umgestiegen sind.

    Fuer Fedora ist die Doku mittelmaesig, 99% der Archlinux Doku funtzt aber genauso, natuerlich kann man auch man-pages und anderes benutzen, habe ich aber bisher recht wenig in dem Zusammenhang. Und die Doku von Archlinux ist das beste was ich jeh gesehen habe.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM), Bonn
  2. ING Deutschland, Frankfurt am Main
  3. PSI Software AG Geschäftsbereich PSI Energie EE, Aschaffenburg
  4. CompuGroup Medical SE & Co. KGaA, Koblenz, Saarbrücken

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ausprobiert: Meine erste Strafgebühr bei Free Now
Ausprobiert
Meine erste Strafgebühr bei Free Now

Storniert habe ich bei Free Now noch nie. Doch diesmal wurde meine Geduld hart auf die Probe gestellt.
Ein Praxistest von Achim Sawall

  1. Gesetzentwurf Weitergabepflicht für Mobilitätsdaten geplant
  2. Personenbeförderung Taxibranche und Uber kritisieren Reformpläne

The Secret of Monkey Island: Ich bin ein übelriechender, groggurgelnder Pirat!
The Secret of Monkey Island
"Ich bin ein übelriechender, groggurgelnder Pirat!"

Das wunderbare The Secret of Monkey Island feiert seinen 30. Geburtstag. Golem.de hat einen neuen Durchgang gewagt - und wüst geschimpft.
Von Benedikt Plass-Fleßenkämper


    Philips-Leuchten-Konfigurator im Test: Die schicke Leuchte aus dem 3D-Drucker
    Philips-Leuchten-Konfigurator im Test
    Die schicke Leuchte aus dem 3D-Drucker

    Signify bietet mit Philips My Creation die Möglichkeit, eigene Leuchten zu kreieren. Diese werden im 3D-Drucker gefertigt - und sind von überraschend guter Qualität. Golem.de hat eine güldene Leuchte entworfen.
    Ein Test von Tobias Költzsch

    1. Smarte Leuchten mit Kurzschluss Netzteil-Rückruf bei Philips Hue Outdoor
    2. Signify Neue Lampen, Leuchten und Lightstrips von Philips Hue
    3. Signify Neue Philips-Hue-Produkte vorgestellt