unix5 auf PiDP11

[Josef Moellers]

Mooi'n,
Ich bin zwar in der benötigten Altersklasse (dieses Jahr 0x40), komme
aber nicht weiter:
Ich habe mir den PiDP11 von Oscar Vermeulen geleistet (oder eher ...
geschenkt bekommen). Sieht schick aus und lief auf Anhieb.
Ich habe dann mal gleich das unix5 ausprobiert und steckte fest: wie in
aller Herrgotts Namen fährt man das ordentlich wieder 'runter?
Also ich meine jetzt nicht simh selber oder gar Raspian, nein: wie fährt
man das unix5 herunter? "shutdown", "telinit", "poweroff" gibt es alles
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.
Any ideas?
Josef

[Michael van Elst]

Post by Josef Moellers
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.

Ein Signal 1 an init sollte das System in single user
runterfahren.

Dann ein dreifaches 'sync' anstimmen und abschalten.

[Kay Martinen]

Post by Josef Moellers
Ich bin zwar in der benötigten Altersklasse (dieses Jahr 0x40), komme

Hier 0x39 aber erst mit HC/PC angefangen.

Post by Josef Moellers
Ich habe mir den PiDP11 von Oscar Vermeulen geleistet (oder eher ...
geschenkt bekommen). Sieht schick aus und lief auf Anhieb.

Cooles Teil. Du meinst den hier von

https://obsolescence.wixsite.com/obsolescence/pidp-11

Post by Josef Moellers
Ich habe dann mal gleich das unix5 ausprobiert und steckte fest: wie in
aller Herrgotts Namen fährt man das ordentlich wieder 'runter?
Also ich meine jetzt nicht simh selber oder gar Raspian, nein: wie fährt
man das unix5 herunter? "shutdown", "telinit", "poweroff" gibt es alles
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.
Any ideas?

Ich kenne solche "Brocken" nicht aber:

Das Panel hat doch einen Schlüsselschalter links unten. Hast du mal
versucht den in HALT zu setzen und dann mit dem Schlüssel aus zu
schalten? Ich erkenne auf den Photos eine Stellung "Off" bei "Power"
wenn ich sie ran zoome.

Oh, im Handbuch steht's doch:
-snip-
Shutting down the PiDP-11
Important. To shut the system down in an orderly manner, push the HALT
switch down and then depress the ADDRESS rotary knob. Wait 15 seconds
more before you cut the power.
-snap-

Zu den OS findet sich unix5 nicht, für unix7 wird geraten drei mal
'sync' aus zu führen bevor man es "verlässt" - wie o.g. vermutlich.

Oder doch einfach AUS!? Kennt unix5 kein sync?

Kay

[Josef Moellers]

Post by Kay Martinen

Post by Josef Moellers
Ich bin zwar in der benötigten Altersklasse (dieses Jahr 0x40), komme

Hier 0x39 aber erst mit HC/PC angefangen.

Post by Josef Moellers
Ich habe mir den PiDP11 von Oscar Vermeulen geleistet (oder eher ...
geschenkt bekommen). Sieht schick aus und lief auf Anhieb.

Cooles Teil. Du meinst den hier von
https://obsolescence.wixsite.com/obsolescence/pidp-11

Ja, genau den.
Unsere FH hatte erst eine /45 und dann eine /60: Nix Blinkenlights ;-)
Sondern kleines Tastaturpanel mit 7-Segment-Anzeige!

Post by Kay Martinen

Post by Josef Moellers
Ich habe dann mal gleich das unix5 ausprobiert und steckte fest: wie in
aller Herrgotts Namen fährt man das ordentlich wieder 'runter?
Also ich meine jetzt nicht simh selber oder gar Raspian, nein: wie fährt
man das unix5 herunter? "shutdown", "telinit", "poweroff" gibt es alles
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.
Any ideas?

Das Panel hat doch einen Schlüsselschalter links unten. Hast du mal
versucht den in HALT zu setzen und dann mit dem Schlüssel aus zu
schalten? Ich erkenne auf den Photos eine Stellung "Off" bei "Power"
wenn ich sie ran zoome.

Ja, wenn der Schlüsselschalter angeschlossen wäre! Isser ... aaaaaber
... nicht ;-)

Post by Kay Martinen
-snip-
Shutting down the PiDP-11
Important. To shut the system down in an orderly manner, push the HALT
switch down and then depress the ADDRESS rotary knob. Wait 15 seconds
more before you cut the power.
-snap-

Ja, das bezieht sich genau auf das Raspbian, was auf dem RasPi läuft.
Auf dem läuft dann als Anwendung der simh und auf dem das unix5 und auf
dem der init!
Bevor man also den Power-Stecker zieht, muß man das Raspbian
ordnungsgemäß herunterfahren.

Post by Kay Martinen
Zu den OS findet sich unix5 nicht, für unix7 wird geraten drei mal
'sync' aus zu führen bevor man es "verlässt" - wie o.g. vermutlich.
Oder doch einfach AUS!? Kennt unix5 kein sync?

Doch. Das habe ich dann ja auch gemacht.
Seltsamerweise gibt's da kein fsck und noch seltsamerweiserer kein
/dev/dsk oder so!

Danke trotzdem,

Josef

[Guido Grohmann]

"init" kill-en führt auch nur dazu, daß es eben keinen mehr gibt.

Oh my good, they've killed init! You <zensiert>!. (Gabs zu Anfangszeiten
von Southpark mal als T-Shirt)

scnr Guido

[Kay Martinen]

Post by Guido Grohmann

"init" kill-en führt auch nur dazu, daß es eben keinen mehr gibt.

Oh my good, they've killed init! You <zensiert>!. (Gabs zu Anfangszeiten
von Southpark mal als T-Shirt)

gab's denn umgekehrt auch eine /sbin/kenny die man (gerechterweise) mal
killen kann? z.b. mit 'fork' oder 'torch' oder 'nuke' gern auch mal mit
'knife' oder allem aus dem LART Baukasten.

Post by Guido Grohmann
scnr Guido

Dito. Ich mag South Park nicht.

Kay

[Andreas Kohlbach]

Post by Kay Martinen

Post by Guido Grohmann

"init" kill-en führt auch nur dazu, daß es eben keinen mehr gibt.

Oh my good, they've killed init! You <zensiert>!. (Gabs zu Anfangszeiten
von Southpark mal als T-Shirt)

gab's denn umgekehrt auch eine /sbin/kenny die man (gerechterweise) mal
killen kann? z.b. mit 'fork' oder 'torch' oder 'nuke' gern auch mal mit
'knife' oder allem aus dem LART Baukasten.

2001 hatte ich mal eine /bin/laden auf Linux. Obama hat sie Jahre später
nach /dev/null verschieben lassen.

Post by Kay Martinen

Post by Guido Grohmann
scnr Guido

Dito. Ich mag South Park nicht.

Ich mochte es mal. Seit vielen Jahren aber auch nicht mehr.

F'up2 poster.

[Josef Moellers]

Post by Guido Grohmann

"init" kill-en führt auch nur dazu, daß es eben keinen mehr gibt.

Oh my good, they've killed init! You <zensiert>!. (Gabs zu Anfangszeiten
von Southpark mal als T-Shirt)

Ja, irgendwann war das dann mal ein Grund für einen panic, aber unix5
scheint das zu tolerieren ;-)

Josef

[Holm Tiffe]

Post by Josef Moellers
Mooi'n,
Ich bin zwar in der benötigten Altersklasse (dieses Jahr 0x40), komme
Ich habe mir den PiDP11 von Oscar Vermeulen geleistet (oder eher ...
geschenkt bekommen). Sieht schick aus und lief auf Anhieb.
Ich habe dann mal gleich das unix5 ausprobiert und steckte fest: wie in
aller Herrgotts Namen fährt man das ordentlich wieder 'runter?
Also ich meine jetzt nicht simh selber oder gar Raspian, nein: wie fährt
man das unix5 herunter? "shutdown", "telinit", "poweroff" gibt es alles
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.
Any ideas?
Josef

Ich kenne die PiDP11 nicht, hab aber hier eine PDP11/83 mit 2.9BSD
und ich habe mehrere EAW P8000 mit Wega (SystemIII).
beide kann man mit halt oder init 1 in den singleuser fahren, mit init 0
fährt die PDP11 in den ODT Prompt.
Die P8000 nach init 1 im singleuser wird gemäß Doku über 3x sync und
dann Reset angehalten.

Gruß,
Holm

[Josef Moellers]

Post by Holm Tiffe

Post by Josef Moellers
Mooi'n,
Ich bin zwar in der benötigten Altersklasse (dieses Jahr 0x40), komme
Ich habe mir den PiDP11 von Oscar Vermeulen geleistet (oder eher ...
geschenkt bekommen). Sieht schick aus und lief auf Anhieb.
Ich habe dann mal gleich das unix5 ausprobiert und steckte fest: wie in
aller Herrgotts Namen fährt man das ordentlich wieder 'runter?
Also ich meine jetzt nicht simh selber oder gar Raspian, nein: wie fährt
man das unix5 herunter? "shutdown", "telinit", "poweroff" gibt es alles
nicht und "/etc/init 0" startet nur eine neue "init"-Instanz. "init"
kill-en führt auch nur dazu, daß es eben keinen mehr gibt.
Any ideas?
Josef

Ich kenne die PiDP11 nicht, hab aber hier eine PDP11/83 mit 2.9BSD
und ich habe mehrere EAW P8000 mit Wega (SystemIII).
beide kann man mit halt oder init 1 in den singleuser fahren, mit init 0
fährt die PDP11 in den ODT Prompt.

Ich bin endlich mal dazu gekommen, es auszuprobieren und: Nein, unix5
kennt kein "halt" und "init 1" startet nur einen zweiten "init"-Prozess.

Post by Holm Tiffe
Die P8000 nach init 1 im singleuser wird gemäß Doku über 3x sync und
dann Reset angehalten.

Wer lesen kann ist eindeutig im Vorteil: wenn man unix5 startet, steht
da tatsächlich "To shutdown, type 'sync' three times and halt the
emulation." B-)

Josef

[Dennis Grevenstein]

Post by Josef Moellers
Wer lesen kann ist eindeutig im Vorteil: wenn man unix5 startet, steht
da tats??chlich "To shutdown, type 'sync' three times and halt the
emulation." B-)

Ein schoenes Stueck aus meiner alten Signatur-Sammlung ist das hier:

"I remarked to Dennis that easily half the code I was writing in Multics was
error recovery code. He said: "We left all that stuff out. If there's an error,
we have this routine called panic, and when it is called, the machine crashes,
and you holler down the hall, 'Hey, reboot it.'"
Tom van Vleck and Dennis Ritchie about Multics <-> UNIX relationship

Ich glaube wir haben uns einfach nur daran gewoehnt, dass Unix immer
zuverlaessig und stabil laeuft. Wir sind uns einfach nicht mehr bewusst,
dass das nicht selbstverstaendlich ist. Unix ist sowas wie eine
Blinddarmentzuending (Appendicitis). Da sind die Leute frueher reihenweise
dran gestorben. Heutzutage wird das 100000 Mal pro Jahr (in .de) operiert.
Bei Unix ganz aehnlich. Das Design mag nicht immer perfekt sein, aber
das ist egal solange der fix gut genug funktioniert.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by Josef Moellers
Wer lesen kann ist eindeutig im Vorteil: wenn man unix5 startet, steht
da tats??chlich "To shutdown, type 'sync' three times and halt the
emulation." B-)

"I remarked to Dennis that easily half the code I was writing in Multics was
error recovery code. He said: "We left all that stuff out. If there's an error,
we have this routine called panic, and when it is called, the machine crashes,
and you holler down the hall, 'Hey, reboot it.'"
Tom van Vleck and Dennis Ritchie about Multics <-> UNIX relationship
Ich glaube wir haben uns einfach nur daran gewoehnt, dass Unix immer
zuverlaessig und stabil laeuft. Wir sind uns einfach nicht mehr bewusst,
dass das nicht selbstverstaendlich ist. Unix ist sowas wie eine
Blinddarmentzuending (Appendicitis). Da sind die Leute frueher reihenweise
dran gestorben. Heutzutage wird das 100000 Mal pro Jahr (in .de) operiert.
Bei Unix ganz aehnlich. Das Design mag nicht immer perfekt sein, aber
das ist egal solange der fix gut genug funktioniert.

Inzwischen ist das mit dem 'zuverlässig laufen' bei Unix eher die
Ausnahme wenn man sich den Rest der Softwarewelt so betrachtet. Der
Service schmiert alle paar Tage aus unklarer Ursache ab? Debuggen?
Wieso? Da schedulen wir einfach einen täglichen Restart, passt!
Alternativ: Wenn er crasht wird automatisch eine neue Instanz
hochgefahren. Wozu haben wir denn Docker usw.?

Gerrit

[olaf]

Post by Gerrit Heitsch
Inzwischen ist das mit dem 'zuverlässig laufen' bei Unix eher die
Ausnahme wenn man sich den Rest der Softwarewelt so betrachtet.

Also meine Erfahrung ist das ein Linux immer noch sehr zuverlaessig
laeuft. (zumindest mein Centos 7.7) Da wo die Linux-Welt gerade in
Kacke versinkt das ist Softwarediversifikation.

Ich wollte auch gerade ein neues Tool (icestorm) installieren. Hat
nicht geklappt. Wieso nicht? Der Programmierer war sich zu schade make
zu benutzen, nein er braucht eine cmake Sonderlocke. Okay, hab ich auch
installiert. Aber nein er braucht mindestens cmake 3.3. Ich hab aber
nur 3.1.x in meiner distribution. Also muesste ich mir als naechsts
den Source von cmake besorgen und selber uebersetzen. Und wer weiss
was da wieder fuer interessante Abhaengigkeiten zu Tage treten.

Also laesst man es irgendwann lieber sein weil man sich denkt das die
Programmierer heute alle einen an der Waffel haben.

Post by Gerrit Heitsch
hochgefahren. Wozu haben wir denn Docker usw.?

Docker haben wir weil die Informatik-Daddelburschen gemerkt haben das
ausser ihnen selber niemand mehr ihre Software installieren kann und
sie sich so sehr einsam gefuehlt haben.

Olaf

[Michael Bäuerle]

Post by olaf
[...]
Ich wollte auch gerade ein neues Tool (icestorm) installieren. Hat
nicht geklappt. Wieso nicht? Der Programmierer war sich zu schade make
zu benutzen, nein er braucht eine cmake Sonderlocke. Okay, hab ich auch
installiert. Aber nein er braucht mindestens cmake 3.3. Ich hab aber
nur 3.1.x in meiner distribution. Also muesste ich mir als naechsts
den Source von cmake besorgen und selber uebersetzen. Und wer weiss
was da wieder fuer interessante Abhaengigkeiten zu Tage treten.

