Könnte auch sein, dass eigene Routinen im C64 leicht anderes Timing haben; JD in der Floppy misst an einer Stelle das Timing des C64 und schaltet in den schnelleren JD-Modus, wenn da minimal was verändert (langsamer!) ist (siehe Dokument "LISTEN AND TALK" auf http://www.nlq.de/ relativ weit unten).
Posts by 1570
-
-
Das mit dem (Re-)Spawn hat mehrere Beweggründe und geht gar nicht in erster Linie um Bugs. Es geht einmal darum, dass im inetd-Modell (falls hier jemand nicht weiß, was inetd ist, bitte auf Wikipedia nachlesen) die Prozesse auf Bedarf gestartet werden und sich nach Abhandeln der Anfrage von außen wieder von alleine beenden. Dann geht es darum, dass Komponenten auch gute Gründe haben können, sich zu beenden (und ggf. neu gestartet werden zu wollen inkl. Notification ans init bzw. die Logger). Schließlich haben alle aktuellen init-Systeme (z.B. runit und supervisord und s6, speziell letzteres gilt als sehr feingranular designt) solche Funktionalität; kann man gerne z.B. bei https://skarnet.org/software/s6/s6-supervise.html nachlesen.
Und man will sowas ggf. in PID 1 haben. Denn wenn z.B. das RAM ausgeht und der Kernel im absoluten Notfall auch mal den sshd abschießt (ja, das kommt in der Praxis leider vor) ist's schon blöd, wenn der nicht neu gestartet wird oder das supertolle feingranulare Init-System auch schon die Grätsche gemacht hat, weil sein Respawn-Daemon eben nicht PID 1 war und auch bereits gekillt wurde. Es gibt auch andere Fälle, in denen ein Prozess ggf. ohne eigene Schuld beendet wird und automatisch neu gestartet werden muss (z.B. zeitweiser Ausfall einer Ressource, die der Prozess braucht).
Init muss halt in der Praxis in allen Fällen, auch den hässlichen Fällen, seinen Dienst erfüllen. Das ist viel wichtiger, als dass sich sein Quellcode liest wie ein Gedicht.
-
Oh, ich habe was! Was ich z.B. an systemd doof finde, ist, dass es a) nicht problemlos als init z.B. in Docker-Containern läuft, und dass b) es sich vermutlich nicht ohne weiteres eindampfen lässt, sodass es z.B. via OpenWrt auf Routern benutzt werden könnte. Ist jetzt beides kein konzeptuelles Problem, sondern beide Anwendungsfälle interessieren die aktuellen systemd-Entwickler nicht, was auch okay ist, die können ja nicht alles machen. Ich bin gespannt, wann/ob es systemd-Forks geben wird, die Sachen in die Richtung nachrüsten. Eine Art vereinfachte Reimplementierung von systemd in Python gibt's schonmal, das deckt wenigstens den Docker-Anwendungsfall ab, aber ist natürlich nochmal was anderes.
-
Was du einfach annimmst, und dann ist es so. Und du definierst natürlich auch, was relevant ist.
Also es kann ja jeder in Deinem Einstiegspost nachlesen. Punkt 1: "Respawn gehört nicht in init" - machen andere inits auch, so what. Punkt 2: "Start von Benutzerprozessen gehört nicht in init". Macht bei systemd nicht init, sondern ein Unterprozess, also falsche Behauptung Deinerseits. Punkt 3: "Logging gehört nicht in init". Macht bei systemd nicht init, sondern ein (unabhängiger) Unterprozess, also falsche Behauptung Deinerseits. Punkt 4: "Verwaltung von Benutzer-Logins gehört nicht in init". Macht bei systemd nicht init, sondern ein Unterprozess, der lt. Dir von systemd-init abhängig ist. Also ist diese Behauptung von Dir eventuell nur halb falsch. Yay.
Auf meinem System kann ich "jailen", was immer ich will, und das in extrem schlanken Containern
Diskutieren wir hier eigentlich auf einmal Linux vs. BSD? Ich dachte, es geht um systemd. Ich meine, es ist ja schön, dass Du BSD magst (ich finde das Trüppchen auch sympathisch), ist aber irgendwie total offtopic.
-
Huh, dann sind halt nur zwei von drei relevanten Punkten falsch, dafür aber definitiv falsch.
Klar kann man Container auch ohne Init-Support benutzen, nur benutzen Daemons das dann nicht oder implementieren alles nochmal selbst.
Man kann beim klassischen chroot sehen, wie gut das funktioniert: Die eine Hälfte der Daemons unterstützt es nicht, weil es dem Entwickler zu viel Aufwand ist, die andere Hälfte macht's falsch.
Und falls jetzt sowas wie "für Container ist Docker/sysjail/tredly zuständig" kommt, urks, ich will doch nur dem nginx den Zugriff auf Userhomes verbieten und nicht gleich hunderte MB Dependencies und Images installieren.
systemd-init kann das, mit einer Zeile Config, die bei den normalen Distributionen inzwischen sogar einfach inklusive ist. So muss das.
-
Ja, damit sind genaugenommen drei Deiner vier Punkte aus dem Eingangsposting höchstwahrscheinlich faktisch falsch und der übrigbleibende (das Respawn-Ding) bestenfalls diskutierenswert (da andere inits ebenso wie systemd Respawn anbieten; genaugenommen verbieten die meisten non-sysvinit-Systeme, dass sich Dienste von alleine in den Hintergrund forken).
Und "was in init gehört und was nicht", ich für meinen Teil bin ganz zufrieden damit, dass z.B. dank der Container-Features im systemd-init ein Großteil der laufenden Daemons bei mir trotz root keinen Zugriff auf /home etc. hat.
-
Noch wegen #25, gerade mal ausprobiert: systemd-journald bekommt man auch ohne systemds init als PID 1 problemlos gestartet. Getestet auf einem System mit runit.
-
Bei systemd läuft ja auch der Großteil davon nicht als PID 1, das hattest Du zwar versucht so erscheinen zu lassen und versuchst es gerade wieder, aber das Thema hatten wir ja bereits durchgekaut. systemd-journald etc. sind eigene Prozesse. Ein paar Sachen wie die Socket-Geschichte und Container-Features (die BSD und andere init-Systeme gar nicht bieten) lassen sich aber eben nicht (sinnvoll) auslagern.
Mir scheint, mit dem Thema sind wir jetzt weitgehend durch, ich bin dann auch mal für heute weg.
-
Die Summe von sysvinit+udevd+rsyslog+containerd+xinetd hat garantiert mehr LOC als das komplette systemd und auch ganz sicher mehr Bugs, bei weniger Funktionalität. Einfach, weil alles völlig unkoordiniert nebenher arbeitet und an etlichen Stellen das Rad neu erfindet (und sei's nur sowas wie das Command Line Parsing).
systemd ist doch auch nicht auf der grünen Wiese entstanden. Die systemd-Autoren wussten sehr genau, was da dranhängt, haben sich überlegt, was man mit Integration alles erreichen könnte, und haben dann mit dem Flohzirkus aufgeräumt. Genauso wie es launchd unter macOS auch gemacht hat (das z.B. das BSD-inetd abgelöst hat).
-
Was ist daran polemisch? Die Socket Activation ist ein integraler Bestandteil für das Dependency Management beim Hochfahren des Systems.
Klar kann man das Auslagern in sowas wie inetd es war.
Dann funktioniert's halt nicht beim Hochfahren und bietet kein Dependency Management.
Und das Ganze wird dann auch zu einem parallelen Init-System.
War ja früher auch so: einmal Startskripte in /etc/rc.d, dann nochmal in /etc/inetd, dann nochmal in /etc/udev und wer weiß noch wo.
War halt ineffizienter schlecht integrierter fehlerträchtiger Mist.
-
Du willst inetd/xinetd? Dann mal los! Niemand hält Dich davon ab, wieder in die 80er zu reisen.
-
Ich setze alle 5 bis 10 Jahre einen Linux-Server auf und ärgere mich die Platze, dass schon wieder alles anders ist,
Hehe, schau Dir mal Windows an.
Ich finde das inbesondere bei systemd nicht weiter schlimm. "service" funktioniert so wie vor 10 Jahren, und auch /etc/rcX funktioniert weiter, wenn man unbedingt will.
Die Änderungen durch journald sind da umfassender, aber ich mag jetzt auch nicht behaupten, dass syslog/rsyslog bei mir Freudenstürme ausgelöst hätten.
eine saubere Startdatei
/etc/rc.local geht auch noch.
-
init, der Prozessmanager, ist ein (kleiner) Teil von systemd und läuft als PID 1.
systemd-journald gehört nicht dazu, journald kannst Du auch einfach killen.
Die meisten Leute mischen das alles gerne zusammen und machen dann eine Strohmannargumentation genau so wie Du, so in Richtung "systemd ist init ist journald alles in einem Binary das ist schlecht", und das ist eben in allen Dimensionen falsch.
Jetzt behauptest Du gerade, dass init und journald bei systemd sehr eng verquickt seien. Das weiß in diesem Thread aber niemand wirklich; ich habe bereits gesagt, warum eine gewisse "Enge" sinnvoll sein könnte.
Und letztendlich ist es auch etwas absurd, systemd-journald verbieten zu wollen, ggf. von Features des systemd-inits (wie dem Socket Activation) zu profitieren.
-
Ich weiß nicht, inwiefern systemd-journald mit PID 1 verquickt ist. Ich vermute, dass sich das in Grenzen hält und es eben nur um Dinge wie die Socket Activation dreht, dass also geloggt werden kann, noch bevor journald oben ist. Das finde ich okay und sinnvoll.
Insbesondere finde ich es irreführend und nicht fair, was von "systemd macht Logging in PID 1" zu faseln bzw. nahezulegen, wenn das eben NICHT der Fall ist.
-
Nach der Logik sind ja alle Kommunikationsbusse böse weil komplex...?
Hm, selbst der Kernel wäre AUS DER HÖLLE, weil die Benutzerprozesse ja nicht ohne den Kernel laufen.
-
schon klar, ich nutze debian schon seit der version 4.... net-tools scheint unvollständig zu sein.... zumindest bei mir geht danach auch kein ifconfig...
Nach "apt-get install net-tools" gibt's kein /sbin/ifconfig?
Als non-root ist /sbin/ natürlich nicht im Pfad.
-
zrs1 Die vier Spiegelstriche sollen Beispiele sein, was in PID 1 nicht reingehört?
Benutzerprozesse: PID 1 startet auch bei systemd keine Benutzerprozesse, das machen separate Instanzen (schau Dir z.B. die pstree-Ausgabe an).
Logging: PID 1 macht auch mit systemd kein Logging, das macht systemd-journald, ein separater Prozess.
Session-Verwaltung: PID 1 macht das nicht, sondern systemd-logind, ein separater Prozess.
"Respawn" kann man drüber diskutieren. Die meisten anderen Systeme (supervisord, runit etc.) machen das genauso wie systemd und die Annahme, dass sich Dienste nur im Fehlerfall beenden, ist ja schon die erste Krux; das tun z.B. inetd-konforme Dienste eben NICHT.
-
"apt-get install net-tools" geht nicht?
Wenn irgendein Befehl fehlt, ist https://www.debian.org/distrib/packages#search_contents dein Freund.
-
Ich schrieb ja auch bereits, dass Performance nur ein kleiner Teil der ganzen Geschichte ist, und dass es andere skriptbasierte Lösungen für das Dependency-Problem gibt, die wenigstens von Ubuntu und Debian wieder aufgegeben wurden.
Was packt denn systemd Deiner Meinung nach in den init-Prozess, was da nicht reingehört? So mal ganz konkret?
-
Ich dachte, dass hätte mittels 2bit IRQ-Loader klappen können.
Der ändert ja nichts daran, dass während der Datenübertragung CPU in C64 und der 1541 blockiert sind. Wenn ich mich nicht irre, dauert ein 512-Byte-Transfer mit den schnellsten Routinen auf zwei Leitungen gut 10ms, und es geht ja nicht nur um den reinen Transfer, sondern auch das Handshake drumherum; wenn z.B. der C64 ewig warten muss, bis die Floppy mit ihren Rechnungen fertig ist und der Transfer beginnen kann, ist das alles Makulatur.
Eventuell könnte man etwas machen, wenn man z.B. die Welt-Berechnungen kontinuierlich in der Floppy laufen ließe und mit sehr kompaktem Format ("Raumschiff X an Position Y in Ausrichtung Z") die Parameter zum C64 übertrüge, aber keine Ahnung, ob das viel brächte und ob dafür überhaupt das RAM in der Floppy ausreichte. Und schon alleine z.B. die vielen Trümmerteile, die nach einem Abschuss rumfliegen, sprengen evtl. den Datenrahmen schon wieder.
Was eine Elite Version mit Sprites angeht: Das müsste ja dann zum einen die Schiffe auch noch darstellen können, wenn sie sehr nahe sind, also sehr groß
Ich meinte "Sprites" im allgemeinen Sinn, nicht im VIC II-Sinn. In dem Fall also Anzeigen der Raumschiffe durch Kopieren aus dem ROM (ggf. unter Zuhilfenahme einen Blitters). Z.B. der C64DTV könnte sowas grundsätzlich.
