|
|
|
|
|
|
|
Es ist aber schon so, dass das wenigste von systemd als Pid 1 läuft. Völlig dämlich sind die nicht 
|
|
|
|
|
|
|
|
|
|
|
Traxer hat den Punkt weiter oben angebracht ; ich weiß nicht, was alles exakt unter PID 1 läuft und was nicht (trololo: bei SysVinit wüsste ich das), aber das Argument sehe ich schon als valide an: systemd ist bisher zwar eine wichtige und sicherheitskritische Komponente, aber man da Netzwerkfunktionalität reinpackt, muss systemd letzlich mindestens genauso hart sein wie jede Netzwerkanwendung mit root. Und das ist ziemlich, ziemlich hart. Da nur ein paar Checks bei den Inet-nahen Teilen einzubauen, reicht nicht aus, das muss im Grunde im Coderbewusstsein bei allen Teilen präsent sein.
Etwas vollkommen anderes.
Ich finde Unit-Files unschön.
Ich sehe: Shellskripte sind für diverse Zwecke blöd, da praktisch unmöglich maschinenlesbar (welche Anwendung wird von diesem Init-Skript gestartet, wo ist die PID-Datei und auf welchen Netzwerkinterfaces möchte es lauschen?). Das kann man da rausfriemeln, aber entweder funktioniert das nicht oder die Skripte müssen angepasst werden (ala export PID_FILE=...).
Ich sehe: Systemd macht das mit INI-Dateien und Variableninterpolation. Das klingt erstmal okay, gerade unter dem Gesichtspunkt der Distro-unabhängigkeit. Aber es ist auch viel weniger flexibel als ein Init-Skript. Das wiegt systemd mit einer riesigen Anzahl an Optionen und Direktiven auf. Komplex. Systemd muss viele Sachen können.
Ich persönlich fände einen Mittelweg mittels einem Paradigma ähnlich homoiconicity viel eleganter. Beispielimplementierung: Keine Init-Skripte, sondern kleine Lua-Skripte. linitd (lua-init-daemon) bringt einen Satz von Lua(!) (nicht C!) Skripten, quasi die linitd-stdlib, mit um diverse übliche Formate von Configdateien zu parsen. Seitens linitd hängen einige freie Funktionen oder Tables/Objekte rum, die vom Skript aufgerufen werden, um formale Parmeter mitzuteilen. Etwa set_name, set_pid_file, require("network") etc.
Der Vorteil einer solchen Lösung wäre, dass die Skripte selbstständig die Konfiguration ihres Daemons einlesen können (bspw.), um das PID-File oder sowas rauszufinden. Die Skripte können auch distro-abhängigen Kram wegabstrahieren, diverse Formen von Conditionals etc. implementieren.
Ein großer Vorteil einer solchen Lösung ist auch, dass der C-seitige, kritische Code extrem einfach ist, weil vieles, was systemd jetzt in C macht, in einer sicheren Skriptsprache abgehandelt werden kann.
Das mag erstmal wie ein und das selbe klingen, aber ist es nicht. Es ist auch nicht das gleiche wie Init-Skripte.
Zweitens ist mir systemd zu monolithisch, aber das ist ein bekannter Kritikpunkt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.08.2014 23:19]
|
|
|
|
|
|
|
|
|
|
Wenns ganz blöd läuft: BSD ist auch schön.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 26.08.2014 23:29]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Zu (2), da suche ich dir jetzt nicht die vielen, vielen Antworten raus
| |
Mir ist hinterher auch klargeworden, dass die Aussage ziemlich doof war.  Zu so einem weiten Feld wie "Sicherheit" kann halt jeder seinen Senf dazugeben. Klar dass das Diskussionsvolumen dadurch massiv wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 26.08.2014 23:27]
|
|
|
|
|
|
|
|
|
|
<hashbreaker> Nice to see systemd finally integrating Firefox into pid 1. The benchmarks show clear improvements in the post-boot browser startup latency.
|
|
|
|
|
|
|
|
|
|
|
Für die Fälle wo die Ini-File nicht ausreicht um alles abzudecken, kannst du auch weiterhin ein normales Startscript benutzen. Habe ich der Einfachheit auf meinem Server auch. Mit z.B. den ExecStart und ExecStop Optionen der service File ist das kein Problem.
Ich hasse es, Systemd zu verteidigen. Ich bin ja kein Fanboy, ich hab einfach nur keine Probleme mit dem System wie es momentan läuft 
|
|
|
|
|
|
|
|
|
|
|
|
Die systemd-Units werden momentan doch größtenteils von den Distro-Leuten geschrieben, oder nich?
|
|
|
|
|
|
|
|
|
|
|
Oder von mir, weil ich eigenes Kram starte
Ich hab z.B. die Files für Sharelatex (sind 4 nodejs-Prozesse mit Abhängigkeiten) und nen paar andere Sachen gemacht. Bin bisher zufrieden. Die einfachen Dinge sind einfach, die schweren Dinge...auch und zur Not gibt es noch ExecStart und ExecStop. Bin sehr zufrieden. SysV war mir dafür immer zu kompliziert und langwierig und Upstart war zwar eigentlich ok, aber völlig verbugt und mit dubiosen Desing-Entscheidungen
|
|
|
|
|
|
|
|
|
|
|
|
Was ich bei systemd tatsächlich sehr überzeugend finde, ist das @-System.
|
|
|
|
|
|
|
|
|
|
|
Also ich finde das mit ExecStart und ExecStop (und ExecReload) eine sehr übersichtliche Art, noch ein paar Aufgaben zu erledigen. Da beide Direktiven mehrfach vorkommen können, spart man sich auch zusätzliche Scripte.
Die Anzahl der Direktiven finde ich übersichtlich: http://www.freedesktop.org/software/systemd/man/systemd.service.html Zumindest ich komme mit der Man page ganz gut klar.
Ich würde sagen, neuere Software kommt meistens schon mit service file, für ältere packages schreiben das die Maintainer der jeweiligen Distro. Aber keine Ahnung. 
Hier übrigens, zur Info, was bei mir so läuft / lief:
| |
| Code: |
~ systemctl list-units -t service --no-pager --no-legend | grep active
colord.service loaded active running Manage, Install and Generate Color Profiles
cups.service loaded active running CUPS Printing Service
dbus.service loaded active running D-Bus System Message Bus
devmon@oli.service loaded active running devmon Service
dhcpcd.service loaded active running dhcpcd on all interfaces
dropbox@oli.service loaded active running Dropbox
getty@tty1.service loaded active running Getty on tty1
kmod-static-nodes.service loaded active exited Create list of required static device nodes for the current kernel
lvm2-lvmetad.service loaded active running LVM2 metadata daemon
lvm2-pvscan@8:18.service loaded active exited LVM2 PV scan on device 8:18
ntpd.service loaded active running Network Time Service
polkit.service loaded active running Authorization Manager
rpcbind.service loaded active running RPC bind service
slim.service loaded active running SLiM Simple Login Manager
sshd.service loaded active running OpenSSH Daemon
syncthing@oli.service loaded active running Syncthing service for oli
systemd-backlight@backlight:acpi_video0.service loaded active exited Load/Save Screen Backlight Brightness of backlight:acpi_video0
systemd-fsck@dev-sdb1.service loaded active exited File System Check on /dev/sdb1
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-modules-load.service loaded active exited Load Kernel Modules
systemd-random-seed.service loaded active exited Load/Save Random Seed
systemd-remount-fs.service loaded active exited Remount Root and Kernel File Systems
systemd-sysctl.service loaded active exited Apply Kernel Variables
systemd-tmpfiles-setup-dev.service loaded active exited Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service loaded active exited Create Volatile Files and Directories
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
systemd-update-utmp.service loaded active exited Update UTMP about System Boot/Shutdown
systemd-user-sessions.service loaded active exited Permit User Sessions
systemd-vconsole-setup.service loaded active exited Setup Virtual Console
udisks2.service loaded active running Disk Manager
user@3769.service loaded active running User Manager for UID 3769
|
|
Wobei alle mit systemd- vorne Interna sind.
/e: omg: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 27.08.2014 10:34]
|
|
|
|
|
|
|
|
|
Die Hälfte ist doch Trollerei. Das macht die Geschichte um seine Person nur noch schlimmer. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Die Hälfte ist doch Trollerei.
| |
Echt?
|
|
|
|
|
|
|
|
|
|
|
|
Der ganze Post is doch Troll ; systemd benutzt doch immernoch glibc oder nich?
|
|
|
|
|
|
|
|
|
|
|
|
Ach so. Ja, das geht mir wohl alles zu sehr am Arsch vorbei, als dass ich da fachlich jeden Troll erkennen könnte.
|
|
|
|
|
|
|
|
|
|
|
Ich hab mich immer noch nicht für eine Seite entscheiden.
Bin ich jetz für oder gegen systemd? Oder ist mir das eher egal? Oder für wasauchimmer besser für Linux ist?
Für Linux klingt gut. Nehm ich.
|
|
|
|
|
|
|
|
|
|
|
Ich mach mir das ganz einfach:
Desktop: Ist mir völlig pupe, welcher initdaemon hinter meiner GUI werkelt.
Alles andere, Server, alles was nach Diensterbringung riecht, inklusive Router: Hands off systemd.
|
|
|
|
|
|
|
|
|
|
|
|
Vielleicht hilft es euch, wenn ich euch sage, dass der 31. März der Tag vor dem 1. April ist?
|
|
|
|
|
|
|
|
|
|
|
Ich wollte damit noch mindestens eine Seite warten
Spielverderber.
|
|
|
|
|
|
|
|
|
|
|
|
Hmmm. Ich habe wohl meinen Ansporn gefunden, mich wirklich nuetzlich zu machen. IOQuake3-Git baut jetzt auf SDL2 auf, das ist auch fuer den Support von Wayland eine Voraussetzung. Bin gerade erschrocken, als ich bemerkt habe das ich als Contributor zum ioquake3-git Paket in AUR aufgelistet werde. Ist nett, weil ich praktisch nichts getan habe. Vielleicht sollte ich mir das auch mal verdienen
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Bin ich jetz für oder gegen systemd? Oder ist mir das eher egal? Oder für wasauchimmer besser für Linux ist?
| |
Am besten ist immer, für die Vorteile und gegen die Nachteile zu sein.
|
|
|
|
|
|
|
|
|
|
|
|
Und gegen Leute, deren Fresse dir nicht passt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
| | Zitat von csde_rats
Bin ich jetz für oder gegen systemd? Oder ist mir das eher egal? Oder für wasauchimmer besser für Linux ist?
| |
Am besten ist immer, für die Vorteile und gegen die Nachteile zu sein.
| |
Hatten wir schon lange nicht mehr: es ist schon traurig, wenn man für oder gegen Software sein muss [weil sie Monokultur etabliert].
|
|
|
|
|
|
|
|
|
|
|
hmmm, grade das erste mal nach 11 jahren probleme mit resize2fs :/
weder online noch offline helfen, mit dem netten nebeneffekt: resize, mount, passt alles, umount, mount, dateisystem wieder so klein wie zuvor.
allerdings hab ich diesmal auch das erste mal (aus rechenfaulheit) zuerst das dingens mit -M verkleinert, sonst hab ich immer ne zahl angegeben dass noch was frei wat :/ gnah.
backup ist selbstverständlich vorhanden aber trotzdem doof
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
Hatten wir schon lange nicht mehr: es ist schon traurig, wenn man für oder gegen Software sein muss [weil sie Monokultur etabliert].
| |
hmmm, haben wir doch die ganze zeit?
.doc(x), skype, m$ allgemein, bzw die ganzen kacke mit vendor lockin?
|
|
|
|
|
|
|
|
|
|
|
doc(x): zum Anschaun gibts Google Docs und libreoffice, Geschriebenes gibts als odt oder lieber als PDF
skype: stimmt, ggf. mumble, wenn kein Video sein muss
MS: bedroht mich in meinem Mikrokosmos nicht
Mir geht es um die Kannibalisierung (geiles Wort) der Polykultur. Lustigerweise war die letzten zwei Jahrzehnte sysvinit auf gut und gerne 90%+ der Linuxsysteme installiert. Das hat mich aber in keinster Weise daran gehindert, minit oder runit (ruin it? ) zu nutzen. Durch den hohen Integrationsgrad von systemd wird/hat sich das fundamental ändern. Das ist mein einziges Problem mit dem Teil.
|
|
|
|
|
|
|
|
|
|
|
|
linitd klingt unter dem Aspekt wie eine lustige Beschäftigung für die nächsten paar Jahre
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
doc(x): zum Anschaun gibts Google Docs und libreoffice,
| |
na dann mal spass wenn dir leute ne datei zuschicken, du drin was änderst und sie ihnen wieder zuschickst.
spätestens wenn das "ergebnis" als xps und nicht als pdf kommt haste spass...
|
|
|
|
|
|
|
|
|
|
|
Geburtsdatum: 31.07.88
Funktioniert, aber ich wasche mir jetzt mal die Hände und stelle sie wieder beiseite
|
|
|
|
|
|
|
|
|
|
|
|
Alternativ einfach in den Geschirrspüler packen und nach dem Waschgang ein, zwei Tage trocknen lassen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Für die Fälle wo die Ini-File nicht ausreicht um alles abzudecken, kannst du auch weiterhin ein normales Startscript benutzen. Habe ich der Einfachheit auf meinem Server auch. Mit z.B. den ExecStart und ExecStop Optionen der service File ist das kein Problem.
Ich hasse es, Systemd zu verteidigen. Ich bin ja kein Fanboy, ich hab einfach nur keine Probleme mit dem System wie es momentan läuft
| |
Im Grund wurde das meiste schon so oft gesagt. Gerade die beiden Artikel von Traxer sind doch nur eine reine Wiederholung.
Systemd
1. sieht vor mit einigen UNIX-Prinzipien zu brechen und eine einheitliche Basis ueberhalb dem Kernel, LIBC und STDLIBC++ bieten.
2. soll einfache und klare Unit-Files etablieren, die fuer jede Software auf jeder Distribution gleich sind. Die Unit-Files sind Aufgabe der Software, nicht des Paketmaintainers.
3. Bootprozess und Systemverwaltung mit parallem, nativen Code
4. Systemd soll aber darueber hinaus auch mit komplexeren Shellscripten umgehen koennen und diese auch fuer den Uebergang hin zu Unit-Files
5. Poettering und Sievers benehmen sich teils wie Idioten (UDEV, Bugs) und finden das komisch, statt aktiv was daran zu aendern
6. Grosse zentrale Dinge wie CGROUPS oder KDBUS werden hinzugefuegt
7. Viele (kleine) Sachen werden hinzugefuegt, die eher befremdlich bis nicht notwendig wirken
Lua-Scripts
@csde_rats:
LUA-Scripts? Bitte nicht. Ich moechte Konfigurationsdateien die einfach verstaendlich und lesbar sind fuer jeden oder etablierte, klare Shell-Scripts
Systemd und die Ramdisk
Mir ist Systemd letzthin hart hingefallen, mit der Verschiebung von /etc/os-release (gehoert zum Paket filesystem). Warum, Systemd hat doch die Verschiebung selbst angeregt? Na weil Archlinux nicht Systemd von der Platte laed sondern aus der Init-Ramdisk, wie viele Distributionen. Zumindest wenn man den Hook "Systemd" verwendet. Der Kernel von Archlinux hat parallel ein Update erhalten und somit eine neue Init-Ramdisk mit neuer Binary von Systemd.
Ich mochte Ramdisks noch nie, weil sie eine reine Verdopplung sind. Und bei einem selbst kompilierten Kernel sind Ramdisks ueberfluessig. Und ich haette an diesem Zusammenhang vorher denken koennen:
Systemd == PID 1
Systemd == Auf Ramdisk
Ramdisk != Aktuell
return fail;
Also muss die Ramdisk immer aktuell sein!
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 27.08.2014 17:46]
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
