Vor-/Nachteile Systemd vs. SysVinit für Benutzer?

Nimm doch einfach die Version, welche von deiner Linux Distro 
unterstützt wird, oder besser gesagt, default ist. Das wird zur 
überwiegenden Mehrheit Systemd sein.

Macht es einen Unterschied? Ja, z.B. wenn du eh schon das komplette 
System mit Systemd konfigurierst gibts keinen Grund einzelne Sachen wo 
anders zu verstecken. Alles schön auf einem Fleck, man kann sich einen 
status an zeigen lassen und alles einheitlich starten und für den 
autostart enablen.

Systemd Units kann man (mit etwas Zeit) auch locker selber schreiben, 
oder einfach eine andere als Template her nehmen.

Edit: Normalerweise sollte Ubuntu sogar eine GUI bieten mit welcher man 
einen automatischen Spindown aktivieren kann nach bestimmter Zeit. Wäre 
noch einfacher.

In der Praxis: völlig wumpe, bzw. Pluspunkt für systemd weils einfach 
mittlerweile sehr weit verbreitet ist und viele Dinge vereinheitlicht.
Langfristig wird SysV-Init eher Underdog-Distris oder Distris für 
Technikfreaks vorbehalten bleiben.

Nachteil:
als systemd-Nutzer kansnt du nicht so schön über den pösen Herrn 
Poettering schimpfen. Insbesondere in Linux-Foren ist das Ablehnen von 
Produkten des besagten Herren ein Zeichen von Kompetenz. Neuankömmlinge 
werden dich aufgrund deines Elitismus hochachten.

Für Benutzer hat es keinen besonderen Unterschied. Man muß sich in beide 
Konzepte einarbeiten. SysV Init ist ausgereift, aber alt. 
Parallelisierung war nur mit hängen&würgen machbar. Wo die Bootzeit 
unwichtig war konnte man alle Fälle damit erschlagen.
Systemd ist ziemlich neu und war ursprünglich für Arbeitsplatzrecher 
designt (also Lennarts Laptop). Es wird allerdings besser, und man kann 
es tatsächlich in weniger kritischen Fällen einsetzen. Es wird 
allerdings daran noch heftig rumgebastelt, so daß man sich auf diverse 
Änderungen bei jedem neuen release freuen darf.

Markus schrieb:
> Als Linux-Neuling finde ich die Konfiguration jedes einzelnen Ansatzes
> schon äußerst rätselhaft. Aber die heftige Auseinandersetzung über die
> beiden Realisierungen bestärkt eigentlich nur jedes Vorurteil, das ein
> Windows-Benutzer über Linux haben kann, weil ich als Benutzer vollkommen
> verwirrt zurückbleibe.

Das schöne an Linux, BSD und dergleichen Systeme, ist, dass man als 
Benutzer selbst die Wahl hat, welches Programm man für eine Aufgabe 
verwenden will, und wie man sein System konfigurieren will. Es gibt 
keinen Weg, von dem man sagen könnte, es wäre der einzig richtige. Es 
ist dem User überlassen, ob er Shellscripts und Sysvinit zum Starten der 
Services verwenden will, oder etwas mehr Descriptives wie Upstart, oder 
eine modernere Alternative zu Sysvinit wie OpenRC, und ob er dass mit 
supervisoren wie daemontools, s6 oder runit kombinieren will. Dass gillt 
für alle Teile des Systems, und hat den Vorteil, dass man das Tool 
wählen kann, das für eine Aufgabe am besten geeignet ist. Bei meinen DNS 
Servern beispielsweise, dort verwende ich bind9 für meine authoritativen 
DNS server für meine domain, aber dnsmasq und unbound als DNS resolver. 
Ich kann alle Teile des Systems, vom init system über die Services bis 
zu den Userspace Programmen, unabhängig voneinander austauschen, ich 
habe laso 100% Kontrolle über mein System und weiss jedes detail 
darüber.

Ein Grundprinzip damit das möglich ist, und erste Regel der Unix 
Philosophie, ist "Do one thing and do it well", also "Tue eine sache und 
mache diese gut". Dies berück sichtigen alle guten und sabilen 
Programme. grep sucht nur nach Zeichenketten, find nach Dateien, cat 
kopiert nur von stdout nach stdin, tail kümmert sich nur um das Ausgeben 
der letzten paar zeilen einer Datei, dnsmasq löst nur DNS-Queries auf, 
und OpenRC und SysvInit kümmern sich nur um das Starten und Stoppen von 
Servicen und um Zombieprozesse.