Wie wäre es z.B. mit C++17 und der vorhandene Compiler kann das nicht.
In Kombination mit inkompatiblem C++ ABI beim neuen Compiler.

Oder Rust (z.B. via librsvg).

[Gerrit Heitsch]

Post by olaf

Post by Gerrit Heitsch
Inzwischen ist das mit dem 'zuverlässig laufen' bei Unix eher die
Ausnahme wenn man sich den Rest der Softwarewelt so betrachtet.

Also meine Erfahrung ist das ein Linux immer noch sehr zuverlaessig
laeuft. (zumindest mein Centos 7.7) Da wo die Linux-Welt gerade in
Kacke versinkt das ist Softwarediversifikation.

Ich meine nicht Linux/Unix, sondern das, was darauf läuft...

Post by olaf

Post by Gerrit Heitsch
hochgefahren. Wozu haben wir denn Docker usw.?

Docker haben wir weil die Informatik-Daddelburschen gemerkt haben das
ausser ihnen selber niemand mehr ihre Software installieren kann und
sie sich so sehr einsam gefuehlt haben.

Womit man sich dann wieder extra Komplexität ans Bein bindet. Hast du
dir mal angeschaut was Docker mit deiner Netzwerkconfig anstellt?

Gerrit

[Arno Welzel]

[...]

Post by Gerrit Heitsch

Post by olaf
Docker haben wir weil die Informatik-Daddelburschen gemerkt haben das
ausser ihnen selber niemand mehr ihre Software installieren kann und
sie sich so sehr einsam gefuehlt haben.

Womit man sich dann wieder extra Komplexität ans Bein bindet. Hast du
dir mal angeschaut was Docker mit deiner Netzwerkconfig anstellt?

Es werden ein paar zusätzliche Interfaces angelegt. Ja und?

Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

[Gerrit Heitsch]

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by olaf
Docker haben wir weil die Informatik-Daddelburschen gemerkt haben das
ausser ihnen selber niemand mehr ihre Software installieren kann und
sie sich so sehr einsam gefuehlt haben.

Womit man sich dann wieder extra Komplexität ans Bein bindet. Hast du
dir mal angeschaut was Docker mit deiner Netzwerkconfig anstellt?

Es werden ein paar zusätzliche Interfaces angelegt. Ja und?

Und warum braucht man diese Interfaces? Du willst doch nur einen Service
bereitstellen, der kann doch das normale Interface benutzen wie jeder
service das tut der ohne Docker direkt läuft.

Post by Arno Welzel
Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

systemd hat einige Probleme gehabt bis er halbwegs brauchbar war. Das
beste war die Fehlermeldung, die mir sagte, ich sollte doch folgenden
Befehl eingeben um rauszufinden was schiefgegangen ist... Und wie mache
ich das wenn ich keine (egal wie einfache) Shell habe?
Schönwettersoftware...

Gerrit

[Bernd Laengerich]

Post by Gerrit Heitsch
Und warum braucht man diese Interfaces? Du willst doch nur einen Service
bereitstellen, der kann doch das normale Interface benutzen wie jeder
service das tut der ohne Docker direkt läuft.

Wenn man ein Betriebssystem in einem Betriebssystem laufen lassen
möchte, tut man gut daran dieses Gastsystem in einem eigenen Netzwerk
laufen zu lassen. Wie sollte wohl sonst ein "telnet localhost" wissen,
ob man den telnetd des Host- oder des Gastsystemes nutzen möchte?

Bernd

[Gerrit Heitsch]

Post by Bernd Laengerich

Post by Gerrit Heitsch
Und warum braucht man diese Interfaces? Du willst doch nur einen
Service bereitstellen, der kann doch das normale Interface benutzen
wie jeder service das tut der ohne Docker direkt läuft.

Wenn man ein Betriebssystem in einem Betriebssystem laufen lassen
möchte, tut man gut daran dieses Gastsystem in einem eigenen Netzwerk
laufen zu lassen. Wie sollte wohl sonst ein "telnet localhost" wissen,
ob man den telnetd des Host- oder des Gastsystemes nutzen möchte?

Ein Docker-Container benutzt aber denselben Kernel wie der Rest des
Systems. Es ist also kein OS im OS. Du benutzt nur ein paar Features im
Kernel den Kram von einander zu isolieren (und hoffst, daß das auch
wirklich zu 100% funktioniert).

Ansonsten... Wenn Port 23 schon vom telnetd des Systems besetzt ist,
dann muss der des Containers eben einen anderen Port benutzen, ist ja
nicht so, daß telnetd nur auf Port 23 laufen kann.

Noch zum Thema Komplexität... Wenn du Container benutzt musst du nicht
nur dein Host-OS auf dem aktuellen Stand halten sondern auch alle deine
Container.

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Bernd Laengerich

Post by Gerrit Heitsch
Und warum braucht man diese Interfaces? Du willst doch nur einen
Service bereitstellen, der kann doch das normale Interface benutzen
wie jeder service das tut der ohne Docker direkt läuft.

Wenn man ein Betriebssystem in einem Betriebssystem laufen lassen
möchte, tut man gut daran dieses Gastsystem in einem eigenen Netzwerk
laufen zu lassen. Wie sollte wohl sonst ein "telnet localhost" wissen,
ob man den telnetd des Host- oder des Gastsystemes nutzen möchte?

Ein Docker-Container benutzt aber denselben Kernel wie der Rest des
Systems. Es ist also kein OS im OS. Du benutzt nur ein paar Features im
Kernel den Kram von einander zu isolieren (und hoffst, daß das auch
wirklich zu 100% funktioniert).

Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Post by Gerrit Heitsch
Ansonsten... Wenn Port 23 schon vom telnetd des Systems besetzt ist,
dann muss der des Containers eben einen anderen Port benutzen, ist ja
nicht so, daß telnetd nur auf Port 23 laufen kann.

Evtl. möchte man ja nicht, dass der Container auf des telnetd des Hosts
zugreifen darf?

Viele Grüße
Ulf

[Gerrit Heitsch]

Post by Ulf Volmer

Post by Gerrit Heitsch

Post by Bernd Laengerich

Post by Gerrit Heitsch
Und warum braucht man diese Interfaces? Du willst doch nur einen
Service bereitstellen, der kann doch das normale Interface benutzen
wie jeder service das tut der ohne Docker direkt läuft.

Wenn man ein Betriebssystem in einem Betriebssystem laufen lassen
möchte, tut man gut daran dieses Gastsystem in einem eigenen Netzwerk
laufen zu lassen. Wie sollte wohl sonst ein "telnet localhost" wissen,
ob man den telnetd des Host- oder des Gastsystemes nutzen möchte?

Ein Docker-Container benutzt aber denselben Kernel wie der Rest des
Systems. Es ist also kein OS im OS. Du benutzt nur ein paar Features im
Kernel den Kram von einander zu isolieren (und hoffst, daß das auch
wirklich zu 100% funktioniert).

Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Prozesse sind schon immer unter Unix voneinander isoliert. Versuch mal
auf den Adressraum eines anderen Prozesses zuzugreifen. Der Kernel haut
dir dann auf die Finger.

Es geht hier darum, daß du dir mit Docker und ähnlichem zusätzliche
Komplexität im System einfängst die dir nachher das Debuggen erschwert
wenns mal klemmt. Daher kommen dann solche Ansätze wie den Container
einfach neu zu starten wenn der Service darin beginnt Probleme zu machen
anstatt den Bug zu finden und zu beheben.

Es beginnt an Windows zu erinnern...'Haben sie den Rechner schon neu
gestartet?'

Post by Ulf Volmer

Post by Gerrit Heitsch
Ansonsten... Wenn Port 23 schon vom telnetd des Systems besetzt ist,
dann muss der des Containers eben einen anderen Port benutzen, ist ja
nicht so, daß telnetd nur auf Port 23 laufen kann.

Evtl. möchte man ja nicht, dass der Container auf des telnetd des Hosts
zugreifen darf?

Wenn man diese Sicherheit braucht sollte der Container vielleicht gar
nicht erst auf dem fraglichen Host laufen sondern woanders, mit Firewall
dazwischen.

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Ulf Volmer
Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Prozesse sind schon immer unter Unix voneinander isoliert. Versuch mal
auf den Adressraum eines anderen Prozesses zuzugreifen. Der Kernel haut
dir dann auf die Finger.
Es geht hier darum, daß du dir mit Docker und ähnlichem zusätzliche
Komplexität im System einfängst die dir nachher das Debuggen erschwert
wenns mal klemmt. Daher kommen dann solche Ansätze wie den Container
einfach neu zu starten wenn der Service darin beginnt Probleme zu machen
anstatt den Bug zu finden und zu beheben.

Ich hatte Deinen Einwurf so verstanden, als ob Dich die zusätzliche
Komplexität im Netzwerk stören würde. Dem scheint nicht so zu sein, Du
magst Container, Jails oder Zonen scheinbar grundsätzlich nicht.
Da ist auch prinzipell nichts gegen einzuwenden. Gerade in dieser
Gruppe.

Viele Grüße
Ulf

[Gerrit Heitsch]

Post by Ulf Volmer

Post by Gerrit Heitsch

Post by Ulf Volmer
Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Prozesse sind schon immer unter Unix voneinander isoliert. Versuch mal
auf den Adressraum eines anderen Prozesses zuzugreifen. Der Kernel haut
dir dann auf die Finger.
Es geht hier darum, daß du dir mit Docker und ähnlichem zusätzliche
Komplexität im System einfängst die dir nachher das Debuggen erschwert
wenns mal klemmt. Daher kommen dann solche Ansätze wie den Container
einfach neu zu starten wenn der Service darin beginnt Probleme zu machen
anstatt den Bug zu finden und zu beheben.

Ich hatte Deinen Einwurf so verstanden, als ob Dich die zusätzliche
Komplexität im Netzwerk stören würde. Dem scheint nicht so zu sein, Du
magst Container, Jails oder Zonen scheinbar grundsätzlich nicht.

Die zusätzliche Komplexität stört. Ich habe lange mit Zonen unter
Solaris 10 gearbeitet. Was ohne einfach war wurde mit Zonen auf einmal
sehr komplex und zeitaufwendig. SunCluster mit Zonen die die Seiten
wechseln können hört sich gut an und funktioniert auch gut... Und jetzt
mach ein OS- und Clustersoftware-Upgrade auf so einem Konstrukt. Meine
eigene Doku zum Ablauf hatte am Ende über 20 Seiten.

Wenn du Container benutzt... Wie ist dein Ansatz um sicherzustellen, daß
sie im Bezug auf sicherheitsrelevante Patches auf demselben Stand wie
das Host-OS sind? Es hilft wenig wenn dein OS zwar auf dem aktuellen
Stand ist deine Container aber eine veraltete Library mit Bugs verwenden.

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Ulf Volmer
Ich hatte Deinen Einwurf so verstanden, als ob Dich die zusätzliche
Komplexität im Netzwerk stören würde. Dem scheint nicht so zu sein, Du
magst Container, Jails oder Zonen scheinbar grundsätzlich nicht.

Die zusätzliche Komplexität stört. Ich habe lange mit Zonen unter
Solaris 10 gearbeitet. Was ohne einfach war wurde mit Zonen auf einmal
sehr komplex und zeitaufwendig. SunCluster mit Zonen die die Seiten
wechseln können hört sich gut an und funktioniert auch gut... Und jetzt
mach ein OS- und Clustersoftware-Upgrade auf so einem Konstrukt. Meine
eigene Doku zum Ablauf hatte am Ende über 20 Seiten.

Dann war meine Beobachtung ja korrekt. Meine Erfahrungen mit Solaris
Zonen sind auch durchwachsen.

Post by Gerrit Heitsch
Wenn du Container benutzt... Wie ist dein Ansatz um sicherzustellen, daß
sie im Bezug auf sicherheitsrelevante Patches auf demselben Stand wie
das Host-OS sind? Es hilft wenig wenn dein OS zwar auf dem aktuellen
Stand ist deine Container aber eine veraltete Library mit Bugs verwenden.

Privat? Da halte ich meine Container halt aktuell, so wie ich es mit
dem OS halte.

Beruflich? PAL, da bin ich üblicherweise nicht für den Inhalt der
Container verantwortlich. Aber auch da gibt es m.W. Tools für,
die den Überblick über den Zoo halten.

Ich halte Deine Skepsis zu Containern ja auch nicht für grundsätzlich
falsch, das ist zu einem guten Teil die Resignation gegenüber schlechtem
Software- Design und entsprechender Dokumentation. Aber wir werden diesen
Zug nicht aufhalten können.

Viele Grüße
Ulf

[Gerrit Heitsch]

Post by Ulf Volmer

Post by Gerrit Heitsch

Post by Ulf Volmer
Ich hatte Deinen Einwurf so verstanden, als ob Dich die zusätzliche
Komplexität im Netzwerk stören würde. Dem scheint nicht so zu sein, Du
magst Container, Jails oder Zonen scheinbar grundsätzlich nicht.

Die zusätzliche Komplexität stört. Ich habe lange mit Zonen unter
Solaris 10 gearbeitet. Was ohne einfach war wurde mit Zonen auf einmal
sehr komplex und zeitaufwendig. SunCluster mit Zonen die die Seiten
wechseln können hört sich gut an und funktioniert auch gut... Und jetzt
mach ein OS- und Clustersoftware-Upgrade auf so einem Konstrukt. Meine
eigene Doku zum Ablauf hatte am Ende über 20 Seiten.

Dann war meine Beobachtung ja korrekt. Meine Erfahrungen mit Solaris
Zonen sind auch durchwachsen.

Post by Gerrit Heitsch
Wenn du Container benutzt... Wie ist dein Ansatz um sicherzustellen, daß
sie im Bezug auf sicherheitsrelevante Patches auf demselben Stand wie
das Host-OS sind? Es hilft wenig wenn dein OS zwar auf dem aktuellen
Stand ist deine Container aber eine veraltete Library mit Bugs verwenden.

Privat? Da halte ich meine Container halt aktuell, so wie ich es mit
dem OS halte.

Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Alle paar Jahre wird dann vielleicht etwas mehr Arbeit fällig wenn das
System neu aufgebaut wird, dafür spare ich mir den Aufwand mit Docker o.ä.

Post by Ulf Volmer
Beruflich? PAL, da bin ich üblicherweise nicht für den Inhalt der
Container verantwortlich.

Das ist auch ein Problem... Du hältst dein OS auf dem aktuellen Stand
und der Angreifer kommt durch einen Container rein bei dem er Eigentümer
(der eher kein Admin ist) das nicht getan hat weil es läuft ja.


Aber auch da gibt es m.W. Tools für,

Post by Ulf Volmer
die den Überblick über den Zoo halten.

