Windows 7 update qual

[Revod]

Sorry, ganz übersehen.

Also... Die Erfahrungen mit PA und systemd teile ich überhaupt nicht.
Zugegeben, die Software wurde in den letzten beiden Jahren bedeutend besser, weil sie weiterentwickelt wurde UND ich selber hab mich intensiv mit positiver Grundeinstellung dazu intensuv beschäftigt...

Das macht schon mal einen Unterschied, ob ich den Tyo nicht leiden kann, weil ich ihm Allmachtsphantasien unterstelle, oder ob mich die Software und ihre Möglichkeiten interessieren... Bei zweiterem klappts eher mal, wenns schwierig wird.

PA, unter PCLinuxOS war die neueste Version von PA lange bevor es in Stretch rein kam. Mit der Vorversion, sowie mit der neueste Version friert es mit meinen HW ein. ( Creative Soundblaster 4.1 und blecklistet HDMI-NV Karte und Intel onboard ). Wie gesagt, habe etliche Male mit PA versucht, einen wirkliches Vorteil kann ich schlichtweg beim besten willen nicht erkennen, auch wenn es die Verwaltung von Player und Audio System zentralisiert. Weil, sämtliche Einstellungen die einzelnen Player selber besitzen, bei Alsa ist es der Alsa-Mixer und meinen erwähnten, kleinen schicken Volumeicon-Alsa.

Zu dem ist es in der Tat so, dass wer Jack Audio nutzt wegen Sound Überbearbeitung und Musikanten Funktionen zusätzlich PA wie eine Kugel am Bein ist, schlicht fehl am Platz und überflüssig. Wer sich mit der Klangqualität von YT und Co. damit zufrieden ist, Jack nicht braucht, mit Sound Dateien und der Werte über Übersteuerungen, " kaputte " Frequenzen usw. sich nicht beschäftigt kann PA eventuell nützlich, doch sorry, ich sehe es wie so was, auf gebranntes Zucker noch zusätzlich mit Karamell belegen... na ja...

Ich nehme an, mit " ... Bei zweiterem klappts eher mal, wenns schwierig wird. " meinst Du Systemd. Wenn das der Fall sein sollte, dann die Frage, warum soll ich denn nicht " all zu alte " HW entsorgen, Geld für neue ausgeben nur wegen Systemd abwärts Inkompatibilität vom Systemd ( Eben, erinnert mich total an der " Windoowsis " Politik. Verzichte doch nicht auf Regen um mich dann noch in Traufe zu stürzen... )?

Die Entwickler und Admins vom " Devian " stufe ich nicht als " Bekloppte " ein, doch warum sie Devian mit Pakete ohne Systemd Kompatibilität entwickeln muss wohl aus ihrer auch seinen berechtigtes Grund haben.

Ich hoffe Ihr könnt verstehen, warum ich kein Freund von beiden bin.

Was die beiden Herren an Ideen so haben finde ich grundsätzlich nicht all zu gut und aus dieser Logik heraus wäre ich sehr froh, wenn ich nicht müsste, hat nichts mit Sympathie zu tun. Bin überzeugt, es gibt noch andere und bessere Wege, wie System und Anwendungen erwähnt, mit Kernel Vereinheitlichungen und libstdc++ abwärts Kompatibilität. Ich vermute, dass gewisse System Dienste sich immer noch nicht mit denen von Systemd vertragen und sich nie vertragen werden ( Der eine steuert nach links, der andere nach rechts so grob gesagt ).

[breakthewall]

Wie schafft Microsoft es bloß, das so zu versemmeln?

Wie man das letztlich schafft, wird wohl deren Geheimnis bleiben. Mit Softwarequalität hat das zumindest wenig gemein, aber der folgende Link könnte das etwas beleuchten zum besseren Verständnis.

https://superuser.com/questions/890038/ ... te-so-slow

[breakthewall]

Mit der Vorversion, sowie mit der neueste Version friert es mit meinen HW ein. ( Creative Soundblaster 4.1 und blecklistet HDMI-NV Karte und Intel onboard ).

Offen gesagt ist Creative das mit weitem Abstand widerlichste und Open-Source feindlichste Unternehmen weltweit. Die hat Linux noch nie interessiert, und bislang haben sie sich maximal dafür eingesetzt, dass deren Soundkarten effektiv schlecht oder erst gar nicht unter Linux funktionieren.

Ich nehme an, mit " ... Bei zweiterem klappts eher mal, wenns schwierig wird. " meinst Du Systemd. Wenn das der Fall sein sollte, dann die Frage, warum soll ich denn nicht " all zu alte " HW entsorgen, Geld für neue ausgeben nur wegen Systemd abwärts Inkompatibilität vom Systemd ( Eben, erinnert mich total an der " Windoowsis " Politik. Verzichte doch nicht auf Regen um mich dann noch in Traufe zu stürzen... )?

Genau genommen hat Systemd null Einfluss darauf, was an Hardware läuft oder nicht. Wenn etwas die Kompatibilität einschränkt, dann ist es ausschliesslich der Linux-Kernel, und dieser ist beliebig austauschbar.

[Revod]

Hättest gerne, doch so " pauschal einfach " ist es eben nicht....

Es hat schon die eine und andere Creative Karte gegeben, die Linux kompatibel war ( Haben die Chipsatz Parameter bekannt gegeben um den CA0106 Treiber zu entwickeln ). Zu dem, nur PA kommt nicht damit zurecht. Mit Alsa und Jack alles kein Problem, daher stimmt Deine Ansicht in meinen Fall nicht überein. Doch dem stimme ich Dir zu, das war lediglich für einen reines " Selbsttest " Kauf, und nun weil ich es habe wird sie auch eingesetzt ( Auch ich, seid sehr lange Zeit achte sehr Streng auf Linux Kompatibilität HW, als gesamtes Rechner Konzept und Peripherie ).

Systemd, auch hier stimmt Deine Ansicht nicht so ganz.

An der Zeit vor ca. 3 Jahren, als Jessie noch Testing war kam dieses schwarze Monitor nach einen Systemd update. Da reinstallierte ich mein Backup zwei mal + 1 mal PCLinuxOS auf das Fuji Notebook installiert, daher weiss ich es genau.

1. An dem Tag alles geupdatet und ca. 30 Sek. später half nur noch die Resett-Taste am Notebook ( Ich vermutete bereits, es muss Systemd für die Ursache sein ).

2. Erstes Backup Reinstallation und danach nur alles vom Systemd inkl udev und allen Abhängigkeiten geupdatet, ohne Kernel , nach ca. 30 - vlt auch 50 Sekunden, das selbe wie Punkt 1.