Das Problem mit Systemd sind nicht die Funktionen und Tools, die es 
anbietet, sondern dass dessen Tools voneinander abhängig sind und nicht 
einfach ersetzt oder ohne den rest von Systemd verwendet werden können. 
Gleichzeitig ersetzen die Systemd Tool zahlreiche alternativen, so dass 
sobald ein Programm ein Systemd tool braucht alles von Systemd benötigt 
wird, und man keine andere wahl hat als alles von Systemd zu verwenden, 
selbst wenn es für gewisse Teile davon bessere Alternativen gegeben 
hätte. Man könnte das ganze als die OSS version von "Embrace, Extend, 
Extinguish" betrachten, all diese Tools und noch mehr wurden schon in 
Systemd übernommen oder von diesem Ersetzt:
 - Interprozesskommunikation: dbus -> systemd-dbus => sd-bus
 - Device managemand: udev -> systemd-udev
 - su/doas/sudo/login, etc. => machinectl shell, machinectl login, etc.
 - docker/lxc => machinectl
 - newpid + chroot oder lxc, etc. => systemd-nspawn
 - syslog => sd_journal_*
 - sysvinit, upstart, openrc, runit, etc. -> systemd
 - dnsmasq, unbound, etc. => systemd-resolved
 - mount => systemd-mount
 - /etc/passwd + glibc => /etc/lib/sysusers.d + systemd-sysusers
 - cron => systemd timers
 - ahci event handlers
 - gnome-session => logind
 - autofs => systemd.automount
 - halt, poweroff, reboot, kexec, etc. -> 
systemd-halt.service/machinectl poweroff, etc.
 - etc.

Das Problem mit Systemd sind nicht die Tools oder deren Funktion, das 
Problem ist, dass diese alle voneinander abhängig sind. Entweder bekommt 
man alles oder nichts. Zusätzlich bietet Systemd in libsystemd0 
funktionen wie sd_journal_* an, welches mit allen anderen syslog daemons 
inkompatibel ist und nur auf systemd systemen läuft, wo es doch schon 
syslog gibt, welches überall funktioniert und mit jedem logging daemon 
kompatibel ist. Oder auch sd_notify, wo der Service systemd sagen muss, 
dass er nun gestartet ist, etc. Dadurch entstehen Dependencies zu 
Systemd in allen möglichen Programmen, egal ob rsyslog, tor, gnome 
session, lxc, libvirt, lxde session, xfce session, lightdm, 
openssh-server, cups, iio-sensor-proxy (ist das program für das erkennen 
der Rotation von geräten, nötig um den Bildschirm zu drehen), xorg, pam, 
asterisk, und einige hunderte mehr. (einige dipendencies sind indirekt 
oder zur compile time abschaltbar, aber für andere, wie z.B. 
iio-sensor-proxy ist das nicht möglich. Compile time only dependencies 
sind hier noch nicht gelistet.)

Es gab hier schonmal eine Diskussion zu Vor und Nachteilen von Systemd 
systemen, die hier entstand: 
Beitrag "RasPi Autostart Skript nicht als root"

Daniel A. schrieb:
> Das schöne an Linux, BSD und dergleichen Systeme, ist, dass man als
> Benutzer selbst die Wahl hat, welches Programm man für eine Aufgabe
> verwenden will, und wie man sein System konfigurieren will.

Das ist nur schön für Leute die da drauf wert legen.
Und die die das tun tun dies meist eher aus Spieltrieb denn zwecks 
konkreten Anforderungen (ja, es gibt immer paar Ausnahmen, geschenkt).

Daniel A. schrieb:
> Das Problem mit Systemd sind nicht die Tools oder deren Funktion, das
> Problem ist, dass diese alle voneinander abhängig sind.

Wieso ist das ein Problem?
Ist doch schön wenn das System schön rund ist und in sich stimmig.
Die 1% der Linuxer die dies anders sehen können sich aber immernoch ihr 
System selbst häkeln. Aber die 99% die ne Distro installieren und dann 
damit produktiv arbeiten wollen sind so gut beraten.

Versteh mich nicht falsch.
Grundsätzlich hast du mit deinen Aussagen recht.
Sie sind nur im Kontext des TE fehl am Platz.

Markus schrieb:
> ...ich kann die jeweiligen Argumente ohnehin nicht nachvollziehen.
> Aber macht das für
> mich als Benutzer einen Unterschied, welche Methode ich nutze (unter
> Ubuntu 16.04) ?

systemd, so wie's der Distributor ausliefert, und gut ists...

Wenn Du nur den Distroinstaller, nur Pakete aus der 
Distro-Paketverwaltung installierst und die Konfigurationseinstellungen 
in den Menüs oder Skripten machst die die Distro bereitstellst, dann ist 
das für Dich total egal welche Dienstverwaltung darunter arbeitest.

Eigentlich ist der SystemD komfortabler und es sind die Erfahrung vieler 
Jahre Linuxnutzung in dessen Entwicklung eingeflossen.

Ein Grund dagegen wäre z.B. ein reines, selbstgebautes System auf 
Linuxbasis, welches von jemandem erstellt wird der nur wenige Dienste 
verwendet und sich mit den init.d-Skripten besser auskennt.