Die dann auch wieder Komplexität mitbringen...

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch
Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Es vereinfacht das Deployment. Es ist mit Docker und Konsorten halt
sehr einfach, eine Development- Umgebung hochzuziehen und die im
Erfolgsfall nach Prod. zu pushen. Auch eine temporäre Buildumgebung
ist in Sekunden da und ebenso schnell wieder weg.

Viele Grüße
Ulf

[Gerrit Heitsch]

Post by Ulf Volmer

Post by Gerrit Heitsch
Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Es vereinfacht das Deployment. Es ist mit Docker und Konsorten halt
sehr einfach, eine Development- Umgebung hochzuziehen und die im
Erfolgsfall nach Prod. zu pushen. Auch eine temporäre Buildumgebung
ist in Sekunden da und ebenso schnell wieder weg.

Du vergisst dabei die Zeit die es braucht den Kram erstmal einzurichten
damit du das machen kannst. Die Dockerfiles schreiben sich nicht von
alleine und irgendwelche fertigen Pakete von einem public Hub wirst du
hoffentlich nicht benutzen. Die könnten schliesslich mehr enthalten als
in der Beschreibung steht.

Da ich kein Programmierer bin (abgesehen von mehr oder weniger
umfangreichen Shell- und PERL-Scripten) beschränkt sich bei mir das
Ganze auf die Installation eines Services aus dem Repository und die
Konfiguration desselben. Wenn das läuft ist das 'Deployment' simpel...
Auf dem Server auch aus dem Repository holen, Config vom Testsystem
rüberkopieren, fertig.

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch
Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Es vereinfacht das Deployment. Es ist mit Docker und Konsorten halt
sehr einfach, eine Development- Umgebung hochzuziehen und die im
Erfolgsfall nach Prod. zu pushen. Auch eine temporäre Buildumgebung
ist in Sekunden da und ebenso schnell wieder weg.

Du vergisst dabei die Zeit die es braucht den Kram erstmal einzurichten
damit du das machen kannst. Die Dockerfiles schreiben sich nicht von
alleine und irgendwelche fertigen Pakete von einem public Hub wirst du
hoffentlich nicht benutzen. Die könnten schliesslich mehr enthalten als
in der Beschreibung steht.

Die Dockerfiles sind erstaunlich schlicht. Das ist für jemanden mit
Kenntnissen des jeweiligen OS in der Tat trivial.
Und es ist dann halt automatisiert.

Viele Grüße
Ulf

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch
Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Es vereinfacht das Deployment. Es ist mit Docker und Konsorten halt
sehr einfach, eine Development- Umgebung hochzuziehen und die im
Erfolgsfall nach Prod. zu pushen. Auch eine temporäre Buildumgebung
ist in Sekunden da und ebenso schnell wieder weg.

Du vergisst dabei die Zeit die es braucht den Kram erstmal einzurichten
damit du das machen kannst. Die Dockerfiles schreiben sich nicht von
alleine

...aber sobald sie geschrieben sind, sind sie beliebig oft wiederverwendbar.

Post by Gerrit Heitsch
und irgendwelche fertigen Pakete von einem public Hub wirst du
hoffentlich nicht benutzen. Die könnten schliesslich mehr enthalten als
in der Beschreibung steht.

Das gilt für alle fertigen Pakete, die man irgendwo runterlädt. Wo hast
du den Compiler her, mit dem du deine Distribution compiliert hast? (Du
hast deine Distribution doch selbst compiliert?)

Post by Gerrit Heitsch
Da ich kein Programmierer bin (abgesehen von mehr oder weniger
umfangreichen Shell- und PERL-Scripten) beschränkt sich bei mir das
Ganze auf die Installation eines Services aus dem Repository und die
Konfiguration desselben. Wenn das läuft ist das 'Deployment' simpel...
Auf dem Server auch aus dem Repository holen, Config vom Testsystem
rüberkopieren, fertig.

...und wenn's nicht läuft, ist's ein Problem.

Bei Perl wäre da z.B. der Zoo aus CPAN-Modulen, der auf beiden Seiten
synchron gehalten werden will, oder ganz allgemein die Interpreter-
Version. Bei compilierten Sprachen ist das die Compiler-/libc-Version;
ich will ja nicht jedes Mal ein Komplettupgrade aller meiner Server
machen, wenn ich das Entwicklersystem upgrade und andersherum.

Mit Sandboxen wie Docker (es gibt ja auch andere) leg ich mir die
Zielumgebung einmal hin und benutze sie wieder.


Stefan

[Gerrit Heitsch]

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch
Wobei ich privat keinen Grund für Container sehe. Da installiere ich mir
den Service, den ich brauche direkt und stelle sicher, daß seine Config
Teil des Backups wird.

Es vereinfacht das Deployment. Es ist mit Docker und Konsorten halt
sehr einfach, eine Development- Umgebung hochzuziehen und die im
Erfolgsfall nach Prod. zu pushen. Auch eine temporäre Buildumgebung
ist in Sekunden da und ebenso schnell wieder weg.

Du vergisst dabei die Zeit die es braucht den Kram erstmal einzurichten
damit du das machen kannst. Die Dockerfiles schreiben sich nicht von
alleine

...aber sobald sie geschrieben sind, sind sie beliebig oft wiederverwendbar.

Post by Gerrit Heitsch
und irgendwelche fertigen Pakete von einem public Hub wirst du
hoffentlich nicht benutzen. Die könnten schliesslich mehr enthalten als
in der Beschreibung steht.

Das gilt für alle fertigen Pakete, die man irgendwo runterlädt. Wo hast
du den Compiler her, mit dem du deine Distribution compiliert hast? (Du
hast deine Distribution doch selbst compiliert?)

Nein, aber dem Repository der von mir verwendeten Distribution traue ich
weiter als einem Hub wo jeder Zeug hochladen kann.

Post by Stefan Reuther

Post by Gerrit Heitsch
Da ich kein Programmierer bin (abgesehen von mehr oder weniger
umfangreichen Shell- und PERL-Scripten) beschränkt sich bei mir das
Ganze auf die Installation eines Services aus dem Repository und die
Konfiguration desselben. Wenn das läuft ist das 'Deployment' simpel...
Auf dem Server auch aus dem Repository holen, Config vom Testsystem
rüberkopieren, fertig.

...und wenn's nicht läuft, ist's ein Problem.

Bisher noch nicht vorgekommen. Man muss natürlich beim Aufsetzen der
Server etwas nachdenken damit Entwicklung, Test und Produktion identisch
sind.

Post by Stefan Reuther
Bei Perl wäre da z.B. der Zoo aus CPAN-Modulen,

So man welche benutzt. Sehr oft kann man das vermeiden wenn man erst
einmal nachdenkt und nicht gleich zu Beginn schaut was es denn an
fertigen Modulen gibt. Man kann auch noch Kram selbst programmieren auch
wenn es anderslautende Gerüchte gibt.

Gerrit

[p***@pocnet.net]

Post by Gerrit Heitsch
Das ist auch ein Problem... Du hältst dein OS auf dem aktuellen Stand
und der Angreifer kommt durch einen Container rein bei dem er Eigentümer
(der eher kein Admin ist) das nicht getan hat weil es läuft ja.

Das ist ja kein neues Problem, sondern existiert schon einige Jahre auf
niedrigeren Ebenenen. Bei großen Hostern sind es keine veralteten oder
gehackten Container, sondern veraltete und gehackte Rootserver-VMs.

:wq! PoC

[Bernd Laengerich]

Post by Ulf Volmer
Beruflich? PAL, da bin ich üblicherweise nicht für den Inhalt der
Container verantwortlich. Aber auch da gibt es m.W. Tools für,
die den Überblick über den Zoo halten.

Ich halte die Container nicht tagesaktuell. Denn sie spiegeln den
Releasestand wieder, mit dem ein Produkt reproduzierbar gebaut und
getestet läuft. Es ist halt einfacher 100 Container vorzuhalten als 100
Rechner, die die jeweile Buildumgebung, Testumgebung und
Produktivumgebung widerspiegeln. Und bei den Rechnern kommt hinzu, daß
man sie für jeden Build und Test zunächst auf einen definierten Stand
zurücksetzen muß.

Ab und zu wird halt mal ein Container aktualisiert und dann damit getestet.

Bernd

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Ulf Volmer
Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Prozesse sind schon immer unter Unix voneinander isoliert. Versuch mal
auf den Adressraum eines anderen Prozesses zuzugreifen. Der Kernel haut
dir dann auf die Finger.
Es geht hier darum, daß du dir mit Docker und ähnlichem zusätzliche
Komplexität im System einfängst die dir nachher das Debuggen erschwert
wenns mal klemmt. Daher kommen dann solche Ansätze wie den Container
einfach neu zu starten wenn der Service darin beginnt Probleme zu machen
anstatt den Bug zu finden und zu beheben.

Container bringen eine weitere Trennschicht.

Erst haben wir unsere Programme in linearem Assembler geschrieben. Als
uns das zu aufwändig wurde, haben wir Subroutinen erfunden und uns
zusätzliche Komplexität eingefangen, die uns das Debuggen erschwert
(wenn der Program Counter auf 'printf' zeigt, weiß ich gar nicht, von wo
das aufgerufen wurde!).

Dann wurde uns zu aufwändig, immer ein komplettes System booten zu
müssen um was zu rechnen und haben ein System erfunden, in dem man
separate Programme laufen lassen kann. Später sogar gegeneinander
isolierte solche, auch wenn das das Debuggen erschwert hat (der Debugger
kann nicht mehr einfach den Debuggee auslesen).

Dann wurde uns zu aufwändig, dass wir die selben Routinen immer wieder
in unsere Programme cut&pasten mussten. Dann haben wir es in mehrere *.o
aufgeteilt und den Linker erfunden, auch wenn das wieder die Komplexität
erhöht.

Dann wurde uns zu aufwändig, immer die selben *.o angeben zu müssen und
haben die Libraries erfunden und die *.o in *.a und später *.so gepackt.

Da sind wir ein paar Jahre geblieben.

Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.
Oder dass es unter Debian 10 immer noch nicht möglich ist, ein Binary zu
bauen, das unter Debian 7 läuft, andersherum aber schon (während das
unter Windows 10 vs. Windows 7 ein eher kleineres Problem ist). Also
wurden Container erfunden.

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch
Ansonsten... Wenn Port 23 schon vom telnetd des Systems besetzt ist,
dann muss der des Containers eben einen anderen Port benutzen, ist ja
nicht so, daß telnetd nur auf Port 23 laufen kann.

Evtl. möchte man ja nicht, dass der Container auf des telnetd des Hosts
zugreifen darf?

Wenn man diese Sicherheit braucht sollte der Container vielleicht gar
nicht erst auf dem fraglichen Host laufen sondern woanders, mit Firewall
dazwischen.

Warum zwei Eisen hinstellen, wenn es eins auch tut?


Stefan

[Gerrit Heitsch]

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Ulf Volmer
Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Prozesse sind schon immer unter Unix voneinander isoliert. Versuch mal
auf den Adressraum eines anderen Prozesses zuzugreifen. Der Kernel haut
dir dann auf die Finger.
Es geht hier darum, daß du dir mit Docker und ähnlichem zusätzliche
Komplexität im System einfängst die dir nachher das Debuggen erschwert
wenns mal klemmt. Daher kommen dann solche Ansätze wie den Container
einfach neu zu starten wenn der Service darin beginnt Probleme zu machen
anstatt den Bug zu finden und zu beheben.

Container bringen eine weitere Trennschicht.
Erst haben wir unsere Programme in linearem Assembler geschrieben. Als
uns das zu aufwändig wurde, haben wir Subroutinen erfunden und uns
zusätzliche Komplexität eingefangen, die uns das Debuggen erschwert
(wenn der Program Counter auf 'printf' zeigt, weiß ich gar nicht, von wo
das aufgerufen wurde!).
Dann wurde uns zu aufwändig, immer ein komplettes System booten zu
müssen um was zu rechnen und haben ein System erfunden, in dem man
separate Programme laufen lassen kann. Später sogar gegeneinander
isolierte solche, auch wenn das das Debuggen erschwert hat (der Debugger
kann nicht mehr einfach den Debuggee auslesen).
Dann wurde uns zu aufwändig, dass wir die selben Routinen immer wieder
in unsere Programme cut&pasten mussten. Dann haben wir es in mehrere *.o
aufgeteilt und den Linker erfunden, auch wenn das wieder die Komplexität
erhöht.
Dann wurde uns zu aufwändig, immer die selben *.o angeben zu müssen und
haben die Libraries erfunden und die *.o in *.a und später *.so gepackt.
Da sind wir ein paar Jahre geblieben.
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.

Solche Programme sind schlecht programmiert und sollten ersetzt bzw.
debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in
einem Container willst du keinen von aussen erreichbaren Service haben
der eine veraltete .so benutzt, also musst du da sowieso ran.

Post by Stefan Reuther
Oder dass es unter Debian 10 immer noch nicht möglich ist, ein Binary zu
bauen, das unter Debian 7 läuft, andersherum aber schon (während das
unter Windows 10 vs. Windows 7 ein eher kleineres Problem ist). Also
wurden Container erfunden.

Ergibt dann aber die zusätzliche Komplexität die Container aktuell zu
halten weil sie eigene Versionen enthalten, also nicht vom
Updatemechanismus des OS behandelt werden.

Wieviele Leute, die Container benutzen kümmern sich um die dort drin
verwendete Software und installieren alle Sicherheitspatches?

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch
Ansonsten... Wenn Port 23 schon vom telnetd des Systems besetzt ist,
dann muss der des Containers eben einen anderen Port benutzen, ist ja
nicht so, daß telnetd nur auf Port 23 laufen kann.

Evtl. möchte man ja nicht, dass der Container auf des telnetd des Hosts
zugreifen darf?

Wenn man diese Sicherheit braucht sollte der Container vielleicht gar
nicht erst auf dem fraglichen Host laufen sondern woanders, mit Firewall
dazwischen.

Warum zwei Eisen hinstellen, wenn es eins auch tut?

Weil Spectre, Meltdown usw. auf demselben Eisen sehr gut funktionieren,
aber nicht mehr wenn es zwei (oder mehr) sind. Und das setzt voraus, daß
deine Trennschicht keine weiteren Löcher hat.

Man könnte auch fragen warum man Prozesse voneinander abschotten muss
und eine MMU braucht wenn Multitasking auch ohne geht (Beispiel: AmigaOS).

Gerrit

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Stefan Reuther
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.

Solche Programme sind schlecht programmiert und sollten ersetzt bzw.
debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in
einem Container willst du keinen von aussen erreichbaren Service haben
der eine veraltete .so benutzt, also musst du da sowieso ran.

Nicht jede Software ist automatisch ein "von außen erreichbarer Service".

Post by Gerrit Heitsch