3. Zweite Backup Reinstallation, alles andere, ausser Systemd und udev inkl. dazugehörende Abhängigkeiten geupdatet. Rebootet und da war kein " Blackscreen " mehr nach ca. 45 Sekunden. Da machte ich mir deswegen sofort einen System Backup, dass ich es so vom Notebook auf meine AMD PC, ca. 10 Jahre alt überspielen konnte. Auf die Art konnte ich Systemd auf das Athlon PC, als Rest noch updaten, was auch klappte und auf dieses Athlon PC wurde kein " Black Screen " verursacht. Beide, Notebook und PC ( PC ist jünger und beide haben eine NV Karte, aber andere CPU und RAM ) sind bis auf einen Jahr auseinander gleich alt.

Habe noch andere, stärkere PC, als mein Notebook Fuji und ausnahmslos, der Blackscreen wird nur auf schwächere, oder inkompatible HW für Systemd ausgelöst.

Nun, weil wie oben beschrieben ich um die Fehlerquelle zu finden mit den Updates vorgegangen bin besteht für mich kein Zweifel, Systemd hat seine " Finger " so ziemlich überall drin im Kernel, Grafik, Benutzer und weiss ich noch mit was es verknüpft ist. Kernel und viele andere Pakete müssen in der Kompilierung mit Berücksichtigung auf das Systemd kompiliert werden, wenn eine Distri für Systemd im System zu implementieren sich dafür entschieden hat.

Hatte im Verlauf letztes Jahres auch zwei andere Distri, die ohne Systemd noch zu haben waren, Megaia und Rosa auf den Fuji mit höhere Kernel als Testing, und ja, ohne Systemd gab es in der Tat keinen Blackscreen. Leider, kurz danach haben es auch sie implementiert. Da nehmen nur noch wenige Distri auf " relativ " ältere HW Rücksicht. Das besagte PC hat 2 Kerne und ist auch 64 bit fähig und in sehr gutes Zustand. Das Fuji tut sein Dienst wirklich sehr gut, FujiTsu-Amilo singel Core und 2 GB RAM. Diese zu entsorgen wäre das gleiche, als ob ich meine ca. 3 Jahre alte Home-Stereoanlage jetzt schon entsorgen würde, ja, in so einen gutes Zustand befinden sich die beiden Rechner, praktisch wie neu.

Edit:

Es lag auch nicht am Kernel, weil ich alles vom Systemd und udev einen gutes halbes Jahr auf " hold " gesetzt hatte, bis gewisse Anwendungen sich nicht mehr updaten liessen, weil die Systemd und edev Versionen nicht mehr übereinstimmten. Das war für mich auch eine Bestätigung meiner obige Aussage und daher kam PCLinuxOS auf das Notebook und Debian-Testing mit Systemd auf meinen Athlon PC.

[scientific]

Also es ist schon einfach zu behaupten, weil Software mit Rücksicht auf systemd kompilliert werden muss, ist systemd schuld, dass auf alter HW ein Blackscreen ausgelöst wird...

Hast du rausgefunden, welcher Teil von systemd das sein soll? Hast du im diagnose-Mode schon gewerkelt? Hast du schon auf der debug-shell versucht der Ursache auf die Schliche zu kommen?

Systemd startet, überwacht und beendet Dienste... Systemd verwendet cgroups des Linux-Kernels um zusammengehörige Prozesse zu gruppieren, in ihren Rechten und Ressourcenverbräuchen einzuschränken (deswegen auch die Verbindung zum Kernel), aber systemd nutzt nur bereits vorhanden gewesene Infrastruktur des Linux-Kernels...

Wär schon spannend, welcher Dienst dazu führt, dass dein Notebook keine Anzeige mehr hat...

Und weil du systemd nicht debuggen kannst, heißt es noch lange nicht, dass es nicht geht, und dass systemd Schuld hat, wenn dein Notebook nicht mehr geht...

lg scientific

[Revod]

Würde es gerne debuggen, wenn die ca. 30 Sek. Zeit ausreichen würde.

Das erstes Blckascreen sah ich in Synaptic Debug Mode bei dem Systemd Update, der das erste mal das Blackscreen verursacht wurde.

Ablauf Zeitpunkt:

Systemd wir vorbereitet.... Systemd wird installiert..... Systemd wird konfiguriert.... und genau hier an dieses Punkt, als Synaptic Paket libude wird vird orberitet.... > Blackscrenn und nichts ging mehr. Und das wörtlich zu verstehen, als ob kein System installiert wäre, keine Maus und keine Tastatur Reaktion mehr und das CPU Lüfter dreht auf das Minimum RPM runter.

Und wegen System Konform Kompilierung. Ich teste ab und an neue Anwendungen, die es auch in pkgs.org zu finden sind. Die Anwendung selbst ist nicht auf Systemd angewiesen, stimmt. Nur braucht Anwendung xy eine Lib xy1, die wiederum von libxy2 abhängig ist und diese Libxy2 wiederum libsystemd ist, was wiederum systemd mit sich nachzieht.

Stimmt, nicht ganz richtig formuliert von, es betreffen etliche Abhängigkeiten, die mit der Variable vom Systemd kompiliert werden müssen, wenn Systemd die Kontrolle aller Dienste übernehmen soll. Somit entsteht zwangsläufig eine lange Verknüpfung Verkettung mit Systemd.. Bin ja kein System Entwickler, ich zähle einfach die 1 plus 1 zusammen und sehe wie sich Distri mit und ohne Systemd auf meine Rechner verhalten und kann daher nur das Ergebnis schreiben.

Das war ohne Systemd nie eine Debug Frage, was System Grundfunktionen anbelangte, das System konnte immer gestartet werden, 10 lange Jahre nach meiner Erfahrung.

Systemg debuggen kann ich nicht , stimmt da hast Du Recht und bis ich mich mit Systemd, als Profi einarbeiten würde, mit meinen Englischkenntnisse kommt längst einen neuen " Furz " ... stehe so zu sagen auf verlorenen Posten, auch weil die notwendige Zeit ich nicht dafür habe mich intensiv mich damit zu beschäftigen.

Das eigenartige ist, erst ab einer bestimmte Version von Systemd wurde das Blackscreen verursacht. Indirekt kann das auch einen Board Chip sein, der via Kernel auf Systemd bestimmte Version alles anders reagieren lässt, oder wie Du sagst Systemd das Kernel mit den Dienste auf Chip xy nicht mehr übereinstimmen lässt.

[scientific]