Le X. schrieb:
> Daniel A. schrieb:
>> Das Problem mit Systemd sind nicht die Tools oder deren Funktion, das
>> Problem ist, dass diese alle voneinander abhängig sind.
>
> Wieso ist das ein Problem?
> Ist doch schön wenn das System schön rund ist und in sich stimmig.

Inwiefern soll die Abhängigkeit der Komponenten ein rundes und in sich 
stimmiges System ausmachen? Es wäre möglich logging, das Init System, 
sd_bus, etc. als voneinander unabhängig zu designen, so dass z.B. das 
Logging den rest von Systemd nicht benötigt, oder man sd_bus ohne den 
Rest verwenden könnte. Von der Verwendung, der Konfiguration und dem 
Interface der Tools müsste sich ja nichts ändern, der Systemd User würde 
gar nichts davon merken, hätte aber zusätzlich die Möglichkeit eine 
Komponente durch etwas anderes zu ersetzen.

> Die 1% der Linuxer die dies anders sehen können sich aber immernoch ihr
> System selbst häkeln. Aber die 99% die ne Distro installieren und dann
> damit produktiv arbeiten wollen sind so gut beraten.

Eine eigene Linux Distribution zu erstellen ist ein enormer Aufwand. Mit 
einer bestehenden Distribution hat man Package Manager und vernünftige 
default Konfigurationen, und der nachträgliche Konfigurationsaufwand ist 
immer sehr gering. Auch init scripts oder unit files muss man nur selten 
erstellen, da die Package Maintainer das meist schon längst gemacht 
haben.  Sich um all das selbst kümmern zu müssen, nur um ein System zu 
haben von dem man weiss, was drauf ist und wie es funktioniert, ist auf 
dauer nicht managebar. Zum Glück gibt es noch einige Distributionen ohne 
Systemd, wie z.B. Devuan oder Void linux, bei dem man sich noch selbst 
ein vernünftiges System zusammensetzen kann, und eine anständige Auswahl 
an Programmen mit anständigen Dependencies mitgeliefert bekommt. Dennoch 
gibt es immer mehr Programme, die mit Systemd verseucht werden, es ist 
beispielsweise schon jetzt unmöglich, bei Drehen von Tablets ohne 
Systemd den Bildschirm mitdrehen zu lassen, weil das Program welches den 
Sensor lesen würde, iio-sensor-proxy, nicht ohne Systemd verwendet 
werden kann! Und die Anzahl solcher Programme nimmt stetig zu! Wieso 
stört es nur so wenige, dass einem sämtliche Auswahl weggenommen wird, 
und man überall nach und nach nur noch das selbe ohne Auswahl vorgesetzt 
bekommt, so dass man gezwungen wird das einzige Package zu nehmen? 
Stellt euch vor es gäbe plötzlich nurnoch Hühnerfleisch in den Läden, 
und der Metzger würde sagen man solle halt selbst ein Rind schlachten, 
wenn man ein Steak wolle. Wie kann einem so etwas nur egal sein? Wieso 
muss man den Experten, die die Linuxsysteme mit erschaffen haben, das 
leben unnötig schwer machen?

Daniel A. schrieb:
> Das schöne an Linux, BSD und dergleichen Systeme, ist, dass man als
> Benutzer selbst die Wahl hat, welches Programm man für eine Aufgabe
> verwenden will, und wie man sein System konfigurieren will.

Das ist andererseits aber eine der größten Schwächen von Linux, die eine 
ernstzunehmende Verbreitung jenseits von Nerd-Desktops zuverlässig 
verhindert. Wo Vielfalt ist, kann keine Einheitlichkeit sein. Aber nur 
Einheitlichkeit gibt Softwareentwicklern Planungssicherheit und ist 
wichtigste Voraussetzung dafür, daß Entwicklergruppen an einem Strang 
ziehen können, um leistungsfähige UND benutzerfreundliche Software zu 
schaffen. Machen wir uns nix vor, die Zeiten, wo dies einzelnen 
Programmierern im stillen Kämmerlein gelang, sind schon lange vorbei. 
Moderne Software hat einen Komplexitätsgrad erreicht, der nur noch mit 
großen Teams beherrschbar ist. Der Grund, warum unter Linux nach wie 
Frickelei mit Kommandozeilen und händisches Basteln am System Usus ist, 
liegt nicht in der allgemein besseren oder schnelleren Bedienbarkeit, 
sondern darin, daß die Programmierer es nicht besser hinbekommen. Nicht 
etwa, weil sie zu doof oder weniger qualifiziert sind als die bei 
Microsoft oder Apple, sondern weil sie ihre Ressourcen durch 
unkoordiniertes und teilweise sogar kontraproduktives Arbeiten 
vergeuden.
Vielleicht ist systemd ein Schritt in die richtige Richtung, um die 
Community zu vereinen und eines Tages vielleicht doch noch das 
Redmondsche Monopol zu brechen.

