Hm, ich weiß garnicht, wie ich's anfangen soll... In fünf Minuten bin ich eh runtergevotet...
Ich finde die Poettering-Tools eigentlich ganz gelungen. Auch systemd gefällt mir gut. Ich habe den Eindruck, dass es viele Dinge mal solide gelöst hat, die vorher eher zusammengeschustert waren. Das Zusammengeschusterte war weder pflegeleicht, noch skalierte es gut, noch hatte es eine ausgearbeitete Fehlerbehandlung.
Dass das so ein riesiger Block ist, der dann auch direkt mal noch cron und 15 andere Tools ersetzen will, naja, das erscheint mir auch nicht direkt ideal. Möglicherweise gibt es aber technische Gründe, die für eine so enge Integration an der Stelle sprechen.
Vielleicht sieht den Kommentar jemand vor'm Downvoting, der diese systemd-Phobie mal technisch motivieren kann.
Genau wie der Kernel ist auch systemd durchaus zum Teil modular.
Der Kernel kann größer oder kleiner gebaut werden, je nach benötigtem (Grund-)Funktionsumfang. Das ist für systemd auch möglich, nicht alle Funktionen müssen benutzt werden.
Der Kernel lädt viele Module nur nach, wenn sie benötigt werden und entlädt sie bei Nichtgebrauch auch wieder. Das ist bei systemd auch so, es werden nur die Services gestartet, die auch zur Laufzeit benötigt werden.
Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Was das digitale Wutbürgertum angeht, hast Du allerdings komplett recht.
> Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Der Grund dafür liegt darin, dass diese Tools alle von Systemd abhängig sind, selbst wenn dies nicht nötig gewesen wäre. Eine Ausmahne bildet dabei meines Wissens nur udev. Für udev und logind gibt es dann noch die abgekoppelten Ersätze eudev und elogind mit anderen Maintainern. Für sämtliche anderen Tools gibt es keine.
Die Library libsystemd0 besitzt zwar einen shim, dieser hat aber systemd als build dependency und generiert eine Library die absolut nichts tut. Das heisst, ein Programm das libsystemd Funktionen nutzt und mit dem shim genutzt wird, funktioniert höchstens noch teilweise. wird z.B. sd_journal_print fürs logging verwendet, gibt es keine Logs mehr.
Das Hauptproblem mit libsystemd ist aber, dass unterschiedliche APIs die nichts miteinander zutun haben in der selben library sind. Dies hat zur folge, dass auf Distributionen mit Binarypacketen nicht z.B. nur die sd_journal Funktionen fürs Logging von einem binary Packet ersetzt werden kann, sondern auch alle anderen Funktionen von einer Library ersetzt werden müssen, was unpraktikabel ist.
Das Problem damit, dass alle Tools voneinander abhängig sind ist, dass Programme, die von den Tools abhängen, ohne Systemd dann nicht mehr funktionieren. Um ein paar prominente Beispiele davon zu nennen: * Snap funktioniert nicht auf nicht systemd Systemen, da es die CGroup und Namespace abstraktionen von Systemd nutzt. * iio-sensor-proxy, dieses Programm ist notwendig, um den Bildschirm z.B. eines Tablets automatisch mitdrehen lassen zu können. * Diverse Desktop Environments und Login Manager, insbesondere Gnome. Bei diesen haben Nicht-Systemd Distributionen haben viel mühe damit, die Abhängigkeiten zu entfernen. Einige versuchen es gar nicht mehr erst.
Ich weise ausserdem schon im vornherein darauf hin, dass diese Abhängigkeiten der Tools zu systemd bei der Entwicklung in keinster weise notwendig gewesen wären. Systemd hätte seine Tools nutzen können, ohne das die Tools auf Systemd angewiesen gewesen wären. Es bietet auch keine bessere Integration in Systemd, die Userinterfaces hätten dafür in keinster weise geändert werden müssen.
Digitales Wutbürgertum? Das Wort beschreibt überhaupt nicht den Stand der Dinge. Warum sind bitte Alle, die systemd ablehnen auf einmal in einer Schublade? Ich habe beispielsweise nicht einmal im Entferntesten Herrn Poettering persönlich attackiert oder verbal sonst irgendwie abgewertet. Die Kritik bezieht sich einzig darauf, dass meiner Meinung nach Distributionen Vielfalt anbieten sollten. Schön, dass systemd gibt. Aber ebenso schön, dass es andere INIT-Systeme wie OpenRC, S6 oder runit gibt. OpenRC beispielsweise finde ich klasse und setze das zusammen mit Hyperbola auf meinem Desktop-System ein. Und nur weil ich systemd aus verschiedensten Gründe ablehne, bin ich ein "digitaler Wutbürger"?
Warum schreibt ihr hier überhaupt dann, wenn systemd für euch so passt? Was kümmert euch dann eine Distribution, die eben auf das Ganze verzichten möchte?
Es war schon immer so, dass eine Distribution meist nur ein einziges Init-System angeboten hatte. Ausnahme sind Source-basierte Distributionen wie Gentoo, wo man ohnehin alles selbst konfigurieren kann.
Der Begriff "Digitales Wutbürgertum" kommt wohl daher, dass einige systemd-Gegner plötzlich was von einer "Init System Freedom" erzählen und die systemd-Entwickler als brutale Unterdrücker darstellen.
Das macht natürlich keinen Sinn, Devuan bietet z.B kein systemd an, ist aber deswegen nicht unterdrückerisch. Jede Distribution kann ja selbst entscheiden, welche Software sie paketieren möchte. Wem das nicht gefällt, der nimmt eine andere Distro, gibt ja genug.
Vielleicht hat Debian da auch falsche Erwartungen geschürt, z.B als sie neben Linux noch kFreeBSD und Hurd anbieten wollten und dann dachten die Leute das müsse beim Init System genauso sein. Ich halte es für sinnvoller, sich auf eine Lösung zu beschränken, zumindest bei so grundlegenden Komponenten, sonst hat man einen Haufen Arbeit und am Ende funktioniert es sowieso nicht zufriedenstellend.
Von Bernhard Vogel am Di, 12. Juni 2018 um 11:20 #
Es spricht nichts gegen Systemd. Es deckt aber nicht jeden Anwendungsfall ab. Will man z.B. Debian Side-Loaded betreiben (z.B. mit Android-Init) dann funktioniert das nicht gut, weil das Systemd-Init und das Android-Init nicht miteinander "können". Und genau darum ist es gut, wenn es Auswahl gibt.
Ich finde die Poettering-Tools eigentlich ganz gelungen.
Ich finde es etwas abwegig, deshalb Leuten, welche die Tools nicht ganz gelungen finden, systemd-Phobie vorzuwerfen. Entschuldigung, aber warum kann man nicht einfach Leuten mit anderer Meinung eine Alternativlösung gönnen? Aus diesem Grund gebührt deinem Beitrag eigentlich tatsächlich ein Downvoting.
Na jetzt tu mal nicht so, als hätte ich jemanden sonstwie beleidigt. Erstmal ist doch eine Phobie auch recht wertfrei, oder? Es ist einfach nur eine Ablehnung gegen etwas.
Aber es gibt auch Menschen, die es sich zur Überlebensstrategie gemacht haben, sich in jeder Situation nur über den Gesprächsmodus, oder die Umstände, oder sonstwas Nebensächliches zu echauffieren. Das wirkt verständig, zurrt einen aber nirgendwo fest. Das bietet immer genügend rhetorische Beinfreiheit.
"Erstmal ist doch eine Phobie auch recht wertfrei, oder? Es ist einfach nur eine Ablehnung gegen etwas."
Wertfrei ist der Begriff "Phobie" ganz gewiss nicht.
Eine Aversion bezeichnet eine Ablehnung.
Eine Phobie bezeichnet eine krankhafte, panische Angst, Schrecken, Furcht vor etwas; eine Angststörung.
Wir merken hier die Wirkung medialer Gehirnwäsche, die auch andere Begriffe wie z.B. "Toleranz" in "Akzeptanz" ummünzt bzw. deren völlig entgegengesetzte Bedeutungen gleichsetzt.
Worte haben Bedeutungen. Gerade die deutsche Sprache lässt es niemals zu, aus einem Löffel eine Gabel zu machen. Politik, Medien und andere Wahnsinnige versuchen jedoch, genau dies zu tun.
Haben die Social Justice Warrior schon Sommerloch?
Ich glaube, den Aspekt des 'krankhaften' hat das Wort 'Phobie' sehr oft, ist aber optional. Ansonsten ist es eine ausgeprägte Angst/Ablehnung.
Wenn du jetzt erwartest, dass ich mich für das Wort 'Phobie' entschuldige, müsstest du länger warten. Ich sehe nicht, wo man sich davon ernsthaft auf den Schlips getreten fühlen kann, außer man sucht danach. Weiterhin, wenn du mal in Foren die Diskussionen um systemd überfliegst, weißt du auch, dass man da durchaus Angststörungen und krankhafte Züge reindeuten _könnte_, wenn man das will.
Ansonsten geht's dir aber noch gut, ja? Mir zu unterstellen, Opfer medialer Gehirnwäsche zu sein, weil ich es mir erlaubt habe, das Wort 'Phobie' zu benutzen, ist reichlich albern, oder?
Hmm, ich finde die Begrifflichkeit "Social Justice Warrior" definitiv unpassend an dieser Stelle. Das was der Teilnehmer zuvor geschrieben hat sehe ich eher aus einer ganz anderen Richtung kommend. Vorzugsweise erfolgreich vom Thema ablenken und dann eine wie auch immer geartete Agenda platzieren. Allein schon, dass Begrifflichkeiten "Politik" und "Medien" fallen. Was kommt als Nächstes? "Lügenpresse"? Vor allem, weil die Begrifflichkeit "Angstphobie" fällt. Haben wir da einen "besorgten Bürger"? Bitte weitergehen, Herr Lustig. Danke.
Zum Thema: Neutrale Begrifflichkeit. "Phobie" ist doch schon sehr stark: Ich bin definitiv auch kein riesiger Fan von systemd und freue mich über Alternativen wie OpenRC beispielsweise. Ich würde da aber eher die Begrifflichkeit "Abneigung aufgrund anderer Präferenzen" bevorzugen. Eine freie Wahl des INIT-Systems sollte da auch unterstützen und systemd vereint meines Erachtens weit zu viele Komponenten und Schnittstellen.
Ohne ein Downvoting vorzunehmen teile ich Deine Meinung nicht. Ich habe die Erfahung gemacht, daß systemd teils sehr unflexibel ist.
Beispiel aus dem wirklichen Leben:
Auf der Textkonsole schätze ich im Nichtgrafikmodus (Multiuser nach systemd-Ausdrucksweise) den gpm. Damit kann man bequem copy&paste machen. Zugegebenermaßen Ansichtssache. Nun kann man die Serivedatei für gpm schön konfigurieren, daß er nur im multiusermodus startet. Jetzt kommt das große Aber: Der grafische Modus braucht den multiusermodus. Und schon ist der gpm im grafischen Modus gestartet. Ich habe auch noch keine Möglichkeit entdeckt, im grafischen Modus den Start des gpm zu verhindern. Gut ich könnte einen gpm_stop service einrichten, der im graphical Mode den gpm herunterfährt. Dann wird es aber absurd; wir wären dann faktisch wieder beim sysvinit, der ja zumindest von den Entwicklern arrogant belächelt wird.
Für mich ist eigentlich aus diesem Grunde der systemd ein nogo. Nicht wegen gpm; gpm ist für mich nur ein Symptom der Unausgegorenheit von systemd. Sowas kann ja auch andere Services betreffen, die mir derzeit nicht bekannt sind und zerstört bei mir deshalb ein gewisses "Vertrauen".
Danke für die sachliche Erklärung. Verstehe ich (auch wenn's wohl eher ein exotischer Fall ist).
Und mit "Conflicts" und "graphical.target" kann man nichts erreichen? Was macht denn gpm im Grafikmodus? Passiert da was Schlimmes, oder stoppt es einfach irgendwie von selbst?
Schädlich ist gpm meistens nicht, es gibt auch Fälle, in denen es nicht harmoniert mit dem XServer. Aber auch, falles es nicht schädlich ist, sehe ich in solchen erwähnten Verhaltensweisen einen Rückschritt oder auch sogar eine Tendenz zur Primitivierung. Und wie gesagt, nicht zu sehr am Beispiel gpm aufhängen, es werden sicherlich auch andere Konstellationen gleichartige Probleme verursachen.
Und das Themat conflicts kenne ich noch nicht. Das könnte ein Anknüpfungspunkt sein.
Von name_schon_vergeben am Di, 12. Juni 2018 um 13:05 #
Ist super simpel zu implementieren. systemd ist in dieser Sicht sogar sehr viel flexibler als das alte sysvinit, da es nicht nur 6 fixe runlevels gibt sondern du dir sogenannte targets anlegen kannst wie du möchtest (targets entsprechen ganz grob den alten runlevels)
In einem Fall würde ich so vorgehen: Leg ein console.target an, dass multi-user.target reinzieht: [Unit] Description=Console Requires=multi-user.target After=multi-user.target rescue.service
In deinem gpm.service machst du nun [Install] WantedBy=console.target
Damit hakt sich gpm service in das console.target beim boot ein und nicht mehr in multi-user.target.
Beim booten kannst du das neue target auswählen, indem du (siehe man kernel-command-line) systemd.unit=console.target and die kernel optionen anwängst Wenn du das öfters brauchst, mach dir in grub einen menu eintrag.
Das hört sich auch interessant an. Ich habe im Moment nicht das unitfile für gpm da. Aber ich muß dafür unter /etc/systemd/system eine eigene gpm.unit einrichten und noch die Konsole. Was ist da flexibel dran; für solch einen schritt ganz schöner Aufwand. Unter sysvinit wird in der ursprünglichsten Form im betreffenden Runlevel der Link auf /etc/init.d/gpm gelöscht. Ansonsten ging es auch mit chkconfig oder insserv.
Da kommt noch ein Kritikpunkt hinu: Unter systemd ist alles (unnötigerweise) aufwändiger als unter sysvinit. Also ist dieses Konzept nicht so effizient. Ich kann den Gedanken einfach nicht verdrängen: Ich fühle mich an Windows erinnert, wo viele aufgeblasene Schritte nötig sind, um ein simples Ziel zu erreichen. Da ich auch BSD-Systeme administriere, sehe ich zu systemd umsomehr die Gegensätze.
Von name_schon_vergeben am Di, 12. Juni 2018 um 13:34 #
schon mal versucht ein sysv init skript "korrekt" zu schreiben. Das nenne ich aufgeblasen, aufwändig und kompliziert. Im vergleich dazu sind .service files eine wahre freude
Das hört sich auch interessant an. Ich habe im Moment nicht das unitfile für gpm da. Aber ich muß dafür unter /etc/systemd/system eine eigene gpm.unit einrichten
Nein, Du legst einfach ein Drop-In an und änderst nur das was du ändern must. Das übersteht auch das nächste Dist-Upgrade.
1. Was für sysvinit das runlevel ist, ist für systemd das target. Und die sind sich ähnlicher als viele meinen. Working with systemd Targets
2. Nicht systemd sondern die "[Install]"-Section des Service-Unit entscheidet in welchem Target der Dienst aktiviert/installiert wird. Und dieses Service-Unit kommt, genau wie bei den Initscripten unter sysvinit, nicht vom verwendeten init sondern vom jeweiligen Softwarepaket. Kritik ist ja schön und gut sollte aber korrekt Adressiert werden.
3. Willst du die Standardvorgaben eines vom Paketmanager installierten Service-Unit verändern ist das absolut problemlos möglich und das auch noch, ganz im Gegensatz zu den Initscripten, auf eine Art und Weise die ein Update durch eben diesen Paketmanager überlebt. Modifying Existing Unit Files
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 13. Jun 2018 um 10:08.
Mag sein, dass es Dinge gibt, die unter systemd einfacher und robuster geworden sind.
Für mich sind jedoch Dinge, die früher einfach waren, schwierig geworden.
Z.B ein automatischer login in Textmodus war früher einfach, da musste man nur einen einzelnen Eintrag in der inittab ändern. Unter systemd muss man erst mal viel lesen und sich dann irgend so eine unit-Datei selbst schnitzen.
Auf Desktop-Systemen laufen mir heutzutage zu viele Dienste, die ich nicht brauche und aus Sicherheitsgründen und zwecks Kompexitätsreduktion abschalten möchte. Einige möchte ich nur punktuell einschalten, wenn ich sie tatsächlich brauche (z.B. wlan).
Unter SystemV war das sehr einfach; da brauchte man nur ein paar symlinks unter /etc/rc3.d bzw. /etc/rc3.d löschen, und die Reihenfolge, in der die Dienste gestartet wurden, war durch die Dateinamen einfachst erkennbar.
Unter Slackware ist es auch sehr einfach, da ändert man die Startskripte auf "nicht ausführbar", wenn man den Dienst loswerden möchte. Die Skripte sind bewusst einfach gehalten, damit man sie auch versteht, wenn man kein bash-Guru ist.
Unter systemd hingegen laufen 70 Dienste mit nur zum Teil selbsterklärenden Namen, eine Hierachie ist mit den Tools, die ich ausprobiert habe, nicht so recht erkennbar, und ich weiss vielfach nicht mehr, wozu die Dienste gut sind und was ich anrichte, wenn ich die abschalte.
Das mag ja alles auf einem Server sinnvoll sein; auf einem Desktopsystem scheint mir das overkill. Alles nur, um ein paar Sekunden boot-Zeit zu sparen.
Will ich nicht, ist mir zu kompliziert, also nehme ich 'ne Distro, die es mir einfacher macht.
Sorry aber allein schon durch die eventbasierte Aktivierung (beispielsweise startet cups erst dann wenn es gebraucht/angesprochen wird) von Diensten welche systemd bietet ist ja eher das Gegenteil der Fall, außer die Distribution verteilt standardmäßig Konfigurationen wo das nicht richtig umgesetzt wird. Und auch das Handling von Abhängigkeiten hat systemd um einiges besser im Griff, sogar so gut das beim ersten Wechsel oft sogar Fehler auffallen die vorher unter sysvinit kaum einer bemerkte.
systemd ist in bestimmten use cases sinnvoll (z.B. auf dem Desktop), in anderen jedoch nicht.
systemd ist möglicherweise einfach(er) zu konfigurieren, das wird jedoch mit technischer Komplexität erkauft. Und Komplexität ist der Feind der Sicherheit. Dass KISS Prinzip und "do one thing and do it well" ist aktueller denn je. Auf einem Server sollte aus Sicherheitsgründen immer das Minimalprinzip gelten - und das ist mit systemd nicht erreichbar.
Von daher bin ich froh, dass es Distros wie z.B. Devuan, Slackware und Alpine für Server gibt - sonst müsste ich wohl auf *BSD umsteigen.
Ich kann BSD auf Servern nur empfehlen. Gut, die Lernkurve ist etwas steiler und die Konfigurationsdateien liegen möglicherweise an anderen Stellen, dennoch geizt BSD nicht an Stabilität. Im Gegenteil, nach meinen Erfahrungen ist BSD stabiler als Linux, was aber auch an meiner Konfiguration liegen könnte.
Das mit der Stabilität liegt wohl nicht an Deiner Konfiguration.
Einmal sind die BSD-Varianten ohnehin berühmt für ihre legendäre Stabilität "rockstable", zum anderen sind sie in Sachen Konfiguration von Haus aus (KISS- keep it small and simple) wesentlich überschaubarer.
Privat wäre ich schon längst bei einem der drei BSDs, wenn es nicht Probleme im ACPI-Umfeld (speziell Resume) gäbe.
Ja, die Stabilität und der geringe Wartungsauswand sowie die Übersichtlichkeit sind die Hauptgründe warum ich auf Servern (und in speziellen Fällen auch Desktops) auf BDS setze.
Welche ACPI-Probleme gibt bzw. gab es denn bei dir? Und welche BSD-Varianten hast bzw. hattest du denn probiert?
ACPI ist bei BSD generell ein noch groß vorhandenes Problem, es ist aber in den letzten 1 bis 2 Jahren deutlich besser geworden.
Getestet habe ich FreeBSd, NetBSD und OpenBSD. Auf FreeBSD und NetBSD funktionierte zwar das Resume, nur der Bildschirm kam nicht mehr zurück. Die Rechner waren ein Thinkpad 410 und 420 bzw. ein Medion vom Sommer 2016. Der genau Bezeichnung habe ich im Moment nicht zur Hand. Multimedia bspw. funktionierte einwandfrei.
Bei OpenBSD funktioniert Resume nach einem Suspend auf beiden Thinkpads einwandfrei, nach einem Hibernate wird noch das Dateisystem gemounted, danach wird der Rechner wieder rebootet. Es kann aber auch daran liegen, daß ich im Monent von 6.3 testeshalber auf current gegangen bin. Ansonsten läuft das System aber super. Ich benutze den Rechner bei der Arbeit als privaten Gastrechner.
Aber wie gesagt, der Medionrechner, als mein privater Universaldesktop hat die erwähnten Problme. Und jedes mal alles neu zu starten, ist mir ehrlich gesagt zu aufwändig.
Von Verfluchtnochmal-05995bd7b am Sa, 16. Juni 2018 um 14:56 #
Und wieder der unreflektierte Unsinn systemd wäre vorwiegend am Desktop sinnvoll - Das genau Gegenteil ist der Fall
Ändere doch mal in init-scripts die Reihenfolge/Abhängigkeiten ohne die Files der Distribution anzufassen - /etc/systemd/system/servicename.service.d/ schmeiss so viele dropins wie du lustig bist (um es übersichtlich zu halten) rein und schon stehen dir so gut wie alle Optionen von Abhängigkeiten über User/Group bis hin zu Namespaces, PrivateTemp, Seccomp, ProtectSystem, ReadwritePaths, ReadOnlyPaths, Restart etc. in einem Umfang zur Verfügung wo du mit einem Shellscript wochenlang rumbasteln kannst und zuverlässig ist es dann immer noch nicht
Wenn du das da alles in /etc/init.d/httpd in vollem Umfang und *stabil* auch über viele Service-Restarts umgesetzt hast darfst du wieder kommen und was von wegen systemd ist für Desktops erzählen
Fantastisch, wenn du systemd gerne benutzen möchtest. Du wirst deine Gründe dafür haben. Viele (fast alle) Distributionen unterstützen es, so dass du nur eine auswählen und installieren musst. Fertig.
Ich beispielsweise bevorzuge sysvinit und habe meine Gründe dafür. Andere bevorzugen openrc und werden auch ihre Gründe dafür haben. Und so freue ich mich, dass es eine Distribution gibt, die es mir erlaubt, mit sysvinit zu arbeiten.
Keine Ahnung, was es da zu diskutieren gibt. Über die technischen Unterschiede der init-Systeme gibt es viele Artikel im Netz, einfach mal suchen.
Schön, dass es unter Linux noch die Möglichkeit gibt und man nicht unbedingt ein windwos-like systemd benutzen muss. Wobei Windows fasst schon stabiler läuft!!
Ich bin im Moment am Void-linux dran und habe es auf einem Uralt Lenovo X61s mit minimal Ausstattung installiert.
Ein bisschen anders als Deb, es erfordert umlernen, aber "xbps" steckt "apt-get" locker in die Tasche und die alte Kiste rennt wie Sau vorm Schlachthof. Überholt meinen modernen Rechner mit Deb +systemd mit SSD und allem Schnick Schnak in jeder Lage haushoch. Und die Stabilität ist das was ich von Linux gewohnt war, bevor es Anno Domini 2014 infiziert wurde.
Keine Ahnung, was es da zu diskutieren gibt. Über die technischen Unterschiede der init-Systeme gibt es viele Artikel im Netz, einfach mal suchen.
Weil die meisten Diskussionen eben keine technischen sondern ideologische Diskussionen sind und dabei werden immer wieder diverse Grenzen überschritten.
Mir persönlich ist es eigentlich ziemlich egal was andere benutzen, natürlich habe ich eine Meinung dazu aber das ist völlig normal. Nicht mehr egal ist mir aber wenn diese selbsternannten "Veteran UNIX Admins" und ihre ganze Anhängerschaft mit Beleidigungen, Verleumdungen und Lügen gegen systemd und jeden der das nutzt (oder sich auch nur neutral damit auseinander setzt) schießen!
Immer wieder werden solche Sachen wie "Windowslike" (Windows könnte sich glück schätzen wenn so es etwas wie systemd hätte), monolithischer BLOB (systemd ist weit modularer als viele Behaupten und fast gleich groß/komplex wie der Komponentenverbund der stattdessen immer wieder eingesetzt wurde) und sonstiger Bullshit in alle greifbaren Foren gekotzt. Immer wieder werden Leute die öffentlich zugeben das sie systemd mögen oder das es sich positiv auf ihren Umgang mit Linux ausgewirkt hat teilweise sehr persönlich angegriffen und eine Linux feindliche Gesinnung unterstellt. Immer wieder werden Forderungen geäußert das Developer und Paketverwalter zwingend beide Welten unterstützen sollten ganz egal ob das sinnvoll Umsetzbar oder überhaupt möglich ist.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 14. Jun 2018 um 11:12.
Finde ich wirklich seltsam, ich erlebe das genau zu 100% umgekehrt. Egal wo ich lese. Kaum wird ein Devuan vorgestellt, sind 90% systemd Anhänger da, denen ja Devuan egal sein kann. Von Devuan Anhänger lese ich so gut wie nichts.
Auf heise.de noch schlimmer.
Im IRC #devuan sind von Anfang an ca. 70% systemd Anhänger drin und machen genau das, was du den Usern vorwirfst, die halt warum auch immer kein systemd mögen.
Zum Glück kann das jeder selber überprüfen, sonst glaubt das noch jemand, was du hier verbreitest.
Geht euch doch einfach mal aus den Weg, ist einfach nur nervig immer wieder das selbe zu lesen.
Ich möchte hier jedenfalls nur was über Devuan lesen, weil es genau darum in dem Artikel geht.
Von Verfluchtnochmal_5987109 am Fr, 15. Juni 2018 um 10:55 #
Tickst du eigentlich noch richtig von wegen "sonst glaubt noch jemand was du hier verbreitest"? Als Fedora User habe ich mich schon ernsthaft mit systemd beschäftigt da war Debian noch im Dornröschenschlaf und ihr paar armen irren die ihr euch in die IT verlaufen habt aber mit Änderungen nicht umgehen könnt noch gar nicht getriggert
Ohne die User die euch aufzeigen wollen dass ihr schlichtweg nur faul seid und euch mit Dingen nicht auseinandersetzen wollt wärt ihr ziemlich einsam in euren Foren weil ihr seid zwar laut aber trotzdem eine irrelevante Minderheit
The tardfuck IAN murdock who let this plague happen to debian (used to be my favourite operating system) is let's just say:
"I'm not glad he's dead, but I'm glad he's gone"
Systemd and pulseaudio have to be shutdown for good, focus your time and energy on something more useful like inventing a 50% efficient solar panel or do cancer research instead of PRODUCING THIS FUCKING CANCER.
Systemd have to be discontined and removed from all the distributions so things can go back to normal as they used to be.
Anybody knows a good shitD free mediacenter by the way with KODI for Raspberry PI 2, 3?
Nicht das ich solche Aktionen wie du sie beschreibst gut heißen würde, wenn es denn war ist, aber:
Die ganzen anti-systemd'ler haben das mit ihren eigenem Verhalten ja überhaupt erst herauf beschworen. Von Anfang an wurde jeder der sich auch nur ansatzweise positiv zu systemd geäußert teils sehr persönlich angegangen und das auf allen Plattformen. Jüngstes Beispiel, und bei weiten nicht das schlimmste, kannst du dir unter dem folgenden Link gleich selbst ansehen: https://lists.freedesktop.org/archives/systemd-devel/2018-June/040855.html
EDIT: Da war wohl einer schneller...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2018 um 14:16.
Von Verfluchtnochmal-05995bd7b am Sa, 16. Juni 2018 um 14:46 #
Und plötzlich ist er leise - Komisch
Der Unterschied ist vor allem dass im Gegensatz zu so Wahnsinns-Posts systemd-user ganz klare technische Vorteile benennen können während sich die andere Seite die Finger in die Ohren steckt, nichtmal versucht zu verstehen und dann im besten Fall noch jedem der seit Jahren damit arbeitet unterstellt er sein ein "Poettering-Fanboy" und immer die gleiche Platte abspult "Aber ich will nichts anderes als ein Shell-Script, ich will die Vorteile es anders zu machen nicht verstehen, was ich nicht kenne fresse ich nicht, ich lese keine manuals"
Dass das so ein riesiger Block ist, der dann auch direkt mal noch cron und 15 andere Tools ersetzen will, naja, das erscheint mir auch nicht direkt ideal.
Das eventbasierte Aktivieren von Diensten ist ja eines der großen Feature von systemd und durch die Timer-Units lässt sich als Event eben auch die Zeit selbst benutzen. Ich vermute es geht mehr darum als um das ersetzen von cron.
Hm, ich weiß garnicht, wie ich's anfangen soll... In fünf Minuten bin ich eh runtergevotet...
Ich finde die Poettering-Tools eigentlich ganz gelungen. Auch systemd gefällt mir gut. Ich habe den Eindruck, dass es viele Dinge mal solide gelöst hat, die vorher eher zusammengeschustert waren. Das Zusammengeschusterte war weder pflegeleicht, noch skalierte es gut, noch hatte es eine ausgearbeitete Fehlerbehandlung.
Dass das so ein riesiger Block ist, der dann auch direkt mal noch cron und 15 andere Tools ersetzen will, naja, das erscheint mir auch nicht direkt ideal. Möglicherweise gibt es aber technische Gründe, die für eine so enge Integration an der Stelle sprechen.
Vielleicht sieht den Kommentar jemand vor'm Downvoting, der diese systemd-Phobie mal technisch motivieren kann.
Der Kernel ist auch ein Riesenblock und alles andere als ideal .. nur alle sichtbare Alternativen erscheinen (oder sind) noch schlechter.
Zum Thema systemd-Phobie: Digitales Wutbürgertum ..
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Jun 2018 um 11:04.Genau wie der Kernel ist auch systemd durchaus zum Teil modular.
Der Kernel kann größer oder kleiner gebaut werden, je nach benötigtem (Grund-)Funktionsumfang. Das ist für systemd auch möglich, nicht alle Funktionen müssen benutzt werden.
Der Kernel lädt viele Module nur nach, wenn sie benötigt werden und entlädt sie bei Nichtgebrauch auch wieder.
Das ist bei systemd auch so, es werden nur die Services gestartet, die auch zur Laufzeit benötigt werden.
Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Was das digitale Wutbürgertum angeht, hast Du allerdings komplett recht.
> Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Der Grund dafür liegt darin, dass diese Tools alle von Systemd abhängig sind, selbst wenn dies nicht nötig gewesen wäre. Eine Ausmahne bildet dabei meines Wissens nur udev. Für udev und logind gibt es dann noch die abgekoppelten Ersätze eudev und elogind mit anderen Maintainern. Für sämtliche anderen Tools gibt es keine.
Die Library libsystemd0 besitzt zwar einen shim, dieser hat aber systemd als build dependency und generiert eine Library die absolut nichts tut. Das heisst, ein Programm das libsystemd Funktionen nutzt und mit dem shim genutzt wird, funktioniert höchstens noch teilweise. wird z.B. sd_journal_print fürs logging verwendet, gibt es keine Logs mehr.
Das Hauptproblem mit libsystemd ist aber, dass unterschiedliche APIs die nichts miteinander zutun haben in der selben library sind. Dies hat zur folge, dass auf Distributionen mit Binarypacketen nicht z.B.
nur die sd_journal Funktionen fürs Logging von einem binary Packet ersetzt werden kann, sondern auch alle anderen Funktionen von einer Library ersetzt werden müssen, was unpraktikabel ist.
Das Problem damit, dass alle Tools voneinander abhängig sind ist, dass Programme, die von den Tools abhängen, ohne Systemd dann nicht mehr funktionieren. Um ein paar prominente Beispiele davon zu nennen:
* Snap funktioniert nicht auf nicht systemd Systemen, da es die CGroup und Namespace abstraktionen von Systemd nutzt.
* iio-sensor-proxy, dieses Programm ist notwendig, um den Bildschirm z.B. eines Tablets automatisch mitdrehen lassen zu können.
* Diverse Desktop Environments und Login Manager, insbesondere Gnome. Bei diesen haben Nicht-Systemd Distributionen haben viel mühe damit, die Abhängigkeiten zu entfernen. Einige versuchen es gar nicht mehr erst.
Ich weise ausserdem schon im vornherein darauf hin, dass diese Abhängigkeiten der Tools zu systemd bei der Entwicklung in keinster weise notwendig gewesen wären. Systemd hätte seine Tools nutzen können, ohne das die Tools auf Systemd angewiesen gewesen wären. Es bietet auch keine bessere Integration in Systemd, die Userinterfaces hätten dafür in keinster weise geändert werden müssen.
Digitales Wutbürgertum? Das Wort beschreibt überhaupt nicht den Stand der Dinge. Warum sind bitte Alle, die systemd ablehnen auf einmal in einer Schublade? Ich habe beispielsweise nicht einmal im Entferntesten Herrn Poettering persönlich attackiert oder verbal sonst irgendwie abgewertet. Die Kritik bezieht sich einzig darauf, dass meiner Meinung nach Distributionen Vielfalt anbieten sollten. Schön, dass systemd gibt. Aber ebenso schön, dass es andere INIT-Systeme wie OpenRC, S6 oder runit gibt. OpenRC beispielsweise finde ich klasse und setze das zusammen mit Hyperbola auf meinem Desktop-System ein. Und nur weil ich systemd aus verschiedensten Gründe ablehne, bin ich ein "digitaler Wutbürger"?
Warum schreibt ihr hier überhaupt dann, wenn systemd für euch so passt? Was kümmert euch dann eine Distribution, die eben auf das Ganze verzichten möchte?
Es war schon immer so, dass eine Distribution meist nur ein einziges Init-System angeboten hatte. Ausnahme sind Source-basierte Distributionen wie Gentoo, wo man ohnehin alles selbst konfigurieren kann.
Der Begriff "Digitales Wutbürgertum" kommt wohl daher, dass einige systemd-Gegner plötzlich was von einer "Init System Freedom" erzählen und die systemd-Entwickler als brutale Unterdrücker darstellen.
Das macht natürlich keinen Sinn, Devuan bietet z.B kein systemd an, ist aber deswegen nicht unterdrückerisch. Jede Distribution kann ja selbst entscheiden, welche Software sie paketieren möchte. Wem das nicht gefällt, der nimmt eine andere Distro, gibt ja genug.
Vielleicht hat Debian da auch falsche Erwartungen geschürt, z.B als sie neben Linux noch kFreeBSD und Hurd anbieten wollten und dann dachten die Leute das müsse beim Init System genauso sein. Ich halte es für sinnvoller, sich auf eine Lösung zu beschränken, zumindest bei so grundlegenden Komponenten, sonst hat man einen Haufen Arbeit und am Ende funktioniert es sowieso nicht zufriedenstellend.
Es spricht nichts gegen Systemd. Es deckt aber nicht jeden Anwendungsfall ab. Will man z.B. Debian Side-Loaded betreiben (z.B. mit Android-Init) dann funktioniert das nicht gut, weil das Systemd-Init und das Android-Init nicht miteinander "können". Und genau darum ist es gut, wenn es Auswahl gibt.
> [...] systemd-Phobie vorzuwerfen
Das ist kein Vorwurf, sondern eine Feststellung. Schau dich halt mal im etwas größeren Maßstab um, wie die Leute so auf systemd reagieren.
> Entschuldigung, aber warum kann man nicht einfach Leuten mit anderer Meinung eine Alternativlösung gönnen?
Klar, ich sag doch nicht, dass ich sie jemandem nicht gönne. Ich bin nur neugierig nach dem Grund.
> Aus diesem Grund gebührt deinem Beitrag eigentlich tatsächlich ein Downvoting.
Davon gehe ich aus. Go ahead!
Na jetzt tu mal nicht so, als hätte ich jemanden sonstwie beleidigt. Erstmal ist doch eine Phobie auch recht wertfrei, oder? Es ist einfach nur eine Ablehnung gegen etwas.
Aber es gibt auch Menschen, die es sich zur Überlebensstrategie gemacht haben, sich in jeder Situation nur über den Gesprächsmodus, oder die Umstände, oder sonstwas Nebensächliches zu echauffieren. Das wirkt verständig, zurrt einen aber nirgendwo fest. Das bietet immer genügend rhetorische Beinfreiheit.
"Erstmal ist doch eine Phobie auch recht wertfrei, oder? Es ist einfach nur eine Ablehnung gegen etwas."
Wertfrei ist der Begriff "Phobie" ganz gewiss nicht.
Eine Aversion bezeichnet eine Ablehnung.
Eine Phobie bezeichnet eine krankhafte, panische Angst, Schrecken, Furcht vor etwas; eine Angststörung.
Wir merken hier die Wirkung medialer Gehirnwäsche, die auch andere Begriffe wie z.B. "Toleranz" in "Akzeptanz" ummünzt bzw. deren völlig entgegengesetzte Bedeutungen gleichsetzt.
Worte haben Bedeutungen. Gerade die deutsche Sprache lässt es niemals zu, aus einem Löffel eine Gabel zu machen. Politik, Medien und andere Wahnsinnige versuchen jedoch, genau dies zu tun.
Wehret den Anfängen!
Haben die Social Justice Warrior schon Sommerloch?
Ich glaube, den Aspekt des 'krankhaften' hat das Wort 'Phobie' sehr oft, ist aber optional. Ansonsten ist es eine ausgeprägte Angst/Ablehnung.
Wenn du jetzt erwartest, dass ich mich für das Wort 'Phobie' entschuldige, müsstest du länger warten. Ich sehe nicht, wo man sich davon ernsthaft auf den Schlips getreten fühlen kann, außer man sucht danach. Weiterhin, wenn du mal in Foren die Diskussionen um systemd überfliegst, weißt du auch, dass man da durchaus Angststörungen und krankhafte Züge reindeuten _könnte_, wenn man das will.
Ansonsten geht's dir aber noch gut, ja? Mir zu unterstellen, Opfer medialer Gehirnwäsche zu sein, weil ich es mir erlaubt habe, das Wort 'Phobie' zu benutzen, ist reichlich albern, oder?
Hmm, ich finde die Begrifflichkeit "Social Justice Warrior" definitiv unpassend an dieser Stelle. Das was der Teilnehmer zuvor geschrieben hat sehe ich eher aus einer ganz anderen Richtung kommend. Vorzugsweise erfolgreich vom Thema ablenken und dann eine wie auch immer geartete Agenda platzieren. Allein schon, dass Begrifflichkeiten "Politik" und "Medien" fallen. Was kommt als Nächstes? "Lügenpresse"? Vor allem, weil die Begrifflichkeit "Angstphobie" fällt. Haben wir da einen "besorgten Bürger"? Bitte weitergehen, Herr Lustig. Danke.
Zum Thema: Neutrale Begrifflichkeit. "Phobie" ist doch schon sehr stark: Ich bin definitiv auch kein riesiger Fan von systemd und freue mich über Alternativen wie OpenRC beispielsweise. Ich würde da aber eher die Begrifflichkeit "Abneigung aufgrund anderer Präferenzen" bevorzugen. Eine freie Wahl des INIT-Systems sollte da auch unterstützen und systemd vereint meines Erachtens weit zu viele Komponenten und Schnittstellen.
Ohne ein Downvoting vorzunehmen teile ich Deine Meinung nicht.
Ich habe die Erfahung gemacht, daß systemd teils sehr unflexibel ist.
Beispiel aus dem wirklichen Leben:
Auf der Textkonsole schätze ich im Nichtgrafikmodus (Multiuser nach systemd-Ausdrucksweise) den gpm. Damit kann man bequem copy&paste machen. Zugegebenermaßen Ansichtssache. Nun kann man die Serivedatei für gpm schön konfigurieren, daß er nur im multiusermodus startet.
Jetzt kommt das große Aber: Der grafische Modus braucht den multiusermodus.
Und schon ist der gpm im grafischen Modus gestartet. Ich habe auch noch keine Möglichkeit entdeckt, im grafischen Modus den Start des gpm zu verhindern.
Gut ich könnte einen gpm_stop service einrichten, der im graphical Mode den gpm herunterfährt. Dann wird es aber absurd; wir wären dann faktisch wieder beim sysvinit, der ja zumindest von den Entwicklern arrogant belächelt wird.
Für mich ist eigentlich aus diesem Grunde der systemd ein nogo. Nicht wegen gpm; gpm ist für mich nur ein Symptom der Unausgegorenheit von systemd.
Sowas kann ja auch andere Services betreffen, die mir derzeit nicht bekannt sind und zerstört bei mir deshalb ein gewisses "Vertrauen".
Danke für die sachliche Erklärung. Verstehe ich (auch wenn's wohl eher ein exotischer Fall ist).
Und mit "Conflicts" und "graphical.target" kann man nichts erreichen? Was macht denn gpm im Grafikmodus? Passiert da was Schlimmes, oder stoppt es einfach irgendwie von selbst?
Ich kenne gpm nur noch aus früheren Tagen...
Schädlich ist gpm meistens nicht, es gibt auch Fälle, in denen es nicht harmoniert mit dem XServer.
Aber auch, falles es nicht schädlich ist, sehe ich in solchen erwähnten Verhaltensweisen einen Rückschritt oder auch sogar eine Tendenz zur Primitivierung.
Und wie gesagt, nicht zu sehr am Beispiel gpm aufhängen, es werden sicherlich auch andere Konstellationen gleichartige Probleme verursachen.
Und das Themat conflicts kenne ich noch nicht. Das könnte ein Anknüpfungspunkt sein.
Ist super simpel zu implementieren. systemd ist in dieser Sicht sogar sehr viel flexibler als das alte sysvinit, da es nicht nur 6 fixe runlevels gibt sondern du dir sogenannte targets anlegen kannst wie du möchtest (targets entsprechen ganz grob den alten runlevels)
In einem Fall würde ich so vorgehen: Leg ein console.target an, dass multi-user.target reinzieht:
[Unit]
Description=Console
Requires=multi-user.target
After=multi-user.target rescue.service
In deinem gpm.service machst du nun
[Install]
WantedBy=console.target
Damit hakt sich gpm service in das console.target beim boot ein und nicht mehr in multi-user.target.
Beim booten kannst du das neue target auswählen, indem du (siehe man kernel-command-line)
systemd.unit=console.target and die kernel optionen anwängst
Wenn du das öfters brauchst, mach dir in grub einen menu eintrag.
systemctl enable gpm.service
natürlich nicht vergessen.
Das hört sich auch interessant an. Ich habe im Moment nicht das unitfile für gpm da. Aber ich muß dafür unter /etc/systemd/system eine eigene gpm.unit einrichten und noch die Konsole. Was ist da flexibel dran; für solch einen schritt ganz schöner Aufwand. Unter sysvinit wird in der ursprünglichsten Form im betreffenden Runlevel der Link auf /etc/init.d/gpm gelöscht. Ansonsten ging es auch mit chkconfig oder insserv.
Da kommt noch ein Kritikpunkt hinu: Unter systemd ist alles (unnötigerweise) aufwändiger als unter sysvinit. Also ist dieses Konzept nicht so effizient. Ich kann den Gedanken einfach nicht verdrängen: Ich fühle mich an Windows erinnert, wo viele aufgeblasene Schritte nötig sind, um ein simples Ziel zu erreichen.
Da ich auch BSD-Systeme administriere, sehe ich zu systemd umsomehr die Gegensätze.
schon mal versucht ein sysv init skript "korrekt" zu schreiben.
Das nenne ich aufgeblasen, aufwändig und kompliziert.
Im vergleich dazu sind .service files eine wahre freude
Nein, Du legst einfach ein Drop-In an und änderst nur das was du ändern must. Das übersteht auch das nächste Dist-Upgrade.
$ mkdir /etc/systemd/system/gpm.service.d
$ echo -e "[Install]\nWantedBy=console.target" > /etc/systemd/system/gpm.service.d/nur-console.conf
1. Was für sysvinit das runlevel ist, ist für systemd das target. Und die sind sich ähnlicher als viele meinen.
Working with systemd Targets
2. Nicht systemd sondern die "[Install]"-Section des Service-Unit entscheidet in welchem Target der Dienst aktiviert/installiert wird. Und dieses Service-Unit kommt, genau wie bei den Initscripten unter sysvinit, nicht vom verwendeten init sondern vom jeweiligen Softwarepaket.
Kritik ist ja schön und gut sollte aber korrekt Adressiert werden.
3. Willst du die Standardvorgaben eines vom Paketmanager installierten Service-Unit verändern ist das absolut problemlos möglich und das auch noch, ganz im Gegensatz zu den Initscripten, auf eine Art und Weise die ein Update durch eben diesen Paketmanager überlebt.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 13. Jun 2018 um 10:08.Modifying Existing Unit Files
Mag sein, dass es Dinge gibt, die unter systemd einfacher und robuster geworden sind.
Für mich sind jedoch Dinge, die früher einfach waren, schwierig geworden.
Z.B ein automatischer login in Textmodus war früher einfach, da musste man nur einen einzelnen Eintrag in der inittab ändern. Unter systemd muss man erst mal viel lesen und sich dann irgend so eine unit-Datei selbst schnitzen.
Auf Desktop-Systemen laufen mir heutzutage zu viele Dienste, die ich nicht brauche und aus Sicherheitsgründen und zwecks Kompexitätsreduktion abschalten möchte. Einige möchte ich nur punktuell einschalten, wenn ich sie tatsächlich brauche (z.B. wlan).
Unter SystemV war das sehr einfach; da brauchte man nur ein paar symlinks unter /etc/rc3.d bzw. /etc/rc3.d löschen, und die Reihenfolge, in der die Dienste gestartet wurden, war durch die Dateinamen einfachst erkennbar.
Unter Slackware ist es auch sehr einfach, da ändert man die Startskripte auf "nicht ausführbar", wenn man den Dienst loswerden möchte. Die Skripte sind bewusst einfach gehalten, damit man sie auch versteht, wenn man kein bash-Guru ist.
Unter systemd hingegen laufen 70 Dienste mit nur zum Teil selbsterklärenden Namen, eine Hierachie ist mit den Tools, die ich ausprobiert habe, nicht so recht erkennbar, und ich weiss vielfach nicht mehr, wozu die Dienste gut sind und was ich anrichte, wenn ich die abschalte.
Das mag ja alles auf einem Server sinnvoll sein; auf einem Desktopsystem scheint mir das overkill. Alles nur, um ein paar Sekunden boot-Zeit zu sparen.
Will ich nicht, ist mir zu kompliziert, also nehme ich 'ne Distro, die es mir einfacher macht.
Sorry aber allein schon durch die eventbasierte Aktivierung (beispielsweise startet cups erst dann wenn es gebraucht/angesprochen wird) von Diensten welche systemd bietet ist ja eher das Gegenteil der Fall, außer die Distribution verteilt standardmäßig Konfigurationen wo das nicht richtig umgesetzt wird. Und auch das Handling von Abhängigkeiten hat systemd um einiges besser im Griff, sogar so gut das beim ersten Wechsel oft sogar Fehler auffallen die vorher unter sysvinit kaum einer bemerkte.
systemd ist in bestimmten use cases sinnvoll (z.B. auf dem Desktop), in anderen jedoch nicht.
systemd ist möglicherweise einfach(er) zu konfigurieren, das wird jedoch mit technischer Komplexität erkauft. Und Komplexität ist der Feind der Sicherheit. Dass KISS Prinzip und "do one thing and do it well" ist aktueller denn je. Auf einem Server sollte aus Sicherheitsgründen immer das Minimalprinzip gelten - und das ist mit systemd nicht erreichbar.
Von daher bin ich froh, dass es Distros wie z.B. Devuan, Slackware und Alpine für Server gibt - sonst müsste ich wohl auf *BSD umsteigen.
Ich kann BSD auf Servern nur empfehlen. Gut, die Lernkurve ist etwas steiler und die Konfigurationsdateien liegen möglicherweise an anderen Stellen, dennoch geizt BSD nicht an Stabilität. Im Gegenteil, nach meinen Erfahrungen ist BSD stabiler als Linux, was aber auch an meiner Konfiguration liegen könnte.
Das mit der Stabilität liegt wohl nicht an Deiner Konfiguration.
Einmal sind die BSD-Varianten ohnehin berühmt für ihre legendäre Stabilität "rockstable", zum anderen sind sie in Sachen Konfiguration von Haus aus (KISS- keep it small and simple) wesentlich überschaubarer.
Privat wäre ich schon längst bei einem der drei BSDs, wenn es nicht Probleme im ACPI-Umfeld (speziell Resume) gäbe.
Ja, die Stabilität und der geringe Wartungsauswand sowie die Übersichtlichkeit sind die Hauptgründe warum ich auf Servern (und in speziellen Fällen auch Desktops) auf BDS setze.
Welche ACPI-Probleme gibt bzw. gab es denn bei dir?
Und welche BSD-Varianten hast bzw. hattest du denn probiert?
ACPI ist bei BSD generell ein noch groß vorhandenes Problem, es ist aber in den letzten 1 bis 2 Jahren deutlich besser geworden.
Getestet habe ich FreeBSd, NetBSD und OpenBSD.
Auf FreeBSD und NetBSD funktionierte zwar das Resume, nur der Bildschirm kam nicht mehr zurück. Die Rechner waren ein Thinkpad 410 und 420 bzw. ein Medion vom Sommer 2016. Der genau Bezeichnung habe ich im Moment nicht zur Hand.
Multimedia bspw. funktionierte einwandfrei.
Bei OpenBSD funktioniert Resume nach einem Suspend auf beiden Thinkpads einwandfrei, nach einem Hibernate wird noch das Dateisystem gemounted, danach wird der Rechner wieder rebootet. Es kann aber auch daran liegen, daß ich im Monent von 6.3 testeshalber auf current gegangen bin. Ansonsten läuft das System aber super. Ich benutze den Rechner bei der Arbeit als privaten Gastrechner.
Aber wie gesagt, der Medionrechner, als mein privater Universaldesktop hat die erwähnten Problme. Und jedes mal alles neu zu starten, ist mir ehrlich gesagt zu aufwändig.
Hallo,
FreeBSD 11.2 steht quasi vor der Tür, probiere es doch einfach mal aus.
Vielen Dank für den Hinweis, ich werde es testen. Für einen Universaldesktop würde ich FreeBSD schon vorziehen.
Und wieder der unreflektierte Unsinn systemd wäre vorwiegend am Desktop sinnvoll - Das genau Gegenteil ist der Fall
Ändere doch mal in init-scripts die Reihenfolge/Abhängigkeiten ohne die Files der Distribution anzufassen - /etc/systemd/system/servicename.service.d/ schmeiss so viele dropins wie du lustig bist (um es übersichtlich zu halten) rein und schon stehen dir so gut wie alle Optionen von Abhängigkeiten über User/Group bis hin zu Namespaces, PrivateTemp, Seccomp, ProtectSystem, ReadwritePaths, ReadOnlyPaths, Restart etc. in einem Umfang zur Verfügung wo du mit einem Shellscript wochenlang rumbasteln kannst und zuverlässig ist es dann immer noch nicht
Wenn du das da alles in /etc/init.d/httpd in vollem Umfang und *stabil* auch über viele Service-Restarts umgesetzt hast darfst du wieder kommen und was von wegen systemd ist für Desktops erzählen
Restart=always
RestartSec=1
UMask=006
TasksMax=1024
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX
RestrictRealtime=yes
SystemCallArchitectures=x86-64
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
ProtectSystem=strict
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ReadWritePaths=-/var/www
ReadWritePaths=-/run/httpd
ReadWritePaths=-/tmp
ReadWritePaths=-/var/log
Fantastisch, wenn du systemd gerne benutzen möchtest. Du wirst deine Gründe dafür haben. Viele (fast alle) Distributionen unterstützen es, so dass du nur eine auswählen und installieren musst. Fertig.
Ich beispielsweise bevorzuge sysvinit und habe meine Gründe dafür. Andere bevorzugen openrc und werden auch ihre Gründe dafür haben. Und so freue ich mich, dass es eine Distribution gibt, die es mir erlaubt, mit sysvinit zu arbeiten.
Keine Ahnung, was es da zu diskutieren gibt. Über die technischen Unterschiede der init-Systeme gibt es viele Artikel im Netz, einfach mal suchen.
ano
PS: Vielen Dank für die tolle Distribution!
Sehe ich genauso.
Schön, dass es unter Linux noch die Möglichkeit gibt und man nicht unbedingt ein windwos-like systemd benutzen muss.
Wobei Windows fasst schon stabiler läuft!!
Ich bin im Moment am Void-linux dran und habe es auf einem Uralt Lenovo X61s mit minimal Ausstattung installiert.
Ein bisschen anders als Deb, es erfordert umlernen, aber "xbps" steckt "apt-get" locker in die Tasche und die alte Kiste rennt wie Sau vorm Schlachthof.
Überholt meinen modernen Rechner mit Deb +systemd mit SSD und allem Schnick Schnak in jeder Lage haushoch.
Und die Stabilität ist das was ich von Linux gewohnt war, bevor es Anno Domini 2014 infiziert wurde.
Mir persönlich ist es eigentlich ziemlich egal was andere benutzen, natürlich habe ich eine Meinung dazu aber das ist völlig normal. Nicht mehr egal ist mir aber wenn diese selbsternannten "Veteran UNIX Admins" und ihre ganze Anhängerschaft mit Beleidigungen, Verleumdungen und Lügen gegen systemd und jeden der das nutzt (oder sich auch nur neutral damit auseinander setzt) schießen!
Immer wieder werden solche Sachen wie "Windowslike" (Windows könnte sich glück schätzen wenn so es etwas wie systemd hätte), monolithischer BLOB (systemd ist weit modularer als viele Behaupten und fast gleich groß/komplex wie der Komponentenverbund der stattdessen immer wieder eingesetzt wurde) und sonstiger Bullshit in alle greifbaren Foren gekotzt.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 14. Jun 2018 um 11:12.Immer wieder werden Leute die öffentlich zugeben das sie systemd mögen oder das es sich positiv auf ihren Umgang mit Linux ausgewirkt hat teilweise sehr persönlich angegriffen und eine Linux feindliche Gesinnung unterstellt.
Immer wieder werden Forderungen geäußert das Developer und Paketverwalter zwingend beide Welten unterstützen sollten ganz egal ob das sinnvoll Umsetzbar oder überhaupt möglich ist.
Finde ich wirklich seltsam, ich erlebe das genau zu
100% umgekehrt. Egal wo ich lese.
Kaum wird ein Devuan vorgestellt, sind 90% systemd
Anhänger da, denen ja Devuan egal sein kann.
Von Devuan Anhänger lese ich so gut wie nichts.
Auf heise.de noch schlimmer.
Im IRC #devuan sind von Anfang an ca. 70% systemd
Anhänger drin und machen genau das,
was du den Usern vorwirfst, die halt warum auch immer kein systemd mögen.
Zum Glück kann das jeder selber überprüfen, sonst
glaubt das noch jemand, was du hier verbreitest.
Geht euch doch einfach mal aus den Weg, ist einfach
nur nervig immer wieder das selbe zu lesen.
Ich möchte hier jedenfalls nur was über Devuan lesen,
weil es genau darum in dem Artikel geht.
Tickst du eigentlich noch richtig von wegen "sonst glaubt noch jemand was du hier verbreitest"? Als Fedora User habe ich mich schon ernsthaft mit systemd beschäftigt da war Debian noch im Dornröschenschlaf und ihr paar armen irren die ihr euch in die IT verlaufen habt aber mit Änderungen nicht umgehen könnt noch gar nicht getriggert
Ohne die User die euch aufzeigen wollen dass ihr schlichtweg nur faul seid und euch mit Dingen nicht auseinandersetzen wollt wärt ihr ziemlich einsam in euren Foren weil ihr seid zwar laut aber trotzdem eine irrelevante Minderheit
Da schau dir an das "Devuan"-Gesocks
-------- Weitergeleitete Nachricht --------
Betreff: [systemd-devel] Devuan ASCII 2.0.0
Datum: Fri, 15 Jun 2018 09:39:58 +0200
Von: freebsd@tango.lu
An: systemd-devel@lists.freedesktop.org
Guten f morgen,
Just dropped by to announce that new version of malware(d) free Debian is available:
https://devuan.org/os/debian-fork/ascii-stable-announce-060818
The tardfuck IAN murdock who let this plague happen to debian (used to be my favourite operating system) is let's just say:
"I'm not glad he's dead, but I'm glad he's gone"
Systemd and pulseaudio have to be shutdown for good, focus your time and energy on something more useful like inventing a 50% efficient solar panel or do cancer research instead of PRODUCING THIS FUCKING CANCER.
Systemd have to be discontined and removed from all the distributions so things can go back to normal as they used to be.
Anybody knows a good shitD free mediacenter by the way with KODI for Raspberry PI 2, 3?
Nicht das ich solche Aktionen wie du sie beschreibst gut heißen würde, wenn es denn war ist, aber:
Die ganzen anti-systemd'ler haben das mit ihren eigenem Verhalten ja überhaupt erst herauf beschworen. Von Anfang an wurde jeder der sich auch nur ansatzweise positiv zu systemd geäußert teils sehr persönlich angegangen und das auf allen Plattformen. Jüngstes Beispiel, und bei weiten nicht das schlimmste, kannst du dir unter dem folgenden Link gleich selbst ansehen:
https://lists.freedesktop.org/archives/systemd-devel/2018-June/040855.html
EDIT:
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2018 um 14:16.Da war wohl einer schneller...
Und plötzlich ist er leise - Komisch
Der Unterschied ist vor allem dass im Gegensatz zu so Wahnsinns-Posts systemd-user ganz klare technische Vorteile benennen können während sich die andere Seite die Finger in die Ohren steckt, nichtmal versucht zu verstehen und dann im besten Fall noch jedem der seit Jahren damit arbeitet unterstellt er sein ein "Poettering-Fanboy" und immer die gleiche Platte abspult "Aber ich will nichts anderes als ein Shell-Script, ich will die Vorteile es anders zu machen nicht verstehen, was ich nicht kenne fresse ich nicht, ich lese keine manuals"
Hat nix mit Phobie zu tun. Die Idee hinter systemd ist suoer, nur die Umsetzung ist einfach Mist. Poetti halt.
IMHO ist SMF von Solaris hier deutlich besser durchdacht und auch umgesetzt.
Ist Dir denn das Voting so wichtig???
Ist es nicht so, dass freie Meinungsäusserung über den
stehen sollte??