Post by Stefan Reuther
Oder dass es unter Debian 10 immer noch nicht möglich ist, ein Binary zu
bauen, das unter Debian 7 läuft, andersherum aber schon (während das
unter Windows 10 vs. Windows 7 ein eher kleineres Problem ist). Also
wurden Container erfunden.

Ergibt dann aber die zusätzliche Komplexität die Container aktuell zu
halten weil sie eigene Versionen enthalten, also nicht vom
Updatemechanismus des OS behandelt werden.

Sofern man die halt aktuell halten muss. Meine Build-Sandboxen sind hier
unter anderem ein Debian 3 und ein Debian 8, da fallen Binaries raus,
die in erster Näherung überall laufen (Debian 3 kann noch sinnvoll
statisch gelinkte Binaries bauen). Und außer mir hat da keiner Zugriff
drauf. Ist mir wurscht, dass da vielleicht noch ein kaputtes openssl
rumliegt.

Und wenn doch ist das Erstellen der Sandboxen gescripted und ich kann
einfach die Pakete tauschen.

Post by Gerrit Heitsch
Wieviele Leute, die Container benutzen kümmern sich um die dort drin
verwendete Software und installieren alle Sicherheitspatches?

Ich habe keinen Grund zu der Annahme, dass die Antwort auf die Frage
eine andere ist als auf die gleiche Frage ohne "Container benutzen".

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch
Wenn man diese Sicherheit braucht sollte der Container vielleicht gar
nicht erst auf dem fraglichen Host laufen sondern woanders, mit Firewall
dazwischen.

Warum zwei Eisen hinstellen, wenn es eins auch tut?

Weil Spectre, Meltdown usw. auf demselben Eisen sehr gut funktionieren,
aber nicht mehr wenn es zwei (oder mehr) sind. Und das setzt voraus, daß
deine Trennschicht keine weiteren Löcher hat.

Wenn mir alle Partitionen des Eisens gehören, ist das nicht so relevant.

Post by Gerrit Heitsch
Man könnte auch fragen warum man Prozesse voneinander abschotten muss
und eine MMU braucht wenn Multitasking auch ohne geht (Beispiel: AmigaOS).

Richtig. Man muss doch einfach nur fehlerfreie Programme schreiben.

(Das ist der Grund, warum ich das einsetze, was man heute Microservices
nennt: ich trau auch meinem selbstgebauten Code nicht.)


Stefan

[Gerrit Heitsch]

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Stefan Reuther
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.

Solche Programme sind schlecht programmiert und sollten ersetzt bzw.
debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in
einem Container willst du keinen von aussen erreichbaren Service haben
der eine veraltete .so benutzt, also musst du da sowieso ran.

Nicht jede Software ist automatisch ein "von außen erreichbarer Service".

Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Post by Stefan Reuther

Post by Gerrit Heitsch
Weil Spectre, Meltdown usw. auf demselben Eisen sehr gut funktionieren,
aber nicht mehr wenn es zwei (oder mehr) sind. Und das setzt voraus, daß
deine Trennschicht keine weiteren Löcher hat.

Wenn mir alle Partitionen des Eisens gehören, ist das nicht so relevant.

Dir ja. Aber wie sieht es bei der großen Mehrheit aus?

Post by Stefan Reuther

Post by Gerrit Heitsch
Man könnte auch fragen warum man Prozesse voneinander abschotten muss
und eine MMU braucht wenn Multitasking auch ohne geht (Beispiel: AmigaOS).

Richtig. Man muss doch einfach nur fehlerfreie Programme schreiben.
(Das ist der Grund, warum ich das einsetze, was man heute Microservices
nennt: ich trau auch meinem selbstgebauten Code nicht.)

Ah, Microservices... Also nochmal mehr Komplexität. Was kann dabei schon
schiefgehen?

Gerrit

[Bernd Laengerich]

Post by Gerrit Heitsch
Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Äh, nein. Gerade Entwicklungs-, Build- und Testsysteme profitieren doch
enorm von Containern. Das Deployment läuft bei uns klassisch mit *viel*
dokumentatorischem und organisatorischem Klimbim.

Bernd

[Gerrit Heitsch]

Post by Bernd Laengerich

Post by Gerrit Heitsch
Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Äh, nein. Gerade Entwicklungs-, Build- und Testsysteme profitieren doch
enorm von Containern.

Testsysteme eigentlich nicht, die sollten, in der Theorie zumindest,
100% identisch zum Produktionssystem sein, sonst sind die Tests nicht
wirklich aussagekräftig. Wenn das also kein Container ist, dann das
Testsystem auch nicht.

Entwicklungssystem als Container? Wieso? Da schreibst du doch nur deinen
Code.

Das Deployment läuft bei uns klassisch mit *viel*

Post by Bernd Laengerich
dokumentatorischem und organisatorischem Klimbim.

Ja, kenn ich... Tickets, Staging...

Gerrit

[Bernd Laengerich]

Post by Gerrit Heitsch
Entwicklungssystem als Container? Wieso? Da schreibst du doch nur deinen
Code.

Wenn der Code auf 5 Plattformen mit 5 verschiedenen Compilern laufen
soll, binde ich mir nicht für jeden Entwickler 5 physische Rechner dafür
ans Bein. Dazu die verschiedenen Releasezweige mit unterschiedlichen
Bibliotheksständen. Das liegt alles als Containerdefinition vor und hat
den Vorteil, immer reproduzierbar gleich zu sein.

Bernd

[Gerrit Heitsch]

Post by Bernd Laengerich

Post by Gerrit Heitsch
Entwicklungssystem als Container? Wieso? Da schreibst du doch nur
deinen Code.

Wenn der Code auf 5 Plattformen mit 5 verschiedenen Compilern laufen
soll, binde ich mir nicht für jeden Entwickler 5 physische Rechner dafür
ans Bein. Dazu die verschiedenen Releasezweige mit unterschiedlichen
Bibliotheksständen. Das liegt alles als Containerdefinition vor und hat
den Vorteil, immer reproduzierbar gleich zu sein.

Nur solange du noch an die Dateien kommst, die du dafür brauchst.
Sollten die mal aus dem Repository fliegen aus dem sie dein
Containersetup laut der Definition zieht ('den alten Schrott braucht
keiner mehr') bekommst du ein Problem. Wenn du es wirklich
reproduzierbar willst, solltest du eine komplette VM nehmen die passend
aufgesetzt ist. Die dann für die nötige Arbeit clonen.

Solange du die Datei, die die VM darstellt, hast geht das und du bist
von keinem anderen abhängig.

Gerrit

[Bernd Laengerich]

Nur solange du noch an die Dateien kommst, die du dafür brauchst. Sollten die

Sicher, aber die erzeugten Images werden hier lokal gespeichert.

Problem. Wenn du es wirklich reproduzierbar willst, solltest du eine komplette
VM nehmen die passend aufgesetzt ist. Die dann für die nötige Arbeit clonen.

Das ist ja noch viel mehr Overhead und Komplexität als ein Container.

Solange du die Datei, die die VM darstellt, hast geht das und du bist von
keinem anderen abhängig.

Solange ich das Docker-Image, das den Container darstellt, habe geht das und
ich bin von keinem anderen abhängig.

Bernd

[Gerrit Heitsch]

Post by Bernd Laengerich

Nur solange du noch an die Dateien kommst, die du dafür brauchst. Sollten die

Sicher, aber die erzeugten Images werden hier lokal gespeichert.

Problem. Wenn du es wirklich reproduzierbar willst, solltest du eine
komplette VM nehmen die passend aufgesetzt ist. Die dann für die
nötige Arbeit clonen.

Das ist ja noch viel mehr Overhead und Komplexität als ein Container.

Wieso? Die VM ist eine Datei.

Gerrit

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Stefan Reuther
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.

Solche Programme sind schlecht programmiert und sollten ersetzt bzw.
debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in
einem Container willst du keinen von aussen erreichbaren Service haben
der eine veraltete .so benutzt, also musst du da sowieso ran.

Nicht jede Software ist automatisch ein "von außen erreichbarer Service".

Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Definiere "typischerweise". In meinem Umfeld ist der Einsatz als
Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind
allerdings soweit ich weiß auch containert.

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch
Weil Spectre, Meltdown usw. auf demselben Eisen sehr gut funktionieren,
aber nicht mehr wenn es zwei (oder mehr) sind. Und das setzt voraus, daß
deine Trennschicht keine weiteren Löcher hat.

Wenn mir alle Partitionen des Eisens gehören, ist das nicht so relevant.

Dir ja. Aber wie sieht es bei der großen Mehrheit aus?

Auch hier gehören uns die kompletten Eisen.

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch
Man könnte auch fragen warum man Prozesse voneinander abschotten muss
und eine MMU braucht wenn Multitasking auch ohne geht (Beispiel: AmigaOS).

Richtig. Man muss doch einfach nur fehlerfreie Programme schreiben.
(Das ist der Grund, warum ich das einsetze, was man heute Microservices
nennt: ich trau auch meinem selbstgebauten Code nicht.)

Ah, Microservices... Also nochmal mehr Komplexität. Was kann dabei schon
schiefgehen?

Man kann es "Microservices" nennen und verdammen, so wie man alles Neue
verdammt.

Oder man nennt es "Unix-way of programming": "do one thing and do it
well". Ein Zoo aus Microservices ist auch nichts viel anders als ein Zoo
aus vielen kleinen Utilities in einer Pipeline. Oder eine Handvoll
FastCGI-Prozesse hinter einem Webserver. Oder ein Postfix, das u.a. aus
Sicherheitsgründen in ein halbes Dutzend Daemons zerlegt wurde - und das
hat nun bei weitem keinen schlechten Ruf.

Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal
besser, als einen fetten monolithischen Servlet-Container hinzustellen,
den man einmal täglich wegen out-of-memory rebooten muss.


Stefan

[Gerrit Heitsch]

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Stefan Reuther
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.

Solche Programme sind schlecht programmiert und sollten ersetzt bzw.
debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in
einem Container willst du keinen von aussen erreichbaren Service haben
der eine veraltete .so benutzt, also musst du da sowieso ran.

Nicht jede Software ist automatisch ein "von außen erreichbarer Service".

Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Definiere "typischerweise". In meinem Umfeld ist der Einsatz als
Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind
allerdings soweit ich weiß auch containert.

Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist
damit verdächtig.

Und ein Repository 'Bitbucket' zu nennen... Der Bitbucket ist immer noch
/dev/null und dem vertraue ich nur Zeug an was weg kann.

Post by Stefan Reuther
Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal
besser, als einen fetten monolithischen Servlet-Container hinzustellen,
den man einmal täglich wegen out-of-memory rebooten muss.

Wenn man das muss, dann muss man auch den Programmierer mit Bugreports
zuwerfen bis er den Fehler findet.

Gerrit

[Hanno Foest]

Post by Gerrit Heitsch
Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist
damit verdächtig.

Es ist grauenhaft. Alles andere mit der gleichen Funktion allerdings
auch. Eher mehr.

Hanno

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Stefan Reuther

Post by Gerrit Heitsch

Post by Stefan Reuther
Nicht jede Software ist automatisch ein "von außen erreichbarer Service".

Dazu werden Container aber typischweise benutzt. Dein Einsatz als
Buildsystem ist da eher eine Ausnahme.

Definiere "typischerweise". In meinem Umfeld ist der Einsatz als
Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind
allerdings soweit ich weiß auch containert.

Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist
damit verdächtig.

Jira führt an unserer Dreckstool-Liste mit mehreren Größenordnungen
Vorsprung (vor Outlook, SAP, Word, Apple-Produkten, ...).

Man sagt ihm nach, dass es viel kann. Das führt dann dazu, dass Leute
mit Schulterklappen Anweisungen erteilen, es so einzurichten, dass es
ihre Workflows abbildet (weil: das muss es ja können), und die
zahlenmäßig überlegene Schar von Leuten ohne Schulterklappen drölfzig
sinnlose Felder ausfüllen müssen, aber für ihre eigenen Workflows
Keywords recyceln müssen. Ich durfte mich auch schon belehren lassen,
dass es sich nicht geziemt, seitenlange Kommentare mit Logzitaten und
Analysen an Fehlertickets zu schreiben, das wird so unübersichtlich.
Ach so, und niemand verkackt Rich-Text-Editoren so gut wie Atlassian.
Immerhin hat's eine dokumentierte API.

Mantis war irgendwie einfacher. Hatte aber auch keinen Rich-Text-Editor.
Und generiert keine 500-Zeilen-Exception-Dumps.

Post by Gerrit Heitsch

Post by Stefan Reuther
Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal
besser, als einen fetten monolithischen Servlet-Container hinzustellen,
den man einmal täglich wegen out-of-memory rebooten muss.

Wenn man das muss, dann muss man auch den Programmierer mit Bugreports
zuwerfen bis er den Fehler findet.

Tja, in einer idealen Welt... In einer realen Welt ist es manchmal
kosteneffizienter, zu rebooten.

Es gab da mal die Story von High-Frequency-Trading-Systemen in Java. Die
bekommen ausreichend RAM, um über einen Börsentag zu kommen, und werden
dann rebootet. Garbage Collection würde die Latenz versauen.


Stefan

[Hanno Foest]

Am 08.03.20 um 10:25 schrieb Stefan Reuther:

[...]

Post by Stefan Reuther
Dann wurde uns zu aufwändig, immer die selben *.o angeben zu müssen und
haben die Libraries erfunden und die *.o in *.a und später *.so gepackt.
Da sind wir ein paar Jahre geblieben.
Und dann haben wir festgestellt, dass das mit den *.so ganz schön
kompliziert ist und manche Programme eben auf einer alten *.so bestehen.
Oder dass es unter Debian 10 immer noch nicht möglich ist, ein Binary zu
bauen, das unter Debian 7 läuft, andersherum aber schon (während das
unter Windows 10 vs. Windows 7 ein eher kleineres Problem ist). Also
wurden Container erfunden.

https://blog.fefe.de/?ts=a0d07bd8

Hanno

[Hanno Foest]

Post by Ulf Volmer

Post by Gerrit Heitsch
Ein Docker-Container benutzt aber denselben Kernel wie der Rest des
Systems. Es ist also kein OS im OS. Du benutzt nur ein paar Features im
Kernel den Kram von einander zu isolieren (und hoffst, daß das auch
wirklich zu 100% funktioniert).

Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um
Prozesse voneinander zu isolieren. Warum möchtest Du das Feature
gerade für's Netzwerk nicht benutzen?

Wenn ich ein Feature nutzen möchte, werde ich das so konfigurieren. Wenn
ich es nicht nutzen möchte, aber das dennoch so reingewürgt bekomme,
finde ich das etwas doof.

Hanno

[Dennis Grevenstein]

Post by Arno Welzel
Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

Ähm... Ich habe bisher gedacht systemd ist böse, weil es kein SystemV
init mehr ist. Bin ich jetzt schon solange aus dem Geschäft raus, dass
ich da was esentielles nicht verstanden habe?

gruss,
Dennis

[Michael Bäuerle]

Post by Dennis Grevenstein

Post by Arno Welzel
Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

Ähm... Ich habe bisher gedacht systemd ist böse, weil es kein SystemV
init mehr ist. Bin ich jetzt schon solange aus dem Geschäft raus, dass
ich da was esentielles nicht verstanden habe?

Das Problem hat wenig bis nichts mit dem Teil von systemd zu tun, der
das init ersetzt (egal welches).

Das Problem an systemd ist, dass da noch viele andere Komponenten
angedockt sind, die alleine (bzw. mit einem anderen init) nicht
lauffähig sind. Diese gesamte Konstruktion bietet diverse APIs an,
mit denen Programme darauf zugreifen können. Auf diese Weise ist es
möglich, dass Abhängigkeiten im System entstehen, die vom init bis
zum GUI reichen.

[Arno Welzel]

Michael Bäuerle:

[...]

Post by Michael Bäuerle
Das Problem an systemd ist, dass da noch viele andere Komponenten
angedockt sind, die alleine (bzw. mit einem anderen init) nicht
lauffähig sind. Diese gesamte Konstruktion bietet diverse APIs an,
mit denen Programme darauf zugreifen können. Auf diese Weise ist es
möglich, dass Abhängigkeiten im System entstehen, die vom init bis
zum GUI reichen.

Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

[p***@pocnet.net]

Post by Arno Welzel
Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

Zum Glück sind die üblichen Serverkomonenten zumindest bei Debian noch
vollständig mit Sysvinit lauffähig.

Als Server-Admin ist es mir ziemlich bums, ob ein Server (oder eine VM) 5 oder
30 Sekunden zum Booten braucht. Als Server-Admin ist es mir wichtig, dass ich
nachts um drei rausgeklingelt nicht erst lange überlegen muss, wie ich einen
Fehler debugge, wenn ich im Systemd-Wust nach Logs forschen muss.

Ja, ich könnte mich versuchen dazu durchzuringen, mir mal einen halben Tag Zeit
zu nehmen und mir das Thema intensiv anzuschauen. Dann brauch ich's ein halbes
Jahr nicht und stehe wieder vor derselben Herausforderung. Vermutlich eine der
Tatsachen, die das Älterwerden mit sich bringt: Früher (Schule/Berufsschule)
hatte ich mehr Zeit und Muße, alles mögliche Zeugs zu lernen. Heute bin ich
bequem und solange mein etabliertes Wissen gut genug funktioniert, sehe ich zu
dass ich damit durchkomme.

Das heißt nicht, dass ich nichts neues lerne. Ich bin lediglich selektiver in
dem *was* ich lernen mag. :-) Zeit wird wertvoller, je älter ich werde.