Wenn von "anständigen Dependencies" die Rede ist (und damit andere 
Dependencies implizit als "unanständig" deklariert werden) und über 
Programme "die mit Systemd verseucht" sind geschimpft wird, bleibt für 
sachliche Diskussion nicht mehr viel Raum. Aber wenn ein Programmautor 
meint, mit dieser oder jener Abhängigkeit (welches Programm hat keine, 
und wenn es nur Bibliotheken sind) leichter zum Ziel zu kommen, dann ist 
das sein gutes Recht. Wer es anders haben will, kann es dank Open Source 
selber ja anders machen oder jemanden finden, der es ändert.
Das ist so ähnlich wie die pro/contra Diskussionen zur GPL, wenn der 
Autor eine Lizenz gewählt hat, die mir nicht passt, ist das mein Problem 
und nicht seins.

Wenn man mit den Init-Scripten "aufgewachsen" ist und da auch schon 
selber Hand angelegt hat, tut man sich anfangs etwas schwerer mit den 
Services, aber letztendlich ist es kein Hexenwerk. Bei meinem Server 
hatte ich es nur gebraucht, um mehrere Tor-Instanzen zu starten, seitdem 
nie wieder. Solange Systemd nicht irgendein Binary Blob ist, dem ich 
aufs Gedeih heraus vertrauen muss, ist mir das eigentlich egal.

Und, ob es überhaupt sinnvoll ist das "redmondsche Monopol" zu brechen, 
bezweifle ich. Denn dann kommen noch die ganzen "Ex-Windows-PowerUser" 
dazu, die schon jetzt bei Open Spource Projekten eine gewisse 
Kundenmentalität an den Tag legen.


Jörg

Markus schrieb:
> - Standby von Festplatten muß ich erst nachinstallieren. Ist hierfür
> hdparm oder hdidle besser? Achso, hdparm funktioniert bei WD Red Platten
> gar nicht. Findet man natürlich erst nach ausgiebiger Internetrecherche
> heraus, nachdem hdparm nicht wie gewünscht funktioniert.

Die meisten Festplatten haben intern einen timer, so dass diese wenn 
über einen bestimmten Zeitraum nichts gelesen oder geschrieben wird von 
selbst in den Standby gehen, ohne dass das OS etwas tun müsste. hdparm 
ist kein tool, um den Standby modus von Festplatten zu verwalten, in der 
manpage (man hdparm) steht ganz oben: [1]

1

hdparm - get/set SATA/IDE device parameters

Es handelt sich also um ein low level tool, um Eigenschaften von SATA 
und IDE Laufwerken zu verändern. Dazu gehört unter anderem 
Firmware-Updates in Laufwerke einspielen, oder interne Einstellungen des 
Laufwerks wie z.B. die Zeit in idle nach der es in den Standby geht. 
Wenn die Firmware eines Laufwerks diesen Parameter nicht unterstützt, 
kann hdparm ihn auch nicht setzen. Da die meisten Laufwerke bereits 
sinnvolle Defaults besitzen und selbst in den Standby gehen können, wird 
hdparm und hd-idle meist nicht benötigt. Weil es aber einige Laufwerke 
gibt, die diesen internen Parameter nicht besitzen, wurde das Programm 
hd-idle geschrieben, welches speziell dafür zuständig ist Festplatten 
nach einer gewissen Zeit in den Standby zu versetzen, sofern das möglich 
ist. Steht auch im ersten Satz der Projektseite von hd-idle: [2]

1

hd-idle is a utility program for spinning-down external disks after a period of idle time.

Man muss also nur den ersten Satz der Gebrauchsanleitung der Tools 
lesen, und schon ist deren Scope, Zweck, Funktionsweise, und die sich 
daraus ergebenden Implikationen sofort klar. Das ein Programm, welches 
speziell dafür gemacht wurde, um Festplatten in den Standby zu 
versetzen, dafür besser geeignet ist als ein Tool, um 
Festplattenparameter zu setzen, erscheint mir ebenfalls logisch.

Interessanter weise gibt es in Debian kein Package für hd-idle, offenbar 
war es niemandem dort wichtig genug das Packet in Debians Repositories 
zu bringen. Ich glaube nicht, dass dies allzu kompliziert wäre, ich habe 
zwar keine eigenen Packete in Debian, aber von mir ist das 
libjournal-shim package in Devuan. Läute, die ihre Hardware auf Energie 
sparen oder Performance tunen, sind vermutlich ebenfalls eine 
Minderheit, die meisten beschäftigen sich gar nicht erst damit.

> Das sind m.E. alles Funktionen, die heutzutage einfach zur
> 'Standardausrüstung' gehören. Wieso muß ich das alles nachinstallieren?
> Und dann gibt es noch nicht einmal eine 'offizielle' Lösung, an der ich
> mich als Neuling orientieren kann.

