Hallo, ich möchte mittels des Programms hdparm meine Festplatten nach einer bestimmten Zeit in den Standby-Modus versetzen. Auf https://www.foxplex.com/sites/festplatten-standby-im-leerlauf-mit-hdparm-und-hd-idle/ wird hierzu der Daemon in den Autostart verlinkt ("update-rc.d"). Auf https://withblue.ink/2016/07/15/what-i-learnt-from-using-wd-red-disks-to-build-a-home-nas.html wird zum Autostart systemd genutzt. Der 'Flamewar' zwischen beiden Systemen ist mir egal, 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) ? Wenn der komplette Rechner in den Ruhezustand versetzt wird (z.B. Suspend-to-Ram), steht der Dienst nach Aufwecken bei beiden Methoden wieder zur Verfügung?
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Stimmt nicht, als systemd Nutzer kann man viel fundierter auf Lennart schimpfen ;-)
Base64 U. schrieb: > Nimm doch einfach die Version, welche von deiner Linux Distro > unterstützt wird, oder besser gesagt, default ist. Ja, so hätte ich es gemacht. Le X. schrieb: > Nachteil: > als systemd-Nutzer kansnt du nicht so schön über den pösen Herrn > Poettering schimpfen. 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.
> ein Windows-Benutzer
hat viele svchost.exe, die noch viel weniger konfigurierbar sind
als das Poetteringsche Machwerk.
Verwirren die dich nicht?
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. Es gibt > keinen Weg, von dem man sagen könnte, es wäre der einzig richtige. Genau das empfinde ich als Neuling total schrecklich! Beispiele: ========== Powermanagement scheint bei Linux irgendwie noch nicht standardmäßig angekommen zu sein (okay, ist etwas unfair, weil ich für mein NAS die Server-Version von Ubuntu installiert habe, also kein Klickibunti). - 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. - Laptop Mode Tools oder TLP fürs allgemeine Powermanagement? Tun sich beide wohl nicht soviel. - automatisch nach gewisser Zeit in den Standby-Mode wechseln (z.B. Suspend-to-Ram oder Suspend-to-Disk): Dazu findet sich im Netz mehr als nur ein Skript, hoffentlich funktioniert zumindest eins davon bei mir, habe ich noch nicht ausprobiert. 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. Apropos Ubuntu Server 16.04 LTS: Für die Installation habe ich am Sonntag 7 Stunden benötigt. Ich hatte das ISO-File auf einen USB-Stick kopiert und davon gebootet, allerdings fand das Installationsprogramm kein CD-Rom-Laufwerk. Klar, gibt schließlich keins, nur den USB-Stick. Mehrmaliges Anfertigen eines bootfähigen Sticks mit der ISO-Datei mit den unterschiedlichsten Programmen (Rufus, LinuxLive USB Creator, unetbootin...) brachten keine Abhilfe. Im Internet gibt es die wildesten Vorschläge wie man die ISO-Datei als CD-Rom mounten solle, irgendwann fand ich den Tip, den USB-Stick an einen anderen USB-Port anzuschließen und nochmal nach dem CD-Rom suchen zu lassen. Eureka, das funktionierte tatsächlich! Am besten dann der Kommentar eines Users, daß dieser Bug schon seit einigen Versionen von Ubuntu-Server bestehen würde. Na super!
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/
:
Bearbeitet durch User
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...
Icke ®. schrieb: > 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. Da kann ich dir nur vollkommen Recht geben. 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. So kann das nie was werden. Die Pflege der Versionen braucht unter Linux definitiv die meiste Zeit. 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. Man muss sich nur mal die 3MB große .configure von PHP5.6 ansehen und versuchen darin was zu verstehen.
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"
Daniel A. schrieb: > 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. Vielen Dank für die ausführliche Antwort. Um kurz bei diesem Thema zu bleiben: Außer einem Datenblatt kann ich auf der Website von Western Digital keine Informationen über die Red-Reihe der internen Festplatten finden. 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). 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? >Für Serveranwendungen ist es eben keineswegs Standard, Festplatten oder > den ganzen Server in Standby zu versetzen, sondern dein spezifischer > use-case. Der 'use-case' ist ganz trivial ein NAS-Server für den Heimgebrauch. Und da fallen die Energiekosten halt ins Gewicht, insbesondere bei der installierten 8 TB-Version der Red-Reihe. Im aktiven Zustand liegt der Verbrauch nämlich lt. Datenblatt bei über 5 W :-(
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.
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. 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" 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. Da hinkt dein HEX Vergleich gewaltig. Versuch mal das php über einen Crosscompiler für Android zu bilden, danach reden wir weiter. 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. Und wen bringt es einen Vorteil von jeder Sache 20 Implementierungen zu haben? 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. Axel S. schrieb: > Hast du was besseres? Ach, nicht. Das Problem ist nicht ob ich was besseres habe, sondern dass so was überhaupt nötig ist. Und damit sind wir wieder bei der Ausgangsaussage: Daniel A. schrieb: > Wo Vielfalt ist, kann keine Einheitlichkeit sein
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.
:
Bearbeitet durch User
temp schrieb: > Unter Linux > geht das nicht mal zwischen verschiedenen Ständen der selben > Distribution, geschweige denn übergreifend. Ich muss da Axel zustimmen. Es geht, sogar einigermaßen transparent und einfach. Es gibt halt mehrere Anforderungen wenn du ein Paket mit dynamischen Libs für mehrere Distributionsversionen bauen willst. Dazu musst du halt einfach sauber ein debian paket erstellen, in dem definiert man halt dann die abhängigkeiten. Fertig aus, dann werden die automatisch mitinstalliert. Einfacher gehts ja wohl nicht. Wenn du dir das nicht antun willst (wie auch schon gesagt) -> statisch linken. Fertig, dann hast du u.U. beim Entwickeln mehr Arbeit, aber beim deployment einfach gar keine Abhängigkeiten mehr.
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
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.