Von cyberpatrol am Di, 17. September 2013 um 20:28 #
Bullshit hoch drei, journalctl kann wesentlich mehr als das. Da all das auch ausführlich dokumentiert ist (man journalctl), spare ich mir hier die Liste.
Möglicherweise ist da kürzlich doch mal jemand auf die Idee gekommen, da noch ein paar Features mehr zu programmieren und die auch zu dokumentieren. Kann aber noch nicht lange her sein.
Aua, also .service-Files sind umständlich, aber Shell-Scripte nicht? Offensichtlich hast Du Dir nie die init-Scripte deiner Distribution angeschaut.
Doch habe ich und ich habe auch schon die sogar auch schonmal gepatcht und diesen Patch sogar an die Distributoren weitergeleitet, die die dann sogar in die Distribution aufgenommen haben. Wenn man natürlich gerade erst von Windows zu Linux gewechselt ist, dann kann man mit Scripten schonmal seine Schwierigkeiten haben. Kann man aber lernen. Ist auch gar nicht schwer,.
Wenn Du sie direkt im init-Script vornimmst, werden sie beim nächsten Update des Pakets überschrieben, sysvinit hat für dieses Problem also *gar nichts* anzubieten.
Dann sagst du dem Paketmanager halt, dass er die nicht überschreiben soll. Außerdem musste ich noch nie ein Initscript anpassen. Lediglich einmal ein Feature dazuschreiben, dass dann wie gesagt auch ganz schnell in die Distribution aufgenommen wurde. Denn jedes Init-Script lässt sich problemlos über die entsprechende Konfigurationsdatei (kein Script) in /etc/conf.d konfigurieren.
Abgesehen davon, dass die Kernel-Namen wie eth0 weder aussagekräftig (was sagt eth0 bitte aus) noch stabil sind (Tausch der Netzwerkkarte zieht oftmals eine Änderung des Interfacenamens mit sich, wtf?), sehe ich nicht, was daran so schlimm sein soll, einen Symlink zu setzen. Es ist jedenfalls einfacher zu scripten als Änderungen an irgendeiner Konfigurationsdatei.
eth0 = 1. Ethernetkarte wlan0 = 1. WLAN-Chip
Hätte man aber auch ganz einfach selbst drauf kommen können, wenn man zumindest ein paar Computergrundkenntnisse hätte und ein paar Computergrundbegriffe kennen würde.
Genau diesen Eindruck machen die systemd-Fanboys wie auch die Entwickler, nämlich den, dass sie von professioneller Computernutzung überhaupt keine Ahnung haben und gerade erst von Windows nach Linux gewechselt sind und sich einbilden, dass Linux jetzt genauso wie Windows funktionieren müsste.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden. Außerdem gabs in udev schon immer die Möglichkeit, udev-Regeln anzulegen, mit denen man die Namensverteilung konsistent hinbekommt. Und das ging schon, bevor Poettering udev gekapert hat.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man. Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft. Ich bevorzuge ein stabiles korrekt arbeitends System.
Dateien in /etc haben Priorität gegenüber denen in /lib. Der Paketmanager legt Konfigurationsdateien in /lib ab, in /etc kann der Administrator sie ggf. überschreiben, und sie bleiben dann erhalten, wenn der Paketmanager eine neue Version des Pakets installiert. Das Verhalten ist also durchdacht und sinnvoll, Du kapierst nur einfach nicht, wovon Du redest.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste. Einfache Konfigurationsdateien in /etc/conf.d werden dagegen nicht einfach überschrieben. Stattdessen werden die neuen Konfigurationsdateien vom Paketmanager mit einem leicht geänderten Namen auf die Platte geschrieben, so dass man die entweder mit locate oder find oder einem zum Paketmanager gehörenden Tool finden und entsprechend anpassen kann.
Ich glaube jetzt mal, dass eher du nicht weißt, wovon du redest.
Angesichts der oben genannten guten Gründe ist der Grund, dass es Dir niemand erklären konnte, wohl eher Deine Merkbefreiung.
Na, hab ichs nicht gesagt, dass jetzt diese unsachliche Trollerei der systemd-Fanboys kommt? Wie recht ich wieder hatte. Jedesmal dasgleiche. Wenn einem halt die Argumente ausgehen.
Wo ist der Thread, wo Poettering das behauptet, und wo ist Dein Beleg, dass seine Aussage falsch ist? Tipp: folgendes ist kein Beleg:
das übrigens schon seit Jahren perfekt out-of-the-box mit diesen Karten umgehen kann.
denn es ist gut möglich, dass PulseAudio Funktionalität im Kernel oder in den Treibern voraussetzt, die andere Applikationen nicht benutzen.
Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.
Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Du kannst es aber auch gerne selbst ausprobieren. Kauf dir doch spasseshalber mal eine M-Audio Audiophile 24/96 oder eine RME Hammerfall und versuch mal, PA damit laufen zu lassen. Kannst mir dann ja mal bescheid sagen. Ich wünsch dir schonmal viel Spaß.
Du kannst aber auch andere fragen, die sich damit auskennen, also nicht die PA-Entwickler, sondern Audio-Profis.
Wenn man keine Ahnung hat, sollte man halt lieber mal still sein.
Systemd funktioniert besser als jedes andere init-System für Linux, das weiß jeder, der sich mal mit den betreffenden Features auseinandergesetzt hat.
*rofl*
Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte. Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
Du solltest überhaupt erstmal einen Fakt liefern, das hast Du nämlich bisher nicht.
*rofl*
Und ich hatte schon wieder recht. Diese systemd-Fanboys ignorieren hartnäckig jeden einzelnen Fakt, bringen selbst nur Polemik und Beleidigungen gegenüber den systemd-Kritikern und behaupten dann, man hätte ja keine technischen Fakten vorgelegt.
Du bist wieder ein Paradebeispiel dafür.
So ignorant und arrogant wie diese systemd-Entwickler und -Fanboys kann man eigentlich gar nicht sein.
Von Anonymous Coward am Mi, 18. September 2013 um 14:13 #
Möglicherweise ist da kürzlich doch mal jemand auf die Idee gekommen, da noch ein paar Features mehr zu programmieren und die auch zu dokumentieren.
Die systemd-Dokumentation ist praktisch seit Beginn des Projekts vollständiger als alles, was jemals aus der sysvinit-Ecke kam, also spar Dir das Getrolle.
Doch habe ich und ich habe auch schon die sogar auch schonmal gepatcht und diesen Patch sogar an die Distributoren weitergeleitet, die die dann sogar in die Distribution aufgenommen haben. Wenn man natürlich gerade erst von Windows zu Linux gewechselt ist, dann kann man mit Scripten schonmal seine Schwierigkeiten haben. Kann man aber lernen. Ist auch gar nicht schwer,.
Ich finde Shell-Scripting furchtbar *weil* ich besser als die meisten weiß, was das für ein Frickelmist ist. Und dem stimmt auch jeder zu, der weiß, wovon er redet. Die Systemd-unit-Dateien sind wesentlich einfacher und deklarativer.
Dann sagst du dem Paketmanager halt, dass er die nicht überschreiben soll.
Selbst wenn das ginge (mir ist keine Möglichkeit bekannt, bspw. dpkg zu vermitteln, dass bestimmte Dateien nicht überschrieben werden sollen, ohne das Update des betreffenden Pakets ganz zu unterbinden), wäre es der Systemd-Lösung unterlegen. Angenommen, Du willst, dass bei irgendeinem Dienst foobar z. B. eine Environment-Variable gesetzt wird, während für alles andere die Konfigurationsparameter des Pakets verwendet werden. Du packst ein entsprechendes Drop-in-Snippet nach /etc/systemd/system/foobar.service.d und alles ist gut. Wenn jetzt ein Update des foobar-Pakets Änderungen an /lib/systemd/system/foobar.service vornimmt, werden diese automatisch übernommen. Vor dem Hintergrund, dass Änderungen an solchen Konfigurationsdateien sicherheitskritisch sein können, ist das ein Killerfeature, was mit init-Scripten schlicht nicht möglich ist, da sie nicht deklarativ sind.
eth0 = 1. Ethernetkarte wlan0 = 1. WLAN-Chip
Jaja, soweit die Theorie. Bis man dann ein paar mal die Netzwerkkarte tauscht und die Ethernetkarte dann auf einmal eth4 heißt, wie es auf einem meiner Systeme jahrelang der Fall war. Offensichtlich hast Du keine Ahnung, wovon Du redest.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Das ist ausführlich in der Dokumentation erklärt, die zu lesen Du offenbar nicht in der Lage bist. Und es wird auch ausführlich erklärt, warum die Sachen jetzt so gemacht werden, wie sie gemacht werden. Zudem sind Namen wie en23kpe6s die absolute Ausnahme. Viel typischer sind Namen wie usb0 (Handy per USB-Tethering), em1 (gemäß Chassis-Label) oder p10p1 (PCI-Slot 10, Port 1 -- eine Bezeichnung, die im Gegensatz zu Kernel-Namen immer die gleiche bleibt, auch wenn man z. B. die Netzwerkkarte tauscht oder das Timing bei der Hardware-Discovery ein anderes ist). Allesamt sinnvoller und aussagekräftiger als "eth0" & Co..
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden.
Ach, und wenn mehrere Netzwerkkarten vom gleichen Treiber bedient werden, was dann? Wieder mal ein Beweis, dass Du keinen blassen Schimmer hast, wovon Du sprichst.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man.
Eine Liste aller Symlinks kann man sich trivial zusammenbauen (z. B. mit `find / -type l`), wie soll da bitte die Übersicht verloren gehen?
Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft.
Ich frage wohl besser nicht nach einer Begründung für diesen Bullshit und weise einfach mal darauf hin, dass Symlinks zu setzen und zu löschen immer noch wesentlich einfacher scriptbar ist als Änderungen an einer Konfigurationsdatei.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste
**ROFLMAO** Genau, weil das ja auch das größte Problem ist bei Konfigurationsdateien, die selten größer als 1kb werden. Da wird doch tatsächlich schon bei einer Milliarde Konfigurationsdateien der Festplattenplatz knapp! Mal abgesehen davon, dass Init-Scripte gerne 5-10mal länger als die entsprechenden sysvinit-Scripte sind, und davon, dass Du das (simple!) Konzept der Drop-In-Snippets offenbar immer noch nicht kapiert hast, denn damit sind deine dämlichen Pseudo-Argumente erst recht hinfällig.
Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.
Abgesehen davon, dass Du immer noch nicht gezeigt hast, wo genau Poettering nun unbegründet anderen die Schuld in die Schuhe schiebt, ist PulseAudio schon immer eine Lösung für Consumer-Audio gewesen, was auch Poettering immer so kommuniziert hat. Schon allein deswegen ist Deine Kritik albern.
Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Unter anderem weil der Kernel kein stabiles ABI bietet, gegen das man entwickeln könnte. Und weil es auch nicht die Aufgabe der PA-Entwickler ist, Bugs im Kernel zu fixen, besonders wenn diese Bugs Hardware betreffen, die die betreffenden Entwickler nicht unbedingt besitzen.
Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Ach. Also welches andere Init-System bietet Prozessmanagement mit Cgroups, Ressourcenlimits, Syscall-Filtering, SELinux-Unterstützung, Socket based activation, device activation, bus-based activation und noch vieles mehr? Und jetzt fragst Du noch, warum Leute Dich für merkbefreit halten?
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte.
Ich hatte auch Probleme, als ich systemd das erste Mal eingesetzt habe. Im Gegensatz zu Dir habe ich diese aber sorgfältig untersucht und letztendlich hat sich herausgestellt, dass das Problem nicht systemd, sondern kaputte init-Scripte waren (zyklische Abhängigkeiten in den LSB-Headern, die Frickel-sysvinit gekonnt ignoriert hat -- prost Mahlzeit).
Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
Abgesehen davon, dass man darüber geteilter Meinung sein kann (eine Begründung hast Du ja nicht geliefert), ist es auch vollkommen unerheblich. Software wird nach Stabilität, Performance, Funktionalität usw. bewertet, und nicht danach, ob sie irgendeinem dogmatischen Regelwerk folgt, das irgendjemand als „Unix-Philosphie“ bezeichnet, und das ich für die heutige Zeit als unbrauchbar ansehe. Und damit bin ich nicht allein. Nettes Zitat von Unix-Urgestein Rob Pike: „Not only is UNIX dead, it's starting to smell really bad“.
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Von cyberpatrol am Mi, 18. September 2013 um 15:37 #
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Ich werde tatsächlich von weiteren Antworten absehen, weil du so einen unglaublichen, unvorstellbaren Schwachsinn von dir gibst, dass es nicht mehr auszuhalten ist. Mach dir aber nichts draus. Ist typisch für systemd-Fanboys.
Und darauf zu antworten ist mir wirklich zu anstrengend. Und dir erstmal überhaupt die grundlegendsten Computer- und Linuxkenntnisse beizubringen, dafür ist hier nicht der geeignete Rahmen.
Ich schlage dir vor, du machst erstmal die Schule fertig, machst dann mal eine Ausbildung oder ein Studium im Bereicht der Informatik und lässt dir vor allem erstmal ein paar Unix-/Linuxgrundlagen beibringen. Dann reden wir irgendwann mal weiter.
Und vor allem dann wieder diese Beleidigungen. Auch typisch für systemd-Fanboys. Keine vernünftigen, haltbaren Argumente liefern, aber mit Beleidigungen um sich werfen.
wlan0 = 1. WLAN-Chip
Hätte man aber auch ganz einfach selbst drauf kommen können, wenn man zumindest ein paar Computergrundkenntnisse hätte und ein paar Computergrundbegriffe kennen würde.
Genau diesen Eindruck machen die systemd-Fanboys wie auch die Entwickler, nämlich den, dass sie von professioneller Computernutzung überhaupt keine Ahnung haben und gerade erst von Windows nach Linux gewechselt sind und sich einbilden, dass Linux jetzt genauso wie Windows funktionieren müsste.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden. Außerdem gabs in udev schon immer die Möglichkeit, udev-Regeln anzulegen, mit denen man die Namensverteilung konsistent hinbekommt. Und das ging schon, bevor Poettering udev gekapert hat.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man. Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft. Ich bevorzuge ein stabiles korrekt arbeitends System.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste. Einfache Konfigurationsdateien in /etc/conf.d werden dagegen nicht einfach überschrieben. Stattdessen werden die neuen Konfigurationsdateien vom Paketmanager mit einem leicht geänderten Namen auf die Platte geschrieben, so dass man die entweder mit locate oder find oder einem zum Paketmanager gehörenden Tool finden und entsprechend anpassen kann.Ich glaube jetzt mal, dass eher du nicht weißt, wovon du redest.
Na, hab ichs nicht gesagt, dass jetzt diese unsachliche Trollerei der systemd-Fanboys kommt? Wie recht ich wieder hatte. Jedesmal dasgleiche. Wenn einem halt die Argumente ausgehen.Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Du kannst es aber auch gerne selbst ausprobieren. Kauf dir doch spasseshalber mal eine M-Audio Audiophile 24/96 oder eine RME Hammerfall und versuch mal, PA damit laufen zu lassen. Kannst mir dann ja mal bescheid sagen. Ich wünsch dir schonmal viel Spaß.
Du kannst aber auch andere fragen, die sich damit auskennen, also nicht die PA-Entwickler, sondern Audio-Profis.
Wenn man keine Ahnung hat, sollte man halt lieber mal still sein.
*rofl*Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte. Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
*rofl*Und ich hatte schon wieder recht. Diese systemd-Fanboys ignorieren hartnäckig jeden einzelnen Fakt, bringen selbst nur Polemik und Beleidigungen gegenüber den systemd-Kritikern und behaupten dann, man hätte ja keine technischen Fakten vorgelegt.
Du bist wieder ein Paradebeispiel dafür.
So ignorant und arrogant wie diese systemd-Entwickler und -Fanboys kann man eigentlich gar nicht sein.
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Und darauf zu antworten ist mir wirklich zu anstrengend. Und dir erstmal überhaupt die grundlegendsten Computer- und Linuxkenntnisse beizubringen, dafür ist hier nicht der geeignete Rahmen.
Ich schlage dir vor, du machst erstmal die Schule fertig, machst dann mal eine Ausbildung oder ein Studium im Bereicht der Informatik und lässt dir vor allem erstmal ein paar Unix-/Linuxgrundlagen beibringen. Dann reden wir irgendwann mal weiter.
Und vor allem dann wieder diese Beleidigungen. Auch typisch für systemd-Fanboys. Keine vernünftigen, haltbaren Argumente liefern, aber mit Beleidigungen um sich werfen.