Nach einer gewissen Zeit in den Standby zu wechseln hat zwar nichts mit 
einem Grafischen Benutzeroberfläche zu tun, aber da dies fast nur 
Desktop-user benötigen haben die DEs die Einstellungen dort integriert. 
Für Serveranwendungen ist es eben keineswegs Standard, Festplatten oder 
den ganzen Server in Standby zu versetzen, sondern dein spezifischer 
use-case. Die meisten Server use-cases kümmern sich weniger um Energie 
sparen, und mehr um Redundanz, gute Belüftung für die Langlebigkeit der 
Server, und optimale Lastverteilung über alle Systeme. Ausserdem ist es 
nicht trivial, ein System auf niedrigen Energieverbrauch zu trimmen, da 
man dazu Anpassungen an den verschiedensten Dingen machen kann, und 
nicht für alle use-cases sind alle sinvoll.

PS: In powertop kann man noch einige Energiesparoptionen aktivieren und 
den Energieverbrauch diverser Dinge nachsehen.

1) https://linux.die.net/man/8/hdparm
2) http://hd-idle.sourceforge.net/

Icke ®. schrieb:
> Das ist andererseits aber eine der größten Schwächen von Linux, die eine
> ernstzunehmende Verbreitung jenseits von Nerd-Desktops zuverlässig
> verhindert. Wo Vielfalt ist, kann keine Einheitlichkeit sein. Aber nur
> Einheitlichkeit gibt Softwareentwicklern Planungssicherheit und ist
> wichtigste Voraussetzung dafür, daß Entwicklergruppen an einem Strang
> ziehen können, um leistungsfähige UND benutzerfreundliche Software zu
> schaffen.

Dafür gibt es Standards und Metapackete. Ein solcher Standard war z.B. 
syslog, jeder hat es unterstützt, und es gab eine Vielfalt von Logging 
daemons dafür. Seit Systemd gibt es 2 Standards, syslog und 
sd_journal_print. Mit sinvollen Standards mit gut durchdachten 
Interfaces kann man eine grosse Auswahl an Software bieten, die gut 
zusammen funktioniert, ohne dass diese direckt voneinander abhängen. Das 
ist der richtige Weg Dinge zu vereinheitlichen. Es hindert 
Distributionen auch nicht daran, ein einheitliches Standartset an 
Anwendungen zu liefern, dafür gibt es Virtuelle Packete und Metapackete. 
Eine Distribution könnte ein Metapacket für Software komponenten wie die 
von Systemd bieten, wären diese nicht schon voneinander abhängig, und 
die Systemd Komponenten könnten dann über einfache und wohldefinierte 
Schnittstellen miteinander interagieren, und für jede Komponente ein 
Virtuelles Packet zuweisen. Das wäre der richtige weg gewesen Systemd zu 
implementieren, die interfaces wären die Selben, man hätte per default 
das ganze Systemd Packet gehabt, mit seiner ganzen Einheitlichkeit, aber 
man hatte auch nur eine einzelne Komponente davon verwenden können, oder 
eine davon ersetzen, wenn man wollte. Aber dafür ist es jetzt eben schon 
zuspät...

temp schrieb:
> Wir entwickeln eine größere
> Anwendung unter Linux, OSX und Windows. Ich übersetzte sie unter Windows
> 10 und es läuft auf allen Versionen von W7 an. Was ich unter OSX10.6
> uebersetzte geht auch mit allen nachfolgenden Varianten. Debian braucht
> fuer Squeeze, Weezy, Jessie und Stretch jeweils eigene Übersetzungen
> weil sich ständig irgendwelche Libs ändern.

Wenn man keine Ahnung hat ...

Auch bei Windows oder OS-X ändern sich Libraries. Dann kann man entweder 
statisch linken oder man baut Binaries spezifisch für ein Zielsystem.

> Und um noch etwas Schärfe in die Diskussion zu bringen: Automake und
> autoconf ist in meinen Augen eine der beschissensten Entwicklungen
> welche das Linux Umfeld zu bieten hat.

Hast du was besseres? Ach, nicht.

> Man muss sich nur mal die 3MB
> große .configure von PHP5.6 ansehen und versuchen darin was zu
> verstehen.

Wenn du mehr als 2 Hirnzellen hättest, dann würdest du dir den 
Quellcode configure.in ansehen und nicht das Compilat. Deine 
"Beschwerde" ist so ungefähr auf dem Niveau von "ich kann in dem .HEX 
File irgendwie gar nicht die Programmstruktur des AVR-C Programms 
erkennen"

Naja Linux ist halt fluch und seegen.

Wenn man nicht hauptberuflich die Möglichkeit hat an allen möglichen 
Stellen Änderungen zu verfolgen ist es quasi nicht machbar den überblick 
zu behalten.