:wq! PoC

[Arno Welzel]

Post by p***@pocnet.net

Post by Arno Welzel
Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

Zum Glück sind die üblichen Serverkomonenten zumindest bei Debian noch
vollständig mit Sysvinit lauffähig.
Als Server-Admin ist es mir ziemlich bums, ob ein Server (oder eine VM) 5 oder
30 Sekunden zum Booten braucht. Als Server-Admin ist es mir wichtig, dass ich
nachts um drei rausgeklingelt nicht erst lange überlegen muss, wie ich einen
Fehler debugge, wenn ich im Systemd-Wust nach Logs forschen muss.

systemd wurde nicht entwickelt, damit Boot-Zeiten schneller werden.

Auch finde ich eine Abfrage mit journalctl deutlich effektiver als
dutzende Logdateien zu durchsuchen. Und so manches SysV-init-Script ist
ziemlich eklig.

Post by p***@pocnet.net
Ja, ich könnte mich versuchen dazu durchzuringen, mir mal einen halben Tag Zeit
zu nehmen und mir das Thema intensiv anzuschauen. Dann brauch ich's ein halbes
Jahr nicht und stehe wieder vor derselben Herausforderung. Vermutlich eine der

[...]

Das würde Dir mit SysV-Init genauso gehen, wenn Du es nicht schon kennen
würdest.

[Gerrit Heitsch]

Post by Arno Welzel

Post by p***@pocnet.net

Post by Arno Welzel
Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

Zum Glück sind die üblichen Serverkomonenten zumindest bei Debian noch
vollständig mit Sysvinit lauffähig.
Als Server-Admin ist es mir ziemlich bums, ob ein Server (oder eine VM) 5 oder
30 Sekunden zum Booten braucht. Als Server-Admin ist es mir wichtig, dass ich
nachts um drei rausgeklingelt nicht erst lange überlegen muss, wie ich einen
Fehler debugge, wenn ich im Systemd-Wust nach Logs forschen muss.

systemd wurde nicht entwickelt, damit Boot-Zeiten schneller werden.

Der Eindruck wurde aber vermittelt.

Post by Arno Welzel
Auch finde ich eine Abfrage mit journalctl deutlich effektiver als
dutzende Logdateien zu durchsuchen. Und so manches SysV-init-Script ist
ziemlich eklig.

Dafür sind die Logdateien Text, das auf dem journalctl aufsetzt nicht.
Solange es funktioniert, schöne Sache. Sobald aber nicht mehr bekommst
du ein Problem. Schönwettersystem eben. Textdateien kann ich auch in
beschädigtem Zustand noch lesen und relevante Informationen extrahieren.
Wie gut kann journalctl das wenn das Journal beschädigt wurde?

Gerrit

[Arno Welzel]

Post by Gerrit Heitsch

Post by Arno Welzel

Post by p***@pocnet.net

Post by Arno Welzel
Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

Zum Glück sind die üblichen Serverkomonenten zumindest bei Debian noch
vollständig mit Sysvinit lauffähig.
Als Server-Admin ist es mir ziemlich bums, ob ein Server (oder eine VM) 5 oder
30 Sekunden zum Booten braucht. Als Server-Admin ist es mir wichtig, dass ich
nachts um drei rausgeklingelt nicht erst lange überlegen muss, wie ich einen
Fehler debugge, wenn ich im Systemd-Wust nach Logs forschen muss.

systemd wurde nicht entwickelt, damit Boot-Zeiten schneller werden.

Der Eindruck wurde aber vermittelt.

Das ist nur ein Nebeneffekt, weil Units parallel starten können, was
gegenüber SysV-Init etwas schneller sein kann. Das konnten andere
Lösungen wie Upstart aber auch schon und ist keine Erfindung von systemd.

Entscheidender ist die Berücksichtigung von Abhängigkeiten zur Laufzeit
und ein einheitliches Format für Units statt Shell-Scripten, die
beliebig komplex sein können.

Post by Gerrit Heitsch

Post by Arno Welzel
Auch finde ich eine Abfrage mit journalctl deutlich effektiver als
dutzende Logdateien zu durchsuchen. Und so manches SysV-init-Script ist
ziemlich eklig.

Dafür sind die Logdateien Text, das auf dem journalctl aufsetzt nicht.

Eben - das ist ja der Vorteil. Es handelt sich um strukturierte Ablage,
die man sehr schnell abfragen kann - alle Meldungen bestimmter Units,
bestimmte Zeiträume usw..

Abgesehen davon können Daemons ja weiterhin auch selber Logs schreiben,
systemd verbietet das ja nicht. Apache, NGINX, Dovecot, Postfix usw. tun
das alle.

Post by Gerrit Heitsch
Solange es funktioniert, schöne Sache. Sobald aber nicht mehr bekommst
du ein Problem. Schönwettersystem eben. Textdateien kann ich auch in
beschädigtem Zustand noch lesen und relevante Informationen extrahieren.
Wie gut kann journalctl das wenn das Journal beschädigt wurde?

Defekte systemd-Logs hatte ich noch nie, daher kann ich das nicht
beantworten. Im Zweifelsfall wäre "journalctl --verify" relevant. Man
kann auch die Logdateien kopieren und auf einem anderen System mit
journalctl -D oder journalctl --file abfragen.

[Gerrit Heitsch]

Post by Arno Welzel

Post by Gerrit Heitsch

Post by Arno Welzel

Post by p***@pocnet.net

Post by Arno Welzel
Wobei es nicht so ist, dass ein System nur noch mit GUI lauffähig wäre,
sondern umgekehrt, dass die GUI auch systemd braucht.

Zum Glück sind die üblichen Serverkomonenten zumindest bei Debian noch
vollständig mit Sysvinit lauffähig.
Als Server-Admin ist es mir ziemlich bums, ob ein Server (oder eine VM) 5 oder
30 Sekunden zum Booten braucht. Als Server-Admin ist es mir wichtig, dass ich
nachts um drei rausgeklingelt nicht erst lange überlegen muss, wie ich einen
Fehler debugge, wenn ich im Systemd-Wust nach Logs forschen muss.

systemd wurde nicht entwickelt, damit Boot-Zeiten schneller werden.

Der Eindruck wurde aber vermittelt.

Das ist nur ein Nebeneffekt, weil Units parallel starten können, was
gegenüber SysV-Init etwas schneller sein kann. Das konnten andere
Lösungen wie Upstart aber auch schon und ist keine Erfindung von systemd.
Entscheidender ist die Berücksichtigung von Abhängigkeiten zur Laufzeit
und ein einheitliches Format für Units statt Shell-Scripten, die
beliebig komplex sein können.

Typischerweise startet eine Unit aber ein Shellscript weil es nur selten
ausreicht den fraglichen Daemon ohne weitere Vorbereitungen zu starten.

Post by Arno Welzel

Post by Gerrit Heitsch

Post by Arno Welzel
Auch finde ich eine Abfrage mit journalctl deutlich effektiver als
dutzende Logdateien zu durchsuchen. Und so manches SysV-init-Script ist
ziemlich eklig.

Dafür sind die Logdateien Text, das auf dem journalctl aufsetzt nicht.

Eben - das ist ja der Vorteil.

Nein, das ist ein großer Nachteil. Ich will meine Logfiles mit den mir
genehmen Tools auswerten können und nicht auf eines festgelegt sein.


Es handelt sich um strukturierte Ablage,

Post by Arno Welzel
die man sehr schnell abfragen kann - alle Meldungen bestimmter Units,
bestimmte Zeiträume usw..

Solange diese 'strukturierte Ablage' nicht beschädigt ist. Ist sie das,
kommt gar nichts mehr. Und ja, ich hab schon öfter beschädigte Logfiles
auswerten müssen. Es reicht ein Crash/kernel panic zur falschen Zeit.
Bei Text keine Sache, die Müllbytes überliest man einfach.

Nimm mal ein Journal-File und injiziere mal etwas Müll. Dann schau nach
was journalctl damit noch anfangen kann.

Gerrit

[Hanno Foest]

Post by Arno Welzel
systemd wurde nicht entwickelt, damit Boot-Zeiten schneller werden.

Mag sein, aber das war das damalige Verkaufsargument. Vielleicht wollen
die systemd-Jünger nichts mehr davon wissen, nachdem die Bootzeiten in
der Praxis nicht schneller wurden, aber mein Gedächtnis funktioniert
noch ganz gut.

Post by Arno Welzel
Auch finde ich eine Abfrage mit journalctl deutlich effektiver als
dutzende Logdateien zu durchsuchen.

Wenn du dutzende Logdateien durchsuchen mußt, machst du was falsch.
Andererseits war die Reboot-Schleife, zu der mir journalctl keinerlei
Auskunft geben wollte (und die ich auch nicht wie SysV Initskripte
händisch abbrechen und debuggen konnte), überaus spannend.

Post by Arno Welzel
Und so manches SysV-init-Script ist
ziemlich eklig.

Und? Es funktioniert, und ich kann zur Fehlersuche mit vi sonstwas
reinschreiben. Im Vergleich eine Wohltat.

Nachdem die systemd Units nicht das beherrschten, was ich brauchte (und
was mit SysV vorher gar kein Problem war), insbesondere im Bereich
Logging und wegen der völlig kranken und auch kaputten Übergabe des
Pfads zur Konfigurationsdatei - Stichwort systemd-escape - starte ich
meine multiplen OpenVPN Instanzen jetzt per rc.local. Fortschritt!

Andererseits ist es ein typisches Strohmannargument, SysV Startsktipte
als einzige Alternative zu postulieren. Niemand hängt explizit an SysV -
es gibt da ja noch ein paar mehr Alternativen, wie upstart, runit...

Hanno

[Michael Bäuerle]

Post by Hanno Foest
[...]
Andererseits ist es ein typisches Strohmannargument, SysV Startsktipte
als einzige Alternative zu postulieren. Niemand hängt explizit an SysV -
es gibt da ja noch ein paar mehr Alternativen, wie upstart, runit...

Das Problem am systemd-Ökosystem ist, dass seine Komponenten nicht
austauschbar und voneinander abhängig sind. Dazu haben sie viele neue
APIs, über die auch Abhängigkeiten jenseits dieses Ökosystems entstehen.

Dank dem Entwicklungsmotto (Zitat Poettering): "Never finished, never
complete, but tracking progress of technology" wird die Sache auch nie
"fertig" sein, da es gar keine definierten Entwicklungsziele gibt.

Diskussionen über Details der Implementierung wie Bootzeiten oder das
Format von Logfiles lenken von den Kernproblemen ab.

[Hanno Foest]

Post by Arno Welzel

Post by Gerrit Heitsch
Womit man sich dann wieder extra Komplexität ans Bein bindet. Hast du
dir mal angeschaut was Docker mit deiner Netzwerkconfig anstellt?

Es werden ein paar zusätzliche Interfaces angelegt. Ja und?
Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

Du kannst mir gerne mal ein aktuelles Debian auf meinem Rootserver mit
linux-vserver installieren, bisher scheiterte das an der Nutzung von
cgroups. Falls dir allerdings deine Zeit für kostenlose Arbeit zu schade
sein sollte: War sie mir bislang auch.

Ich hab ja gar nichts dagegen, daß sich manchmal Dinge ändern,
insbesondere, wenn das einen Mehrwert bringt. Aber Arbeit aufwenden zu
müssen für Dinge, deren Nutzen mir nicht erkenntlich ist, geht mir etwas
weit.

Hanno

[p***@pocnet.net]

Post by Hanno Foest
Ich hab ja gar nichts dagegen, daß sich manchmal Dinge ändern,
insbesondere, wenn das einen Mehrwert bringt. Aber Arbeit aufwenden zu
müssen für Dinge, deren Nutzen mir nicht erkenntlich ist, geht mir etwas
weit.

Ja, in der Tat. Debian Rescue System. ifconfig? Fehlanzeige. route?
Fehlanzeige. Uvam...

:wq! PoC

[Gerrit Heitsch]

Post by p***@pocnet.net

