@tomtomtom: du hast Upstart vergessen.
Da hadda Recht.
Supporter
![]() Anmeldungsdatum: Beiträge: 55206 Wohnort: Berlin |
|
Anmeldungsdatum: Beiträge: 29567 |
Hallo, wobei man Upstart ja zugute halten muss, dass es das 1. System war, was im größeren Maßstab (= alle *buntu) zum Einsatz kam, um das stark angestaubte SysV-Init System zu ersetzen. Und man kann auch spekulieren, ob ohne Upstart systemd zu der Zeit in der Form entwickelt worden wäre. AFAIR wäre Debian fast auf Upstart gewechselt, hat sich dann aber für systemd entschieden - hätten die sich anders entschieden, wäre die Situation heute vielleicht anders. Wobei IMHO systemd das bessere System ist. Wobei systemd sich ja auch nicht zu 100% durchgesetzt hat. Es soll gerüchteweise immer noch Leute gaben, auch nach 10 Jahren systemd, die Cron Jobs statt systemd Timer Units benutzen. Na ja, Fortschritt und Teile der Linux-Community sind halt leider stark gegenpolig. Wenigsten das hat Konstanz in der Linux Community. Gruß, noisefloor |
(Themenstarter)
Anmeldungsdatum: Beiträge: 23 |
Das ist falsch. Richtig ist: Ein Einzelner kann kein Betriebssystem seit min 20 Jahren mehr verstehen. Aber ein Einzelner kann einen (sehr) begrenzten Teil davon verstehen. Wenn also ausreichend viele Individuen oder Gruppen sich begrenzte Teile davon vornehmen, können auch größere Systeme verstanden werden. Vorausgesetzt der Quellcode liegt vor und der Binärcode kann mit dem Quellcode verifiziert werden. Siehe:https://www.danisch.de/blog/2024/03/31/it-sicherheitskatastrophe-durch-code-of-conduct/ |
Anmeldungsdatum: Beiträge: 1388 |
Das ist ja eigentlich auch nachvollziehbar. Wer über Jahrzehnte hinweg seine zeitgesteuerten Skripte über Cron Jobs hat laufen lassen, der wird das Systen nicht bloß deswegen umstellen, weil es jetzt schicke neue Timer Units gibt. Besonders, wenn es nur darum geht, ganz primitive Skripte zu bestimmten Zeiten laufen zu lassen, dann ist die Crontab immer noch ein bisschen einfacher zu handhaben: es wird die Zeile mit dem Zeitrhythmus und dem Skriptpfad in die Crontab geworfen, und das war's. Dagegen muss man sich bei den Timer Units Gedanken darüber machen, wie die jeweilige .service-Datei und .timer-Datei heißen soll, von welchem Typ der Service ist und welche Umgebung benötigt wird. Auch wenn jeder dieser Gedanken höchstens eine Sekunde dauert, so wird am Ende die Faulheit siegen, solange alles rund läuft. Wenn man allerdings bei einem Cron Job einen Workaround benötigt hat, und beim Ausprobieren der Timer Units feststellt, dass es auch ohne Workaround geht, dann ist man relativ schnell von Crontab, Autostart und Gedöns weg. |
Anmeldungsdatum: Beiträge: 1247 |
Alpine Linux 😎 Gerade wenn es was kleines, leichtes sein soll. Und die haben ohne systemd und ohne glibc vermutlich nur müde gelacht, als die xz-backdoor gefunden wurde. |
Anmeldungsdatum: Beiträge: 445 |
Dies ist definitiv falsch! Das Problem ist die sog. "Emergenz", dass aus einfachen und Bedingungen hochkomplexe Ergebnisse herauskommen, die nirgends in den Ursprungsbedingungen vorhanden sind oder wie Aristoteles sagt "Das Ganze ist mehr als die Summe seiner Teile." Siehe auch "Conways Spiel des Lebens"
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 23 |
Was ist definitiv falsch? Meine erste Aussage (somit Beide):
Oder nur die Zweite:
Ich habe weder Informatik noch Philosophie noch Geschichte studiert, kann weder griechisch noch Latein und werde schon gar keine 2000 Jahre Toten zitieren. Mit diesem Nebensatz
stimmt etwas nicht. Da fehlt etwas und die Schlussfolgerung ergibt keinen Sinn. Ich behaupte auch nicht, dass man genügend gute Leute finden kann und man genug Zeit hat ein ganzes Betriebssystem zu verstehen. Vor allem da sie ständig weiterentwickelt werden und die Voraussetzung:
nicht erfüllt ist. Aber ich behaupte zusätzliche 800+ MB Code erschweren es massiv, ein System zu verstehen. |
Anmeldungsdatum: Beiträge: 2265 |
Bin auch kein Experte, und ich habe nicht viel für snap übrig, aber das größere Volumen ergibt sich nicht daraus, dass wirklich mehr Code zugrunde liegt und kontrolliert werden müsste. Das System bläht sich auf, weil das Prinzip der Paktetverwaltung aufgegeben bzw. umgangen wird. Jedes Programm wird mit allen seinen Abhängigkeiten installiert, damit kommen dann viele Pakete mehrfach auf die Platte. Dass jemand den Quellcode "mitliest" geschieht aber (hoffentlich) früher, also "näher an der Quelle". Wenn er dort in Ordnung ist, kann er stromabwärts ruhig mehrfach kopiert werden. Das - für sich - ist eigentlich kein Sicherheitsproblem. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 23 |
Ich gebe dir recht, der Code der dem größerem Volumen zu Grunde liegt, ist nicht proportional zum Fett. Aber viele Pakete liegen nicht in der exakt gleichen Version in den Snaps (soweit ich es verstanden habe). Und viele Snaps haben Zugang nach Außen (Internet). Wer stellt sicher, dass dort keine Backdoors eingebaut werden oder Code nachgeladen wird. Da die Komplexität des Gesamtsystems überproportional (exponentiell?) steigt (vielleicht hat Yabba-Dabba-Doo das gemeint), ist, meiner Meinung nach, unnötiges Aufblähen des Gesamtsystems unbedingt zu vermeiden. |
Anmeldungsdatum: Beiträge: 445 |
Nein, dies ist ein Denkfehler, da ein System gänzlich andere Eigenschaften hat, als wenn man nur die Einzelteile betrachtet. Nimm von mir aus mal ein altes Radio, das noch funktioniert, zerlege es in seine Einzelteile und warte darauf, bis Musik herauskommt, da wirst lange darauf warten können. Man sollte nicht den Fehler machen und meinen man könnte einfach die Eigenschaften der Einzelteile aufsummieren und hätte dann die Systemeigenschaften, das ist falsch. Deshalb können auch nicht durch eine Vielzahl an Einzelbetrachtungen die Systemeigenschaften verstanden werden.
Sieh hierzu auch
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 23 |
Das hat mich jetzt überzeugt. Du hast recht. |