Wenn bei mir sowas passiert (ja, ich hatte auch schon Hänger in der Graphik, die vom i915 verursacht wurde, oder btrfs, oder ein hängengebliebener ftp-Mountpoint..., der den Kernel zu einfrieren brachte), versuche ich mich von einem zweiten Rechner per ssh einzuloggen. Geht das? Bin ich schon einen Schritt weiter.

Geht das nicht, lasse ich von einem zweiten Rechner (da hast ja welche verfügbar, was ich gelesen habe), aus das journal über ssh mitlaufen, bis der erste Rechner einfriert. Das gibt auch schon mal Aufschluss über die Ursache.

Dann würd ich dir empfehlen, einmal nur in den Textmodus zu starten. also folgendes ausführen:

Code: Alles auswählen

systemctl disable gdm

wenn du gdm im Einsatz hast.

Oder du wechselst das default-target wie hier beschrieben:
https://wiki.archlinux.org/index.php/sy ... _boot_into

Code: Alles auswählen

systemctl set-default multi-user.target

Dann bootest du neu und solltest nur mehr ein getty bekommen, wo du dich auf der Textkonsole einloggen kannst. Funktioniert das? Dann kannst du von hier aus weiter debuggen.

Eine unverzichtbare Hilfe zum Debuggen ist auch die debug-shell. Die aktivierst du mit

Code: Alles auswählen

systemctl enable --now debug-shell.service

Wechsle mit Strg+Alt+F9 in die Debug-Shell. Das ist eine Root-Shell ohne session, ohne Environment. Vim meckert, dass er statusfiles nicht schreiben kann usw. Das soll sich nicht stören. Die Debug shell wird ziemlich am Anfang im Bootprozess gestartet und beendet sich erst, wenn der Rechner stromlos geschaltet wird beim runterfahren.
Mit der Debug-Shell kannst du dein System quasi von außen beobachten und steuern.

Manchmal spinnt mein Graphik-Treiber, dann kann ich mit Strg+Alt+F9 nicht mehr das TTY wechseln... dann komm ich auch nicht in die Debug-Shell. Dann versuche ich mich per ssh einzuloggen und kille mit loginctl alle User-Sessions. Auch jene von Debian-gdm. Oft hilft das, und ich kann wieder in die debug-shell.
Der Befehl lautet:

Code: Alles auswählen

loginctl

Der liefert die alle Sessions und alle Benutzer.

Code: Alles auswählen

loginctl kill-user user1 user2 user3<

beendet alle Sessions all dieser User. Du fliegst natürlich auch aus der ssh wieder raus damit.

Um zu sehen, was sich gerade im system tut, lässt du das journal mitlaufen

Code: Alles auswählen

journalctl -f

Code: Alles auswählen

Das ist wie tail -f /var/log/syslog /var/log/dmesg /var/log/messages

und was sonst noch an Logfiles geschrieben wird, während des Betriebes.

Kannst du es auf spezielle Services eingrenzen, welche ev. die Blackouts verursachen, dann lass das journal für diese(n) Service mitlaufen:

Code: Alles auswählen

journalctl -f -u user@1000.service -u sshd.service

Du kannst auch gleich in den Diagnosemodus booten. Dazu sollte grub eine Option anbieten. Aber meiner Erfahrung nach ist das setzen von multi-user.target als default.target (wie oben beschrieben) und die debug-shell schon Debug-Möglichkeit genug, um das System näher zu analysieren.

Code: Alles auswählen

journalctl -b

liefert dir übrigens das Journal mit sämtlichen Bootmeldungen von Laden des Kernels an. Die Option -b schränkt es auf den aktuellen Boot ein.
-b-1 würde dir das Journal des vorangegangenen Boots zeigen. Wenn du also erfolgreich in die Debug-Shell ohne graphischer Oberfläche kommst, kannst du mit

Code: Alles auswählen

journalctl -b-1

eventuell sogar die Absturz/Einfrierursache des vorhergegangenen Freezes analsysieren.
Dazu musst du aber das Verzeichnis /var/log/journal als root anlegen und den Freeze einmal verursachen.

Aus dem Diagnose-Modus kommst du übrigens mit

Code: Alles auswählen

systemctl graphical.target

in den graphischen Runlevel...

Ich hoffe das reicht dir erstmal für eine Diagnose.

lg scientific

PS: systemd war vor zwei Jahren noch extrem stark in Entwicklung. Und jede Version brachte neue Befehle mit sich und ließ andere wegfallen. Aber seit einem guten Jahr ist die API ziemlich stabil. Sich aufgrund änderndern Features nicht damit beschäftigen zu können ist genauso eine Ausrede, wie Linux nicht installieren zu können, weil es so schwierig ist - weil es Ende der 1990er wirklich schwierig war. Aber die Realität ist schon lange eine andere...

PPS: Ich habe auch Skripte paketiert, die direkt eine Abhängigkeit zu systemd verursachen. Und du kannst sie nicht installieren und nutzen, wenn du systemd nicht haben möchtest.
Die Frage ist nur - ist es eine Glaubensfrage, und ist systemd jetzt böse, weil meine Software ohne systemd nicht funktioniert?
Die Antwort ist relativ einfach: Ich verwende zur Steuerung meiner Backups nicht cron sondern instanziierende Systemd-Units. Denn das ist praktisch. systemd macht da einen ziemlich guten Job und ich kann meine Dienste auch schön überwachen. systemd ermöglicht mir auch eine äußerst einfach abfrage, welches Backupintervall aktiviert ist, und welches nicht - und ich kann mit dem output eine gnome-shell-extension füttern, die mir zeigt, welche Intervalle ich konfiguriert habe und welche aktiv sind und welche momentan gerade ein Snapshot von meinem System machen. Ohne systemd ein ungleich größerer Aufwand... daher die Abhängigkeit zu systemd. Und ich vermute einmal, dass die Mehrzahl der Software auf meinem System, welche eine Abhängigkeit zu systemd hat, ebenfalls nur deswegen so eine Abhängigkeit hat, weil die Dienste mit systemd gestartet und gestoppt werden und deshalb units vorhanden sind die von systemd verarbeitet werden.

lg scientific

[Revod]

@ scientific

Ich danke Dir für die Anleitung

( Der Weg dafür so wie Du es sehr einleuchtend erklärt hast heraus zu finden ist für mich schwierig, weil 1. ich mich in englische Ausdrücke richtig verstehen und im Satzsinn auch müss kann ich nicht und 2. ich Null Ahnung vom Programmieren habe und noch weniger davon über Ausdrücke im Code was diese bewirken und wie " eben das dazu gehörende Hintergrund Wissen " ).