Post by Hanno Foest
Ich hab ja gar nichts dagegen, daß sich manchmal Dinge ändern,
insbesondere, wenn das einen Mehrwert bringt. Aber Arbeit aufwenden zu
müssen für Dinge, deren Nutzen mir nicht erkenntlich ist, geht mir etwas
weit.

Ja, in der Tat. Debian Rescue System. ifconfig? Fehlanzeige. route?
Fehlanzeige. Uvam...

'ifconfig' ist auch irgendeinem Grund obsolet, heute benutzt man 'ip'.
Wo dann auch gleich 'route' integriert wurde.

Gerrit

[p***@pocnet.net]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Ja, in der Tat. Debian Rescue System. ifconfig? Fehlanzeige. route?
Fehlanzeige. Uvam...

'ifconfig' ist auch irgendeinem Grund obsolet, heute benutzt man 'ip'.
Wo dann auch gleich 'route' integriert wurde.

Ja eben. Das haut in die glieche Kerbe wie Hanno so passend schreibt: Aber
Arbeit aufwenden zu müssen für Dinge, deren Nutzen mir nicht erkenntlich ist,
geht mir etwas weit.

Zum Glück kann man sich das Debian-Live-Gedöhns sehr einfach selbst bauen.

:wq! PoC

[Hanno Foest]

Post by p***@pocnet.net

Post by Gerrit Heitsch

Post by p***@pocnet.net
Ja, in der Tat. Debian Rescue System. ifconfig? Fehlanzeige. route?
Fehlanzeige. Uvam...

'ifconfig' ist auch irgendeinem Grund obsolet, heute benutzt man 'ip'.
Wo dann auch gleich 'route' integriert wurde.

Ja eben. Das haut in die glieche Kerbe wie Hanno so passend schreibt: Aber
Arbeit aufwenden zu müssen für Dinge, deren Nutzen mir nicht erkenntlich ist,
geht mir etwas weit.

Wenn in einem beschränkten Rescue System "ip" gleich mehrere Tools
ersetzt (ifconfig, route, arp...) ist mir andererseits der Nutzen
durchaus ersichtlich. Auch wenn mir z.B. "ip neigh show" nicht so gut
von der Hand geht wie "arp -an" - ersteres hat obendrein noch einen
Mehrwert (STALE, REACHABLE...) - wobei mir die Eigenarten im ARP cache
bei den neueren Kerneln bislang nicht so ganz eingängig sind. Daß
Anzeige von IPs der Default ist und man deren DNS-Auflösung mit -r extra
zuschalten muß (was ich praktisch nie will) paßt mir wiederum gut in den
Kram. Also "ip" ist so nen Fall, wo ich sagen würde, die Änderungen
gehen schon in die richtige Richtung - auch wenn es meiner Trägheit
widerstreben mag.

Andererseits hab ich gestern laut fluchend avahi von meinem
neuinstallierten Arbeits-Laptop beseitigt, nachdem es 10 Versuche
brauchte, mich mit dem zu konfigurierenden Router, der direkt per Kabel
dranhing, zu verbinden. Ohne avahi kein Problem. Nachgeguckt - natürlich
Poetteringsoft. Vielleicht funktioniert das in irgendeinem Szenario
sogar so, wie es soll, aber ich BRAUCH DAS NICHT. Das sind so die
Änderungen, denen ich GAR nichts abgewinnen kann.

Hanno

[Gerrit Heitsch]

Post by Hanno Foest
Andererseits hab ich gestern laut fluchend avahi von meinem
neuinstallierten Arbeits-Laptop beseitigt, nachdem es 10 Versuche
brauchte, mich mit dem zu konfigurierenden Router, der direkt per Kabel
dranhing, zu verbinden. Ohne avahi kein Problem. Nachgeguckt - natürlich
Poetteringsoft. Vielleicht funktioniert das in irgendeinem Szenario
sogar so, wie es soll, aber ich BRAUCH DAS NICHT. Das sind so die
Änderungen, denen ich GAR nichts abgewinnen kann.

Ich hab beim Einrichten meiner Workstation hier gleich mal auf eine
feste IP umgestellt und ausserdem auf eine reale /etc/resolv.conf die
nicht bei jedem Boot überschrieben wird.

Machte leider einiges an Arbeit bis das wirklich so lief, der
systemd-resolved.service nervte eine Weile bis ich ihn einfach abgewürgt
habe.

Gerrit

[Arno Welzel]

Post by p***@pocnet.net

Post by Hanno Foest
Ich hab ja gar nichts dagegen, daß sich manchmal Dinge ändern,
insbesondere, wenn das einen Mehrwert bringt. Aber Arbeit aufwenden zu
müssen für Dinge, deren Nutzen mir nicht erkenntlich ist, geht mir etwas
weit.

Ja, in der Tat. Debian Rescue System. ifconfig? Fehlanzeige. route?
Fehlanzeige. Uvam...

Statt ifconfig/route nutzt man schon ziemlich lange "ip". Und das hat
auch nichts mit systemd zu tun.

Siehe auch <https://linux.die.net/man/8/ip>

Und IPv6 gibt's übrigens auch schon länger, nur falls jemand glaubt, das
könnte man noch eine Weile aussitzen und müsste sich nicht damit befassen.

[Arno Welzel]

Post by Hanno Foest

Post by Arno Welzel

Post by Gerrit Heitsch
Womit man sich dann wieder extra Komplexität ans Bein bindet. Hast du
dir mal angeschaut was Docker mit deiner Netzwerkconfig anstellt?

Es werden ein paar zusätzliche Interfaces angelegt. Ja und?
Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd
böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems
entspricht

Du kannst mir gerne mal ein aktuelles Debian auf meinem Rootserver mit
linux-vserver installieren, bisher scheiterte das an der Nutzung von
cgroups. Falls dir allerdings deine Zeit für kostenlose Arbeit zu schade
sein sollte: War sie mir bislang auch.

Eben. Ich nutze linux-vserver nicht und kann Dir dazu nichts sagen. Hier
laufen ein dutzend Debian-Kisten in ESXi völlig problemlos.

[Hanno Foest]

Post by Arno Welzel

Post by Hanno Foest
Du kannst mir gerne mal ein aktuelles Debian auf meinem Rootserver mit
linux-vserver installieren, bisher scheiterte das an der Nutzung von
cgroups. Falls dir allerdings deine Zeit für kostenlose Arbeit zu schade
sein sollte: War sie mir bislang auch.

Eben. Ich nutze linux-vserver nicht und kann Dir dazu nichts sagen. Hier
laufen ein dutzend Debian-Kisten in ESXi völlig problemlos.

Alternativ kannst du mir natürlich auch kostenlos mein Dutzend
vserver-Instanzen nach etwas konvertieren, das auf ESXi lauffähig ist,
udn mir die Lizenz dazu schenken.

Hanno

[Nils M Holm]

Post by olaf
Also laesst man es irgendwann lieber sein weil man sich denkt das die
Programmierer heute alle einen an der Waffel haben.
[...]
Docker haben wir weil die Informatik-Daddelburschen gemerkt haben das
ausser ihnen selber niemand mehr ihre Software installieren kann und
sie sich so sehr einsam gefuehlt haben.

Amen!

Ich habe es auch schon lange aufgegeben, "moderne" Programme installieren
zu wollen. Im Prinzip sind wir auf Umwegen wieder im Zeitalter proprietaerer
Software angelangt. Entweder sie ist mit Deinem Setup kompatibel oder eben
nicht. Im letzteren Fall, Pech gehabt. Open *Source*? LOL. Das meiste Zeug
koennte man duch den MOVfuscator[1] schicken und es waere danach exakt
genauso lesbar.

[1] https://github.com/xoreaxeaxeax/movfuscator

[Dennis Grevenstein]

Post by Nils M Holm
Ich habe es auch schon lange aufgegeben, "moderne" Programme installieren
zu wollen. Im Prinzip sind wir auf Umwegen wieder im Zeitalter proprietaerer
Software angelangt. Entweder sie ist mit Deinem Setup kompatibel oder eben
nicht. Im letzteren Fall, Pech gehabt. Open *Source*? LOL.

aber die sourcen hast Du doch noch... Dass sie Dir nicht gefallen und
Dir das Design der Software nicht gefällt, weil sie vielleicht nicht
mehr den altehrwürdigen Prinzipien der Unix-Programmierung entspricht,
ist wieder ein ganz anderes Thema.
Man darf da sicher nicht in so ein "früher war alles besser" verfallen.
Aber wie jemand anderes mal gesagt hat: "Es gab Dinge, die waren früher
gut. Und sie wären es auch heute noch, wenn man die Finger davon gelassen
hätte."
Das von mir angesprochene alte Unix-Phänomen, dass das Design vielleicht
nicht perfekt ist, aber es halt solange gefixt wird bis es super stabil
läuft, funktioniert verständlicherweise nicht mehr, wenn man das grundlegende
Design alle 5 Minuten neu macht, weil man die Phantasie hat, dass dann
alles besser wird. Apple und Microsoft machen das natürlich, damit sie
den Leuten alle 5 Minuten was neues verkaufen können. Warum die Open
source community das macht, ist mir nie so richtig klar geworden.

gruss,
Dennis

[Nils M Holm]

Post by Dennis Grevenstein

Post by Nils M Holm
Ich habe es auch schon lange aufgegeben, "moderne" Programme installieren
zu wollen. Im Prinzip sind wir auf Umwegen wieder im Zeitalter proprietaerer
Software angelangt. Entweder sie ist mit Deinem Setup kompatibel oder eben
nicht. Im letzteren Fall, Pech gehabt. Open *Source*? LOL.

aber die sourcen hast Du doch noch... Dass sie Dir nicht gefallen und
Dir das Design der Software nicht gefällt, weil sie vielleicht nicht
mehr den altehrwürdigen Prinzipien der Unix-Programmierung entspricht,
ist wieder ein ganz anderes Thema.

Bitte beachte, dass ich ein Prinzip kritisiert habe und Du dem
kritisierenden Anhaften an altehrwuerdigen Prinzipien unterstellst.
Meiner Ansicht nach ist da ein grosser Unterschied, und ich bin
nicht bereit, die Diskussion auf dieser Basis fortzusetzen.

Abgesehen davon bin ich mit dem Rest Deiner Antwort einverstanden.

Post by Dennis Grevenstein
Man darf da sicher nicht in so ein "früher war alles besser" verfallen.
Aber wie jemand anderes mal gesagt hat: "Es gab Dinge, die waren früher
gut. Und sie wären es auch heute noch, wenn man die Finger davon gelassen
hätte."
Das von mir angesprochene alte Unix-Phänomen, dass das Design vielleicht
nicht perfekt ist, aber es halt solange gefixt wird bis es super stabil
läuft, funktioniert verständlicherweise nicht mehr, wenn man das grundlegende
Design alle 5 Minuten neu macht, weil man die Phantasie hat, dass dann
alles besser wird. Apple und Microsoft machen das natürlich, damit sie
den Leuten alle 5 Minuten was neues verkaufen können. Warum die Open
source community das macht, ist mir nie so richtig klar geworden.
gruss,
Dennis

[olaf]

Post by Dennis Grevenstein
alles besser wird. Apple und Microsoft machen das natürlich, damit sie
den Leuten alle 5 Minuten was neues verkaufen können. Warum die Open
source community das macht, ist mir nie so richtig klar geworden.

Weil die alten Saecke die das mal aufgebaut haben irgendwann keinen
Bock mehr hatten oder Tod sind. Der Nachwuchs steht dann vor dem Problem
das er extrem viel auf einmal lernen muss und sieht es, vermutlich
sogar berechtigt, als einfacher an alles neu zu machen. Auch eine
sendmail Konfiguration oder sowas wie awk, make usw war ja nicht
wirklich selbsterklaerend.
Bloss wenn eines Software frueher drei Libaries genutzt hat sind es
heute dreissig. Die Warscheinlichkeit das etwas schief geht liegt um
eine Groessenordnung hoeher. Und das es heute ein Dutzend
Linuxdistributionen gibt macht es auch nicht einfacher.

Ich hab mir gerade aus Spass mal ein aktuelles cmake
runtergeholt. (80MByte!) Auf einem Ryzen 3700 braucht ein make -j16
dann so 20-30s. (gefuehlt nicht gestoppt) Unglaublich krass fett fuer
sowas banales wie ein Maketool. Aber immerhin make und make install
laufen durch.
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Entweder das wird sehr schnell besser oder Linux faehrt bald gegen die
Wand. Ich haette nicht gesagt das ich das mal sagen wuerde.

Olaf

[Gerrit Heitsch]

Post by olaf

Post by Dennis Grevenstein
alles besser wird. Apple und Microsoft machen das natürlich, damit sie
den Leuten alle 5 Minuten was neues verkaufen können. Warum die Open
source community das macht, ist mir nie so richtig klar geworden.

Weil die alten Saecke die das mal aufgebaut haben irgendwann keinen
Bock mehr hatten oder Tod sind. Der Nachwuchs steht dann vor dem Problem
das er extrem viel auf einmal lernen muss und sieht es, vermutlich
sogar berechtigt, als einfacher an alles neu zu machen. Auch eine
sendmail Konfiguration oder sowas wie awk, make usw war ja nicht
wirklich selbsterklaerend.

Das war schon immer nicht selbsterklärend. Man hat es aber gelernt weil
die Kenntnisse auch sonst hilfreich sind. Speziell 'awk' (und 'sed'
natürlich) sollte man in Grundzügen kennen.

Post by olaf
Bloss wenn eines Software frueher drei Libaries genutzt hat sind es
heute dreissig.

Und da wäre hin und wieder mal zu überlegen ob das wirklich sein muss.

Post by olaf
Ich hab mir gerade aus Spass mal ein aktuelles cmake
runtergeholt. (80MByte!) Auf einem Ryzen 3700 braucht ein make -j16
dann so 20-30s. (gefuehlt nicht gestoppt) Unglaublich krass fett fuer
sowas banales wie ein Maketool. Aber immerhin make und make install
laufen durch.
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Warum für solchen Kram heute überall Python benutzt wird verstehe ich
nicht. Textmanipulation? Wenns mehr sein muss als sed und awk können
(und die können eine Menge!) ist PERL besser und hinreichend ausgereift,
daß es unwahrscheinlich ist, daß die installierte Version zu alt ist.

Ansonsten... Finde den Pyhton-Versionscheck im Source und nimm ihn raus.
U.U. hat der Entwickler nur seine aktuell installierte Version als
Minimum definiert, aber nie getestet ob das auch wirklich das Minimum ist.

Gerrit

[Arno Welzel]

[...]

Post by Gerrit Heitsch

Post by olaf
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Warum für solchen Kram heute überall Python benutzt wird verstehe ich
nicht. Textmanipulation? Wenns mehr sein muss als sed und awk können
(und die können eine Menge!) ist PERL besser und hinreichend ausgereift,
daß es unwahrscheinlich ist, daß die installierte Version zu alt ist.