Ich finde es auch gut, wenn man die Wahl hat und selbst entscheiden 
kann, allerdings will man auch, das eine Ditri funktioniert und der 
jenige der die Ditrie baut muss auch einen Weg gehen und kann nicht jede 
Alternative auf dem Schirm haben.

Klar nervt es gewaltig wenn nach einem Neustart das Netzwerkinterface 
nicht mehr eth0 heisst wie es immer hieß und klar dieser systemd macht 
es auch nicht nur einfacher.

Selbst Debian hat den systemd in Verwendung, obwohl es immer hieß das 
man bei debian eher konservativ sei.

Klar wenn ich mich mit meinem System wenig bis garnicht auseinader 
setzen will muss ich halt SuSe nehmen oder so.


Das es für den Softwareentwickler teilweise noch schwieriger ist als für 
den Anwender, kann ich mir durchaus vorstellen.

Ich denke mir so oft, das es schon irgendwie krass ist, wie ein 
Entwickler sourcen zu Verfügung stellt die für alle möglichen Platformen 
und System verwendbar sind. Man muss entwickeln und testen...

Das nicht jeder diese Möglichkeiten hat ist auch klar.

temp schrieb:
> Axel S. schrieb:
>> Wenn du mehr als 2 Hirnzellen hättest, dann würdest du dir den
>> Quellcode configure.in ansehen und nicht das Compilat.
>
> Wenn du nur mehr als eine Hirnzelle hättest, würdest du erkennen können,
> dass Probleme bei diesem Geraffel nicht an der configure.in gelöst
> werden können.

Ich hatte noch nie Probleme mit autoconf, die es notwendig gemacht 
hätten, das generierte configure Skript verstehen zu müssen. In 
configure.in habe ich hingegen schon sehr oft geschaut.

> Versuch mal das php
> über einen Crosscompiler für Android zu bilden

PHP für Android? OMFG. Da scheint eine $GOTTHEIT auf unserer Seite zu 
sein, wenn das nicht geht.

> Warum ist dieser Aufwand überhaupt nötig? Nur deshalb weil jeder seine
> eigene Suppe kocht. Abwärtskompatibilität ist etwas worauf bei Linux
> geschissen wird.

Das wird durch Wiederholung nicht wahrer. Selbstverständlich gibt es 
unter Linux auch ältere Versionen von Libraries. Im Gegensatz zu Windows 
sogar mit Versionsnummer und der Möglichkeit, sie parallel zu neueren 
Versionen konfliktfrei(!) installiert zu haben. "dll hell" - schon mal 
gehört?

>> Hast du was besseres? Ach, nicht.
> Das Problem ist nicht ob ich was besseres habe, sondern dass so was
> überhaupt nötig ist.

Auch das hast du also nicht verstanden. Die autotools werden nicht 
benötigt, um Software zu schreiben die auf Linux baut. Sondern um 
Software zu schreiben, die auf (nahezu) allen UNICES baut.

> Axel S. schrieb:
>> Auch bei Windows oder OS-X ändern sich Libraries. Dann kann man entweder
>> statisch linken oder man baut Binaries spezifisch für ein Zielsystem.
>
> Klar ändern sie sich, aber trotzdem laufen die Binaries die für W7 oder
> OSX10.6 gebildet werden auch auf den aktuellen Systemen. Unter Linux
> geht das nicht mal zwischen verschiedenen Ständen der selben
> Distribution, geschweige denn übergreifend.

Wie gesagt, wenn man keine Ahnung hat ...

Wahrscheinlich merkst du das bloß nicht, weil du für Windows alle 
Libraries ohnehin selber mitlieferst. Mitliefern mußt, denn eine 
Paketverwaltung gibt es da ja nicht. OS-X weiß ich nicht, das ignoriere 
ich so gut ich kann. Aber unter der Haube ist es ein BSD, so viel anders 
als Linux kann es nicht sein.

PS: und nur daß wir uns richtig verstehen: selbstverständlich ist bei 
Linux nicht alles eitel Freude und Sonnenschein. Es gibt eine Menge 
Dinge, über die man mit Recht ranten könnte. Aber das was du hier 
anführst, sind einfach nur deine Defizite.

Markus schrieb:
> Im Datenblatt ist zwar der Energieverbrauch für den aktiven Zustand,
> den idle sowie standby-Zustand angegeben, jedoch finden sich
> keinerlei Informationen, wann diese Zustände eingenommen
> werden (z.B. eine Angabe einer Zeitspanne).

Es ist heutzutage leider nicht unüblich, das in Datenblättern von 
Geräten für Endverbraucher einige Angaben fehlen. Grundsätzlich wird die 
Platte idle sein, solange das OS keine daten davon liest oder darauf 
schreibt.

> Außerdem würde ich gerne wissen, wie ich den aktuellen Zustand auslesen
> kann, um z.B. zu kontrollieren, ob die Platte tatsächlich in den
> Standby-Mode wechselt. hdparm scheidet offensichtlich aus, sind die von
> smartctl gelieferten Angaben für diese Modellreihe verläßlich?