Vor 30 Jahren war alles " schwierig " zu installieren....

Ich kann für mich nur den Weg gehen, von Distri nehmen, die es mit meiner HW können, was glücklicherweise noch möglich ist. Der ganze Aufwand jedoch hat wenig Sinn, weil wenn eines meiner Rechner ausfällt ich noch 3 in Reserve habe die ca. um 5 Jahre jünger als meine beiden erwähnte und 2. was heute zutrifft ist in ca. 2 bis 3 Jahre alles nicht mehr gültig, weil es wird sehr rasches neues heraus gebracht ( Praktisch um für die gleichen Ergebnisse zu erzielen ). Ich in meinen Alter mich nicht mehr zum " Speissrutenläufer " machen lasse, auch aus mangelndes Wissen über das " tiefe System Hintergrund "

Es ist keine Ausrede, manche Hürden sind für manche Leute schlichtweg unüberwindbar, sei es aus fehlendes Verständnis über der Materie und anderes zusammenhängendes Hintergrund Wissen usw.

Wenn Systemd alle Dienste steuert stellt sich auch die Frage ob " chkconfig " Tool noch notwendig ist.

Ich will Dich nicht Unrecht vermitteln, auch ich denke, was man selbst nicht versucht hat zu meistern bleibt es für einen selbst für immer weg. Und auch Du solltest von mir wissen, ich gebe erst dann auf wenn ich mich eingestehen muss, " das wächst mich nun wirklich über den Kopf, oder in irgend einer Weise mich ab einen bestimmtes Moment überfordert " ( Testing hätte ich in den letzten 4 sicher 2 mal aufgeben können, " Zu dieser Gelegenheit, wo bleibt unser " Freund joahlen " er hatte es mir Mal die Aufgabe empfohlen, doch habe es immer wieder geschafft zurecht zu biegen )

Der Fuji dient als Rserve meines " uraltes, kleines " Notebook, ca. 17 Jahre, der seinen Dienst immer noch sehr gut verrichtet, auch nur mit PCLinuxOS 32 bit. Die 3 Reserve Rechner ( nicht im Gehäuse verbaut, sondern nur als Komponente vorhanden ) sind 1 davon 8 J 2 CPU und 2 5 J. und haben 4 CPU mit " modernere " Chipsätze. Aus dem Grund belasse ich es, auch weil wenn wirklich was neues dazu gekauft werden muss auch ich für 64 bit mich entscheiden werde, ist nichts anderes im Angebot ( Für reine Desktops Anwendungen würde 32 bit immer noch mehr als genug ausreichen, meine Meinung ). Und dann sind ganz andere Gegebenheiten vorhanden und somit einen anderen " Weg " Ablauf.

Die Frage ist nicht ob " Du mit Deinen Systemd abhängige Scripte " oder Systemd böse ist. Genau das was Du auch schreibst vermute ich eben auch, nämlich Befehle hinzugefügt und andere ältere Befehle weg programmiert Und mit letzteres bestätigst Du doch meine " Behauptung " der ältere HW Kompatibilität, weil mit ältere Systemd Versionen mein Notebook keinen Blackscreen hatte. Sondern eher, warum nur diese, als das eine und als einzige Werkzeug Lösung? Warum so schnell, bevor wirklich nicht das meiste davon ausgetestet wurde? Und warum alte Befehle weg programmieren, wenn diese für neue Chipsätze keine Rolle spielen würden doch für ältere essentiell sein könnten ( Genau so wie mit Kernel Module Politik die man eventuell zu rasch raus schneidet )?

Das ist das was mich so stört, diese " arrogante hohe Geschwindigkeiten " über was man " gebrauchen hat " und was nicht mehr für " mich " gut sein soll. Ich finde, wenn es doch schon vorhanden und niemandem stört, belangt oder sonst was dann belasst es doch enthalten.

Vielleicht trifft es einen Befehl, der durch einen neuen Ersetzt wurde. Nun, würde ich dieses neuen Befehl auf meine HW wieder anpassen, nach dem debuggen heruas gefiltert könnte es durchaus sein, dass wieder auf etwas anderes nicht mehr übereinstimmen würde und aus dieser Vermutung heraus ist es auch einen Grund warum ich es gut sein lassen möchte ( Unnötiges Aufwand, der vielleicht nicht nur an einen Grund liegen könnte und joa es kommen sehr rasch wärmere Tage wieder, die der " Nase " zu anderem inspirieren lässt ).

Trotzdem, nochmals vielen Dank.

[scientific]

Ich mag es auch nicht, wenn funktionierendes aufgegeben wird. Außer, das neue ist "geil"...

Für mich ist es so, dass ich anfänglich - auch aufgrund des Naserümpfens hier im Forum - über Pöttering und systemd sehr sehr skeptisch war. Heute muss ich mir eingestehen, ich war voreingenommen, ohne das Ding überhaupt zu kennen.

Hab mich dann, als es in Jessie aufgeschlagen ist, einmal eingehend damit beschäftigt. Ja und ich hab nur widerwillig systemctl disable blalba.service getippt, wenn man doch auch einfach einen Symlink in ein bestimmtes Verzeichnis setzen oder löschen kann... nicht viel anderes tut systemctl enable/disable... Aber dieser Befehl setzt das halt immer ins richtige Verzeichnis. Und gibt man mehrere Units an, dann macht der das gleich für mehrere.

Und so bin ich dann hinter das Konzept gestoßen und es begann mir zu gefallen.

Klar geht manches mit einer einfachen Zeile in der crontab oder in der fstab einfacher. Oder auch eine Zeile in rc.local ist einfach. Aber im Gesamtkonzept löst das systemd schon sehr sehr fein. Ich kann mounts über die fstab lösen - aus der systemd dann mit einem Generator mount.units baut. Ich kann aber auch manuell mount-Units zusammenbauen, die dann in Abhängigkeit von einem eingesteckten Netzteil oder dem Laufen des NetzwerkManagers oder was auch immer mir für eine Abhängigkeit einfällt, ein Verzeichnis mountet - auch für User...

So hab ich mir ein fuse-Filesystem programmiert, welches die Snapshots vom lokalen BTRFS-Store und einer externen Platte zusammen in ein Verzeichnis mapped.
Da ich auch kein Programmierer bin, war das eine ziemliche Herausforderung.

Aber jetzt hab ich ein Filesystem, welches ich dem User zum Mount vorwerfen kann, und er bekommt in $HOME/backup alle (externe wie interne) Snapshots nur seines eigenen Homes angezeigt. Das realisiere ich mit einer systemd.service, welches in das allgemeine Verzeichnis für User-Prozesse von systemd gelegt wird. Dieses Service wird beim Login automatisch gestartet, und der User kann sofort in seine Backups.
Dazu lege ich lediglich einen Link im deb-Paket an der richtigen Stelle ab, und es funktioniert wie es soll. Kein Parsen der vorhandene User, oder sonst irgendwelche umständlichen Krücken, dieses Filesystem beim Login zu mounten und beim letzten Logout wieder zu unmounten. Das macht systemd für mich - sogar ohne Mount-Unit. Über die fstab ist sowas überhaupt nicht zu realisieren...

Oder das saubere Beenden aller von mir gestarteten Prozesse nach dem letzten Logout... mit systemd kein Problem. Sogar das sich daraus ergebende Problem mit screen oder tmux konnte ich sauber lösen.

Nach wirklich eingehender Beschäftigung mit dem Ding hab ich systemd wirklich zu schätzen gelernt. Und die Probleme dass das System beim Runterfähren oder Booten hängt und keiner weiß warum, kann man mit der debug-shell, systemctl und loginctl analysieren und dann lösen.
Ich hatte auch solche Schwierigkeiten - immer wieder mal. Und ich bin verzweifelt. Aber nachdem ich mich damit beschäftigt habe, ging es auf einmal viel leichter als zuvor. Wo findest du denn die Logmeldungen vom Boot-Screen bei initv? Das geht mit systemd und journald.

Ich bin auch richtig froh gewesen, dass vor 2, 3 Jahren die Entwicklung so rasch voranging. Denn ich vermisste einige Features ziemlich und dachte mir "ach so ein Scheiß dieser systemd... kann fast alles, aber dann doch nicht, und das wesentliche fehlt...", und siehe da, zwei, drei Versionen später war das Feature implementiert... Wenn da die Entwicklung so langsam wie bei Gimp wäre, wär das Projekt sicher zum Scheitern verurteilt gewesen... Aber so ist da ein System herangewachsen, dass mittlerweile echt viel kann. Und weil es so viele Distributionen rasch einsetzten, konnten auch viele Fehler gefunden und ausgebessert werden - bzw. Features implementiert werden, die das Ding sehr komfortablen machen.

Wenn man halt Jessie ohne Backports einsetzt, dann hat man eine URALT-Version am Start, die 1. viele Fehler hat und der 2. viele Features fehlen... Von diesem Status auf systemd zu schließen ist wie über die Ineffizienz im Buchdruck zu sprechen, wenn man als Vergleich bloß Gutenbergs erste Druckerpresse kennt, aber vom Diskonter ums Eck die bunte Reklame sieht... Da fragt man sich dann auch, wie das gehen soll.

Soweit so gut. Ich hoffe, ich konnte dir gute Anregungen zum Weiterforschen geben. Ich helf auch gerne mit Rat und Tat weiter.
Aber in einem anderen Thread.

lg scientific

[Revod]

...
Soweit so gut. Ich hoffe, ich konnte dir gute Anregungen zum Weiterforschen geben. Ich helf auch gerne mit Rat und Tat weiter.
Aber in einem anderen Thread.

lg scientific

Mit dem was Du schreibst bestätigst meine Vermutungen, worüber ich unsicher war.

Ok, den Vorteil habe ich durch Deine Beispiele verstanden und doch, Du musstest sehr viel Zeit investieren bis Du die Benutzer ... §HOME/ soweit mit einer einfache Ausführung einrichten konntest um auch alle Prozesse des ausgeloggten Benutzer zu beenden ( Ginge auch mit einen Neustart, ok, der etwas mehr Zeit braucht ).

Genau in dieses Sinn rede ich über meine, für mich Überforderung. Solche essentielle Grundfunktionen über einen Dienst den wenn man es schon einbaut auch mit bedenken und mit der Benutzbarkeit fertig entwickeln sollte. Und nicht nur unzählige Dienste, die einige dann entweder ins leere führen, oder nur halbwegs funktionieren, weil das Anfang bis zum Ende des Kreises nicht geschlossen ist ( Ich kann es nur auf diese Ableitung Art erklären ), und dann wie Du beschrieben hast noch das fehlende Teil selber programmieren musst, wir Benutzer es müssen.

Und bei solche Fälle wie bei mir wird es schon " relativ " umständlich mit dem VPN und SSH, was ich nicht sooo gerne einrichten möchte, wegen meine Bedenken über eine weitere, mögliche Sicherheitslücke wegen eines zusätzliche Remote Anbindung Anwendung. Und jepp, es ist richtig, Systemd kam erst lange nach meinen beiden genannte Rechner als erste Version heraus. Gebe zu, im ersten Moment war es für mich schon sehr ärgerlich, als plötzlich Blackscreen eintrat, doch alles getestet kann man auch nicht, weil die Rechner nicht mehr im Handel sind und bin schon tollerant gegenüber. Nur wie schon gesagt, altes Belangloses für neue HW, die noch alte HW unterstützen würde nicht einfach aus dem Kernel und Systemd raus schneiden. Wenn man bedenkt, dass neue HW Generation Zyklus im Schnitt alle 3 Jahren ist wären es für bis zu 21 jährige Rechner durchaus machbar ( 21 : 7 mal mehr Implementationen für ältere HW, ich denke so wären bis zu 21 jährige Rechner abwärts kompatibel und natürlich mit der Berücksichtigung der bit Version 32 bit ).

Ich denke bevor Deine Hilfe greifen kann muss der Benutzer erst Mal sich selber mit Systemd beschäftigen und Schritt für Schritt erst ab dem Punkt wo man selbst wirklich nicht weiter kommt um Hilfe anfragen ( Mich überfordert es wegen meiner Zeit, keine englische Sprache, meine Schwäche Befehl Ausdrücke und dessen Sequenzen zu behalten daher auch meine Schwäche mit dem Terminal usw. Z. B. für wiederkehrende Befehle habe ich mir GTK-Dialog UI Scripte gebastelt, die funktionieren und die Knöpfe entsprechend betitelt und dort wo der Titel zu lange würde, nicht genügt unmittelbar unterhalb des Knopf eine kurze, klare Ausführung Beschreibung geschrieben ( Erst später habe ich gelernt wie das mit dem Tooltipp im GTK-Dialog funktioniert ). Syntax des GTK-Dialog Code habe ich mir abgeguckt und mit den Reiter sicher 2 Wochen lang geübt, bis ich die UI einheitlich hinbekommen habe ).

Und so wie Du es beschreibst erinnert es mich, so fern es auch sein mag, an die " registry " des... und ich war so froh das Teil durch Linux los zu werden.... Kann mir vorstellen, man muss nochmal die " Schulbank " drücken....

Joa, soweit so gut Du hast Recht, es ist in der Tat ein ganz anderes Thema. Ich danke Dir sehr für Deinen Angebot.

[scientific]

...
Soweit so gut. Ich hoffe, ich konnte dir gute Anregungen zum Weiterforschen geben. Ich helf auch gerne mit Rat und Tat weiter.
Aber in einem anderen Thread.

lg scientific

Mit dem was Du schreibst bestätigst meine Vermutungen, worüber ich unsicher war.

Ok, den Vorteil habe ich durch Deine Beispiele verstanden und doch, Du musstest sehr viel Zeit investieren bis Du die Benutzer ... §HOME/ soweit mit einer einfache Ausführung einrichten konntest um auch alle Prozesse des ausgeloggten Benutzer zu beenden ( Ginge auch mit einen Neustart, ok, der etwas mehr Zeit braucht ).

Genau in dieses Sinn rede ich über meine, für mich Überforderung. Solche essentielle Grundfunktionen über einen Dienst den wenn man es schon einbaut auch mit bedenken und mit der Benutzbarkeit fertig entwickeln sollte. Und nicht nur unzählige Dienste, die einige dann entweder ins leere führen, oder nur halbwegs funktionieren, weil das Anfang bis zum Ende des Kreises nicht geschlossen ist ( Ich kann es nur auf diese Ableitung Art erklären ), und dann wie Du beschrieben hast noch das fehlende Teil selber programmieren musst, wir Benutzer es müssen.

Das stimmt so nicht.
Als "normaler" User müsste ich überhaupt nix programmieren. Ich hab mich in systemd eingearbeitet, weil es mich interessierte, weil ich schon zuvor meinen fvwm ziemlich gepimpt habe und Spaß an der Freude habe, das Zeugs zu verstehen und zu verbessern.

Wenn Software neu ist, fehlt natürlich noch dies und das, und das und das andere ist noch nicht entwickelt, weil der Bedarf noch nicht aufgetaucht ist. Systemd hat gerade für die "Übergangszeit" Generatoren mitgebracht, um die alten sysV-Init-Skripte, um die Mounts aus /etc/fstab usw. nahtlos übernehmen zu können, was auch im Großen und Ganzen gut funktioniert. Meine Erfahrung ist, dass mit systemd native Units oft schneller und einfacher sind, als ein sysv-Skript zu starten bzw. wie die programmiert sind. Was im Shellskript oft in vielen Zeilen abgefragt wird (z.B. den Stromversorgungsstatus) wird mit systemd in einer einzigen Zeile gelöst. (Hab mir auch einige init-Skripte angeschaut um daraus dann bisher noch fehlende native Units zu bauen, weil es sie vom Paketbetreuer noch nicht gibt). Das hab ich selber programmiert - war aber einfach eine Fleißaufgabe.

Und bei solche Fälle wie bei mir wird es schon " relativ " umständlich mit dem VPN und SSH, was ich nicht sooo gerne einrichten möchte, wegen meine Bedenken über eine weitere, mögliche Sicherheitslücke wegen eines zusätzliche Remote Anbindung Anwendung. Und jepp, es ist richtig, Systemd kam erst lange nach meinen beiden genannte Rechner als erste Version heraus. Gebe zu, im ersten Moment war es für mich schon sehr ärgerlich, als plötzlich Blackscreen eintrat, doch alles getestet kann man auch nicht, weil die Rechner nicht mehr im Handel sind und bin schon tollerant gegenüber. Nur wie schon gesagt, altes Belangloses für neue HW, die noch alte HW unterstützen würde nicht einfach aus dem Kernel und Systemd raus schneiden. Wenn man bedenkt, dass neue HW Generation Zyklus im Schnitt alle 3 Jahren ist wären es für bis zu 21 jährige Rechner durchaus machbar ( 21 : 7 mal mehr Implementationen für ältere HW, ich denke so wären bis zu 21 jährige Rechner abwärts kompatibel und natürlich mit der Berücksichtigung der bit Version 32 bit ).

Ich denke bevor Deine Hilfe greifen kann muss der Benutzer erst Mal sich selber mit Systemd beschäftigen und Schritt für Schritt erst ab dem Punkt wo man selbst wirklich nicht weiter kommt um Hilfe anfragen ( Mich überfordert es wegen meiner Zeit, keine englische Sprache, meine Schwäche Befehl Ausdrücke und dessen Sequenzen zu behalten daher auch meine Schwäche mit dem Terminal usw. Z. B. für wiederkehrende Befehle habe ich mir GTK-Dialog UI Scripte gebastelt, die funktionieren und die Knöpfe entsprechend betitelt und dort wo der Titel zu lange würde, nicht genügt unmittelbar unterhalb des Knopf eine kurze, klare Ausführung Beschreibung geschrieben ( Erst später habe ich gelernt wie das mit dem Tooltipp im GTK-Dialog funktioniert ). Syntax des GTK-Dialog Code habe ich mir abgeguckt und mit den Reiter sicher 2 Wochen lang geübt, bis ich die UI einheitlich hinbekommen habe ).

Nun, du hast gelernt, wie du GTK-Dialoge programmierst, fühlst dich aber von systemd überfordert... das erstaunt mich jetzt

Pöttering behauptet ja oft, dass Software "falsch" programmiert wäre, und sie machen es richtig. Bei screen hab ich das verstanden, wie das gemeint ist.

Die Geschichte, dass Prozesse, die vom User gestartet werden, mit dem Logout auch zuverläsig wieder beendet werden ist durchaus ein Sicherheitsmerkmal. Blöd nur, dass screen aber genau das nicht soll. Es soll weiterlaufen, damit ich mich an anderer Stelle wieder einloggen kann - obwohl ich zwischendurch ausgeloggt war... Schließt sich also gegenseitig aus.

Im Zuge der Recherche habe ich dann gelernt, dass das mit den Userprozessen seit 40 Jahren tatsächlich falsch gemacht wird. Auf großen Servern ließ der Admin offenbar einmal die Woche ein Skript laufen, das alle Prozesse von Usern beendet, die eigentlich gar nicht eingeloggt sind.
Ein Beispiel ist der Zeitgeist Datahub, das hplip Systemtray und andere Prozesse, die per xdg-autostart gestartet werden, die aber beim Ausloggen nicht beendet werden und einfach weiterlaufen.

Seit kurzem ist bei systemd eine Default-Einstellung, dass Userprozesse beim letzten Ausloggen gekillt werden.
Die Einstellung findest du in der Datei /etc/systemd/logind.conf als "KillUserProcesses=yes"
Diese Einstellung hat aber zur Folge, dass auch screen oder tmux beim Logout gekillt wird und ein relogin in die bestehende Session nicht mehr möglich ist... Gab ein großes Bahö und Debian hat die Einstellung wieder auf "no" gestellt.

Dabei wäre es so einfach... eine Unit für den System-systemd, welche eine screen-Session für den User startet, die außerhalb des User-systemd läuft. Die wird nämlich von root verwaltet, läuft aber als der User und wird NICHT gekillt, wenn sich der User ausloggt.
Das sind aber Feinheiten, die erst beim "tun" an die Oberfläche kommen. Das fördert auch tradierte schlechte Gewohnheiten und unsystemisches Verhalten zu Tage und stößt natürlich jene vor den Kopf, die diese schlechten Gewohnheiten seit Jahrzehnten pflegen... Und damit durchaus auch eine Sicherheitslücke aufreißen.

Jetzt kann man natürlich auch diskutieren, ob screen so gestartet nicht auch eine Sicherheitslücke darstellt... aber das ist eine Lücke und nicht 10 Lücken wenn 10 Prozesse ohne mein Wissen nach dem Logout weiterlaufen. Ich war sehr erstaunt, was da noch alles weiterläuft, nachdem ich mich ausgeloggt habe...

Und so wie Du es beschreibst erinnert es mich, so fern es auch sein mag, an die " registry " des... und ich war so froh das Teil durch Linux los zu werden.... Kann mir vorstellen, man muss nochmal die " Schulbank " drücken....

Joa, soweit so gut Du hast Recht, es ist in der Tat ein ganz anderes Thema. Ich danke Dir sehr für Deinen Angebot.

Von der Registry sind wir aber weit entfernt... systemd stellt eine einfache, skriptingfähige Schnitstelle zur Verfügung. Ich kann systemd skipten, und ich kann Skripte in System verwenden... das geht in der Registry so nicht... Ich hab da immer wieder mit irgendwelchen cryptischen Einträgen zu tun die nicht dokumentiert sind, und eine Art Magie darstellen... Systemd ist gut dokumentiert (ja, Englisch sollte man derzeit dazu schon können) und bei Weitem nicht so kryptisch wie die Registry...

lg scientific

[Revod]

Ok alles klar...

Nöö, ich kann aus dem Stegreif keine GTK-Dialoge Programmieren. Ich brauche erst Mal eine Syntax Vorlage in der ich die kompletten Code Abschnitte umbauen kann um z. B. einen neuen Tab in der UI zu erzeugen. Syntax Fein Programmierung um zu bauen brauche ich dann Internet und deutsche Dokumentation und Beispiele, und viel Geduld und das immer wenn ich eine neue Idee habe, das könnte ich auch " Guifizieren "

Und wegen Dein Zitat was habe ich falsch verstanden ( oder Du mich )?

...
So hab ich mir ein fuse-Filesystem programmiert, welches die Snapshots vom lokalen BTRFS-Store und einer externen Platte zusammen in ein Verzeichnis mapped.
Da ich auch kein Programmierer bin, war das eine ziemliche Herausforderung.
...

[scientific]

Ok alles klar...

Nöö, ich kann aus dem Stegreif keine GTK-Dialoge Programmieren. Ich brauche erst Mal eine Syntax Vorlage in der ich die kompletten Code Abschnitte umbauen kann um z. B. einen neuen Tab in der UI zu erzeugen. Syntax Fein Programmierung um zu bauen brauche ich dann Internet und deutsche Dokumentation und Beispiele, und viel Geduld und das immer wenn ich eine neue Idee habe, das könnte ich auch " Guifizieren "

Und wegen Dein Zitat was habe ich falsch verstanden ( oder Du mich )?

...
So hab ich mir ein fuse-Filesystem programmiert, welches die Snapshots vom lokalen BTRFS-Store und einer externen Platte zusammen in ein Verzeichnis mapped.
Da ich auch kein Programmierer bin, war das eine ziemliche Herausforderung.
...

Dieses Fuse-Filesystem für das Backup-Skript hab ich selbst gemacht. Auch die systemd-Units dazu und das Backupskript natürlich auch.

Aber das hat im Prinzip nix mit systemd für "normale" User zu tun. Als Entwickler (ich bin nur Hobby-Entwickler in meiner Freizeit) aber kann man systemd wunderbar einsetzen - dazu muss an sich aber auch einarbeiten - was ich getan hab

Aber ist es nicht so, dass man sich in jedes komplexe System erst einmal einarbeiten muss? Selbst initv mit den Init-Skripten bedürfen eingehender bash-Kenntnisse, die man zuerst einmal erwerben muss. Und InitV selber muss man auch erst Mal behirnen.

Wenn man genau hinschaut, unterscheiden sich systemd und SysV schon sehr, aber es gibt auch Parallelen. Auf der einen Seite gibt es Unit-Files, auf der anderen Seite werden diese per Symlink in Verzeichnisse gelinkt, von wo sie dann abgearbeitet werden.
InitV-Skripte haben ein relativ komplexes System an Abhängigkeiten in die Files vor ein paar Jahren verpasst bekommen, welches die Symlinks in den rc-Files irgendwie umgeangen sind, dann doch wieder nicht... und ich hab das ehrlich gesagt nie ganz durchschaut. Es gibt für sysV ja auch Verwaltungsprogramme, welche die Symlinks in die rc-Verzeichnisse setzen, so ähnlich wie systemctl. Ich vermute einmal, dass die systemd-Entwickler sich da durchaus gute Ideen aus dem SysV geholt haben.

Die Anzahl der Unit-Files in den Verzeichnissen von systemd sind durchaus nicht mehr überschaubar, das sind jene in /etc/init.d/ auch nicht. Aber eine systemd-Unit zu verstehen, schafft bald einmal jemand. Exec, After, Before, Wants, WantedBy... alles aussagekräftige Bezeichner. Und so lange sind die Units nicht.

Durchschau einmal jemand ein init-Skript! Bei vielen braucht man schon tiefergehende bash-Kenntnisse. Dann sind in die init-Skripte Helper-Skripte gesourced. Die blähen den Code wiederum mehr auf. Und die muss man auch einmal erst verstehen, bevor man sie einsetzt. Und die Header... Kommentare im Bash-Skript, die dann doch keine Kommmentare sind?? Ist doch unlogisch.

Ganz ehrlich... System-V ist nicht wirklich "einfacher" als systemd. Aber für geübte Admins ist es gewohntes Terrain... Und dieses verlassen offenbar wenige wirklich gerne.

lg scientific

[clue]

Wie schafft Microsoft es bloß, das so zu versemmeln?

Wie man das letztlich schafft, wird wohl deren Geheimnis bleiben. Mit Softwarequalität hat das zumindest wenig gemein, aber der folgende Link könnte das etwas beleuchten zum besseren Verständnis.

https://superuser.com/questions/890038/ ... te-so-slow

Hey, vielen Dank für den Link! Der war wirklich hilfreich dabei zu verstehen, wie zermurkst die gesamte update Politik von MS wirklich ist.

Beispiel: Weshalb sollte es MS kümmern, was für 3-party-software auf den Maschinen installiert ist? Die sollen sich einfach um ihr besch* Betriebssystem kümmern, und sonst nichts. Ob dann noch Photoshop läuft oder nicht, das ist doch nicht deren Sache. Wenn MS die updates sauber abgeliefert hat (also funktionierend) und sie damit ihre Fehler korrigiert haben, so muss sich dann entweder der Anwender oder Photoshop selbst darum kümmern, ob und wie ihre 3-party-software noch läuft.

Die Linux-Philosophie ist (war): 1 Program für genau 1 Zweck - keep it plain and simple. Und darum klappt das Aktualisieren mit apt auch so schnell und zuverlässig, im Gegensatz zum Murks von MS. Die haben ihren Schei* einfach viel zu hyperkompliziert und somit nicht mehr handhabbar zurechtgestümpert.

@scientific
Ich bin wirklich froh, dass Du Dich als Systemd-Versteher geoutet hast . Ich habe nämlich seit Jahren einen echt mega fiesen bug, der es mir nur bei jedem 3. booten erlaubt, auch tatsächlich erfolgreich zu sein. Könnte ich Dich eventuell die Tage mal um Hilfestellung beim debugging für das Debian BTS ersuchen? Vielleicht machen wir einen öffentlichen Thread draus, damit andere exemplarisch sehen können, wie man solch fiese bugs mithilfe von Systemd BTS-tauglich analysieren kann? Ich würd mich dann bei Dir dann per persönlicher Nachricht melden. Ich bin momentan aber etwas sehr beschäftigt, deswegen dauert alles bei mir etwas länger

[ViNic]

Wie schafft Microsoft es bloß, das so zu versemmeln?

Wie man das letztlich schafft, wird wohl deren Geheimnis bleiben. Mit Softwarequalität hat das zumindest wenig gemein, aber der folgende Link könnte das etwas beleuchten zum besseren Verständnis.

https://superuser.com/questions/890038/ ... te-so-slow

Hey, vielen Dank für den Link! Der war wirklich hilfreich dabei zu verstehen, wie zermurkst die gesamte update Politik von MS wirklich ist.

Beispiel: Weshalb sollte es MS kümmern, was für 3-party-software auf den Maschinen installiert ist? Die sollen sich einfach um ihr besch* Betriebssystem kümmern, und sonst nichts. Ob dann noch Photoshop läuft oder nicht, das ist doch nicht deren Sache. Wenn MS die updates sauber abgeliefert hat (also funktionierend) und sie damit ihre Fehler korrigiert haben, so muss sich dann entweder der Anwender oder Photoshop selbst darum kümmern, ob und wie ihre 3-party-software noch läuft.

Gut okay ... aber ich denke mir einfach jetzt folgendes. Würden sie den Weg der Linux Welt gehen, wären sie nicht dort wo sie sind. Was ich auch etwas schmerzlich lernen musste, das es das richtig oder falsch in der Softwareentwicklung nicht wirklich gibt. Es ist vollkommen Wurst, ob der Code schön ist, sich nicht wiederholt, den CleanCode-Richtlinien entspricht, Objektorientiert, Funktional oder reinster Spaghetti Code ist .... wenn es funktioniert, ist das eine gute Lösung.

Das deren Update-Prozess mag kompliziert sein, weil es 3rd Party Software beachtet und sonst was wird (habe den link da oben nicht gelesen), aber es hinterlässt ein funktionierendes System. MacOS geht eine ähnlichen Weg. Man kann unter Windows und MacOS auch ältere Software installieren, bzw. es wird noch ältere Software unterstützt. Bei Linux und Debian, mit der "angeblich" perfekten Lösung, funktioniert nach einer kurzen Zeit mit der externen Software schon nichts mehr. Ich habe keine gekaufte Software und auch zum Teil Hardware(Drucker) für Linux, das heute noch läuft.

Mein Laserdrucker kaufte ich zu Zeiten von Windows XP und wird auch unter Windows10 mit Treibern versorgt. Der selbige Drucker funktionierte auch unter Debian Etch, mit basteln unter Debian Lenny und ab Squeeze gar nicht mehr. Unter Linux also vielleicht 3 Jahre Spaß damit gehabt. Unter Windows min. 10 Jahre. Software genauso. Nichts was ich mir für Linux damals gekauft habe, funktioniert heute noch. Deswegen kaufe ich mir für Linux heute nichts mehr und überwiegend nur für Windows, weil ich die Erfahrung gemacht habe, das es noch in 10 Jahren laufen wird, während ich unter Linux bereits jetzt vor dem nächstem Release haben müsste.

Deswegen ... der Windows Weg mag nicht der "Perfektion" der Linux Welt entsprechen, aber er funktioniert. Der Linux Teil meist nicht, nur intern (dh. innerhalb einer Distribution wie zb. Debian) und das ist meist zu wenig. Kritisieren ist immer einfacher, als etwas zu verbessern was man kritisiert.

[clue]

Nichts was ich mir für Linux damals gekauft habe, funktioniert heute noch. Deswegen kaufe ich mir für Linux heute nichts mehr und überwiegend nur für Windows, weil ich die Erfahrung gemacht habe, das es noch in 10 Jahren laufen wird, während ich unter Linux bereits jetzt vor dem nächstem Release haben müsste.

Komisch, bei mir ist es gerade anders herum: Mein uralter HP-PSC1350-Drucker -> läuft.
Mein noch viel älterer Scanner, der noch am COM-Port angeschlossen wurde (Win95), lief unter Linux noch lange, nachdem es ab Win2000 keine Treiber mehr gab. Meine inzwischen 17 Jahre alte Webcam von Logitech -> läuft bis heute wunderbar.