Python wird beim Raspberry Pi als *die* Sprache angepriesen, mit der
auch Einstieger schnell was bauen können. Vermutlich färbt das ab. Quasi
das BASIC der Neuzeit.

[Gerrit Heitsch]

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by olaf
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Warum für solchen Kram heute überall Python benutzt wird verstehe ich
nicht. Textmanipulation? Wenns mehr sein muss als sed und awk können
(und die können eine Menge!) ist PERL besser und hinreichend ausgereift,
daß es unwahrscheinlich ist, daß die installierte Version zu alt ist.

Python wird beim Raspberry Pi als *die* Sprache angepriesen, mit der
auch Einstieger schnell was bauen können. Vermutlich färbt das ab. Quasi
das BASIC der Neuzeit.

Schon... aber wenn ich nicht auf dem Pi arbeite sondern in einem
normalen System? Python hat ein paar Probleme, daß Einrückungen zur
Syntax gehören ist nur eines davon.

Gerrit

[Arno Welzel]

Post by Gerrit Heitsch

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by olaf
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Warum für solchen Kram heute überall Python benutzt wird verstehe ich
nicht. Textmanipulation? Wenns mehr sein muss als sed und awk können
(und die können eine Menge!) ist PERL besser und hinreichend ausgereift,
daß es unwahrscheinlich ist, daß die installierte Version zu alt ist.

Python wird beim Raspberry Pi als *die* Sprache angepriesen, mit der
auch Einstieger schnell was bauen können. Vermutlich färbt das ab. Quasi
das BASIC der Neuzeit.

Schon... aber wenn ich nicht auf dem Pi arbeite sondern in einem
normalen System? Python hat ein paar Probleme, daß Einrückungen zur
Syntax gehören ist nur eines davon.

Das interessiert die Einsteiger, die Python vom Raspberry Pi mit Raspian
als Linux kennen, aber eher wenig.

[olaf]

Post by Arno Welzel
Python wird beim Raspberry Pi als *die* Sprache angepriesen, mit der
auch Einstieger schnell was bauen können. Vermutlich färbt das ab. Quasi
das BASIC der Neuzeit.

Python ist eine relativ verbreitete Sprache bei Leuten die zwar etwas
programmieren wollen oder muessen, aber nicht in erster Linie
Programmierer werden wollen.

Olaf

[Gerrit Heitsch]

Post by olaf

Post by Arno Welzel
Python wird beim Raspberry Pi als *die* Sprache angepriesen, mit der
auch Einstieger schnell was bauen können. Vermutlich färbt das ab. Quasi
das BASIC der Neuzeit.

Python ist eine relativ verbreitete Sprache bei Leuten die zwar etwas
programmieren wollen oder muessen, aber nicht in erster Linie
Programmierer werden wollen.

Das geht in PERL und bash-scripten auch.

Gerrit

[p***@pocnet.net]

Post by Gerrit Heitsch

Post by olaf
Bloss wenn eines Software frueher drei Libaries genutzt hat sind es
heute dreissig.

Und da wäre hin und wieder mal zu überlegen ob das wirklich sein muss.

Nicht nur hin und wieder. Und zwar aus einem ganz anderen Gesichtspunkt: Die
massive Verschleuderung von Energie durch ineffiziente Programmierung und/oder
gestapelte Bequemlichkeitserleichterer, die so lange abstrahieren dass eine CPU
die gleichen Daten -zig mal durch die Register schubsen muss, bis sie beim
Endanwender ankommen.

Für den Endanwender macht es wenig Unterschied, ob er bei einem Shopbesuch seine
Produkliste innerhalb von etwas über oder etwas unter einer Sekunde präsentiert
bekommt. Wenn mit Software a der Core eines Serverprozessors eine halbe Sekunde
länger auf Volldampf läuft als mit Software b, die aber beide letztendlich genau
das gleiche Ergebnis erbringen, ist relativ klar, dass das nur eine eine geringe
Menge Energie mehr kostet. Wenn man diese geringe Menge aber auf die
Nutzungszahlen hochrechnet, kommen sehr schnell stattliche Summen an monetärem
Mehraufwand (für Strom *und* Klimatisierung) zusammen.

Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

Kleinere und schlankere Software benötigt zudem weniger RAM. Weniger RAM
benötigt auch weniger Strom. Auch das ist bei einem einzigen Rechner, dem man
einen Riegel oder zwei rausnehmen kann, sehr übersichtlich. Aber wenn man in
einem RZ drei Racks an Servern stilllegen kann, weil tausende an VMs plötzlich
mit einem Gigabyte weniger RAM auskommen, ist das ein spürbarer Kostenfaktor.

Ich ignoriere an dieser Stelle ganz bewußt den resultierenden CO2-Ausstoß. Das
ist für viele ein abstraktes Problem und verursacht daher lediglich ein
schlechtes Gewissen. Wenn's allerdings an den Geldbeutel geht, kriegt man
Menschen zum Handeln.

Aber, ein Anfang ist gemacht:
https://media.ccc.de/v/36c3-10852-wie_klimafreundlich_ist_software

:wq! PoC

[olaf]

Post by p***@pocnet.net
Ich ignoriere an dieser Stelle ganz bewußt den resultierenden CO2-Ausstoß. Das
ist für viele ein abstraktes Problem und verursacht daher lediglich ein
schlechtes Gewissen. Wenn's allerdings an den Geldbeutel geht, kriegt man
Menschen zum Handeln.

Klar, aber der Zusammenhang ist demjenigen der es letzlich bezahlt
nicht klar. Deshalb achtet er da wohl nicht drauf.

Ich staune jedesmal wenn ich bei meiner Bank den Geldautomat benutze
darueber das ich mindestens 10x schneller tippe wie die Software etwas
darstellen kann. Wenn ich da die Abnahme gemacht haette dann haette
ich den Programmierer vermutlich rausgeworfen angesichts der
Dreistigkeit mir mit sowas unter die Augen zu treten. Und jedes Jahr
wird das schlimmer weil die Bank vermutlich eine neue Software
installieren muss, aber sich nicht jedes Jahr einen neuen Geldautomaten
leisten kann. Aber auf die Idee die Software vernuenftig zu schreiben
kommt trotzdem keiner.

Und dem normalen Endkunden ist sowas garnich klar. Der glaubt einfach
das geht nicht anders. Dafuer muesste Strom wohl erst 10x teurer werden.

Olaf

[p***@pocnet.net]

Post by olaf
Ich staune jedesmal wenn ich bei meiner Bank den Geldautomat benutze
darueber das ich mindestens 10x schneller tippe wie die Software etwas
darstellen kann.

Jo, das ist wiederum ein Problem für sich. Die alten DOS-Gurken mit Knöpfen
neben dem Display waren gefühlt 3x so schnell mit Auszahlen und haben trotzdem
gut funktioniert. Vermutlich ist der vorige Programmierer in Rente gegangen und
sein Nachfolger meinte, das müsse man jetzt mal modern machen.

Eine Haltung, die man im AS/400, pardon, IBM i Umfeld sehr oft findet: Wir
brauchen eine Weboberfläche für unsere Warenwirschaft. - Warum denn, alle
Mitarbeiter kommen bestens mit der Textoberfläche zurecht. - Es sieht
altbacken und angestaubt aus, was sollen unsere Kunden denken? - Ah, okay,
Imagepflege ist natürlich ein legitimer Grund, Geld in die Hand zu nehmen.
Erst recht, wenn's um ein Image geht, was Kunden selten bis nie zu Gesicht
bekommen...

Es gibt ein paar schon fast religiöse Verfechter von 5250-ist-tot. Die erkennt
man daran, dass sie schmerzerfüllt zusammenzucken, wenn jemand in ihrer
Gegenwart bestimmte Schlüsselworte sagt. AS/400. Veraltet. 5250.

:wq! PoC

[Gerrit Heitsch]

Post by p***@pocnet.net

Post by Gerrit Heitsch

Post by olaf
Bloss wenn eines Software frueher drei Libaries genutzt hat sind es
heute dreissig.

Und da wäre hin und wieder mal zu überlegen ob das wirklich sein muss.

Nicht nur hin und wieder. Und zwar aus einem ganz anderen Gesichtspunkt: Die
massive Verschleuderung von Energie durch ineffiziente Programmierung und/oder
gestapelte Bequemlichkeitserleichterer, die so lange abstrahieren dass eine CPU
die gleichen Daten -zig mal durch die Register schubsen muss, bis sie beim
Endanwender ankommen.

Kenne ich, ja. Ich hab noch ein Netbook mit Atom N270. Mit 1.6 GHz ist
der eigentlich rasend schnell. Zumindest die ganzen Unix-Tools die man
so kennt und schätzt, ebenso X11 mit XFCE.

Aber ein moderner Webbrowser bremst den gnadenlos aus. Nicht weil
Speicher fehlt, mit 2GB RAM kommt man unter Linux gut hin wenn man nicht
gerade 10 oder mehr Tabs offen hat.

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Gerrit

[Arno Welzel]

[...]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...

Wozu überhaupt etwas anderes als statisches HTML? Hat doch auch schon
ausgereicht für Websites. Und Videos im Netz streamen? Wozu? Ging doch
früher mit TV über Antenne auch gut.

[Gerrit Heitsch]

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...

Im Browser kann man das machen (wenn es auch zu oft gemacht wird), aber
auf dem OS will ich keinen Javascript Interpreter haben. Da habe ich
genug andere Scriptsprachen und sogar Compiler zur Verfügung in denen
ich einen Server schreiben kann. Wozu da Javascript, eine Sprache die
kurz mal in 10 Tagen zusammengehackt wurde?

Post by Arno Welzel
Wozu überhaupt etwas anderes als statisches HTML?

Für vieles reicht das vollkommen aus. Die von mir auf der Arbeit
aufgesetzte Monitoring-Seite benutzt reines HTML ohne jede Scripterei,
ja nicht einmal CSS ist da drin. Den automatischen Refresh erledigt ein
<meta> Tag.

Sieht nur marginal anders aus als eine ähnliche Seite die jemand anderes
aufgesetzt hat die Scripte und CSS benutzt. Der Job beider Seiten ist es
den Status einiger Systeme anzuzeigen, mehr nicht. Keine weitere
Interaktion mit dem User.

Gerrit

[Arno Welzel]

Post by Gerrit Heitsch

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...

Im Browser kann man das machen (wenn es auch zu oft gemacht wird), aber
auf dem OS will ich keinen Javascript Interpreter haben. Da habe ich

Und wo läuft der Browser? Nicht in einem OS?

Post by Gerrit Heitsch
genug andere Scriptsprachen und sogar Compiler zur Verfügung in denen
ich einen Server schreiben kann. Wozu da Javascript, eine Sprache die
kurz mal in 10 Tagen zusammengehackt wurde?

"kurz mal in 10 Tagen zusammengehackt"?

Du kennst
<https://www.ecma-international.org/publications/standards/Ecma-262.htm>
offenbar nicht.

Abgesehen davon compiliert Node.js natürlich auch und führt zur Laufzeit
keine Script-Interpretation aus.

[Gerrit Heitsch]

Post by Arno Welzel

Post by Gerrit Heitsch

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...

Im Browser kann man das machen (wenn es auch zu oft gemacht wird), aber
auf dem OS will ich keinen Javascript Interpreter haben. Da habe ich

Und wo läuft der Browser? Nicht in einem OS?

Doch, aber die Scripte haben keinen Zugriff auf Dinge ausserhalb des
Browsers. Wenn doch ist das ein Bug und gehört gefixt.

Post by Arno Welzel

Post by Gerrit Heitsch
genug andere Scriptsprachen und sogar Compiler zur Verfügung in denen
ich einen Server schreiben kann. Wozu da Javascript, eine Sprache die
kurz mal in 10 Tagen zusammengehackt wurde?

"kurz mal in 10 Tagen zusammengehackt"?
Du kennst
<https://www.ecma-international.org/publications/standards/Ecma-262.htm>
offenbar nicht.

Du kennst die Geschichte von Javascript offenbar nicht:

https://www.checkmarx.com/blog/javascript-history-infographic/

Money Quote:

Brendan Eich, a Netscape Communications Corporation programmer, created
JavaScript in September 1995. It took Eich only 10 days to develop the
scripting language, then known as Mocha.

Gerrit

[Stefan Reuther]

Post by Gerrit Heitsch

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

node.js... Server in Javascript. Wer kommt auf sowas?

Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...

Im Browser kann man das machen (wenn es auch zu oft gemacht wird), aber
auf dem OS will ich keinen Javascript Interpreter haben. Da habe ich
genug andere Scriptsprachen und sogar Compiler zur Verfügung in denen
ich einen Server schreiben kann.

Aber warum zwei Sprachen, wenn's auch eine tut?

Ja, ich mach die Server in C++ und Perl. Aber verlockend ist's doch
schon manchmal, die Logik nur einmal zu haben.

Post by Gerrit Heitsch
Wozu da Javascript, eine Sprache die kurz mal in 10 Tagen
zusammengehackt wurde?

Ich fürchte, wenn wir das als Metrik nehmen, müssten wir eine Menge
ausmisten. Unix oder C haben jetzt auch keinen besonders intensiven
Designprozess hinter sich. Sie sind hinterher nur gereift, und man hat
mit ihnen umzugehen gelernt. Wie bei JavaScript. Sie haben halt alle
ihre historisch gewachsenen Warzen. JavaScript hat die "automatic
semicolon insertion", Unix hat Buchstaben in creat und umount vergessen.

Post by Gerrit Heitsch

Post by Arno Welzel
Wozu überhaupt etwas anderes als statisches HTML?

Für vieles reicht das vollkommen aus. Die von mir auf der Arbeit
aufgesetzte Monitoring-Seite benutzt reines HTML ohne jede Scripterei,
ja nicht einmal CSS ist da drin. Den automatischen Refresh erledigt ein
<meta> Tag.
Sieht nur marginal anders aus als eine ähnliche Seite die jemand anderes
aufgesetzt hat die Scripte und CSS benutzt. Der Job beider Seiten ist es
den Status einiger Systeme anzuzeigen, mehr nicht. Keine weitere
Interaktion mit dem User.

Es gibt genug unnütz eingesetztes JavaScript, keine Frage. Aber
spätestens für die Interaktion ist es schon sehr nützlich. Hand aufs
Herz: was würden wir ohne Google Maps/Bing Maps/OpenStreetMap machen?

Und selbst für ein Monitoring-Widget: wenn man da eine Grafik haben will
("CPU-Last in der letzten Stunde"), muss man entweder serverseitig eine
Grafik generieren (braucht also schon mal wenigstens zwei Endpunkte: für
das HTML und die Grafik, sowie entsprechende Libraries). Oder man kippt
einfach ein Skript nebst Datenfeld in das HTML und rendert clientseitig
in ein <canvas> (OK, inline-SVG wäre noch eine Alternative).