Auch wenn die Festplatte das Setzen der Dauer des spinndown timers 
ignoriert, bedeutet dies nicht dass dies ein Problem mit hdparm wäre und 
man damit den Zustand nicht auslesen könnte. hdparm -C, hdparm -y, und 
hdparm -Y sollten theoretisch trotzdem funktionieren. Letztendlich 
sendet hd-idle auch nur den Befehl an die Disk, dass diese in den 
Standby modus gehen soll, der unterschied ist nur dass hd-idle als 
daemon selbst überwacht wie lange die Disk im idle war, und den 
spinndown timer der Festplatte nicht setzt. Ich kann dies aber gerade 
nicht überprüfen, weil ich keine WD Red Festplatte habe.

Ich denke das grössere Problem wird sein zu verhindern, dass ständige 
Lese und Schreibzugriffe die Platte wieder aus dem Standby holen. Wenn 
man sein ganzes System darauf hat, müssten z.B. ja alle ca. 5 Sekunden 
neue Einträge in Logfiles wieder auf die Festplatte geschrieben werden, 
und das würde diese wieder aus dem Standby holen. In dem fall müsste man 
solche Dateien auf z.B einen usb-stick oder ein tmpfs auslagern. Man 
könnte sich auch drastischere Massnahmen überlegen, wie z.B. das NAS 
nach einer weile ganz ausschalten und mit WakeOnLan wieder einschalten, 
etc.

Autoconf ist furchtbar. cmake hat sich einigermaßen etabliert, denke ich 
...

Markus schrieb:
> Daniel A. schrieb:
>> Das schöne an Linux, BSD und dergleichen Systeme, ist, dass man als
>> Benutzer selbst die Wahl hat, welches Programm man für eine Aufgabe
>> verwenden will, und wie man sein System konfigurieren will. Es gibt
>> keinen Weg, von dem man sagen könnte, es wäre der einzig richtige.
>
> Genau das empfinde ich als Neuling total schrecklich!

Das ist aber ein wesentlicher Punkt dessen, was Linux ausmacht. Das 
Modell, nach dem sich Linux weiterentwickelt, ist im Groben so: einer 
hat eine Idee, implementiert sie in Software und bietet sie der 
Community an, und dann setzt sich die Idee im Laufe der Zeit durch oder 
eben nicht. Im Moment hat sich systemd durchgesetzt, mit Ausnahme 
einiger kleiner Exoten setzen alle großen Distributionen darauf und aus 
administrativer Sicht ist das wesentlich besser und konsistenter als es 
SysV-Init, upstart und alle anderen mit bekannten Init-Systeme je 
gewesen sind.

Nun stoßen solche Weiterentwicklungen und Veränderungen allerdings immer 
auch auf Widerstand. Linux-Anwender sind ja keine Jubelperser, die allem 
wie die Lemminge hinterherlaufen, sondern meistens sind Linux-Anwender 
ja Menschen, die sich aus ganz individuellen Gründen, jedenfalls aber 
ganz bewußt vom üblichen Mainstream abgewandt haben -- also, um es 
salopp zu sagen, meistens irgendwo auch Quer- und manchmal sogar 
Trotzköpfe.

Aber am Ende sind es genau diese Diskussionen, die dazu führen, daß 
Linux sich stetig und konstruktiv weiterentwickelt; im Prinzip ist das 
der Streit  der Community um den richtigen Weg. Einsteiger sollten das 
ignorieren und sich, soweit möglich, lieber heraushalten. ;-)

Daniel, meine Wenigkeit, und einige andere haben hier lange und 
ausführlich über systemd und seine Alternativen diskutiert, und 
wenngleich ich seine Argumente nachvollziehen und seine Bewertung 
verstehen kann, komme ich bei meiner persönlichen Bewertung zu einem 
gänzlich anderen Ergebnis und finde systemd richtig gut, obwohl auch ich 
einige Kritikpunkte habe. Aber so ist das nunmal: eine ideale Software, 
die alle Probleme löst und an der keine Kritikpunkte gefunden werden 
können, gibt es leider nicht. Dazu sind die Themen, die systemd 
behandelt, zu komplex, und die Ziele, die mit solchen Systemen erreicht 
werden sollen, auch zu widerstrebend.

Im Moment ist es jedenfalls so, daß sich alle großen Distributoren für 
systemd entschieden haben, und vermutlich wird das auf absehbare Zeit 
auch so bleiben. Wer das nicht will, wird mit gewissen Nachteilen leben 
müssen. Aber andererseits sind Linux-Anwender diese Art von Entscheidung 
gewöhnt: jeder von uns hat ganz bewußt die Abwägung getroffen, sich vom 
üblichen Mainstream abzuwenden und dafür zwar einerseits einige 
Nachteile in Kauf nehmen zu müssen, dafür aber andererseits und an 
anderer Stelle wiederum unsere Vorteile davon zu genießen, die uns 
wichtiger erscheinen.

