FreeBSD ist durchaus „General Purpose“. Was systemd angeht: Viele Köche verderben den Brei? Eine Zeitlang war dort Lennart Poettering (inzwischen passenderweise bei Microsoft) Ton angebend, also „viele Menschen kennen den Code“ ändert wenig an „der Code ist schlecht“.
Dsss viele Menschen „den Code sehen“, bedeutet auch noch nicht automatisch bessere Codequalität. Microsoft bezahlt regelmäßig externe Firmen dafür, „den Code zu sehen“ (und Fehler zu melden). Welchen Teil deiner Linuxdistribution hast du dir schon angesehen und verstanden?
Das hat einen ganz einfachen Grund: 386BSD, das erste komplett freie BSD (also ohne AT&T-lizenzierten “proprietären” Code*) für PCs, daher auch der Name, kam erst im März 1992 in einer ersten Version “raus”. Linus Torvalds hat später selbst zu Protokoll gegeben:
If 386BSD had been available when I started on Linux, Linux would probably never had happened.
Mit “gut” hat das also nichts zu tun, nur mit “gratis”. Er hätte einfach nur ein paar Monate warten müssen.
* Ganz früher waren Unix und BSD ja sozusagen freie Software Freeware und wurden quasi zum Selbstkostenpreis verteilt. Leider fingen die Rechteinhaber von Unix irgendwann an, das für eine dumme Idee zu halten. Schade.
ich nenne zuerst einmal die vorteile aus meiner sicht, anhand eines vergleichs:
man mag ja über JavaScript denken was man mag, aber eine sache haben sie gut hingekriegt, und das ist das modul-system (import bzw. statisches/dynamisches verlinken).
das modulsystem ist so aufgebaut, dass der programmcode beginnt mit
Jedoch hat import den Vorteil, dass es eine “Deklaration” ist, kein “Funktionsaufruf”.
Das heißt, wenn das System startet, analysiert es zuerst alle Importe, und führt diese Parallel aus. Wenn stattdessen funktionsaufrufe genutzt würden, würden diese erst zur Laufzeit starten und seriell ausgeführt werden. Das wäre aber, vor allem bei vielen Abhängigkeiten, deutlich langsamer.
Jetzt ist es mit systemd so, dass Services parallel gestartet werden können, weil es sich um Deklarationen (in jeweils eigenen .service files handelt). Bei SysVinit handelt es sich meines wissens nach um bash-skripte, die seriell laufen, und damit um einiges langsamer sind. was sagst du zu diesem einwand?
Jetzt ist es mit systemd so, dass Services parallel gestartet werden können, weil es sich um Deklarationen (in jeweils eigenen .service files handelt). Bei SysVinit handelt es sich meines wissens nach um bash-skripte, die seriell laufen, und damit um einiges langsamer sind. was sagst du zu diesem einwand?
Zunächst einmal Grundsätzliches: System V ist sh, nicht bash. (Nein, die bash ist keine “bessere sh”.) Aber das ist natürlich Erbsenzählerei. Zu dem Einwand sage ich Folgendes:
Ja, System V lädt Scripts seriell. Nun wurde systemd aber insbesondere als vorteilhaft für Server bezeichnet. Wie oft startest du deine Server neu, dass das überhaupt ins Gewicht fällt? (Startest du deine Desktops neu oder reicht dir da der Ruhezustand?)
systemd macht ja wesentlich mehr als nur Servicestart, sonst wäre es vielleicht eine brauchbare Alternative zu anderen Initsystemen. Leider frisst es sich durch das gesamte System und absorbiert zusehends mehr Dienste. Man kann wohl einen Teil davon immer noch optional laden, aber unter Linux (portabel ist systemd ja zum Glück nicht…) verlassen sich immer mehr Anwendungen darauf, dass das ganze Paket da ist. (Einen Teil dieser Optionen will man nicht haben. Warum muss man hartkodierte Google-IPs nutzen? Warum gibt es keine Option für textbasierte Logdateien, die man einfach greppen könnte?)
Je komplexer die Software, desto mehr Sicherheitslücken weist sie auf. Das ist eine allgemeine Beobachtung, die nicht nur für systemd gilt, aber in einem Prozess, der höchste Rechte im System haben muss, will man das am allerwenigsten.
Die “Dienste” bei systemd sind INI-Dateien. Damit haben wir in den 90ern unter Windows arbeiten müssen. Spaß hat das nicht gemacht.
Alternativen, die weit weniger wuchern, gibt es zuhauf, darunter OpenRC (Gentoo, aber portabel) und runit (Void, aber portabel).
FreeBSD ist durchaus „General Purpose“. Was systemd angeht: Viele Köche verderben den Brei? Eine Zeitlang war dort Lennart Poettering (inzwischen passenderweise bei Microsoft) Ton angebend, also „viele Menschen kennen den Code“ ändert wenig an „der Code ist schlecht“.
Dsss viele Menschen „den Code sehen“, bedeutet auch noch nicht automatisch bessere Codequalität. Microsoft bezahlt regelmäßig externe Firmen dafür, „den Code zu sehen“ (und Fehler zu melden). Welchen Teil deiner Linuxdistribution hast du dir schon angesehen und verstanden?
ja was denkst du dann war der ursprüngliche grund dass linux überhaupt entwickelt wurde wenn die BSDs eh so toll sind?
Das hat einen ganz einfachen Grund: 386BSD, das erste komplett freie BSD (also ohne AT&T-lizenzierten “proprietären” Code*) für PCs, daher auch der Name, kam erst im März 1992 in einer ersten Version “raus”. Linus Torvalds hat später selbst zu Protokoll gegeben:
Mit “gut” hat das also nichts zu tun, nur mit “gratis”. Er hätte einfach nur ein paar Monate warten müssen.
* Ganz früher waren Unix und BSD ja sozusagen
freie SoftwareFreeware und wurden quasi zum Selbstkostenpreis verteilt. Leider fingen die Rechteinhaber von Unix irgendwann an, das für eine dumme Idee zu halten. Schade.ich verstehe, das ist ein interessantes Argument. Ich werde darüber nachdenken, versprochen. :D
Prima. Bei weiteren Fragen gern fragen!
:D
was ist dein problem mit systemd?
ich nenne zuerst einmal die vorteile aus meiner sicht, anhand eines vergleichs:
man mag ja über JavaScript denken was man mag, aber eine sache haben sie gut hingekriegt, und das ist das modul-system (
importbzw. statisches/dynamisches verlinken).das modulsystem ist so aufgebaut, dass der programmcode beginnt mit
import stuffA from './fileA.js'; import stuffB from './stuffB.js'; console.log("all dependencies loaded...");im gegensatz dazu steht das früher genutzte
require:const stuffA = requre('./fileA.js'); const stuffB = require('./stuffB.js'); console.log("all dependencies loaded...");Jedoch hat
importden Vorteil, dass es eine “Deklaration” ist, kein “Funktionsaufruf”.Das heißt, wenn das System startet, analysiert es zuerst alle Importe, und führt diese Parallel aus. Wenn stattdessen funktionsaufrufe genutzt würden, würden diese erst zur Laufzeit starten und seriell ausgeführt werden. Das wäre aber, vor allem bei vielen Abhängigkeiten, deutlich langsamer.
Jetzt ist es mit
systemdso, dass Services parallel gestartet werden können, weil es sich um Deklarationen (in jeweils eigenen .service files handelt). Bei SysVinit handelt es sich meines wissens nach um bash-skripte, die seriell laufen, und damit um einiges langsamer sind. was sagst du zu diesem einwand?Es löst das falsche Problem.
Etwas ausführlicher:
Zunächst einmal Grundsätzliches: System V ist
sh, nichtbash. (Nein, diebashist keine “besseresh”.) Aber das ist natürlich Erbsenzählerei. Zu dem Einwand sage ich Folgendes:systemdaber insbesondere als vorteilhaft für Server bezeichnet. Wie oft startest du deine Server neu, dass das überhaupt ins Gewicht fällt? (Startest du deine Desktops neu oder reicht dir da der Ruhezustand?)systemdmacht ja wesentlich mehr als nur Servicestart, sonst wäre es vielleicht eine brauchbare Alternative zu anderen Initsystemen. Leider frisst es sich durch das gesamte System und absorbiert zusehends mehr Dienste. Man kann wohl einen Teil davon immer noch optional laden, aber unter Linux (portabel istsystemdja zum Glück nicht…) verlassen sich immer mehr Anwendungen darauf, dass das ganze Paket da ist. (Einen Teil dieser Optionen will man nicht haben. Warum muss man hartkodierte Google-IPs nutzen? Warum gibt es keine Option für textbasierte Logdateien, die man einfachgreppen könnte?)systemdgilt, aber in einem Prozess, der höchste Rechte im System haben muss, will man das am allerwenigsten.systemdsind INI-Dateien. Damit haben wir in den 90ern unter Windows arbeiten müssen. Spaß hat das nicht gemacht.