Stefan

[Hanno Foest]

Post by Arno Welzel
Die gleichen Leute, die JavaScript im Browser nutzen, HTML5, WebGL usw...
Wozu überhaupt etwas anderes als statisches HTML? Hat doch auch schon
ausgereicht für Websites.

Hat halt Nebenwirkungen. Der volkswirtschaftliche Schaden durch die
durch JS entstandenen Sicherheitsprobleme dürfte in die Billionen
(10^12) gehen.

Post by Arno Welzel
Und Videos im Netz streamen?

Mach ich seit dem letzten Jahrtausend. Dazu benötigt wurden (ggf.) wget,
mplayer und eine hinreichend schnelle Internetanbindung. Zum Senden
icecast, ok, das war dann schon so 2003.

Ja, ich weiß, daß das nicht massenkompatibel ist. Ob der status quo mit
lauter hintereinandergeschalteten Komplexitätsverstärkern und immer
größer werdenden Sicherheitsproblemen so viel besser ist weiß ich aber
auch nicht.

Hanno

[Arno Welzel]

***@pocnet.net:

[...]

Post by p***@pocnet.net
Wenn ich mir Node JS (oder den Ableger Node Red), Java oder den letzten Schrei -
Containerisierung - anschaue, sehe ich in Sachen Effizienzverbesserung
*erhebliche* Möglichkeiten.

Ja, wo genau? Also außer diese Techniken einfach gar nicht nutzen?

Post by p***@pocnet.net
Kleinere und schlankere Software benötigt zudem weniger RAM. Weniger RAM
benötigt auch weniger Strom. Auch das ist bei einem einzigen Rechner, dem man
einen Riegel oder zwei rausnehmen kann, sehr übersichtlich. Aber wenn man in
einem RZ drei Racks an Servern stilllegen kann, weil tausende an VMs plötzlich
mit einem Gigabyte weniger RAM auskommen, ist das ein spürbarer Kostenfaktor.

Wenn man nur danach geht, sollte man einfach aufhören, Software zu
entwickeln und nur noch Bugfixes machen. Die wesentlichen Anwendungen
sind bereits seit 20-30 Jahren alle komplett entwickelt.

Post by p***@pocnet.net
https://media.ccc.de/v/36c3-10852-wie_klimafreundlich_ist_software

Das Problem ist nicht, dass Hersteller nicht verpflichtet sind,
nachhaltige Produkte zu verkaufen und dass Kunden vielfach daran auch
kein Interesse haben.

Ähnlich wie WhatsApp & Co. - freie Software wäre besser, aber den
Endnutzern ist es egal, ob die Software frei ist oder nicht, sondern sie
wollen einen Nutzen davon haben.

[Stefan Reuther]

Post by olaf
Bloss wenn eines Software frueher drei Libaries genutzt hat sind es
heute dreissig. Die Warscheinlichkeit das etwas schief geht liegt um
eine Groessenordnung hoeher. Und das es heute ein Dutzend
Linuxdistributionen gibt macht es auch nicht einfacher.
Ich hab mir gerade aus Spass mal ein aktuelles cmake
runtergeholt. (80MByte!)

Das ist der feine Grat zwischen "dreißig Libraries nutzen", was du oben
kritisierst, und "Dependencies mitbringen".

Davon ab sind's natürlich *nicht* 80 MByte, der Tarball hat reichlich 8.

Post by olaf
Auf einem Ryzen 3700 braucht ein make -j16
dann so 20-30s. (gefuehlt nicht gestoppt) Unglaublich krass fett fuer
sowas banales wie ein Maketool. Aber immerhin make und make install
laufen durch.

Die von CMake erstellten Makefiles sind furchtbar. Nicht ganz so
furchtbar wie die von autofoo erstellten, aber furchtbar. Denn es sind
rekursive Makefiles, und seit 30 Jahren weiß man, dass das keine gute
Idee ist. Das liegt aber auch daran, dass CMake Dinge umzusetzen
versucht wie die Erkennung, ob sich ein Compilerflag geändert hat, um
dann neu zu bauen. Das kann make einfach nicht und muss aufwändig
drumherum gebaut werden. Besser wird es mit ninja als Grundlage.

Und das liegt jetzt eben nicht daran, dass der neumodische Kram
neumodischer Kram ist der ohne Not alte funktionierende Dinge ersetzt.
Sondern daran, dass der neue Kram neue Probleme löst. Mit CMake kann man
problemlos mehrere out-of-tree-builds aus einem Quellbaum machen (z.B.
einen mit "-O2" und einen mit "-pg"). Mit händisch erstellten Makefiles
artet das in Arbeit aus und Probleme wie "jetzt ein *.o weniger in das
*.a packen" oder "Compilerflags ändern" werden mit "make clean && make"
gelöst.

Post by olaf
Funktioniert es? Nein. Es beschwert sich jetzt das mein Python eine
Version zu alt ist. Wofuer braucht der Kack jetzt wieder Python? Und
was glaubt ihr wohl was alles wieder nicht geht wenn ich daran drehe.

Ich könnte dir jetzt verraten, dass dieses Problem mit einem Container
sehr elegant zu lösen wäre. Einfach den Dienst in einem Container bauen,
in dem die korrekte Python-Version installiert ist.

Das muss nicht docker sein. Die Szene hat durchaus auch Build-Tools
hervorgebracht, die das können. Bazel könnte bekannt sein; ich nehme Bob
Build Tool.

Läuft natürlich nicht auf unix5 auf PiDP11.


Stefan

[p***@pocnet.net]

Warum die Open source community das macht, ist mir nie so richtig klar
geworden.

Um nicht altbacken zu erscheinen? Oder damit Linux dieses Jahr ganz ganz sicher
den Durchbruch auf den Desktop schafft?

:wq! PoC

[Andreas Schwarz]

Post by Gerrit Heitsch
Inzwischen ist das mit dem 'zuverlässig laufen' bei Unix eher die
Ausnahme wenn man sich den Rest der Softwarewelt so betrachtet. Der
Service schmiert alle paar Tage aus unklarer Ursache ab? Debuggen?
Wieso? Da schedulen wir einfach einen täglichen Restart, passt!
Alternativ: Wenn er crasht wird automatisch eine neue Instanz
hochgefahren. Wozu haben wir denn Docker usw.?

Tja, der docker hype ist ein Zeichen von Voellerei und Ueberfluss,
bequem, aber langfristig wirklich von Vorteil?

[p***@pocnet.net]

Post by Andreas Schwarz
Tja, der docker hype ist ein Zeichen von Voellerei und Ueberfluss,
bequem, aber langfristig wirklich von Vorteil?

Danke, ich bin froh zu sehen, dass ich nicht alleine mit meiner Meinung bin.

IMO "löst" Docker Probleme damit, dass es einen ganzen Batzen eigener Probleme
mitbringt. Komplexität und zusätzlicher Overhead in Sachen RAM und CPU z. B.

:wq! PoC

[Arno Welzel]

Post by p***@pocnet.net

Post by Andreas Schwarz
Tja, der docker hype ist ein Zeichen von Voellerei und Ueberfluss,
bequem, aber langfristig wirklich von Vorteil?

Danke, ich bin froh zu sehen, dass ich nicht alleine mit meiner Meinung bin.
IMO "löst" Docker Probleme damit, dass es einen ganzen Batzen eigener Probleme
mitbringt. Komplexität und zusätzlicher Overhead in Sachen RAM und CPU z. B.

Mag sein - in der Praxis habe ich hier aber keine Einschränkungen
dadurch. Aber zeige doch mal, wie Du einen Build- und Testlauf ohne
Docker effektiv automatisiert bekommst, bei dem die Vorgabe ist, dass
für jeden Test ein Linux-System auf einem definierten Stand aufgesetzt
wird - und das so, dass das nach erstellen eines Pull-Requests in Git
ausgeführt wird, damit man sieht, ob die Änderungen etwas am System
kaputt machen.

[Gerrit Heitsch]

Post by Arno Welzel

Post by p***@pocnet.net

Post by Andreas Schwarz
Tja, der docker hype ist ein Zeichen von Voellerei und Ueberfluss,
bequem, aber langfristig wirklich von Vorteil?

Danke, ich bin froh zu sehen, dass ich nicht alleine mit meiner Meinung bin.
IMO "löst" Docker Probleme damit, dass es einen ganzen Batzen eigener Probleme
mitbringt. Komplexität und zusätzlicher Overhead in Sachen RAM und CPU z. B.

Mag sein - in der Praxis habe ich hier aber keine Einschränkungen
dadurch. Aber zeige doch mal, wie Du einen Build- und Testlauf ohne
Docker effektiv automatisiert bekommst, bei dem die Vorgabe ist, dass
für jeden Test ein Linux-System auf einem definierten Stand aufgesetzt
wird - und das so, dass das nach erstellen eines Pull-Requests in Git
ausgeführt wird, damit man sieht, ob die Änderungen etwas am System
kaputt machen.

Wie testest du 'ob was kaputtgemacht wurde'? Wenn du ein ganzes Linux-OS
in einem Docker-Container hast ist da eine Menge an Funktionalität zu
testen. Oder machst du nur einen Check auf welche Dateien sich geändert
haben?

Gerrit

[Arno Welzel]

[...]

Post by Gerrit Heitsch

Post by Arno Welzel
Mag sein - in der Praxis habe ich hier aber keine Einschränkungen
dadurch. Aber zeige doch mal, wie Du einen Build- und Testlauf ohne
Docker effektiv automatisiert bekommst, bei dem die Vorgabe ist, dass
für jeden Test ein Linux-System auf einem definierten Stand aufgesetzt
wird - und das so, dass das nach erstellen eines Pull-Requests in Git
ausgeführt wird, damit man sieht, ob die Änderungen etwas am System
kaputt machen.

Wie testest du 'ob was kaputtgemacht wurde'? Wenn du ein ganzes Linux-OS

U.a. mit Cypress. Es gibt definierte Anwendungsfälle, die auch nach
einer Änderung noch funktionieren müssen.

Post by Gerrit Heitsch
in einem Docker-Container hast ist da eine Menge an Funktionalität zu
testen. Oder machst du nur einen Check auf welche Dateien sich geändert
haben?

Nö. Anwendungen werden komplett installiert, Datenbanken mit
Fixture-Daten eingerichtet etc. und es wird dann die Nutzung getestet
und das Ergebnis in der GUI und bzgl. Ausgaben in Dateien etc. geprüft.

[Gerrit Heitsch]

Post by Arno Welzel
[...]

Post by Gerrit Heitsch

Post by Arno Welzel
Mag sein - in der Praxis habe ich hier aber keine Einschränkungen
dadurch. Aber zeige doch mal, wie Du einen Build- und Testlauf ohne
Docker effektiv automatisiert bekommst, bei dem die Vorgabe ist, dass
für jeden Test ein Linux-System auf einem definierten Stand aufgesetzt
wird - und das so, dass das nach erstellen eines Pull-Requests in Git
ausgeführt wird, damit man sieht, ob die Änderungen etwas am System
kaputt machen.

Wie testest du 'ob was kaputtgemacht wurde'? Wenn du ein ganzes Linux-OS

U.a. mit Cypress. Es gibt definierte Anwendungsfälle, die auch nach
einer Änderung noch funktionieren müssen.

Wenn ich deren Webseite richtig verstehe, dann testet das doch nur Kram
im Browser? Ich hatte den Eindruck, du testest das OS weil du 'am
System' geschrieben hast.

Post by Arno Welzel

Post by Gerrit Heitsch
in einem Docker-Container hast ist da eine Menge an Funktionalität zu
testen. Oder machst du nur einen Check auf welche Dateien sich geändert
haben?

Nö. Anwendungen werden komplett installiert, Datenbanken mit
Fixture-Daten eingerichtet etc. und es wird dann die Nutzung getestet
und das Ergebnis in der GUI und bzgl. Ausgaben in Dateien etc. geprüft.

Und das alles in einem Container? Wäre da nicht eine VM die alles
passend hat und die man cloned nicht besser?

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Arno Welzel
Nö. Anwendungen werden komplett installiert, Datenbanken mit
Fixture-Daten eingerichtet etc. und es wird dann die Nutzung getestet
und das Ergebnis in der GUI und bzgl. Ausgaben in Dateien etc. geprüft.

Und das alles in einem Container? Wäre da nicht eine VM die alles
passend hat und die man cloned nicht besser?

Warum sollte das besser sein?

Viele Grüße
Ulf

[Gerrit Heitsch]

Post by Ulf Volmer

Post by Gerrit Heitsch

Post by Arno Welzel
Nö. Anwendungen werden komplett installiert, Datenbanken mit
Fixture-Daten eingerichtet etc. und es wird dann die Nutzung getestet
und das Ergebnis in der GUI und bzgl. Ausgaben in Dateien etc. geprüft.

Und das alles in einem Container? Wäre da nicht eine VM die alles
passend hat und die man cloned nicht besser?

Warum sollte das besser sein?

Weil da wirklich alles in einer Datei drin ist und man nicht nur eine
Beschreibungsdatei hat die darauf angewiesen ist, daß der Inhalt des
Containers von irgendwo kommt.

Ich mags bei kritischen Dingen simpel.

Gerrit

[Ulf Volmer]

Post by Gerrit Heitsch

Post by Ulf Volmer

Post by Gerrit Heitsch

Post by Arno Welzel
Nö. Anwendungen werden komplett installiert, Datenbanken mit
Fixture-Daten eingerichtet etc. und es wird dann die Nutzung getestet
und das Ergebnis in der GUI und bzgl. Ausgaben in Dateien etc. geprüft.

Und das alles in einem Container? Wäre da nicht eine VM die alles
passend hat und die man cloned nicht besser?

Warum sollte das besser sein?

Weil da wirklich alles in einer Datei drin ist und man nicht nur eine
Beschreibungsdatei hat die darauf angewiesen ist, daß der Inhalt des
Containers von irgendwo kommt.

Du brauch einen Hypervisor, der zur 'Datei' paßt.
Die 'Datei' will initial erstellt und gepflegt sein.

Wenn die 'Datei' weg ist, mußt Du sie mühsam neu erstellen.

All diese Probleme hast Du bei Container nicht.
Plus dem Vorteil, dass sich die Dokumentation auf 'Dockerfile liegt im
git' beschränkt.

Post by Gerrit Heitsch
Ich mags bei kritischen Dingen simpel.

Nur, weil Du meinst, Du hättest VMs verstanden, ist es nicht gleich
simpel.

Viele Grüße
Ulf

[p***@pocnet.net]

Das Design mag nicht immer perfekt sein, aber das ist egal solange der fix
gut genug funktioniert.

Das gilt für so ziemlich alles, sobald Kommerz ins Spiel kommt.

:wq! PoC