So, und um jetzt ganz am Ende Deine Frage zu beantworten: nimm systemd, 
das ist der Default Deines Distributors und für Dich als Einsteiger 
sicher der einfachste Weg. Du hast gerade leider das Pech, daß der 
größte Teil der Linux-Welt sich für eine neue Init-Software entschieden 
hat und es darum gleichzeitig eine Menge Material und 
Online-Dokumentation sowohl für die alten als auch für das neue System 
gibt. Am Besten läßt Du die meisten Online-Quellen links liegen und 
hälst Dich strikt an die Dokumentation Deiner Distribution 
beziehungsweise an die der Basis-Distribution, von welcher Deine 
Distribution abgeleitet ist.

Ein paar Links zu Dokumentationen für Debian, auf dem Ubuntu basiert:

http://debiananwenderhandbuch.de/
https://debian-handbook.info/browse/de-DE/stable/

und wenn Du lieber ein Buch haben möchtest:

https://kofler.info/buecher/linux/

Ansonsten bringen Dein Betriebssystem und seine Softwarepaket jeweils 
ihre eigene Dokumentation mit, die Du unter /usr/share/doc/<paketname> 
finden kannst, sowie Manpages oder eigene Dokumentationspakete 
<paketname>-doc. Darin ist jeweils der Weg dokumentiert, den Dein 
Distributor vorsieht -- und als Einsteiger solltest Du Dich lieber daran 
halten. ;-)

Sheeva P. schrieb:
> Linux-Anwender sind ja keine Jubelperser, die allem
> wie die Lemminge hinterherlaufen,

NB: Welche Gründe auch immer die sprichwörtlichen Lemminge haben mögen, 
Jubelperser haben andere. Und teurere. ;-)

"Der Begriff ist als abwertende Bezeichnung für (üblicherweise 
gewaltlose) Claqueure, also bezahlte Applaudierer, in die deutsche 
Sprache eingegangen."
https://de.wikipedia.org/wiki/Jubelperser

A. K. schrieb:
> Sheeva P. schrieb:
>> Linux-Anwender sind ja keine Jubelperser, die allem
>> wie die Lemminge hinterherlaufen,
>
> NB: Welche Gründe auch immer die sprichwörtlichen Lemminge haben mögen,
> Jubelperser haben andere.

Da meine Kenntnisse hinsichtlich der Tribus Lemmini begrenzt sind, kann 
ich pekuniäre Motive bei Lemmingen nicht ausschließen. Sofern Du da 
andere, im Idealfall sogar belastbare Erkenntnisse hast, möchte ich Dich 
bitten, Deine Expertise mit mir zu teilen. Lieben Dank.

Sheeva P. schrieb:
> andere, im Idealfall sogar belastbare Erkenntnisse hast, möchte ich Dich
> bitten, Deine Expertise mit mir zu teilen. Lieben Dank.

Lebensraum im Osten, Süden, Westen und Norden. ;-)
http://www.zeit.de/stimmts/1997/1997_38_stimmts

Sven B. schrieb:
> Autoconf ist furchtbar. cmake hat sich einigermaßen etabliert, denke ich

cmake ist nur anders schlimm. Wir haben unser Build-System auch auf 
cmake migriert. Migrieren müssen, weil Windoze anders nicht sinnvoll zu 
handeln war (laut Aussage des zuständigen Entwicklers). Ich kann am Ende 
mit beidem leben. Mit cmake aber nur, weil ich das im Zweifelsfall an 
den Kollegen delegiere, der uns das eingebrockt hat. Wenn ich die Wahl 
habe, nehme ich autoconf. Andererseits weigere ich mich auch 
kategorisch, Windoze in eigenen Projekten überhaupt zu unterstützen. 
Insofern habe ich auch gar keinen Bedarf an cmakes besonderen 
Fähigkeiten.

Axel S. schrieb:
> Andererseits weigere ich mich auch
> kategorisch, Windoze in eigenen Projekten überhaupt zu unterstützen.
> Insofern habe ich auch gar keinen Bedarf an cmakes besonderen
> Fähigkeiten.

Jo kann man natürlich so machen, ist halt nur mäßig pragmatisch und 
mäßig zielführend.

Axel S. schrieb:
> Selbstverständlich gibt es
> unter Linux auch ältere Versionen von Libraries. Im Gegensatz zu Windows
> sogar mit Versionsnummer und der Möglichkeit, sie parallel zu neueren
> Versionen konfliktfrei(!) installiert zu haben. "dll hell" - schon mal
> gehört?

Kamellen aus dem letzten Jahrtausend. Die DLL-Hölle ist seit W2K 
Geschichte. Und verschiedene Versionen von Runtimes á la .NET und 
VisualC++ laufen auch problemlos nebeneinander.