Hallo. Ich wollte definitiv die Windows Welt verlassen und auf MINT wechseln.Ich habe mich bisher durch alle 'Widrigkeiten' durchgemogelt. Soweit alles gut. Aber: Einen Netzwerkdrucker (HP1132 MFP) auf dem Testrechner anzusteuern gelingt mir nicht. Gefunden wird der Drucker, Unter Mint sind alle Treiber auf dem neuesten Stand. Schon beim Drucken der Testseite sagt mir das System nach einer Weile dass irgendeine Berechtigung fehlt und ich weiss nicht wo ich sowas einzustellen habe. Ich habe das allerletzte 20.3 Mint installiert,viele webseiten gelesen ... aber keine Lösung gefunden. Ich will noch immer weg von Windows, die 10er und 11er habe ich niemals installiert. (( Aber mal so gesagt: solche Troubles hatte ich bei Windows niemals mit Druckern )) Ist das das Druckerproblem "versionsbehaftet" oder ist da irgendwo ein Bug ? Thomas
Thomas L. schrieb: > Schon beim Drucken der Testseite sagt mir das System nach einer Weile > dass irgendeine Berechtigung fehlt und ich weiss nicht wo ich sowas > einzustellen habe. Das sagt das System? Das das das kann. ›Dir fehlt irgendeine Berechtigung‹ Drücke irgendeinen Knopf. Wie findet man beim Auto den platten Reifen? Im Kreis tauschen und schauen ob der Fehler mitwandert!
Und dann noch die Frage: Ist die HPLIP installiert? (Kein Schreibfehler, LIP nicht LIB)
Danke Norbert für die Ermunterung, Windoofs User sind ja Spott in und aus der Linux Welt gewohnt ;) Warum ich umsteige? Unter Windows gehört meine Machine Microsoft, und das will ich nicht wirklich. Ich habe eine ganze menge Projekte in Harbour und die sind eher in Linux "zu Hause" - also späte Einsicht ... aber doch Einsicht. :) Jupp, die HP-Teile sind installiert, auch der GUI Teil. Ich habe vom Druck & Berechtigungssystem unter MINT ... NULL Ahnung. Aber Drucken möchte ich schon.
Thomas L. schrieb: > Danke Norbert für die Ermunterung, Windoofs User sind ja Spott in und > aus der Linux Welt gewohnt Anscheinend zu Recht - nicht einmal das Wort "Linux" können mache unfallfrei schreiben.
Thomas L. schrieb: > Danke Norbert für die Ermunterung, Windoofs User sind ja Spott in und > aus der Linux Welt gewohnt ;) Ja, aber lieb gemeinter Spott. ;-) Hilf uns doch einfach mal mit der präzisen Fehlermeldung. Das soll manchmal Wunder wirken, vielleicht auch dieses Mal.
Noch etwas, es dürfte ja mutmaßlich CUPS (Common Unix Printing System) installiert sein. Das kannst du mit 'nem Browser unter localhost:631 erreichen.
Hi Norbert ... Ich werde mal das ganze System neu aufsetzen und screen shots machen. Übrigens: Wenn ich den Drucker local anschliesse "findet" Mint das Teil und druckt die Testseite.. Und ich werde zu MINT wechseln, ich werde das schon hinbekommen. Danke Norbert --> thomasleu.hh@gmail.com Thomas
" (( Aber mal so gesagt: solche Troubles hatte ich bei Windows niemals mit Druckern ))" Und das ist erst der Anfang:-) Und dann noch der Spaß mit der hochnäsigen Community Bitte Bitte teile uns mit, wenn du wieder zurück zu Windows gehst. Die linux Gemeinde meint nämlich alle steigen auf Linux um und wundern sich weshalb es bei 1,5% Marktanteil rumdümpelt Weil eben, so gut wie nie, jemand mitteilt, das der Wechsel gescheitert ist und sie es mit Linux vielleicht..mal wieder in 10 jahren versuchen, wenn es vielleicht mal so weit ist Und NEIN, Android, Server etc sind NICHT bei diesen 1,5%, den um diese Systeme geht es hier nicht!
hiya KArl Fred M. .... nö...ich halte mich vom Stress fern - und ich will ja MINT und wenn der Preis dafür ein paar nett gemeinte Jokes sind ... passt das. Ich lerne dazu und werde mein Wissen weitergeben. Ich denke dieser Gedanke ist mehr LINUX- als WINDOWS- Welt. neues lernen ist immer doof... Thomas
KArl Fred M. schrieb: > Und das ist erst der Anfang:-) > Und dann noch Befürchte mal Dein Post wird wohl wieder eine Diskussionslawine Win vs. Linux los treten.
Thomas L. schrieb: > Hi Norbert ... > > Ich werde mal das ganze System neu aufsetzen und screen shots machen. Scheint mir Overkill zu sein, das macht Dir Arbeit, die hochstwahrscheinlich vollkommen unnoetig ist. > Übrigens: Wenn ich den Drucker local anschliesse "findet" Mint das Teil > und druckt die Testseite.. Na, dann funktioniert er auch im Netzwerk. Wie schliesst Du den denn Local an? Per Ethernet oder USB? Zumindest Drucken auf dem Multifunktionsteil sollte nun wirklich unter CUPS einzurichten sein, kann nur sein, dass Du UFW (nehme mal an, diese Firewall laeuft da auch bei Dir) sagen musst, dass der Traffic zum Drucker erlaubt ist. Funktioniert denn ein PING auf den Drucker?
Zeno schrieb: > KArl Fred M. schrieb: >> Und das ist erst der Anfang:-) >> Und dann noch > Befürchte mal Dein Post wird wohl wieder eine Diskussionslawine Win vs. > Linux los treten. Man muss zugeben, wir hatten schon lange keine mehr :D
Thomas L. schrieb: > Einen Netzwerkdrucker (HP1132 MFP) auf dem > Testrechner anzusteuern gelingt mir nicht. Gefunden wird der Drucker, Thomas L. schrieb: > Übrigens: Wenn ich den Drucker local anschliesse "findet" Mint das Teil > und druckt die Testseite.. Das gleiche Problem habe ich mit einem HP-Laser, der am Parallelport eines Printserver steckt: WinDOOF10 findet den, setzt sogar den Druckauftrag ab, aber es wird nichts gedruckt. Direkt per USB angeschlossen, druckt er. Du kannst also nicht sicher sein, dass Windows Dein Problem löst - es sei denn, eine ältere Version vor 10. KArl Fred M. schrieb: > Und dann noch der Spaß mit der hochnäsigen Community > > Die linux Gemeinde meint nämlich alle steigen auf Linux um und wundern > sich weshalb es bei 1,5% Marktanteil rumdümpelt Da mag ich Dir nicht widersprechen. Windows wird zunehmend unbenutzbarer, weshalb ich die letzten Monate viele Stunden mit Linux verbracht habe. Linux hat Konzeptprobleme, die dessen Einsatz auf dem Desktop vermeidbar schwierig machen. Als K.O. sehe ich hauptsächlich dessen Paketverwaltung, Programme, die ich nicht nach eigenem Belieben austauschen kann. Ich soll Update / Upgrade anstoßen, ohne genau zu wissen, was dann alles umgebogen wird - das ist noch undurchsichtiger als bei Windows. Johannes U. schrieb: > Na, dann funktioniert er auch im Netzwerk. Traumtänzer! > Funktioniert denn ein PING auf den Drucker? Überflüssige Frage, weil: Thomas L. schrieb: > Gefunden wird der Drucker, Reinhard S. schrieb: >> Befürchte mal Dein Post wird wohl wieder eine Diskussionslawine Win vs. >> Linux los treten. > Man muss zugeben, wir hatten schon lange keine mehr :D Der ist eigentlich auch überflüssig, aber: KArl Fred M. schrieb: > Und dann noch der Spaß mit der hochnäsigen Community da hat Karlfred das Problem beschrieben, es wird Religion verteidigt anstatt sich der Nutzerprobleme anzunehmen.
Manfred schrieb: > Da mag ich Dir nicht widersprechen. Windows wird zunehmend > unbenutzbarer, weshalb ich die letzten Monate viele Stunden mit Linux > verbracht habe. Linux hat Konzeptprobleme, die dessen Einsatz auf dem > Desktop vermeidbar schwierig machen. Das ist gut formuliert! Speziell der letzte Satz trifft es leider recht genau. Bin selbst gerade dabei ein neues Linuxsystem aufzusetzen, weil ich für meinen BananaPi zwei Module kompilieren muß. Der Rechner ist nicht mehr ganz neu und mit einer NVidia GForce 7300 bestückt. Wird zwar vom Installer erkannt und über den Noveau-Treiber eingerichtet. Der Treiber ist leider so bugy, das ein Arbeiten damit nicht möglich ist. Von NVidia gibt es zwar probitäre Treiber die funktionieren, aber die lassen sich halt nicht so einfach unter Debian11 (Kernel 5.10.0-14) installieren. Da sitze ich auch schon mehrere Tage dran. Heute hat es wieder mal einen ordenlichen Schritt nach vorn getan, aber so richtig Freude kommt bei so etwas eben nicht auf.
Das eigentlich interessante ist, das sich die Linux kritischen Stimmen eher mehren. Wir alle haben es schon versucht und wünschten und eine Alternative zu einem Windows, nur noch ist die zeit nicht gekommen, noch lange nicht.....sehr lange... Warum aber immer mehr kritische Stimmen sich langsam mehr und mehr zu Wort melden, weiß ich auch nicht. Die Probleme von Linux waren damals noch viel größer als heute, dennoch habe ich den Eindruck das der Marktanteil eher schrumpft als stagniert. Ich bin aber dafür sehr gespannt was es stattdessen vielleicht mal geben wird. Ob es eine neue Alternative geben wird. Wird vielleicht spannend
bei mir lag es letztens mit debian an der fehlerhaften ghostscript Version. Habe die aus dem vorherigen Release genommen und es hat funktioniert. Dann noch festpinnen, sonst ist sie veim nächsten Update wieder ersetzt.
Einen Threat loszutreten liegt mir fern... Ich denke, dass alle Jobs die man auf Windows erledigen kann... auch in Linux funktionieren. Ich mag halt nicht auf Win10 oder 11 'umsteigen' - und Mint sieht so aus als wenn es eben DAS OS für Umsteiger ist. Der nett gemeinte Spott ist ok, und HILFE gibt es - (danke für die mails) !! Fazit: Problem gegen 21:00 gepostet, email veröffentlicht UND dann HILFE erhalten - also die Linux community ist nicht "hochnäsig". Punkt. ich denke jeder der mit Windows glücklich ist, soll dabei bleiben. Jeder der etwas anderes sucht ist hier GUT aufgehoben. Danke dafür. Thomas
KArl Fred M. schrieb: > Warum aber immer mehr kritische Stimmen sich langsam mehr und mehr zu > Wort melden, weiß ich auch nicht. Aus meiner Sicht ganz klar: Die Unzufriedenheit mit Windows steigt, weshalb sich immer mehr Leute Linux anschauen. Ich kenne MS seit DOS_3 und WfW_3.1, aus meiner Sicht hat es nach Win_2000 nur noch Verschlechterungen der Benutzbarkeit gegeben. Ich denke dabei nicht an meine Schwester oder Nichte, deren "ich kann Internet" sich auf Google-Aufrufe beschränkt, sondern Nutzung im gewerblichen Umfeld incl. der jeweiligen Server-Versionen. > Die Probleme von Linux waren damals noch viel größer als heute, Das ist richtig, meine ersten Versuche habe ich vor vielen Jahren stets nach kurzer Zeit mit zerschossenen Systemen aufgegeben. Das ist besser geworden, aber man braucht noch immer verdammt viel guten Willen und Forschertrieb, sich dem zu stellen. Ganz interessant zu lesen ist der IT-Mann der Stadt Schwäbisch Hall: https://www.heise.de/hintergrund/IT-Leiter-der-Stadt-Schwaebisch-Hall-Unter-Linux-leidet-die-Produktivitaet-6678160.html
Thomas L. schrieb: > Fazit: Problem gegen 21:00 gepostet, email veröffentlicht UND dann HILFE > erhalten - also die Linux community ist nicht "hochnäsig". Punkt. Und was war jetzt die Lösung?
Zeno schrieb: > Der Rechner ist nicht mehr > ganz neu und mit einer NVidia GForce 7300 bestückt. Die Geforce 7300 braucht die 304.x Treiber: https://us.download.nvidia.com/XFree86/Linux-x86_64/470.103.01/README/supportedchips.html Und die letzte Debian Version, die diese mitgeliefert hat, war Debian 9 (Stretch): https://wiki.debian.org/NvidiaGraphicsDrivers Wenn Debian das Paket bei einer neuen Debian Version rausschmeißt, dann liegt das daran, weil es mit dem neuen Kernel in der neuen Debian Version nicht mehr funktioniert. > Wird zwar vom > Installer erkannt und über den Noveau-Treiber eingerichtet. Der Treiber > ist leider so bugy, das ein Arbeiten damit nicht möglich ist. Von NVidia > gibt es zwar probitäre Treiber die funktionieren, aber die lassen sich > halt nicht so einfach unter Debian11 (Kernel 5.10.0-14) installieren. Da > sitze ich auch schon mehrere Tage dran. Heute hat es wieder mal einen > ordenlichen Schritt nach vorn getan, aber so richtig Freude kommt bei so > etwas eben nicht auf. Die Arbeit kannst du dir sparen, es wird nicht funktionieren und die Nouveu Treiber bleiben bis auf weiteres Buggy. Lösungen: 1. Du brauchst eine neue Grafikkarte. 2. Oder alternativ, du steigst zurück auf Debian 9, aber das ist schon oldoldsteable und wird laut WP nur noch bis zum 20. Juni 2022 supported. Und supported heißt hier wahrscheinlich nur das Serverzeugs und auch nicht mehr offiziell, den normalerweise ist oldstable die offiziell älteste supportete Version und das auch nur für 1 Jahr nach Release der neuen Stable. Für Bullseye ist das aber schon wieder eine Weile her. Für den offline Betrieb sollte Debian Stretch aber genügen. 3. Du nimmst einen Desktop und einen Loginscreen, der ohne 3d Features auskommt. Also kein Gnome, kein KDE und dann benutzt du den VESA Treiber, anstatt den Nouveau Treiber. 4. Falls die CPU eine eigene iGPU hat und das Mainboard über entsprechende Grafikanschlüsse verfügt, könntest du auch diese nehmen. Und die Geforce ausbauen. Andere Lösungen für den lokalen Einsatz gibt es nicht.
Nano schrieb: > Zeno schrieb: >> Der Rechner ist nicht mehr >> ganz neu und mit einer NVidia GForce 7300 bestückt. > > Die Geforce 7300 braucht die 304.x Treiber: > https://us.download.nvidia.com/XFr > >> Wird zwar vom >> Installer erkannt und über den Noveau-Treiber eingerichtet. Der Treiber >> ist leider so bugy, das ein Arbeiten damit nicht möglich ist. Von NVidia >> gibt es zwar probitäre Treiber die funktionieren, aber die lassen sich >> halt nicht so einfach unter Debian11 (Kernel 5.10.0-14) installieren. Da >> sitze ich auch schon mehrere Tage dran. Heute hat es wieder mal einen >> ordenlichen Schritt nach vorn getan, aber so richtig Freude kommt bei so >> etwas eben nicht auf. > > Die Arbeit kannst du dir sparen, es wird nicht funktionieren und die > Nouveu Treiber bleiben bis auf weiteres Buggy. > > Lösungen: > 1. Du brauchst eine neue Grafikkarte. > > 2. Oder alternativ, du steigst zurück auf Debian 9, aber das ist schon > oldoldsteable und wird laut WP nur noch bis zum 20. Juni 2022 supported. > Und supported heißt hier wahrscheinlich nur das Serverzeugs und auch > nicht mehr offiziell, den normalerweise ist oldstable die offiziell > älteste supportete Version und das auch nur für 1 Jahr nach Release der > neuen Stable. Für Bullseye ist das aber schon wieder eine Weile her. > Für den offline Betrieb sollte Debian Stretch aber genügen. > > 3. Du nimmst einen Desktop und einen Loginscreen, der ohne 3d Features > auskommt. Also kein Gnome, kein KDE und dann benutzt du den VESA > Treiber, anstatt den Nouveau Treiber. > > 4. Falls die CPU eine eigene iGPU hat und das Mainboard über > entsprechende Grafikanschlüsse verfügt, könntest du auch diese nehmen. > Und die Geforce ausbauen. > > Andere Lösungen für den lokalen Einsatz gibt es nicht. ee86/Linux-x86_64/470.103.01/README/supportedchips.html > > Und die letzte Debian Version, die diese mitgeliefert hat, war Debian 9 > (Stretch): > https://wiki.debian.org/NvidiaGraphicsDrivers Wirklich? Ich habe auf LMDE4, welches auf Debian 10 basiert, den 304er im Einsatz. In einem Rechner steckt eine Geforce 210(?), die eben auch den 304er Treiber braucht.. Es war schon Bastelei, weil so einiges Andere deinstalliert werden musste, um den ans laufen zu bringen, hat aber geklappt. Kann morgen mal schauen, nen Link zu ner Anleitung die ich genutzt habe auszugraben. > Wenn Debian das Paket bei einer neuen Debian Version rausschmeißt, dann > liegt das daran, weil es mit dem neuen Kernel in der neuen Debian > Version nicht mehr funktioniert. Der 304er wird vom DKMS ab Kernelhauptversion 5 nicht erfolgreich gebaut. Nativ ist so bei Kernel 4.9 Schluss. Es existiert jedoch ein Patch, mit dem der Treiber dann auch auf 5er Kernel verwendet werden kann. Muesste ich dann auch nochmal raussuchen den Link dazu.
:
Bearbeitet durch User
Nano schrieb: > Die Geforce 7300 braucht die 304.x Treiber: > https://us.download.nvidia.com/XFree86/Linux-x86_64/470.103.01/README/supportedchips.html Das ist mir schon klar. Ich habe mir das passende Treiberpaket bei NVidia heruntergeladen. Ich habe die Kernelsourcen installiert und was sonst so noch nötig ist. Ich kann den Build auch anstoßen. Die Prüfungen die dabei ausgeführt werden laufen auch alle durch und der Installer beginnt auch mit dem Compilerlauf. Wenn man mit DKMS installiert dann fliegt er dort raus und mosert rum das der Kernel nicht konfiguriert ist. Um den Fehler zu beheben solle man in den Headersourcen "make oldconfig && make prepare" ausführen. Funktionier leider nicht weil make oldconfig schon ein fehlendes /sripts/mkmakefile anmosert. Das hat erst mal nix mit dem NVidiatreiber zu tun, das ist letztendlich wieder einmal ein zusammengemurkstes Makefile - so eine typische OSS-Sache. Ich bin ja nicht der Einzige wo dieser Fehler auftritt. Wenn man da Google bemüht wird man da schnell fündig. Da wird dann von der Community groß getönt aber Lösungen gibt es da nicht wirklich. Ohne DKMS bricht der Installer dann auch ab, da muß man dann das Logfile des Installers bemühen dort steht dann ne Fehlermeldung drin. Da soll man eine Umgebungsvariable vorm Aufruf des Installers setzen, aber man schweigt sich halt aus auf was man die setzen soll. Ich hab jetzt mal Mint 20.03 mit XFCE installiert. Das hat zwar auch den Noveautreiber und man kann halbwegs damit arbeiten, auch wenn der Betrieb von 2 Desktops nicht funktioniert. Was bei Mint, welches ja auch auf Debian basiert, anders ist keine Ahnung. Vielleicht liegt es ja am Desktopmanager. Zudem gibt es für diese Mintversion noch ne Anleitung mit der man den Treiber angeblich zum Laufen bringen kann. Mal sehen obs wirklich funktioniert. Unter Debian hat mich die Anleitung auf alle Fälle schon mal weiter gebracht und das läßt hoffen. Nano schrieb: > Lösungen: > 1. Du brauchst eine neue Grafikkarte. Ich werde dem Rechner definitiv keine neue Grafikkarte spendieren. Das ist mein Testrechner und da müßte ich dann die anderen Systeme auch updaten und das dann dumm läuft gibt es für die dann keinen Treiber für die neue Karte. Die Karte an sich ist gut und sie funktioniert bei den anderen Systemen die auf diesem Rechner laufen perfekt. Nano schrieb: > 2. Oder alternativ, du steigst zurück auf Debian 9 Das läuft schon auf dem Rechner, aber da mosert die Toolchain für das Kernelmodul des BanaPi rum, das da einiges zu alt ist. Könnte man möglicherweise auch korrigieren aber das artet dann auch wieder in Frickelei aus. Nano schrieb: > und dann benutzt du den VESA > Treiber, Nicht Dein Ernst? Wenn das jetzt mit dem Mint nichts wird dann ist das Thema schlichtweg durch und mein Bedarf an Linux auf dem Desktop für die nächste Zeit gedeckt. Dann muß ich sehen, wenn ich da durchsteige, das ich die Toolchain anderweitig zum Laufen bekomme. Wenn's gar nicht dann muß ich halt auf das Kernelmodul für BananaPi verzichten. Es notfalls auch ohne aber es ist halt wieder zusätzlicher und eigentlich unnötiger Programmieraufwand.
Johannes U. schrieb: > Kann morgen mal schauen, nen Link zu ner Anleitung die ich genutzt habe > auszugraben. Das wäre natürlich super! Johannes U. schrieb: > Es existiert jedoch ein Patch, mit dem der Treiber dann auch auf 5er > Kernel verwendet werden kann. Ich habe da nach der Mintanleitung auch mehrere Patches installiert, da ging es dann auch erst mal weiter.
Zeno schrieb: > Was bei Mint, welches ja auch > auf Debian basiert, anders ist keine Ahnung. Ich bitte um Klarheit im Ausdruck! Mint == Ubuntu Mint != LMDE LMDE == Debian > Vielleicht liegt es ja am > Desktopmanager. Habe hier LMDE4 mit XFCE und das geht mit dem 304er. > Zudem gibt es für diese Mintversion noch ne Anleitung > mit der man den Treiber angeblich zum Laufen bringen kann. Die habe ich mit Sicherheit nicht genutzt, kenne sie auch garnicht, wahrscheinlich meinst Du hier auch Mint == Ubuntu? Waere also fuer meinen Fall dann auch nicht relevant gewesen. > Mal sehen obs > wirklich funktioniert. Unter Debian hat mich die Anleitung auf alle > Fälle schon mal weiter gebracht und das läßt hoffen. Wenn Deine Praefernz eh auf Debian liegt, wuerde ich mir nich Mint installieren, sondern LMDE, durch die Debianbasis greifen da auch die Anleitungen fuer Debian.
Zeno schrieb: > Johannes U. schrieb: >> Kann morgen mal schauen, nen Link zu ner Anleitung die ich genutzt habe >> auszugraben. > Das wäre natürlich super! Wie gesagt, ich grabe morgen, spaetestens uebermorgen mal danach, keine Ahnung, ob ich ein Bookmark gesetzt habe. Wahrscheinlich habe ich aber auf jeden Fall die Bashhistory der entsprechenden apt Bastelei auf dem erfolgreichen Weg dahin gesichert.. darus ginge dann hervor, was Alles weg muss. Muss ich allerdings auch erst nach suchen.
Manfred schrieb: > KArl Fred M. schrieb: >> Warum aber immer mehr kritische Stimmen sich langsam mehr und mehr zu >> Wort melden, weiß ich auch nicht. > > Aus meiner Sicht ganz klar: Die Unzufriedenheit mit Windows steigt, > weshalb sich immer mehr Leute Linux anschauen. Damit meinte ich, weshalb sich immer mehr kritisch zu Linux äußern... Diese Stimmen mehren sich deutlich
Mach mal Testweise folgendes. Schalte die Grundsätzlich aktivierte Firewall von Mint AB. Wenn er dann druckt, weißt du mit wenn du diskutieren musst. Ich hatte mit der FW auch meine Diskussionen bis sie anfragen meines Win-7 PC akzeptierte und anders herum. Wenn die Kiste lokal ja druckt, liegt es nicht am Treiber sondern an der Schnittstelle selbst i.d.R. Ich habe Linux Mint 17.* und 20.* auf meinen Laptops und bei beiden wurde nach der Änderung der FW auch mein Canon-Drucker im Netz gefunden inkl. Scanner. !!!! Ist aber nur so eine Idee.
Thomas L. schrieb: > Ist das das Druckerproblem "versionsbehaftet" oder ist da irgendwo ein > Bug ? Wieso das mit dem Drucken in Linux (schon lange) ein Problem ist, kann ich nicht genau sagen, aber man muss halt schauen, dass man Hardware zusammenstellt, die (erfahrungsgemäß) einigermaßen unter Linux "läuft". Baldurs Gate2 läuft nicht gut unter Linux, aufgrund eines unerklärlichen Maus-Versagens. Zumindest da weiß ich, dass man als Maus-Nutzer in Linux schon immer 2. Klasse war. Das ist aber auch gut, man kann man dankbar sein, denn bei Unix ist die Maus eher Holz-Klasse - falls überhaupt. Dass Unix dank Spielerei überhaupt auf die Welt gekommen ist, darf man gar nicht erzählen. Spielen passt einfach nicht in das Weltbild gewisser Leute.
KArl Fred M. schrieb: > Damit meinte ich, weshalb sich immer mehr kritisch zu Linux äußern... > Diese Stimmen mehren sich deutlich Wahrscheinlich von Redmond bezahlte Windowstrolle...
Johannes U. schrieb: > Wahrscheinlich von Redmond bezahlte Windowstrolle... Nö. Dazu sind die viel zu geizig. Das erledigt das Standard-Pycho-Programm mit automatischen Brainwashing. Hier ein sehr gutes Beispiel. Beitrag "Welche IDE für esp32 nehmen?" Die ersten Antworten . NUR MS-Zeug. Und das obwohl es mehr als jede Menge gute Alternativen gibt.
Johannes U. schrieb: > Wahrscheinlich von Redmond bezahlte Windowstrolle... Wohl kaum, eher die hochnäsige Community. Viele haben es einfach satt angepampt zu werden, oder wie man hier sieht, wirft sofort jemand das Wort "Trolle" in den raum Das beobachte ich sowohl bei Heise, Golem als auch hier, das es immer mehr gibt, die meine kritischen Kommentare untermauern. Wie auch in diesem Thread zu sehen. Vor einigen Jahren war keine Gegenstimmte da, seit 2 Jahren mehren sie sich
Schlaumaier schrieb: > Die ersten Antworten . NUR MS-Zeug. Und das obwohl es mehr als jede > Menge gute Alternativen gibt. tja, auch so ein Problem. WARUM, ist das wohl so?!? Jetzt überleg mal rein objektiv. Liegt es vielleicht daran das wenn ein System einen Marktanteil von unter 2% hat, das einfach die 98% mehr zum tragen kommen? Das hat nichts mit Verschwörung zu tun, wie es sich einige Linux Fans einreden. Das ist einfach Realität und nichts merkwürdiges
Hallo, Schlaumaier schrieb: > Das erledigt das Standard-Pycho-Programm mit automatischen Brainwashing. > > Hier ein sehr gutes Beispiel. > > Beitrag "Welche IDE für esp32 nehmen?" > > Die ersten Antworten . NUR MS-Zeug. Und das obwohl es mehr als jede > Menge gute Alternativen gibt. Womöglich gibt es einfach nur mehr Desktop-Windows Nutzer als Desktop-Linux Nutzer? Gruß aus Berlin Michael
Michael U. schrieb: > Womöglich gibt es einfach nur mehr Desktop-Windows Nutzer als > Desktop-Linux Nutzer? Das sowieso. Aber es geht hier darum das man wenn möglich auf Alternativen Ausweichen kann / soll. Ist wie mit den Gas. Alle benutz(t)en es. Und wenn der Hauptlieferant durchdreht, haben wir ALLE ein Problem. Wo ist der Unterschied zwischen MS und GAS. ???
Schlaumaier schrieb: > Aber es geht hier darum das man wenn möglich auf Alternativen Ausweichen > kann / soll. Das ist leider nicht so. Der Vergleich mit Gas passt daher auch gar nicht. Gas ist Gas, egal woher(und nicht mal das stimmt, es gibt je nach Land unterschiedliche Qualitäten) Alternativen sind generell nicht unbedingt schlecht, aber auch nicht immer von Vorteil. Siehe Messenger. Zu viel Vielfallt wäre die reinste Katastrophe, eine einheitliche Schnittstelle würde womöglich viel Entwicklung im Keim ersticken. Bei OS genau das Selbe. Bei MS gibt es alles, unheimlich komfortabel und leicht bedienbar, keine Frickelei. Gibt es zu viele Plattformen, dann gibt es Tool X nicht auf System Y, dafür aber das Tool g für System N, aber nicht für V etc. Es war schon gut, das sich ein System durchgesetzt hat und so sollte es auch bleiben. Linux und Apple sind so, wie sie jetzt sind super. Es gibt alternativen, die den Marktführer vorantreiben, aber nicht so viel Marktanteil besitzen, das sich alles zu sehr splittet
KArl Fred M. schrieb: > Es war schon gut, das sich ein System durchgesetzt hat und so sollte es > auch bleiben. Grundsätzlich gebe ich dir völlig Recht. Bloß das RECHT und PATENTE und Co. sind dabei das Problem. Wenn man plötzlich sagt : Meine Rechte meine Regeln , und derjenige die Macht hat durch die Marktpräsents das auch durchzusetzen dann hat man ein Problem. Sieh Windows 10 + noch schlimmer 11. Was ja der Grund für die Diskussion hier ist. Der TO will umsteigen weil er sich nicht mehr gängeln und überwachen lässt. Ist wie beim Drogenhandel. Die ersten Drogen sind schön bunt und lecker. Und dann bist du in der Falle. Ich persönlich habe mir Gesagt das Win-7 das letzte OS von MS ist, was ich nutze. Ich brauche es nicht mehr für die Arbeit und Privat reicht es mir so. Für den Rest. Naja, ich habe wie das TO auch mich für Linux-Mint entschieden. Selbst wenn irgendwann mein Kaspersky Win-7 nicht mehr unterstützt , dann mache ich den Online-Zeug halt mit Linux. Ein Browser kann ich auch da bedienen. ;) Und mehr brauche ich auf einen Linux-System nicht wirklich.
Eigentlich solle ein Mod mal all die offtopic Beiträge von den Windows Trollen oben löschen, das ist ja weit jenseits vom Thema. An den TO noch den Tipp, trolle am besten ignorieren, und wenn Diskussionen in die falsche Richtung gehen, eventuell ne klare Ansage machen, "bitte beim Thema bleiben". In dem Forum gibt es leider mittlerweile einige, die andere Interessen als zu helfen haben... Thomas L. schrieb: > Schon beim Drucken der Testseite sagt mir das System nach einer Weile > dass irgendeine Berechtigung fehlt Sagt es, worauf es zuzugreifen versucht? Der exakte Wortlaut einer Fehlermeldung ist wichtig, dann sieht man soetwas oft. (Das wollte Norbert mit "Das sagt das System? Das das das kann." eigentlich sagen). Wobei, bei einem Netzwerkdrucker ist das schon merkwürdig, das ist ja keine Datei oder so. Vielleicht findet man noch etwas in den Logs, schau mal in /var/log/cups/ Auf meinem Devuan & Xfce System (Von welchem aus das Drucken über Netzwerkdrucker läuft), sehe ich mit "id" die Gruppen "cdrom, floppy, audio, pulse, video, dip, plugdev, users, netdev, input, lpadmin, scanner, bluetooth, kvm, wireshark". Ich bin mir nicht sicher, welche es braucht, aber lpadmin, scanner, users, und eventuell netdev und plugdev, schau mal ob du die alle hast, und füge sie eventuell hinzu (braucht dann eine Neuanmeldung zum übernehmen). Versuche eventuell auch mal, ob du als root per "lp" etwas drucken kannst.
Johannes U. schrieb: >> Was bei Mint, welches ja auch >> auf Debian basiert, anders ist keine Ahnung. > > Ich bitte um Klarheit im Ausdruck! > Mint == Ubuntu > Mint != LMDE > LMDE == Debian Wo braucht es da Klarheit? Wenn ich schreibe Mint basiert auf Debian dann ist das klar genug. Wenn Mint auf Ubuntu basiert, dann basiert es letztendlich auf Debian. Zum anderen habe ich hier geschrieben, daß ich MINT 20.03 mit XFCE installiert habe, damit sollte eigentlich klar sein das es kein LMDE ist. Johannes U. schrieb: > Wenn Deine Praefernz eh auf Debian liegt, wuerde ich mir nich Mint > installieren, sondern LMDE, durch die Debianbasis greifen da auch die > Anleitungen fuer Debian. Da es für Debian keine brauchbare Anleitung gibt - ich habe zumindest in der letzten Woche nichts Brauchbares gefunden - werde ich es jetzt erst mal mit MINT versuchen. Wenn das auch in die Hose geht werde ich eine andere Lösung finden.
Johannes U. schrieb: > Muss ich allerdings auch erst nach suchen. Ja such mal bitte! Die Bashhistory wäre ja schon gut ist ja quasi auch ne Anleitung.
Hallo... und nochmal Danke! Ich habe nie gedacht hier eine solche Welle loszutreten - aber es zeigt doch dass die Community ..lebt! ich sehe keinen Beitrag als "troll-post" und als Windoofs User ist man den Spott und die Häme irgendwie gewöhnt. :) Ich habe das Problem mit dem Drucken gelöst, es geht jetzt. Der weg dorthin war aber wirr.. ich habe Linux neu aufgesetzt. diesmal nicht als erstes die vom System vorgeschlagenen "Erste Schritte" durchgeführt. Dann eine sudo -i shell aufgerufen dann apt-get und beide HP lip dinger geholt ( auch die GUI ) dann HP-install Testseite versucht zu drucken ---> Fehler dann poppte ein Fenster auf in dem stand : es fehlen zwei Dateien. Freundlicherwiese wurde ich auch gefragt, diese fehlenden Dateien JETZT dowloaden? habe ich gemacht, testdruck wiederholt ... und es ging. danach habe ich die "ersten Schritte" durchgeführt und alles ist gut. So, mein Fazit: Linuxer sind keine Trolle und so manche schräge Bemerkung ist ganz sicher mit einem Augenzwinkern gemeint. Und jupp, ich werde weiter den Linux weg gehen. Und wenn mal wieder etwas schief geht... Hier wird einem geholfen. Grosses Danke und einen schönen Windows-freien Sonntag! Thomas
Schlaumaier schrieb: > Aber es geht hier darum das man wenn möglich auf Alternativen Ausweichen > kann / soll. Wie stellst Du Dir das bei 98% Windowsusern vor? Die empfehlen natürlich dann Windowssoftware, weil sie die kennen.
Zeno schrieb: > Wie stellst Du Dir das bei 98% Windowsusern vor? Die empfehlen natürlich > dann Windowssoftware, weil sie die kennen. Rabatt-Apps haben auch Mio von Usern. Alexa + Co. haben auch Mio. von Usern die es gern haben wenn man ihn beim Poppen zuhört. Ist wie mit fast allen. Die meisten Menschen merken es erst wenn es zu spät ist. Wie halt bei den Drogen. ;) Kein Anfänger nimmt Heroin. Man muss halt langsam daran geführt werden. ;)
Manfred schrieb: > Als K.O. sehe ich hauptsächlich dessen Paketverwaltung, Programme, die > ich nicht nach eigenem Belieben austauschen kann. Ich soll Update / > Upgrade anstoßen, ohne genau zu wissen, was dann alles umgebogen wird - > das ist noch undurchsichtiger als bei Windows. Bei mir gibts da vorher eine Übersicht über alle Pakete und wenn ich einzelne davon nicht will kann ich die abwählen. Allerdings dürfte sich Otto-Normal-Nutzer der Sinn / die Zuordnung von vielen Paketen nicht sofort erschließen... Letztenendes hast du das Problem des Unwissens genauso unter Windows, nur das du das Update dann halt für jedes Programm einzeln starten musst.
Reinhard S. schrieb: > Letztenendes hast du das Problem des Unwissens genauso unter Windows, > nur das du das Update dann halt für jedes Programm einzeln starten > musst. Eine Komische KB******* Nr gegen ein komischen Paket. Wo ist der Unterschied. Wenn ich es nicht selbst geschrieben habe, muss ich eh den Ersteller trauen. Und ich muss halt notfalls backups machen ;) Und der Spruch "es wurde eine Sicherheitslücke entdeckt" ist doch für alles ein Totschlag-Argument. Wie Waschmittelwerbung : Das weisseste Weiß das es je gab. ;)
Reinhard S. schrieb: > Bei mir gibts da vorher eine Übersicht über alle Pakete und wenn ich > einzelne davon nicht will kann ich die abwählen. Genau so ist es! > Allerdings dürfte sich Otto-Normal-Nutzer der Sinn / die Zuordnung > von vielen Paketen nicht sofort erschließen... Muss er auch nicht. Da kann er einmalig auswählen ob nur die wirklich benötigten Pakete oder vielleicht auch die empfohlenen Pakete installiert werden sollen. Iss jetzt nicht wirklich Raketenwissenschaft. Und die Zeiten wo man um jedes einzelne Byte feilschen musste sind nu' auch vorbei.
Manfred schrieb: > Als K.O. sehe ich hauptsächlich dessen Paketverwaltung, Programme, die > ich nicht nach eigenem Belieben austauschen kann. Ich soll Update / > Upgrade anstoßen, ohne genau zu wissen, was dann alles umgebogen wird - > das ist noch undurchsichtiger als bei Windows. Das kann man, wenn man will, sehr wohl genau herausfinden. $ apt update zeigt an, ob Pakete zu aktualisieren sind $ apt list --upgradable zeigt an welche Pakete aktualisiert werden. Z.B. unter https://www.debian.org/distrib/packages.de.html kann man sich für alle Pakete die Dateien bis herunter zum Quellcode anschauen, bevor man $ apt upgrade zum Herunterladen und Installieren der Pakete eingibt. Und natürlich kann man auch gezielt einzelne Pakete neu installieren. Mit $ apt update und $ apt upgrade werden lediglich die bereits intallierten Pakete auf den neuesten Stand gebracht. Wenn man Debian stable verwendet, sind das in der Regel nur Sicherheits-Updates und auch da kann man sich vorher genau anschauen welche Fehler genau behoben werden.
Alexander S. schrieb: > Das kann man, wenn man will, sehr wohl genau herausfinden. Größter Fehler an Linux ZU VIEL TIPPEN
Hallo Thomas Leu schrieb: > So, mein Fazit: Linuxer sind keine Trolle und so manche schräge > Bemerkung ist ganz sicher mit einem Augenzwinkern gemeint. Leider aber ein nicht zu kleiner Teil der sich in den Foren und ähnlichen Plattformen immer (ist leider kein Vorurteil) als erstes und lautesten melden - das allerdings auch auf der Windows Seite... Das mit den augenzwinkern funktioniert aber schriftlich gegnüber absolut Fremden und der möglichkeit das ein dritter (vierter, fünfter...) auch noch seinen sempf loswerden kann, nur extrem beschränkt. Schriftlich muss man leider immer die Sarkasmusflagge hochhalten bzw. halt die bei so vielen hier im Forum unbeliegte Emojis verwenden (ja wir haben nicht mehr 1996...). Zwischen Mobben, beleidigen, überheblichkeit und einen Augenzwinkern ist nun mal nur ein sehr kleiner Unterschied wenn dies schriftlich zwischen Unbekannten mit öfter verschiedener Grundeinstellung erfolgt. Lieber etwas zu freundlich und deutlich (sarkasmusflagge) als auch nur ein nicht beabsichtigter Angriff
Alexander S. schrieb: > Manfred schrieb: >> Als K.O. sehe ich hauptsächlich dessen Paketverwaltung, Programme, die >> ich nicht nach eigenem Belieben austauschen kann. Ich soll Update / >> Upgrade anstoßen, ohne genau zu wissen, was dann alles umgebogen wird - >> das ist noch undurchsichtiger als bei Windows. Keineswegs. Es zeigt alle Programme an, die geupdated würden. Am namen sieht man eigentlich recht schnell, wofür die sind. Falls nicht, kann man sich die Beschreibung anzeigen lassen. Für die Änderungen kann man sich einen Changelog anzeigen lassen - davor, oder danach per E-Mail zusenden lassen. Packete von Updates ausschliessen, oder nur einzelne Updaten, kann man auch machen. Und man kann sich auch später noch den Changelog eines Packets anzeigen lassen "apt changelog [paketname]". GUIs gibt es für all das natürlich auch. Früher war mal synaptic in. Heute nutzt man eher gnome-software oder plasma-discover. Unter Windows ist das viel schwieriger. Und deren Changelogs sind oft auch nicht sehr informativ / vollständig.
Zeno schrieb: > Nano schrieb: >> Lösungen: >> 1. Du brauchst eine neue Grafikkarte. > Ich werde dem Rechner definitiv keine neue Grafikkarte spendieren. Das > ist mein Testrechner und da müßte ich dann die anderen Systeme auch > updaten und das dann dumm läuft gibt es für die dann keinen Treiber für > die neue Karte. Die Karte an sich ist gut und sie funktioniert bei den > anderen Systemen die auf diesem Rechner laufen perfekt. Ist halt auch eine Zeit+Aufwand vs. Kostenfrage und irgendwann ist halt mit den proprietären Treibern Schicht im Schacht. Das die Karte reibungslos ihre Arbeit macht, glaube ich dir ja, aber von der Softwareseite muss es halt auch stimmen. > > Nano schrieb: >> und dann benutzt du den VESA >> Treiber, > Nicht Dein Ernst? Doch, vor allem wenn man nur noch die Wahl zwischen Nouveau und VESA hat und die Nouveautreiber instabil sind. Also der Rechner damit keine Stunde ohne Absturz der Grafikoberfläche funktioniert. Der große Vorteil der VESA Treiber ist, dass die wenigstens bombenstabil sind. Damit kannst du Stundenlang den Rechner ohne Absturz laufen lassen. Du darfst dann halt keinen modernen Desktop mehr verwenden, der auf eine 3d Beschleunigung angewiesen ist oder bei dem das 3d Zeugs dann mit llvmpipe dann in Software emuliert wird. Das ist nämlich grottenlangsam und die CPU läuft damit unter Vollast. Deswegen nimmt man da einen anderen klassischen Desktop und braucht die llvmpipe dann nicht mehr und dann läuft das mit den VESA Treibern durchaus wieder akzeptabel. > Wenn das jetzt mit dem Mint nichts wird dann ist das Thema schlichtweg > durch und mein Bedarf an Linux auf dem Desktop für die nächste Zeit > gedeckt. Dann muß ich sehen, wenn ich da durchsteige, das ich die > Toolchain anderweitig zum Laufen bekomme. Wenn's gar nicht dann muß ich > halt auf das Kernelmodul für BananaPi verzichten. Es notfalls auch ohne > aber es ist halt wieder zusätzlicher und eigentlich unnötiger > Programmieraufwand. Wie schon gesagt VESA und eine klassische Desktopoberfläche könnten hier helfen. Mate als Desktop Environment müsste noch gehen, falls nicht, dann musst du halt nen klassischen Window Manager wie bspw. FVWM nehmen. Den Displaymanager musst du auch noch austauschen. Xdm sollte mit den VESA Treibern gut funktionieren. Hauptsache nichts, was 3d Beschleunigugng benötigt und dann die llvmpipe im Softwaremodus nutzt. Also kein Gnome 3, kein modernes KDE und bei den Displaymanagern kein gdm3. Und damit die VESA Treiber benutzt werden, müssen die Nouveautreiber auf die blacklist. Das sollte dann gehen, auch stabil über mehrere Stunden.
Johannes U. schrieb: > Der 304er wird vom DKMS ab Kernelhauptversion 5 nicht erfolgreich > gebaut. > Nativ ist so bei Kernel 4.9 Schluss. > Es existiert jedoch ein Patch, mit dem der Treiber dann auch auf 5er > Kernel verwendet werden kann. > Muesste ich dann auch nochmal raussuchen den Link dazu. Gut, wenn das geht, kannst du das natürlich so machen.
Zeno schrieb: > Manfred schrieb: >> Da mag ich Dir nicht widersprechen. Windows wird zunehmend >> unbenutzbarer, weshalb ich die letzten Monate viele Stunden mit Linux >> verbracht habe. Linux hat Konzeptprobleme, die dessen Einsatz auf dem >> Desktop vermeidbar schwierig machen. > Das ist gut formuliert! Speziell der letzte Satz trifft es leider recht > genau. > Bin selbst gerade dabei ein neues Linuxsystem aufzusetzen, weil ich für > meinen BananaPi zwei Module kompilieren muß. Kompiliere doch direkt auf dem Pi.
Schlaumaier schrieb: > Mach mal Testweise folgendes. > Schalte die Grundsätzlich aktivierte Firewall von Mint AB. > Wenn er dann druckt, weißt du mit wenn du diskutieren musst. > Ich hatte mit der FW auch meine Diskussionen bis sie anfragen meines > Win-7 PC akzeptierte und anders herum. Ähm ... die Firewall ist bei Mint (zumindest Mate) nach der Installation eigentlich aus.
Willi schrieb: > Ähm ... die Firewall ist bei Mint (zumindest Mate) nach der Installation > eigentlich aus. Mag sein. Aber bei meiner linux mint cimarron 20.x war sie definitiv nach der Installation an. Installation über die einigen Oberfläche gestartet vom Stick.
Reinhard S. schrieb: > Allerdings dürfte sich > Otto-Normal-Nutzer der Sinn / die Zuordnung von vielen Paketen nicht > sofort erschließen... Genau das ist der Knackpunkt. Und so frei ist man in seiner Auswahl auf Grund der vielen Abhängikeiten da auch nicht. Da wählt man irgend etwas ab und dann wird es dennoch installiert, weil irgend etwas aus dem Paket als Abhängigkeit für ein anderes Paket definiert ist. Durchsehen tut da jedenfalls keiner mehr. @nano Mein Mint 20.03 mit Kernel 5.4 läuft jetzt. Allerding war es eine Orgie dem System das beizubringen. Der Normaluser scheitert daran definitiv und ich hätte es ohne Google und einer gehörigen Portion Ausdauer (eine gute Woche) auch nicht gebacken bekommen. Die Schwierigkeit ist nicht der Installer von NVidia, den kann jeder bedienen, das Problem ist hier eindeutig Linux. Ebenso das Eintragen des nouveau-Treibers in Blacklist ist ist Pillepalle (macht sogar der NVidiainstaller nach Nachfrage selbst). Man muß erst mal jede Menge Software entfernen und eine ältere Version installieren. Der Knackpunkt hierbei ist, das man da erst mal alle Standardrepositorities der Distribution deaktivieren muß und dann die Repos angeben muß die die alte Software enthalten. Da muß man natürlich wissen was man da installieren muß. Da ist z.B. auch ne Lib von GStreamer erforderlich, obwohl ich weder GStreamer installiert habe noch möchte ich etwas streamen, aber es ist wohl irgendeine Abhängigkeit. So lange wie hier habe ich bei bisher bei keinem Windowstreiber gebraucht. Da wundert mich der Desktopanteil von Linux überhaupt nicht mehr. Jens B. schrieb: > Kompiliere doch direkt auf dem Pi. Würde ich gerne machen bzw. habe ich auch schon gemacht. Der Treiber wird zwar fehlerfrei gebaut und auch als Modul installiert. Allerdings weigert sich der Kernel das Modul anschließen zu laden, mit der Begründung das die Version des Modules nicht stimmt. Das Abfragen der Version mit modinfo liefert die gleiche Version wie uname -r - hab's ja auch gegen die aktuellen Kernelquellen kompiliert. Man kann beim Laden der Module ja auch die Versionsabfrage unterdrücken. Dieser Parameter wird aber ignoriert. Bei den Quellen sind noch einige Tools dabei, die offensichtlich für die Installation des Moduls erforderlich sind. Allerding laufen diese Tools nicht auf auf dem Pi. Die wollen ein möglichst aktuelles Linux auf dem PC. In der Berschreibung reden die auch davon das man das Modul in einer Crosscompileumgebung bauen soll. Das ist übrigens kein RasPi sondern ein BananaPi und der unterscheidet sich in einigen Dingen sehr stark vom RasPi. Leider gibt es beim BananaPi nicht so eine große Community und man steht da mehr oder weniger alleine im Regen und ist da auf das angewiesen was Chinamann meint anbieten zu müssen.
Zeno schrieb: > Man muß erst mal jede Menge Software entfernen und eine ältere Version > installieren. Der Knackpunkt hierbei ist, das man da erst mal alle > Standardrepositorities der Distribution deaktivieren muß und dann die > Repos angeben muß die die alte Software enthalten. Da muß man natürlich > wissen was man da installieren muß. Dann hast du ein Mischmasch aus alter und neuer Distributionsversion und somit für einen Großteil der Software keine Updates. Falls du die Repos der neuen Version wieder aktiviert hast, was machst du dann, wenn Sicherheitspatches über die alte Versionen drübergebügelt werden bzw. du keine Sicherheitspatches bekommst, weil noch das alte Repo aktiv ist? Mir wäre das zu viel Aufwand und zu unsicher, d.h. ich hätte den VESA Weg genommen. Aber gut wenn es bei dir jetzt funktioniert. > So lange wie hier habe ich bei bisher bei keinem Windowstreiber > gebraucht. Da wundert mich der Desktopanteil von Linux überhaupt nicht > mehr. Tja, so ist das halt. Linux ist eigentlich nicht dafür ausgelegt, dass man am offiziellen Repo vorbei installiert bzw. dieses auf alte Repoversionen umgibt. Auf der Anwendungsebene gibt's aber durch Flatpak & Co zumindest Abhilfe, wenn da der Nutzer eine ganz aktuelle Version benötigt. Treiber gehören da aber natürlich nicht dazu, das gilt übrigens auch in die andere Richtung, wenn die Hardware zu neu ist, dann ist der normale Anwender mit einer noch aktuellen Distriversion auch aufgeschmissen. Da gibt es dann zwar Point Releases, aber die kommen halt auch nur alle paar Monate mal raus und wenn der Nutzer dann eine nagelneue GPU kauft, hat er halt auch das Problem, dass die Distri das noch nicht von Haus aus unterstützt. Die Ursache warum ist klar, es liegt an der fehlenden stabilen Linux-Treiber-Schnittstelle, aber die ist von Linus Torvalds und vielen weiteren Kernelentwicklern aus guten Gründen nicht gewünscht. Siehe dazu folgende Erklärung: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst Insofern wird sich auf Treiberebene auch nichts ändern. Neue Hardware benötigt eine nagelneue Distributionsversion, idealerweise eine Rolling Release Distri wie Arch und Open Source Treiber. Erst wenn die Hardware etwas älter ist, kann man auf eine Distri mit einem anderen Releasezyklus wechseln. Und proprietäre Treiber sind pures Gift. Um solche Hardware sollte man einen großen Bogen machen. Bei NVidia Karten nicht für jeden immer möglich, aber bei allem anderen geht das in der Regel schon.
Nano schrieb: > Tja, so ist das halt. Linux ist eigentlich nicht dafür ausgelegt, dass > man am offiziellen Repo vorbei installiert bzw. dieses auf alte > Repoversionen umgibt. Sry, meinte umbiegt.
Thomas L. schrieb: > Hallo. Ich wollte definitiv die Windows Welt verlassen und auf > MINT wechseln. Generell empfehle ich Dir dazu eher das Forum von Mint: https://forums.linuxmint.com Vorzugsweise auf englisch, denn der deutschsprachige Teil ist deutlich weniger frequentiert. Denk dran, bei Fragen den fetten roten Abschnitt bei den Foren zu lesen, wie man Hilfe bekommt, besonders Punkt 5 mit den Systemdetails: https://forums.linuxmint.com/viewtopic.php?f=17&t=83444
Nano schrieb: > Dann hast du ein Mischmasch aus alter und neuer Distributionsversion und > somit für einen Großteil der Software keine Updates. Mir wäre es auch lieber wenn es sauber ohne Klimmzüge funktionieren würde. Nano schrieb: > Falls du die Repos der neuen Version wieder aktiviert hast, was machst > du dann, wenn Sicherheitspatches über die alte Versionen drübergebügelt > werden bzw. du keine Sicherheitspatches bekommst, weil noch das alte > Repo aktiv ist? Ich hoffe mal das Setzen auf "Hold" das Updaten der betreffenden Pakete (sind eigentlich nur 4 xserver Pakete) verhindert. Ich habe die Repros natürlich auf die neue Version zurückgesetzt und ein apt update && apt upgrade gemacht. Am Ende meinte er es seien noch 4 Pakete da für die es neuere Versionen gibt - schein also zu funktionieren. Nano schrieb: > Tja, so ist das halt. Linux ist eigentlich nicht dafür ausgelegt, dass > man am offiziellen Repo vorbei installiert bzw. dieses auf alte > Repoversionen umgibt. s.o. Solange man nicht in der Lage ist vernünftige Treiber bereit zustellen, bleiben halt nur wenige Alternativen. Windows, von XP bis einschließlich Win10, hat mit der Hardware keine Probleme. Nano schrieb: > Und proprietäre Treiber sind pures Gift. Um solche Hardware sollte man > einen großen Bogen machen. Bei NVidia Karten nicht für jeden immer > möglich, aber bei allem anderen geht das in der Regel schon. Sehe ich etwas anders. Ist halt ne typische Ausrede der Linuxer: "Es kann nicht sein was nicht sein darf". Es hat schon seinen Grund warum viele Hersteller von Hardware keine oder nur spärlich Treiber für Linux anbieten. Bei einem Anteil von knapp 2% im Desktopbereich ist die Entwicklung der Treiber einfach viel zu teuer und da konzentriert man sich lieber auf die verbleibenden 98%, also Windows und Mac. Dann noch der Wildwuchs im Linuxbereich, der es unmöglich macht einen einheitlichen Treiber für alle Distributionen bereitzustellen.
Zeno schrieb: > Sehe ich etwas anders. Ist halt ne typische Ausrede der Linuxer: "Es > kann nicht sein was nicht sein darf". Es hat schon seinen Grund warum > viele Hersteller von Hardware keine oder nur spärlich Treiber für Linux > anbieten. Bei einem Anteil von knapp 2% im Desktopbereich ist die > Entwicklung der Treiber einfach viel zu teuer und da konzentriert man > sich lieber auf die verbleibenden 98%, also Windows und Mac. Dann noch > der Wildwuchs im Linuxbereich, der es unmöglich macht einen > einheitlichen Treiber für alle Distributionen bereitzustellen. Hast du das verlinkte Dokument überhaupt gelesen? Gerade wenn der Treiber Open Source ist und im Kernel gelandet ist, hat man als Hardwarehersteller am wenigstens Aufwand. Die Probleme fangen ja nur genau dann an, wenn man als Hardwarehersteller unbedingt proprietäre Treiber haben will.
Zeno schrieb: > Es hat schon seinen Grund warum > viele Hersteller von Hardware keine oder nur spärlich Treiber für Linux > anbieten. Die Loesung ist ganz einfach: Solche HW kaufe ich nicht und dann kann ich mir auch das rumgemurkse der Installation ersparen. Wenn Du auf eine solche Art und Weise proprietaere HW zum laufen bringen willst, sind zukuenftige Probleme programmiert. Das kann man dann aber nicht Linux anlasten. Die Liste solcher Hersteller ist uebrigens sehr ueberschaubar. Da faellt der Verzicht nicht sonderlich schwer. Nano schrieb: > Die Probleme fangen ja nur genau dann an, wenn man als > Hardwarehersteller unbedingt proprietäre Treiber haben will. Nein, die Probleme fangen an, wenn man solchen Mist kauft.
Zeno schrieb: > @nano > Mein Mint 20.03 mit Kernel 5.4 läuft jetzt. Bezieht sich das auf einen nun funktionierenden nvidia-legacy-304xx-driver? Dann muesste ich ja erstmal nicht mehr nach meinem Loesungsweg graben, den Rechner selber habe ich auch gerade nicht zur Hand. Davon ab, hier wurde ja oben auch behauptet, Debian haette ab Version 9 den 304er Treiber aus den Quellen entfernt. Nun, das kann nicht zutreffen, denn ich habe mir hier letztens mal eine Installation von Debian Testing, also Debian 12, auf eine Platte gebuegelt. Auch da habe ich problemlos die 304er nvidia-Treiber in den Paketquellen.
Nano schrieb: > Das sollte dann gehen, auch stabil über mehrere Stunden Was für ein Aufstand, um mit einem System arbeiten zu können. Es soll Betriebssysteme geben, die ersparen dem Nutzer so ein Gschiss.
Nano schrieb: > Johannes U. schrieb: >> Der 304er wird vom DKMS ab Kernelhauptversion 5 nicht erfolgreich >> gebaut. >> Nativ ist so bei Kernel 4.9 Schluss. >> Es existiert jedoch ein Patch, mit dem der Treiber dann auch auf 5er >> Kernel verwendet werden kann. >> Muesste ich dann auch nochmal raussuchen den Link dazu. > > Gut, wenn das geht, kannst du das natürlich so machen. Nun, in dem Moment 'musste' es sein und ging dann auch :) Grund fuer das MUSS war damals der Wunsch ein aktuelles Blender aus den Backports ans Laufen zu bekommen, dies benoetigte nun wiederum eine openGL-Version, die mir nur mit dem nvidia-Treiber zugaenglich war... Und da die Graphik in meinem ollen Thinkpad auch diese openGL-Option nicht hatte, gab es keine andere Moeglichkeit. IdR wird dieser Rechner mit der nvidia-Karte nur per ssh benutzt, um Daten rauf oder runterzuschaufeln oder vielleicht mal was per X-forward abzuspielen. Im Nachhinein, hat sich auch Blender fuer mich als obsolet erwiesen, ist mir zu ueberfrachtet und zu kompliziert - ich will nicht erst lernen muessen ein Flugzeug zu fliegen, um mal eben was fuer den 3D-Druck zusammenzustricken, da kann ich mir zielfuehrender mit openScad helfen. Dennoch werde ich, wenn ich mir LMDE5 oder Debian Bookworm (Testing/Debian 12) auf dem Rechner installiere, auch dann wieder hingehen und den 304er Treiber aktivieren, freue ich mich auch schon wieder drauf :\ Und naja, neue Karte? In diesen Zeiten mit Mondpreisen in dem Sektor ne neue Karte in einen 10 Jahre alten Rechner stecken? Denke nicht, dass sich das lohnt.
Ja, Nvidia ist immer ein krampf, und dann wird der proprietäre Mist auch noch für linux von gamern weiterempfohlen. Eventuell wird es nun zumindest ein bisschen weniger ein Krampf: https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1 https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ https://github.com/NVIDIA/open-gpu-kernel-modules Damit sollten Debian und Co. das immerhin schon mal in die main statt non-free componente packen können. Manchmal wird man aber wohl immernoch DKMS Versions / build Probleme haben, das Modul ist immernoch off-tree. Und die user space Teile von NVIDIA sind weiterhin closed source, diese währen ja das wirklich interessante, also erst ein kleiner Schritt...
🐧 DPA 🐧 schrieb: > Und die user space Teile von NVIDIA sind weiterhin closed source, diese > währen ja das wirklich interessante, also erst ein kleiner Schritt... Für mich sind da erstmal die problematische Maus-Situation in Baldurs Gate2 oder auch Screenshots in Skyrim mit Wine (für die es scheinbar keine einfache Lösung gibt) spannender. Drucker (Tintenstrahl) oder Scanner habe ich auch - und weil mein Windows 8 NB nicht mehr alles mitmacht, würde ich solche Sachen schon zentral auf der Linux-Kiste laufen lassen. Aber den Drucker habe ich noch nicht angeworfen. Weil ich das nicht oft brauche, würde ich zum Drucken lieber wieder die Spielhalle nutzen, die wohl jetzt auch wieder zugänglicher ist (gesetzlich Beschränkungen weg, 3G weg usw.) Tatsächlich reizt es mich mal zu schauen, ob ich dort wie früher Drucken kann. Praktisch ein Testdruck vor Ort. Das System war ja von vornherein Linux.
Andreas B. schrieb: > Nano schrieb: >> Die Probleme fangen ja nur genau dann an, wenn man als >> Hardwarehersteller unbedingt proprietäre Treiber haben will. > > Nein, die Probleme fangen an, wenn man solchen Mist kauft. Du siehst es also nicht als Problem an, wenn der Hardwarehersteller unbedingt proprietäre Treiber haben will und aktiv verhindert, dass Informationen, die die Entwicklung eines freien Treibers begünstigen könnten, wenn er ihn schon nicht selber entwickelt, an die Öffentlichkeit gelangen? Meiner Meinung liegt das Problem ursächlich am Hersteller, der Kunde reagiert darauf nur in zweiter Instanz, aber wenn man das Problem am Schopf packen will, dann liegt es am Hersteller.
Komisch. Ich habe auf meine Laptop eine Nivia Grafikkarte. Witziger weise habe ich mit den Nivida-Treiber von Nivida etwas Probleme. Wenn ich aber den "eingebauten" Treiber von Mint nehme, funktioniert das PERFEKT. Sogar mit Sondereinstellungen = Umskalierung des Bildschirms weil ich die Ausgabe auf einen Exteren Monitor (mit Standfuß) umlenke. Ich muss aber zugeben, ich mache da nur "office-ähnliche" Anwendungen.
Johannes U. schrieb: > Davon ab, hier wurde ja oben auch behauptet, Debian haette ab Version 9 > den 304er Treiber aus den Quellen entfernt. Das wurde von mir nicht behauptet, ich sagte ab Version 10. Version 9 ist die letzte Version, die den Treiber noch hat. Siehe: https://packages.debian.org/search?keywords=nvidia-legacy-304 > Nun, das kann nicht zutreffen, denn ich habe mir hier letztens mal eine > Installation von Debian Testing, also Debian 12, auf eine Platte > gebuegelt. > Auch da habe ich problemlos die 304er nvidia-Treiber in den > Paketquellen. Da hast du dich entweder verguckt oder du hast ein fremdes oder altes Repository eingebunden. Die sind nämlich nicht mehr im Repo. Schau hier und überzeuge dich selbst: https://packages.debian.org/search?keywords=nvidia-legacy-304&searchon=names&suite=bookworm§ion=all Bookworm ist Testing und 304 ist da nicht mehr drin. 304 war letztmalig in Stretch drin. Aber das sagte ich ein paar Kommentare weiter oben schon.
Alternativ kann man sich das auch mit rmadison anzeigen lassen:
1 | rmadison nvidia-legacy-304xx-driver |
2 | nvidia-legacy-304xx-driver | 304.137-0~deb8u1 | oldoldoldstable/non-free | amd64, i386 |
3 | nvidia-legacy-304xx-driver | 304.137-5~bpo9+1 | stretch-backports/non-free | amd64, i386 |
4 | nvidia-legacy-304xx-driver | 304.137-5~deb9u1 | oldoldstable/non-free | amd64, i386 |
oldoldstable ist Debian Stretch, also Debian 9. oldoldoldstable ist Debian Jessie, also Debian 8.
Nano schrieb: > Du siehst es also nicht als Problem an, wenn der Hardwarehersteller > unbedingt proprietäre Treiber haben will und aktiv verhindert, dass > Informationen, die die Entwicklung eines freien Treibers begünstigen > könnten, wenn er ihn schon nicht selber entwickelt, an die > Öffentlichkeit gelangen? Den HW Herstellern steht es frei, irgendwelche dubiosen oder gar keine Treiber zu entwickeln aber ich muß den Müll ja auch nicht kaufen. Das nennt sich freie Marktwirtschaft.
Johannes U. schrieb: > Und naja, neue Karte? > In diesen Zeiten mit Mondpreisen in dem Sektor ne neue Karte in einen 10 > Jahre alten Rechner stecken? > Denke nicht, dass sich das lohnt. Man muss für einen alten Rechner keine High-End Karte kaufen. Durch den großen Zeitabstand wird auch eine Niedrigpreiskarte schneller sein, als diese alte Karte. Zumal das ohnehin nur eine Geforce 7300 war. Die Ziffer 3 an der 3. Stelle (bei heutigen Karten ist es die 2. Stelle) steht bei NVidia für die Klassifizierung der Karte und die 3 steht für Office PC. Unteres Midrange beginnt bei 5, z.b. Geforce 7500, Midrange bei 6, z.B. Geforce 7600 und ab 8 beginnt High End, also Geforce 7800. Siehe auch: https://de.wikipedia.org/wiki/Nvidia-GeForce-7-Serie#Modelldaten
🐧 DPA 🐧 schrieb: > Ja, Nvidia ist immer ein krampf, und dann wird der proprietäre Mist auch > noch für linux von gamern weiterempfohlen. > > Eventuell wird es nun zumindest ein bisschen weniger ein Krampf: > https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1 > https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ > https://github.com/NVIDIA/open-gpu-kernel-modules Ist mir bekannt die News. Meine Geforce 1070 ist leider nicht dabei. :( > Damit sollten Debian und Co. das immerhin schon mal in die main statt > non-free componente packen können. Der Treiber wird im Prinzip in zwei Hälften aufgeteilt. Es wird eine proprietäre Firmware geben und die wird in non-free bleiben. Es sollte damit aber zumindest einfacher werden, die Karten länger lauffähig zu halten.
rbx schrieb: > 🐧 DPA 🐧 schrieb: >> Und die user space Teile von NVIDIA sind weiterhin closed source, diese >> währen ja das wirklich interessante, also erst ein kleiner Schritt... > > Für mich sind da erstmal die problematische Maus-Situation in Baldurs > Gate2 oder auch Screenshots in Skyrim mit Wine (für die es scheinbar > keine einfache Lösung gibt) spannender. Es gibt von BG 2 eine Enhanced Edition, die läuft auch unter Linux, siehe: https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition
Andreas B. schrieb: > Nano schrieb: >> Du siehst es also nicht als Problem an, wenn der Hardwarehersteller >> unbedingt proprietäre Treiber haben will und aktiv verhindert, dass >> Informationen, die die Entwicklung eines freien Treibers begünstigen >> könnten, wenn er ihn schon nicht selber entwickelt, an die >> Öffentlichkeit gelangen? > > Den HW Herstellern steht es frei, irgendwelche dubiosen oder gar keine > Treiber zu entwickeln aber ich muß den Müll ja auch nicht kaufen. > Das nennt sich freie Marktwirtschaft. Du beantwortest meine Frage nicht. Die Frage war der Punkt was das Problem ist und das Problem fängt nicht erst beim Kunden an, sondern eben beim Hersteller.
Nano schrieb: > Alternativ kann man sich das auch mit rmadison anzeigen lassen: > >
1 | > rmadison nvidia-legacy-304xx-driver |
2 | > nvidia-legacy-304xx-driver | 304.137-0~deb8u1 | oldoldoldstable/non-free |
3 | > | amd64, i386 |
4 | > nvidia-legacy-304xx-driver | 304.137-5~bpo9+1 | |
5 | > stretch-backports/non-free | amd64, i386 |
6 | > nvidia-legacy-304xx-driver | 304.137-5~deb9u1 | oldoldstable/non-free |
7 | > | amd64, i386 |
8 | > |
> > oldoldstable ist Debian Stretch, also Debian 9. > oldoldoldstable ist Debian Jessie, also Debian 8. Aeh, ja, schaut so aus, als muesste ich Abbitte leisten... Hatte mit apt-cache nachgeguckt, dabei aber ein grep auf 304 gemacht und vergessen -A und -B als Schalter zu setzen. Bookworm kennt den 304er Treiber also noch entfernt dem Namen nach, mit den Standardquellen gibt es aber in der Tat keinen Installationskandidaten..
Thomas Leu schrieb: > Ich habe das Problem mit dem Drucken gelöst, es geht jetzt. Der weg > dorthin war aber wirr.. Super, das freut mich, wenngleich sich der Weg... nunja... tatsächlich etwas wirr liest. Naja, Hauptsache es funktioniert. Viel Spaß und Erfolg mit Linux, herzlich willkommen! Wenn ich Dir für die Zukunft einen kleinen Tipp geben darf: das, was so ein Linux ausgibt und / oder in seine Logdateien schreibt, ist fast immer wichtig. Das ist nicht wie unter anderen Systemen, die ihre User manchmal mit so vielen (und nicht selten, sagen wir... inhaltlich armen) Dialogen nerven, bis die nur noch entnervt "Ok" oder "Weiter" klicken, ohne zu lesen, was da steht. Damit wirst Du unter Linux wahrscheinlich in größere Schwierigkeiten geraten und auf jeden Fall häufig sehr sinn- und wertvolle Tipps zu den Fehlerursachen und ihrer Behebung verpassen (ja, tatsächlich, manche Programme sind so klug, direkt Hinweise auszugeben). PS: Das Buch "Linux" von Michael Kofler ist das deutschsprachige Standardwerk zu Linux und zwar sehr umfangreich und nicht ganz billig, aber dennoch wärmstens empfohlen. Darin sind nicht nur die Basics und die Zusammenhänge gut beschrieben, sondern Du findest auch Anleitungen zu einer Vielzahl gebräuchlicher Programme für alle möglichen Aufgaben. Viel Spaß!
Zeno schrieb: > Mein Mint 20.03 mit Kernel 5.4 läuft jetzt. Allerding war es eine Orgie > dem System das beizubringen. Der Normaluser scheitert daran definitiv > und ich hätte es ohne Google und einer gehörigen Portion Ausdauer (eine > gute Woche) auch nicht gebacken bekommen. Die Schwierigkeit ist nicht > der Installer von NVidia, den kann jeder bedienen, das Problem ist hier > eindeutig Linux. Vielleicht muß man an dieser Stelle einmal kurz daran erinnern, wie so etwas alternativ unter Windows aussieht. Wenn Microsoft mal wieder das Treibermodell ändert und der Hersteller einer Hardware sich entscheidet, seine Treiber nicht für das neue Treibermodell bereitzustellen, dann schaut der Benutzer im Zweifelsfall in die Röhre und hat oft nicht einmal mehr die Möglichkeit, seine ansonsten tadellos funktionierende Hardware auf einer aktuellen Windows-Version weiter zu nutzen. In solchen Fällen hat man mit einem offenen System wie Linux immerhin oft zumindest eine Chance, seine Hardware mit etwas Gebastel zum Funktionieren zu bekommen. Was NVidia-Karten angeht, so kann ich bislang weder über die Nouveau-Treiber klagen -- die funktionieren zumindest auf meinen Systemen absolut einwandfrei, nur hin und wieder beim Hin- und Herschalten zwischen der 2D-Grafikchip des Prozessors und dem 3D-Grafikchip auf der Nvidia-Karte macht er manchmal ganz kurze Zicken (kleinere Streifchen, die in Sekundenbruchteilen wieder verschwinden). Und am Ende ist das Problem... nunja, wenn der Hersteller einer proprietären Software komische Treiber ausliefert oder diese nicht auf aktuelle Kernelversionen portiert, andererseits aber auch den Entwicklern eines freien Treibers keine Informationen zukommen lassen will, dann ist das im Grunde kein Problem von Linux, sondern dieses Herstellers -- auch wenn sich das für die betroffenen Anwender leider als ein Problem zwar nicht von, dennoch aber eines mit Linux darstellt.
Ein T. schrieb: > (ja, tatsächlich, manche Programme sind so klug, direkt Hinweise > auszugeben). Bei Windows kriegst du deswegen einen Fehlercode, weil das viel kürzer und fehlerfreier ist, wenn der Kunde die Telefonhotline benutzen können soll. Und deswegen macht das Microsoft sehr wahrscheinlich genau so und nicht anders. 10 Sätze vorzulesen, die den Fehler beschreiben, dauern nämlich länger, als eine Zahl durchzugeben. Und am Support kann man bei gebührenpflichtigen Rufnummern als Unternehmen ja noch mitverdienen. Und was das fehlerfreier betrifft, wenn der Code noch eine Prüfsumme anhängt enthält, dann ist der Code überprüfbar und genau das dürfte gemacht werden. Der Fehlercode 8256...usw. wird am Telefon also nicht zur 8356... nur weil der Kunde in seinen Bart gemurmelt hat oder die Hotline es bei dem Genuschel nicht richtig verstanden hat. Klar, als erfahrener IT affiner Endanwender sind einem die langen ausführlichen Fehlermeldungen natürlich lieber und aus dieser Sicht auch besser, aber Microsoft hat da eine ganz andere Sichtweise darauf und das wollte ich hiermit nur mal erklären warum das überhaupt so gemacht wird. Das ist also kein Fehler eines unzulänglicheren Systems, sondern Absicht und aus MS Sicht ist dieses System klar das bessere und somit nicht unzulänglich. Denn kurze Codes kann man schneller abhandeln und man kann noch daran mitverdienen.
Nano schrieb: > Hast du das verlinkte Dokument überhaupt gelesen? Jein nur übeflogen, denn es löst nicht mein Problem. Ich brauche am Ende ein funktioniertendes System und da ist es mir erst mal so ziemlich Rille ob da (wie der Verfasser am Ende schreibt) "andere User den Treiber verbessern". Die Entwickler haben es in 16 Jahren! (nouveau ging 2006 los) nicht geschafft einen funktionieren Treiber bereit zu stellen. Es ist ja fürs erste auch nicht schlimm, offensichtlich ist das Ganze ja nicht so trivial. Was Mist ist, das sie die Leinen des Netzes gekappt haben, welche einen auffangen würde wenn man abstürzt. Sei's drum mein Problem ist jetzt gelöst und damit ist das für mich erst mal abgehakt. Johannes U. schrieb: > Bezieht sich das auf einen nun funktionierenden > nvidia-legacy-304xx-driver? Ja genau auf den, genauer gesagt es ist das Treiberpakekt 304.137 von NVidia. Ob der in den Paketquellen von Debian enthaltene legacy Treiber mit diesem identisch ist, vermag ich nicht zu beurteilen. Ich habe dann trotzdem noch mal versucht das Ding unter Debian mit 5.10'er Kernel zum Laufen zu kriegen, bisher aber recht erfolglos. Es scheint also noch weitere Unterschiede zwischen Kernel 5.4 (Mint) und Kernel 5.10 zu geben, die das Einspielen des Treibers verhindern. Auf alle Fälle sind in den beiden Headertrees unter /usr/src deutliche Unteschiede zu sehen und genau an den hakt es auch. Unter 5.10 funktioniert ja noch nicht einmal ein make im Headertree und das hat ja nun mal nix mit dem Treiber zu tun. Make meint das da Dateien fehlen würden (sie fehlen wirklich). Dafür gibt es dann eigentlich nur 2 Erklärungen entweder ist das Paket mit den Headerdateien falsch zusammengeschnürt oder man hätte das Makefile anpassen müssen.
Mit anderen Worten, MS ist nicht dumm, sondern gerissen. Die sind so schlau, dass sie Fehlercode nutzen um daran auch noch zu verdienen und die Supportzeiten kurz zu halten.
Nano schrieb: > Bei Windows kriegst du deswegen einen Fehlercode, weil das viel kürzer > und fehlerfreier ist, wenn der Kunde die Telefonhotline benutzen können > soll. Ja, weil das abtippen von den kryptischen Codes so fehlerfrei ist, hat man auch keine Funktion zum Kopieren in die Zwischenablage eingebaut. Usability stand da voll im Vordergrund. Danke MS, die du an uns Deutsche mit den Telefon- und Faxgeräten denkst!
Karl schrieb: > Nano schrieb: >> Bei Windows kriegst du deswegen einen Fehlercode, weil das viel kürzer >> und fehlerfreier ist, wenn der Kunde die Telefonhotline benutzen können >> soll. > > Ja, weil das abtippen von den kryptischen Codes so fehlerfrei ist, hat > man auch keine Funktion zum Kopieren in die Zwischenablage eingebaut. > Usability stand da voll im Vordergrund. Danke MS, die du an uns Deutsche > mit den Telefon- und Faxgeräten denkst! Das liegt an UAC, das ist etwas anderes. Da geht es um eine Abschottung zwischen UAC Dialog und dem Rest. Daher lässt sich nichts aus dem UAC Dialog in die Zwischenablage (Rest) kopieren.
Nano schrieb: > Zumal das ohnehin nur eine Geforce 7300 war. Ja und? Die Karte versieht mit dem passenden Treiber klaglos ihren Dienst und macht das was sie soll.
Ein T. schrieb: > Vielleicht muß man an dieser Stelle einmal kurz daran erinnern, wie so > etwas alternativ unter Windows aussieht. Wenn Microsoft mal wieder das > Treibermodell ändert Das machen die allerdings eher selten, während das Linux praktisch bei fast jedem BUILD macht. (OK, ist praktisch ein klein wenig übertrieben, aber theoretisch möglich). Sprich: Linux besitzt nichtmal sowas, was richtige OS ein Treibermodell nennen würden. Weswegen jede Änderung an diesem (de facto nicht vorhandenem) "Modell" dazu führt, dass unzählige Mannmonate Entwicklerpower immer und immer wieder nur damit verbraten werden müssen, den neuesten Geistesfurz der Kernel-Entwickler daraufhin zu überprüfen, inwiefern er die Funktion des Treibers tangiert. Bei Tausenden von Treibern fällt da auch gerne mal was hinten runter. Es ist bei älteren und/oder wenig benutzten Treibern einfach niemand mehr da, der das auch nur ernsthaft kontrolliert, geschweige denn repariert, wenn der Test negativ ausgeht... Was wiederum dazu führt, dass es unzählige Treiber im ganz offiziellen Kernel gibt, die de facto nicht mehr funktional sind...
Ein T. schrieb: > Wenn Microsoft mal wieder das > Treibermodell ändert und der Hersteller einer Hardware sich entscheidet, > seine Treiber nicht für das neue Treibermodell bereitzustellen, dann > schaut der Benutzer im Zweifelsfall in die Röhre und hat oft nicht > einmal mehr die Möglichkeit, seine ansonsten tadellos funktionierende > Hardware auf einer aktuellen Windows-Version weiter zu nutzen. Nein es ist nicht ganz so wie Du schreibst. Problem unter Win10 ist die Treibersignatur, die alte Treiber nicht haben. Ohne diese Signatur verweigert Windows die Installation. Man kann aber die Überprüfung der Treibersignatur abschalten und dann meist problemlos den Treiber installieren. Oftmals werden Treiber auch über ein ganz normales Setupprogramm installiert und das funktioniert meist problemlos. Ansonsten hat Windows für viele Dinge auch noch einen Wald und Wiesen Treiber mit dem die Hardware erst mal benutzbar funktioniert.
c-hater schrieb: > Weswegen jede Änderung an diesem (de facto nicht vorhandenem) "Modell" > dazu führt, dass unzählige Mannmonate Entwicklerpower immer und immer > wieder nur damit verbraten werden müssen, den neuesten Geistesfurz der > Kernel-Entwickler daraufhin zu überprüfen, inwiefern er die Funktion des > Treibers tangiert. Bei Tausenden von Treibern fällt da auch gerne mal > was hinten runter. Es ist bei älteren und/oder wenig benutzten Treibern > einfach niemand mehr da, der das auch nur ernsthaft kontrolliert, > geschweige denn repariert, wenn der Test negativ ausgeht... Dem ist nichts mehr hinzu zu fügen. c-hater schrieb: > Was wiederum dazu führt, dass es unzählige Treiber im ganz offiziellen > Kernel gibt, die de facto nicht mehr funktional sind... Ja weil sie einfach in der Hochnäsigkeit der Kernelentwickler untergehen. Die interessiert es halt einen Scheißdreck ob der Rest des Systems noch funktioniert. Man hat halt wieder mal einen Geistesblitz im Kernel untergebracht und der Kernel tut, der Rest ist ne andere Baustelle.
Zeno schrieb: > Nano schrieb: >> Zumal das ohnehin nur eine Geforce 7300 war. > Ja und? Die Karte versieht mit dem passenden Treiber klaglos ihren > Dienst und macht das was sie soll. Es geht darum, dass man nicht viel Geld ausgeben muss, um eine Geforce 7300 zu ersetzen. Da reicht also die billigste Linux taugliche Grafikkarte mit guten Open Source treiber. Und jetzt vergleiche deren günstiger Preis mit deinen 2 Wochen Aufwand, den du reinstecken musstest, um die alte GPU irgendwie wieder zur Mitarbeit zu bewegen.
c-hater schrieb: > Ein T. schrieb: > >> Vielleicht muß man an dieser Stelle einmal kurz daran erinnern, wie so >> etwas alternativ unter Windows aussieht. Wenn Microsoft mal wieder das >> Treibermodell ändert > > Das machen die allerdings eher selten, während das Linux praktisch bei > fast jedem BUILD macht. (OK, ist praktisch ein klein wenig > übertrieben, aber theoretisch möglich). Das stimmt nicht. Für proprietäre Treiber gibt es Schnittstellen wie DKMS, die in sehr stabil sind und selten geändert werden. Zumindest beim Rolling Release von Windows 10 sah das hingegen gänzlich anders aus. Da wurde nämlich mehrmals das Treibermodell geändert, und zwar tatsächlich bei jedem neuen Release von Win10 -- allerdings abwärtskompatibel: [1]. [1] https://en.wikipedia.org/wiki/Windows_Driver_Frameworks#Versions
c-hater schrieb: > Was wiederum dazu führt, dass es unzählige Treiber im ganz offiziellen > Kernel gibt, die de facto nicht mehr funktional sind... Ich hatte noch nie Hardware, bei der so war. Und falls doch, dann ist die so alt, dass ich die mit neuren Distris nicht mehr getestet habe.
Nano schrieb: > Das liegt an UAC, das ist etwas anderes. Da geht es um eine Abschottung > zwischen UAC Dialog und dem Rest. Daher lässt sich nichts aus dem UAC > Dialog in die Zwischenablage (Rest) kopieren. Sicher, schon zu Windows 98 dachte MS als erstes an die Sicherheit des Systems. Beim unsicherem Linux ist das problemlos möglich, deshalb kommt es auf kritischen Systemen im Internet nicht zum Einsatz.
Karl schrieb: > Nano schrieb: >> Das liegt an UAC, das ist etwas anderes. Da geht es um eine Abschottung >> zwischen UAC Dialog und dem Rest. Daher lässt sich nichts aus dem UAC >> Dialog in die Zwischenablage (Rest) kopieren. > > Sicher, schon zu Windows 98 dachte MS als erstes an die Sicherheit des > Systems. Beim unsicherem Linux ist das problemlos möglich, deshalb kommt > es auf kritischen Systemen im Internet nicht zum Einsatz. Oh, Oh. Der war aber böse. ;-) ;-) ;-)
Nano schrieb: > Es geht darum, dass man nicht viel Geld ausgeben muss, um eine Geforce > 7300 zu ersetzen. Es geht nicht darum wie viel Geld man da ausgeben muß. Es ist einfach unnötig. Hinzukommt noch, aber das schrieb ich ja bereits, das dies mein Softwaretestrechner ist, wo ungefähr 10 Betriebssysteme installiert sind. Wenn ich da so was ändere da sitze ich erst mal ne Weile um da überall die passenden Treiber zu installieren. Wenn's ganz dumm läuft dann gibt es für die neue Karte keinen XP-Treiber oder keinen Treiber für das darauf laufende Fedora. Mit anderen Worten ich mache mir da möglicherweise Baustellen auf auf die ich gern verzichte. Und jetzt komm nicht "ist eh alles alter Kram" und kann deshalb weg. Das weis ich selber, aber ich habe meine Gründe warum ich diesen alten Kram noch am Laufen habe. Nano schrieb: > Und jetzt vergleiche deren günstiger Preis mit deinen 2 Wochen Aufwand, Mach Dir mal um meinen Arbeitsaufwand keine Sorgen. Es nervt zwar und ist auch unschön, im Gegenzug bin ich aber nicht dümmer geworden und da ich früh nicht mehr den Wecker stellen muß habe ich durchaus diese Zeit, auch wenn ich die eigentlich lieber für das mit dieser Aktion angestrebte Endergebnis genutzt hätte. Jetzt ist es gut und abgehakt.
Zeno schrieb: > Hinzukommt noch, aber das schrieb ich ja bereits, das dies mein > Softwaretestrechner ist, wo ungefähr 10 Betriebssysteme installiert > sind. Du leistest Dir also den Luxus eines eigenen Softwaretestrechers, aber 100 Euro für eine unterstützte Grafikkarte sind unzumutbar... Ah ja. Und Software kann man nicht in einer VM testen? Das muß ja eine sehr spezielle Software sein. ;-)
Zeno schrieb: > Jetzt ist es gut und abgehakt. Du wolltest doch eine Antwort und die hast du bekommen. Hat deine 7300 eigentlich noch AGP? Falls ja, dann würde es mit dem Ersetzen tatsächlich schwierig werden.
Karl schrieb: > Nano schrieb: >> Das liegt an UAC, das ist etwas anderes. Da geht es um eine Abschottung >> zwischen UAC Dialog und dem Rest. Daher lässt sich nichts aus dem UAC >> Dialog in die Zwischenablage (Rest) kopieren. > > Sicher, schon zu Windows 98 dachte MS als erstes an die Sicherheit des > Systems. Beim unsicherem Linux ist das problemlos möglich, deshalb kommt > es auf kritischen Systemen im Internet nicht zum Einsatz. Wenn du etwas anderes meinst, dann findest du das in der Ereignisanzeige. Dafür ist die da. Und Kerneldumps (Stichwort BlueScreen) werden in einem Verzeichnis abgelegt, die du dann mit dem entsprechenden Programm laden und anzeigen kannst. Da kannst du dir dann auch die BS Meldung wieder angucken.
Ein T. schrieb: > Und > Software kann man nicht in einer VM testen? Wäre sicher möglich, aber reale Hardware ist und bleibt nun mal reale Hardware. Ein T. schrieb: > Das muß ja eine sehr > spezielle Software sein. Ach so speziell ist die gar nicht. Sie kleine Tools, die dem Servicetechniker die Arbeit erleichtern sollen. Wenn man da vor Ort ist und das Werkzeug (SW ist nichts anderes) funktioniert dann nicht wie gewünscht, steht man praktisch allein im Regen und macht sich noch beim Kunden zum Vollhorst. Ich habe lang genug im Außendienst gearbeitet und weis da wovon ich rede. Da man oftmals nicht vorhersagen kann welche Hardware bzw. welches OS man beim Kunden vorfindet, prüfe ich halt die SW unter möglichst vielen Umgebungen. Ich mach's halt ein bischen anders als die nouveau-Entwickler denen es egal ist ob's funktioniert oder nicht. Nano schrieb: > Hat deine 7300 eigentlich noch AGP? Ich meine die ist PCI, kann es momentan aber nicht genau sagen.
Zeno schrieb: >> Und Software kann man nicht in einer VM testen? > Wäre sicher möglich, aber reale Hardware ist und bleibt nun mal reale > Hardware. Der Streit kommt mir bekannt vor! Ich hatte in der Firma einen Rechnerzoo und Acronis-TrueImage, um die Maschinen wieder zurückzusetzen. VM habe ich abgelehnt und bin auf den Realumgebungen mehr als einmal über Probleme gestolpert, die dem hauptberuflichen SW-Tester in seinen VMs nicht aufgefallen sind.
Manfred schrieb: > Der Streit kommt mir bekannt vor! Ich hatte in der Firma einen > Rechnerzoo und Acronis-TrueImage, um die Maschinen wieder > zurückzusetzen. > > VM habe ich abgelehnt und bin auf den Realumgebungen mehr als einmal > über Probleme gestolpert, die dem hauptberuflichen SW-Tester in seinen > VMs nicht aufgefallen sind. Ich hatte mit einer Software zur Steuerung einer Maschine zu tun die echte Hardware und dort auch exklusiven Zugriff verlangt hat. Das war eigentlich eine DOS-Software, lief aber auch unter Win95 im Vollbildmodus. Danach war dann Schluß, weil die Folgesysteme allen einen NT Kern hatte der derartige exklusive Zugriffe nicht mehr erlaubt hat. Da diese Software für den Werker sehr gut zu bedienen war, wollten einige Kunden dann DOS in einer virtuellen Maschine installieren und die Software dort laufen lassen, sind daran aber kläglich gescheitert. Am Ende haben sie sich dann einen Rechner (< P4) besorgt und darauf Win98 installiert.
Zeno schrieb: > Da diese Software für den Werker sehr gut zu bedienen war, wollten > einige Kunden dann DOS in einer virtuellen Maschine installieren und die > Software dort laufen lassen, sind daran aber kläglich gescheitert. Natürlich sind sie das. Damals gab es ja auch noch kein Virtual I/O. Auf heutigen Systemen ist das anders, da kann man die HW direkt an das Gastsystem durchreichen. Hat man also bspw. ein USB Gerät von 1998, das auf neuen Systemen mangels Treiber nicht mehr unterstützt wird, kann man es trotzdem an einen neuen Rechner anschließen, dann in einer VM das alte OS als Gastsystem laufen lassen und das USB Gerät direkt an dieses durchreichen und dann kann man da die alten Treiber für das Gastsytem installieren und das Gerät so trotzdem nutzen.
Nano schrieb: > Auf heutigen Systemen ist das anders, da kann man die HW direkt an das > Gastsystem durchreichen. Es läuft trotzdem nicht - glaube es mir einfach.
Seit längerer Zeit schafft Windows es jedenfalls, das die Systeme bei den Kunden mit weniger Support Aufwand laufen als zu XP oder Windows 7 Zeiten. Windows 10 ist mit allen Treibern, einzug in die Domäne Drucker und Office, ERP und Bankingsoftware oft in unter einer Stunde eingerichtet. Da diskutieren die Linuxjünger noch darüber welche Distribution sie nehmen sollen. Linux ist wie alle Betriebssteme in manchen Dingen stark und hat Schwächen bei anderem. Ich nutze es öfter zum Spielen mit Raspi und uralt PCs habe aber mehr als genug aktuellere Hardware. Produktiev kenne ich bei Windows fast jede Schraube und niemand konnte mich davon überzeugen hunderte von Stunden in unverkäufliches zu investieren um einen vergleichbaren Wissensstand aufzubauen. Da setzte ich mich lieber an den Lötkolben, programmiere PICs oder fahre mit dem Wohnwagen ins Grüne statt damit meine knappe Freizeit zu verbringen, Fehler im Betriebsstemen zu suchen. MfG Michael
Zeno schrieb: > Es läuft trotzdem nicht - glaube es mir einfach. GDI Drucker kriegt man aber so zum Laufen.
Dieter schrieb: > Zeno schrieb: >> Es läuft trotzdem nicht - glaube es mir einfach. > > GDI Drucker kriegt man aber so zum Laufen. Es geht bei der von mir beschriebenen Sache eben nicht um Drucker oder irgend eine andere Hardware. Es geht schlicht und ergreifend um eine 3D-Messoftware auf DOS-Basis. Die Software wurde Anfang der 90'ziger mit Pascal von MS geschrieben. Sie enthält auch jede Menge Assemblercode, weil anders damals manche Sachen nicht realisierbar waren. Die Software schreibt z.B. direkt per Assembler in den Bildspeicher, damit der Bildschirmaufbau flott funktioniert. Man nutzt also nicht die Grafikbefehle die Pascal mit bringt, weil das viel zu langsam wäre (da könnte man beim Malen zuschauen). Da eine solche Messsoftware naturgemäß viel und möglichst genau rechnen muß, macht sie natürlich auch extensiven Gebrauch vom mathematischen Coprozessor (das war in der 286'er/386'er Zeit noch ein Extrabaustein, so was hatte ein Standardrechner meist nicht). Schon beim Start hat die Software diverse Coprozessorbefehle geprüft. Wenn da nicht das Passende zurück kam, war schlicht und ergreifend Schluß. Es gab zu jener Zeit auch Software die den Coprozesser vorgegaukelt hat, das hat die SW aber mitbekommen und dann den Dienst verweigert. Ebenso funktionieren keine Rechner mehr mit P4 oder höher. Da haben sich lt. Entwickler der SW einige Coprozessorinstruktionen geändert. Da zu diesem Zeitpunkt aber schon die neue SW-Generation für Windows unterwegs war und sich das Ende der alten SW abzeichnete, wurde das auch nie gefixt.
Zeno schrieb: > Ebenso > funktionieren keine Rechner mehr mit P4 oder höher. Da haben sich lt. > Entwickler der SW einige Coprozessorinstruktionen geändert. Welche sollen das sein? Intel und AMD kümmern sich eigentlich darum, dass die neuen Prozessoren kompatibel zu alter Software sind. Das einzige was rausflog ist 3dNow und das A20 Gate.
Michael_O schrieb: > Produktiev kenne ich bei Windows fast jede Schraube Wenn man nur einen Hammer kennt, sieht jedes Problem wie ein Nagel aus.
Google findet zu dem Begriff kinux nichts. Also gehe ich davon aus, dass es kinux nicht gibt. Aber warum findet Google unter dem Begriff kinux diesen Thread hier nicht? Bedeutet das, dass es diesen Thread gar nicht gibt und aus einer Parallelwelt stammt?
Hallo, den Thread findet Google als ersten Treffer. Natürlich sucht das kluge Google mit: Ergebnisse für kinox Stattdessen suchen nach: kinux Mit den kinux-Treffern kann man dann wenigstens auch im Chip-Forum weiterlesen: https://forum.chip.de/discussion/1348152/kinux-startet-nicht Und das alles sogar unter Win10 pro / 64Bit ohne MS-Konto... Gruß aus Berlin Michael
Nano schrieb: > Welche sollen das sein? > > Intel und AMD kümmern sich eigentlich darum, dass die neuen Prozessoren > kompatibel zu alter Software sind. > Das einzige was rausflog ist 3dNow und das A20 Gate. Kann ich Dir nicht sagen. Da müßte man den Entwickler fragen. Das Programm arbeitet beim Start eine Checklist ab und, da kann ich mich selbst noch daran erinnern, da fliegt er dann beim Coprozessortest raus, wenn da ein Chip >=P4 verbaut ist. AMD-Prozessoren haben mit dem Programm auch nicht funktioniert. Da ist Vieles in Assembler gemacht und da könnte es schon sein das da was nicht mehr passt. Aber egal die Zeit ist lange vorbei.
Zeno schrieb: > Kann ich Dir nicht sagen. Da müßte man den Entwickler fragen. Das > Programm arbeitet beim Start eine Checklist ab und, da kann ich mich > selbst noch daran erinnern, da fliegt er dann beim Coprozessortest raus, > wenn da ein Chip >=P4 verbaut ist. AMD-Prozessoren haben mit dem > Programm auch nicht funktioniert. Da ist Vieles in Assembler gemacht und > da könnte es schon sein das da was nicht mehr passt. > Aber egal die Zeit ist lange vorbei. Vielleicht war es auch einfach nur geplante Obsoleszenz. Man könnte im Programm einen Code einbauen, der die CPU abfragt und wenn die CPU Generation dann unbekannt bzw. zu neu ist, dann das Programm beendet. Mit einem Debugger könnte man das überprüfen, was da genau gemacht wird, und wahrscheinlich wird das Programm einwandfrei weiter funktionieren, wenn man nur diese eine Stelle einfach überspringt. Denn wenn es wirklich ein Prozessorproblem wäre, dann würde das bedeuten, dass die CPU nicht 100 % abwärtskompatibel wäre und dann würde das sehr viele Programme betreffen und nicht nur eines von tausenden.
Nano schrieb: > Vielleicht war es auch einfach nur geplante Obsoleszenz. > Man könnte im Programm einen Code einbauen, der die CPU abfragt und wenn > die CPU Generation dann unbekannt bzw. zu neu ist, dann das Programm > beendet. Nö das glaube ich nicht. Das war ein selbständiger Programmierer und der hat an der SW auch sehr gut verdient. Der hätte die SW auch gern weiter gemacht da sie bei den Kunden sehr beliebt war, von einer geplanten Obsolenz hätte er herzlich wenig gehabt. Die CPU hat er nicht abgefragt, die war an sich so ziemlich Rille solange sie von Intel war. Als der Pentium 3 war die Entwicklung des Programmes schon eingestellt, da wurden maximal noch gravierende Bugs beseitigt. Auch ältere Versionen der SW, also wo noch nicht bekannt war das es überhaupt mal Pentium geben würde, laufen dennoch auf P3. Bei P4 wurde einiges gegenüber P3 geändert. U.a. wurde die NetBurst-Architektur eingeführt, was auch zur Änderung/Anpassung des Befehlssatzes führte. Da kann ich mir durchaus vorstellen, das dies Auswirkung auf Programme haben kann, die die HW sehr direkt per Assembler ansprechen. Ich kann mich daran erinnern das es zu DOS-Zeiten Emulatoren für den Coprozessor gab. Ich hatte mir sowas besorgt, damit ich das Programm mal auf dem heimischen PC zum Üben nutzen kann. Hat leider nicht funktioniert und ich habe meine Holde dann davon überzeugt, das ein Coprozessor undbedingt notwendigt ist - für den 386DX war der nicht ganz billig. Nano schrieb: > Mit einem Debugger könnte man das überprüfen, was da genau gemacht wird, Kann man sicher machen. Nano schrieb: > wenn man nur diese eine Stelle einfach überspringt. Einfaches Überspringen wird da wahrscheinlich nicht reichen. Da wird man wohl einige Befehle anpassen müssen. Wenn es so einfach gewesen wäre, hätte man das ganz bestimmt versucht - wir hatten durchaus pfiffige Kunden. Nano schrieb: > Denn wenn es wirklich ein Prozessorproblem wäre, dann würde das > bedeuten, dass die CPU nicht 100 % abwärtskompatibel wäre und dann würde > das sehr viele Programme betreffen und nicht nur eines von tausenden. Ich denke nicht das die CPU's zu 100% abwärtskompatibel sind, vor allem dann nicht, wenn hardwarenah programmiert wird. Und wenn die Anwendung keinen Coprozessor benötigt, fällt es auch nicht auf, wenn sich die Instruktionen ändern. Habe gerade noch was gefunden (https://www.computerix.info/skripten/hw-prog.pdf). Da wird beschrieben das sich um den P3 herum einiges geändert hat.
Zeno schrieb: > Habe gerade noch was gefunden > (https://www.computerix.info/skripten/hw-prog.pdf). Da wird beschrieben > das sich um den P3 herum einiges geändert hat. Das bezieht sich auf die SSE Einheiten die mit dem Pentium 3 erstmals eingeführt wurden und in vielen Fällen besser ist als die FPU, das bedeutet aber nicht, dass die FPU entfernt wurde. Der P3 hat immer noch eine FPU und versteht daher auch ihre Befehle. Und mit anderen Befehlen sind hier die SSE Befehle gemeint, die sich natürlich von den Befehlen der FPU unterscheiden. Siehe dazu auch: https://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
> Zeno schrieb: >> Habe gerade noch was gefunden >> (https://www.computerix.info/skripten/hw-prog.pdf). Da wird beschrieben >> das sich um den P3 herum einiges geändert hat. > PS, damit hier niemand suchen muss. Es geht wohl um Seite 79.
Zeno schrieb: > Nano schrieb: >> Vielleicht war es auch einfach nur geplante Obsoleszenz. >> Man könnte im Programm einen Code einbauen, der die CPU abfragt und wenn >> die CPU Generation dann unbekannt bzw. zu neu ist, dann das Programm >> beendet. > Nö das glaube ich nicht. Das war ein selbständiger Programmierer und der > hat an der SW auch sehr gut verdient. Der hätte die SW auch gern weiter > gemacht da sie bei den Kunden sehr beliebt war, von einer geplanten > Obsolenz hätte er herzlich wenig gehabt. Hast du aber nicht gesagt, dass es später eine Windowsversion gab? Wenn er die verkaufen wollte, hätte er von der vielleicht mehr gehabt, als für die alte Software weiter Support zu leisten. > Die CPU hat er nicht abgefragt, > die war an sich so ziemlich Rille solange sie von Intel war. Dann hat er ja zumindest schon einmal überprüft ob sie "Genuine Intel" war. Manche Software machte das früher tatsächlich und war natürlich ein Problem für die kompatiblen CPUs von AMD, Cyrix usw.. > Als der > Pentium 3 war die Entwicklung des Programmes schon eingestellt, da > wurden maximal noch gravierende Bugs beseitigt. Auch ältere Versionen > der SW, also wo noch nicht bekannt war das es überhaupt mal Pentium > geben würde, laufen dennoch auf P3. Es wäre möglich, dass die Prüfroutinen auf Pentium, Pentium Pro und Pentium 2 geprüft haben und er dann einfach davon ausging, dass das Namensschema so weiter geht und dann noch auf die 3 geprüft. Das hätte dann ein paar Jahre Ruhe gegeben um dann bei Version 4 zu scheitern. > Bei P4 wurde einiges gegenüber P3 geändert. U.a. wurde die > NetBurst-Architektur eingeführt, Die Netburst Architektur sollte aber keine negativen Auswirkungen auf normalen Programmcode haben. Wäre es nämlich so, dann hätte diese superlange Pipeline einen defekt bzw. unbrauchbar und das war sie nicht, denn sie konnte ja alten Code ausführen. > was auch zur Änderung/Anpassung des > Befehlssatzes führte. Der Befehlssatz wurde aber nicht verändert, sondern die CPUs mussten zur x86 voll kompatibel bleiben. > Da kann ich mir durchaus vorstellen, das dies > Auswirkung auf Programme haben kann, die die HW sehr direkt per > Assembler ansprechen. Ich nicht. Denn die CPUs müssen 100 % abwärtskompatibel bleiben. Und ein Compiler macht auch nicht mehr, als einen Hochsprachenquellcode in Assemblercode und dann in Binärcode oder gleich direkt in Binärcode umzuwandeln. Was vorkommen kann sind Fehler im Programm, die dann erst bei schnelleren Prozessoren auftreten können. Man denke da z.B. an den Runtime Error 200 von Turbo Pascal auf Pentium CPUs ab 200 MHz. Aber das war ein Timingproblem, der zu einem Schleifenüberlauf führte und kein Thema von inkompatiblen Prozessorbefehlen. Du kannst davon ausgehen, dass alle vorherigen x86 Befehle auch im P4 implementiert wurden. Zwar nutzte der P4, wie auch schon der Penitum Pro dafür µOps um diese dann umzusetzen, dennoch waren die alle vorhanden und Intel hat auch definitiv ausgiebig geprüft, dass die alle funktionieren. Das es also an CPU Befehlen lag, halte ich praktisch für ausgeschlossen. Dann ist es eher ein Timingproblem, wie beim TP Bug. > Ich kann mich daran erinnern das es zu DOS-Zeiten Emulatoren für den > Coprozessor gab. Ich hatte mir sowas besorgt, damit ich das Programm mal > auf dem heimischen PC zum Üben nutzen kann. Hat leider nicht > funktioniert Eine Coprozessoremulation läuft nur in Software und ein Programm, dass die Zeit misst, kann so natürlich recht einfach herausfinden, ob sie auf einem echten CoProzessor läuft, oder der CoProzessor lediglich emuliert wird. Zumindest gilt das für damalige CPUs. Außerdem wäre es auch möglich, dass die Software CoProzessor Lösung nicht korrekt oder vollständig umgesetzt ist. Da kommt's also auch auf den Softwarehersteller der Emulation an, ob der gute Arbeit macht oder nicht. Bei der P4 Geschichte sprechen wir aber nicht von irgendeiner Wald und Wiesen Shareware Klitsche, sondern von Intel, die zusehen muss, dass alle ihre Prozessoren voll abwärtskompatibel sind und allen alten Code ausführen können. >> Mit einem Debugger könnte man das überprüfen, was da genau gemacht wird, > Kann man sicher machen. Das wäre auch am sinnvollsten, da man sich so das Spekulieren ersparen könnte. >> wenn man nur diese eine Stelle einfach überspringt. > Einfaches Überspringen wird da wahrscheinlich nicht reichen. Da wird man > wohl einige Befehle anpassen müssen. Wenn es so einfach gewesen wäre, > hätte man das ganz bestimmt versucht - wir hatten durchaus pfiffige > Kunden. Wenn es ein Timingproblem war, hätte man vielleicht ein bisschen mehr machen müssen. Vielleicht hätte aber auch einfach eine Softwarebremse genügt. Beim obigen Turbo Pascal Runtime Error 200 Problem hat die bspw, auch funktioniert.
Zeno schrieb: > Da ist Vieles in Assembler gemacht und > da könnte es schon sein das da was nicht mehr passt. > Aber egal die Zeit ist lange vorbei. Es ist aber schon noch ein Unterschied, ob man über das Bios bzw. mit "Bios-Interrupts" die Grafikkarte anspricht, oder indirekt über Speicherübergaben die FPU bzw. genauso blöd MMX. Das verbreitete Know How wird auch bei der Grafikkartenansprache besser gewesen sein, aufgrund der speziellen Frage mit den Coprozessoren. Auch Diskussionen unter E-Technik-Studenten bezogen sich eher auf Grafikkarten als auf Coprozessoren bzw. die FPU. Und in der c't gab mal ein netten Artikel über MMX, und wie lange das dauert, bis das überhaupt (im Kompatibilitäts-) Sinne verstanden wird, bzw. bis sich solche Art von Technik mit der Welt draußen vertraut macht: ca 10 Jahre. Mitte der 90er ging es in Richtung Dos-Extender - das war auch noch mal ein spezieller Fall. So ganz ganz grob, also so wirklich wirklich grob: Bei HPC oder bei Bitcoin-Berechnungen werden Grafikkarten benutzt, nicht Coprozessor, nicht MMX, Dualcore, bzw. Multicore auch nicht wirklich. Da konnten wohl auch die Cell-Blades (bei HPC) mit ihren SPEs besser punkten. Aber in der c't wurde freundlicherweise gezeigt, wie extrem gut die Cell-Compis von gepflegtem Assember profitieren. https://de.wikipedia.org/wiki/Cell_(Prozessor) Wirklich schlecht waren die Cells eher bei Desktop-Anwendungen. Und da wären wie dann wieder beim Intel und seinen "Optimierungen". Tja, und allzuweit weg vom Thema Spielen sind wir auch nicht bzw. hatte ja auch Joel Spolsky darauf hingewiesen, dass es gewisse Optimier-Kräfte in diesem Zusammenhang bei MS gegeben hatte - und möglicherweise noch gibt.
Nano schrieb: > Hast du aber nicht gesagt, dass es später eine Windowsversion gab? > Wenn er die verkaufen wollte, hätte er von der vielleicht mehr gehabt, > als für die alte Software weiter Support zu leisten. Die Windowsversion ist trotzdem gut gelaufen bzw. läuft auch noch gut, ob wohl der Fokus mittlerweile mehr auf der 2D-Variante liegt - die Firma wurde an einen Hersteller von Optischen Messgeräten verkauft und für den ist 2D natürlich interessanter. Liegt aber nicht an dem SW-Entwickler oder schlechter SW, vielmehr hat der Gerätehersteller der diese SW mit seinen Geräten verkauft hat kein Interesse SW weiter anzubieten. Da kann ich hier aber nicht ins Detail gehen. Nano schrieb: > Dann hat er ja zumindest schon einmal überprüft ob sie "Genuine Intel" > war. Dazu brauchte es ganz sicher nicht viel, es war ja bekannt das die Prozessoren von AMD und Cyrix eben nicht 100% kompatibel zu Intel waren. Aber noch einmal der hatte definitiv kein Interesse da ne geplante Obszolenz einzubauen, im Gegenteil. Wenn die Herstellung der Kompatibilität zu >=P4 einfach gewesen wäre hätte er dies definitiv getan. Die SW wurde noch bis ca. 2003/2004 verkauft was nicht ganz unproblematisch war da Rechner mit max. P3 zu diesem Zeitpunkt schon schwer beschaffbar waren. Nein er hat einfach nur spezielle Instruktionen abgefragt und geprüft ob die das gewünschte Resultat liefern. Selbst wenn es die Instruktionen noch gab, aber wenn die halt ein anderes Ergebnis zurückliefern als erwartet, dann war das bereits ein Ausschlußkriterium. Allein schon die Breite eines Integers kann da das Aus sein. Und natürlich hat sich der Befehlssatz von P3 zu P4 geändert. P3 hatte noch den x86 (16 bit)/x86-32 Befehlssatz, während es beim P4 der IA-32/Intel 64 Befehlssatz war. 16Bit wurde vom Petium 4 also nicht mehr unterstützt. Ich meine es geschrieben zu haben, das war ein reines DOS-Programm. Wenn ich mich recht entsinne konnte DOS nur 16Bit und da ist es natürlich schon blöd wenn der 16Bit Befehlssatz plötzlich nicht mehr unterstützt wird bzw. nicht mehr so wie man das erwartet. Da eine weitere Diskussion zu diesem Thema zu nichts führt und Du offensichtlich aller besser zu wissen scheinst, ist für mich die Diskussion an dieser Stelle beendet. Das Thema wurde nun auch mehr als ausreichend diskutiert. Nur noch soviel, ich habe mal zu der Zeit als absehbar das die diese SW eingestellt wird, ein kleines Tool zur Migration einiger spezieller Maschinendaten in die neue SW geschrieben. Damit das möglich war brauchte es die Kenntnis einiger Datenstrukturen und da ich den Entwickler persönlich kannte war das auch kein Problem. Er hat mir da auch weiter geholfen und da haben wir auch über einige Internas gesprochen, ohne das er mir natürlich Details offenbahrt hat - war ja auch nicht erforderlich. Also Du darfst mir durchaus glauben, oder auch nicht, was was ich da geschrieben habe.
rbx schrieb: > Es ist aber schon noch ein Unterschied, ob man über das Bios bzw. mit > "Bios-Interrupts" die Grafikkarte anspricht, oder indirekt über > Speicherübergaben die FPU bzw. genauso blöd MMX. Nur noch soviel er hat direkt in den Speicher der Graka geschrieben. Genauso direkt hat er die FPU angesprochen. Das war ne Software die hat eine Maschine angesteuert, nebenher die zurückglieferten Daten in Geometrieelemente (3d) umgerechnet und das Ergebnis zu auf dem BS auch grafisch zur Anzeige gebracht. Damit das möglichst schnell und reibungslos ablief, war das nur mit direkten HW-Zugriffen realisierbar. Mal nicht vergessen das war ein reines DOS-Programm und lief auch schon auf einem 286'er. Da hat man noch alles schön zu Fuß gemacht und zwar nacheinander. Mehrere parallele Threads gab's da auch nicht und Speicher war eher rar - ne Kiste mit 1MB war da schon toll. Wenn man da was wuppen wollte dann ging das eben nur mit ausgefeilten und durchdachten Programmen. Ohne hardwarenahe Programmierung war da meist nichts zu machen, bei allen Nachteilen die dies hatte - z.B. schlecht portierbar.
Nano schrieb: > Wenn es ein Timingproblem war, hätte man vielleicht ein bisschen mehr > machen müssen. Vielleicht hätte aber auch einfach eine Softwarebremse > genügt. > Beim obigen Turbo Pascal Runtime Error 200 Problem hat die bspw, auch > funktioniert. Ach Nano Du bist schon ein echter Schlauberger. Es war kein Timingproblem. Softwarebremse wäre in diesem Falle eine ganz schlechte Idee gewesen - warum, weshalb, wieso habe ich im Post geschrieben wo ich rbx geantwortet habe. Wo habe ich geschrieben das die SW in Turbopascal geschrieben wurde?? Ich schrieb: Zeno schrieb: > Die Software wurde Anfang der 90'ziger mit Pascal von MS geschrieben. In MS Pascal gab es meines Wissens diesen Runtimeerror nicht. Im übrigen gab es zwischen MS Pascal und Turbo Pascal erhebliche Unterschiede. Mit Turbo Pascal bzw. Borland Pascal konnte man deutlich mehr machen, warum die Entscheidung seinerzeit auf MS gefallen ist - keine Ahnung.
Zeno schrieb: > Genauso direkt hat er die FPU angesprochen. Da kommen aber normalerweise nur (mathematische) Rechenwerte rein (oder raus), und die werden halt beim Intel über den Speicher abgerufen/übergeben bzw. natürlich auch gleich praktischerweise ins passende Format hin- und zurück - übersetzt. Was sich tatsächlich gut einstellen lässt, das ist die Rundungsgenauigkeit bzw. das Rundungsverhalten an sich.
Zeno schrieb: > Nano schrieb: >> Dann hat er ja zumindest schon einmal überprüft ob sie "Genuine Intel" >> war. > Dazu brauchte es ganz sicher nicht viel, es war ja bekannt das die > Prozessoren von AMD und Cyrix eben nicht 100% kompatibel zu Intel waren. Ähm, die AMD Prozessoren waren 100 % kompatibel zu Intel, es gab zwischen Intel und AMD dazu auch ein Abkommen. Die Cyris CPUs waren AFAIK auch 100 % kompatibel, obwohl es kein Abkommen zwischen Intel gab. Es war nur so, dass es eben diese Abfragemöglichkeit auf Genuine Intel gab, die war aber kein Teil des Befehlssatzes, sondern das, was ein Befehl zurückmeldete und manche Software diese verwendet hat, so dass die Software auf AMD und Cyrix Prozessoren nicht lief. Das Genuine Intel konnten bzw. durften die nämlich nicht nachmachen, weil sich sonst die CPU als Genuine Intel ausgeben hätte müssen und das war rechtlich irgendwie geschützt. Unterschiede gab es beim V20 und V30 von NEC, das war aber 1 Jahrzehnt vorher und nicht als 386er und 486er für jedermann bezahlbar waren. > Und natürlich hat sich der Befehlssatz von P3 zu P4 geändert. P3 hatte > noch den x86 (16 bit)/x86-32 Befehlssatz, während es beim P4 der > IA-32/Intel 64 Befehlssatz war. 16Bit wurde vom Petium 4 also nicht mehr > unterstützt. Das ist Unsinn. Die 64 Bit Erweiterung beim P4 kam erstens sehr spät, die ersten P4 waren noch 32 Bit CPUS. Und 16 Bit läuft auf so einem Prozessor weiterhin, nur eben nicht im 64 Bit Modus. Trotzdem kann man so einen P4 natürlich in einen 16 Bit Real Mode versetzen und dann 16 Bit Programme ausführen. > Ich meine es geschrieben zu haben, das war ein reines > DOS-Programm. Wenn ich mich recht entsinne konnte DOS nur 16Bit und da > ist es natürlich schon blöd wenn der 16Bit Befehlssatz plötzlich nicht > mehr unterstützt wird bzw. nicht mehr so wie man das erwartet. Du kannst auf einem 64 Bit Rechner weiterhin DOS booten, solange er ein BIOS oder Legacy BIOS Mode hat. > Da eine weitere Diskussion zu diesem Thema zu nichts führt und Du > offensichtlich aller besser zu wissen scheinst, Tue ich halt. > ist für mich die > Diskussion an dieser Stelle beendet. Schade. > Das Thema wurde nun auch mehr als > ausreichend diskutiert. Nur noch soviel, ich habe mal zu der Zeit als > absehbar das die diese SW eingestellt wird, ein kleines Tool zur > Migration einiger spezieller Maschinendaten in die neue SW geschrieben. > Damit das möglich war brauchte es die Kenntnis einiger Datenstrukturen > und da ich den Entwickler persönlich kannte war das auch kein Problem. > Er hat mir da auch weiter geholfen und da haben wir auch über einige > Internas gesprochen, ohne das er mir natürlich Details offenbahrt hat - > war ja auch nicht erforderlich. Also Du darfst mir durchaus glauben, > oder auch nicht, was was ich da geschrieben habe. Kein Problem, ich versuche es halt nur nachzuvollziehen, denn die x86 CPUs sind eigentlich abwärtskompatibel, also muss das andere Gründe haben, wenn mal etwas nicht mehr funktioniert. Timinggründe als Möglichkeit habe ich ja schon genannt.
Zeno schrieb: > Nano schrieb: >> Wenn es ein Timingproblem war, hätte man vielleicht ein bisschen mehr >> machen müssen. Vielleicht hätte aber auch einfach eine Softwarebremse >> genügt. >> Beim obigen Turbo Pascal Runtime Error 200 Problem hat die bspw, auch >> funktioniert. > Ach Nano Du bist schon ein echter Schlauberger. Es war kein > Timingproblem. Softwarebremse wäre in diesem Falle eine ganz schlechte > Idee gewesen - warum, weshalb, wieso habe ich im Post geschrieben wo ich > rbx geantwortet habe. Auf einem P4 mit über 3 GHz Taktfrequenz hätte das Programm selbst mit aktiver Softwarebremse immer noch schneller ausgeführt werden können, als auf einem 286er damals ohne Softwarebremse, für den das Programm geschrieben wurde und darum geht es ja. Alte Software auf neuen Maschinen lauffähig machen. > Wo habe ich geschrieben das die SW in Turbopascal geschrieben wurde?? TP ist ein Beispiel. Da gab es nämlich diesen Runtime Error 200 Bug, eben weil die Pentium CPUs ab 200 MHz Taktfrequenz für die alten Softwareroutinen, die in eine TP Lib verwendet wurde, zu schnell lief. Genau so etwas wäre auch bei diesem Programm möglich und nein, dazu muss es nicht in TP geschrieben sein, es hätte genügt, wenn die Softwareroutinen genauso schlecht programmiert gewesen wären und davon gehe ich momentan auch aus, denn an die Story mit nicht kompatiblen Befehlssätzen glaube ich nämlich nicht. Lies hier weiter: https://en.wikipedia.org/wiki/Turbo_Pascal#Issue_with_CRT_unit_on_fast_processors > Mit > Turbo Pascal bzw. Borland Pascal konnte man deutlich mehr machen, warum > die Entscheidung seinerzeit auf MS gefallen ist - keine Ahnung. Vermutlich war es günstiger.
Thomas L. schrieb: > Schon beim Drucken der Testseite sagt mir das System nach einer Weile > dass irgendeine Berechtigung fehlt und ich weiss nicht wo ich sowas > einzustellen habe. Ich habe mir mal 1000 mostly useless gespart und frage mal zum Thema (sry forum): Hast Du mal probiert als Superuser zu drucken? Wenn das geht, dann hat Dein "normaler" Benutzer vermutlich ein Problem mit der Firewall. Dann könnte man sich mal die Logs vornehmen. Da wird sowas normalerweise protokolliert. Und dann weisst Du auch schnell WAS Dir als Berechtigung fehlt. /regards
Nano schrieb: > Schade. So ist das halt, eine weitere Diskussion bringt eben nichts, weil Nano schrieb: > alles besser zu wissen scheint, oder zumindest glaubt es besser zu wissen. Ich kenne das Programm, habe Geräte mit diesem Programm gut 20 Jahre betreut und u.a. alle Prüfprogramme (CNC-Programme) für die Maschinen geschrieben die mit diesem Programm ausgestattet waren und die komplette SW zum Auswerten der Daten, ich kenne den Entwickler des Programmes und den der die SW in unserer Firma betreut hat und z.B . die ganzen Anpassungen an unsere Maschinen im Programm gemacht hat persönlich. Ich habe auch ein Zusatztool zum Programm geschrieben mit dem die Kunden mehr CNC-Programme verwalten konnten als es mit dem Programm allein möglich war - ich sage nur 64kB Grenze. Und jetzt kommst Du, der nur durch diesen Thread vom diesem Programm gehört hat, daher und meint alles besser zu wissen. OK ich akzeptiere das, aber dann ist jede weitere Diskussion zwecklos und dreht sich nur im Kreise. Ich habe weitergeben was mir der Programmentwickler, der ja sein Programm am besten kennt, erläutert hat.
Jetzt muß ich doch noch was anmerken. Nano schrieb: > Da gab es nämlich diesen Runtime Error 200 Bug, > eben weil die Pentium CPUs ab 200 MHz Taktfrequenz für die alten > Softwareroutinen, die in eine TP Lib verwendet wurde Das war ja nun mehr als simpel. Der Fehler war in der CRT-Unit. In dieser Unit gibt es eine Funktion Delay und damit die ein hablwegs genaues Delay erzeugt wurde die bei der Initialisierung kalibriert, unabhängig davon ob die Funktion im Programm benutzt wurde oder nicht. Für diese Kalibrierung wurde ein Zähler benutzt der ab etwa 200MHz schlichtweg übergelaufen ist. Das hat auch nichts mit schlampiger Programmierung zu tun, ok nano hätte es vermutlich besser gemacht, sondern das lag einfach daran, das man zu dem Zeitpunkt als man diese Unit implementiert hat, die Taktfrequenzen der Prozessoren noch im einstelligen MHz Bereich lagen und dafür war der Zähler mehr als großzügig bemessen. Das die Entwicklung so schnell voranschreitet konnte man zu diesem Zeitpunkt noch nicht vorhersehen. Es gab dann sehr schnell einen Patch mit dem man die Unitpatchen konnte, sofern man über deren Quelltext verfügt hat. Den hatte aber jeder der Turbo/Borland Pascal offiziell erworben hatte. Es gab wohl auch eine Möglichkeit die Exe zu patchen, allerdings haben sich dann die Delayzeiten halbiert, was dann u.U. zu anderen Problemen geführt hat.
Zeno schrieb: > Ich kenne das Programm, habe Geräte mit diesem Programm gut 20 Jahre > betreut und u.a. alle Prüfprogramme (CNC-Programme) für die Maschinen > geschrieben die mit diesem Programm ausgestattet waren Du hast das Programm als Anwender benutzt, du hast es aber nie in den 20 Jahren durch einen Debugger oder gar Disassembler geschoben. > Und jetzt kommst Du, der nur durch diesen Thread vom diesem Programm > gehört hat, daher und meint alles besser zu wissen. Weil deine Behauptung, dass der P4 inkompatibel zu alter Software sei und sogar andere Befehlssätze hätte, aus berechtigten Gründen mehr als fragwürdig und sehr wahrscheinlich auch falsch ist. Da brauch ich die Software gar nicht angucken, um diese Behauptung anzuzweifeln. Ebenso habe ich dir wahrscheinlichere Gründe genannt, warum diese alte Software auf dem P4 Probleme machen könnte, was ich ja nicht abstreite. Ich gehe mal davon aus, dass du die Software auf einem P4 mal versucht hast zu starten. > OK ich akzeptiere > das, aber dann ist jede weitere Diskussion zwecklos und dreht sich nur > im Kreise. Der Schritt den du jetzt tun müsstest, wäre deine Behauptung konkret zu belegen.
Nano schrieb: > Du hast das Programm als Anwender benutzt, Ja vorzugsweise. Nano schrieb: > du hast es aber nie in den 20 > Jahren durch einen Debugger oder gar Disassembler geschoben. Warum hätte ich das tun sollen? Wenn's ein Problem gab habe ich einfach den Entwickler des Programmes angerufen und dann war Fehler oder der Wunsch meist in weniger als 1 Woche erledigt. Zweitens hatte ich in irgend einem Post geschrieben das ich ein Programm geschrieben habe mit dem man spezielle Maschinendaten in ein anders Datenformat konvertieren konnte (brauchte man wenn man von alter SW auf SW umgerüstet hat und der Kunde die Orginaldisketten nicht mehr hatte). Für diesen Zweck hatte ich die Orginalquellen vorliegen, ich mußte also keinen Disassembler bemühen. Du kennst das Programm nicht, Du kenns noch nicht einmal dessen Namen, aber Du weist offensichtlich ganz genau wie es funktioniert. Aber so ganz sicher bist Du Dir offensichtlich auch nicht, denn sonst würdest Du nich schreiben: Nano schrieb: > aus berechtigten Gründen mehr als > fragwürdig und sehr wahrscheinlich auch falsch ist. Du meinst zu wissen wie das Ding funktioniert, aber Du weist es nicht, da bin ich mir jetzt zu 100% sicher. Nano schrieb: > Ich gehe mal davon aus, dass du die Software auf einem P4 mal versucht > hast zu starten. Ich brauchte das nicht zu versuchen, weil es bekannt war das es nicht funktionieren wird. Da der Aufwand für zu hoch (vom Entwickler) eingeschätzt wurde das Programm anzupassen, hat man lieber in der Folgezeit (ca. 2 Jahre) die Maschinen für die diese Software geordert wurde mit P3 PC ausgeliefert. Jetz wirst Du gleich wieder um die Ecke kommen und rufen "aber ...", aber jetzt ist von meiner Seite endgültig Schluß zu diesem Thema. Du bist wie der Typ mit dem ich zusammen eine SW entwickeln sollte, der hat sich von niemanden was sagen lassen wußte auch alles und hat dann nach 6 Jahren das SW-Projekt komplett in den Sand gesetzt. Jetzt wurde eine neues Projekt angefangen, er ist natürlich wieder dabei, und es sieht jetz nach 1 1/2 Jahren auch schon wieder nicht so gut aus. Ich habe mich Gott sei Dank bei Zeiten aus dem Ganzen ausgeklinkt. Und jetzt klinke ich mich hier aus.
Kleine Korrektur: Zeno schrieb: > brauchte man wenn man von alter SW auf > SW umgerüstet hat brauchte man wenn man von alter SW auf neue SW umgerüstet hat
Zeno schrieb: > Du kennst das Programm nicht, Du kenns noch nicht einmal dessen Namen, > aber Du weist offensichtlich ganz genau wie es funktioniert. Das habe ich nicht behauptet. Ich habe aber eine plausible Erklärung abgegeben warum es das auf dem P4 nicht tut, während deine Erklärung unplausibel ist, eben weil ein P4 abwärtskompatibel ist, ja sogar sein muss, denn sonst würde noch viel mehr Software nicht mehr funktionieren. > Aber so ganz sicher bist Du Dir offensichtlich auch nicht, denn sonst > würdest Du nich schreiben: > Nano schrieb: >> aus berechtigten Gründen mehr als >> fragwürdig und sehr wahrscheinlich auch falsch ist. > Du meinst zu wissen wie das Ding funktioniert, aber Du weist es nicht, > da bin ich mir jetzt zu 100% sicher. Wie schon gesagt, deine behauptet bezüglich dem P4 ist nun einmal mehr als fragwürdig, es sei denn du kannst einen Beweis liefern von dem ich noch nichts weiß und solange du das noch nicht kannst, ist deine Behauptung sehr wahrscheinlich falsch. Das ist meine Aussage und das hat mit deinem Programm überhaupt gar nichts zu tun. > Ich brauchte das nicht zu versuchen, weil es bekannt war das es nicht > funktionieren wird. Da der Aufwand für zu hoch (vom Entwickler) > eingeschätzt wurde das Programm anzupassen, hat man lieber in der > Folgezeit (ca. 2 Jahre) die Maschinen für die diese Software geordert > wurde mit P3 PC ausgeliefert. Er hätte wahrscheinlich die ganzen Timingroutinen, bei dem es auf dem P4 Zählerüberläufe gibt, weil er zu schnell ist, anpassen müssen. > Jetz wirst Du gleich wieder um die Ecke kommen und rufen "aber ...", > aber jetzt ist von meiner Seite endgültig Schluß zu diesem Thema. > Du bist wie der Typ mit dem ich zusammen eine SW entwickeln sollte, der > hat sich von niemanden was sagen lassen wußte auch alles und hat dann > nach 6 Jahren das SW-Projekt komplett in den Sand gesetzt. Es ist unsinnig vergleiche mit anderen Personen zu ziehen, Ich habe dir eine konkrete Frage gestellt, nämlich deine Behauptungen bezüglich dem P4 zu belegen. Nicht mehr und nicht weniger. Und wenn du den Entwickler der Software kennst, dann kannst du ihn ja mal fragen.
Ich habe diese Diskussion am 14.Mai gestartet.Jetzt haben wir den 8.Juni.Ich denke es ist mehr als fair hier ein Feedback zu geben und ein Fazit zu ziehen. Mittlerweile kann meine Mint Maschine alles was ich zuvor mit der Windows-Kiste gemacht habe.Einschränkungen? Keine.Nochmal zur Sache:Ich will nicht mehr von Redmond abhängig sein und ich denke,dass meine Maschine(n) mir gehören und ich über mein Eigentum frei bestimmen sollte... Ich bin weit davon entfernt zu sagen,dass MINT oder Windows "BESSER" ist-das ist ungefähr so als wenn ein Fordfahrer & ein Opelfahrer über das "bessere" Auto "diskutieren".Punkt.Email,Bürozeug und Browser funktionieren unter MINT wie unter Windows.OHNE Einschränkungen.Die Community hier ist hilfreich und von einigen Trollen abgesehen durchaus professionell.Das ist bei den Windows Foren nicht immer der Fall.. Für meine Hauptanforderungen an einen Computer ist MINT für mich jetzt "State of the art".Also ist für mich der "Umstieg" auf Linux erfolgreich geglückt.Schon der globale Werbeblocker in meinem HomeNet ist ein Pi-Hole (der verrichtet schon seit gefühlten Ewigkeiten ohne Probleme seinen Job). Werde ich Windows weiter benutzen? Ja! Allerdings nur um mit meinen Enkeln und Söhnen zu "Daddeln" (Diablo Immortal,Diablo3,C&C,etc).Und das solange,wie es geht.Ich werde ganz gewiss kein win10 oder höher auf meinen Kisten installieren. Mein allgemeines Fazit: Wer für 'normale' PC-Anwendungen ein gutes & stabiles OS sucht,ist mit MINT 100% gut bedient.Verfügt ein Gewerbebetrieb über einen halbwegs gescheiten ITler ist MINT sicher auch die erste Wahl. Ich komme von DOS3.1 bis hin zu win8.1. Ich habe programmiert und habe noch immer viele Anwendungen (Harbor/C++) im Feld.Auch diese Anwendungen sind unter MINT "gefühlt" besser zu warten ;) Abschließend meinen Dank an die vielen professionals hier - ich fühle mich schon ganz zu Hause hier.So wie ich meine Kenntnisse in MINT vertieft habe,werde ich mein Wissen auch teilen und weitergeben (das ist -denke ich- der Spirit der Community). Thomas
Thomas Leu schrieb: > Werde ich Windows weiter benutzen? Ja! Allerdings nur um mit meinen > Enkeln und Söhnen zu "Daddeln" Naja, es gibt eine ganze Reihe von Programmen, da kommst du um Windows nicht herum. Bei mir gibt es auch Hardware, die tut unter Mint viel aber nicht das was sie sollen. Zb. Drucker und Scanner. Ich hatte keine lust die auf den Müll zu werfen um dann teure Drucker zu kaufen die mit Linux Treibern geliefert werden. Oft ist es auch die Graka die nicht will aber unter Windows geht. Deine "Ehe " mit Linux ist noch in den Flitterwochen...warte mal ab mit dem absingen von Lobliedern... ;-) Mit den Ansprüchen wachsen auch die Probleme... Naja, Du schaffst das schon...
Link zu Kinux bitte. Scheint eine sehr unbekannte Distribution zu sein. Ich habe keine Infos dazu gefunden.
Beitrag #7091376 wurde von einem Moderator gelöscht.
...sorry die Verwirrung : Ich habe absichtlich den Post unter "Kinux" gestartet - als "Eyecatcher" . Also der vermeintliche Schreibfehler war gewollt ;). LINUX ... mit L ist gemeint - in dem Falle 'MINT'
Die Druckerinstallation unter Mint ist nach meinen Erfahrungen absolut schmerzfrei. Funktioniert einfach. Egal ob über USB oder über LAN. Man braucht auch keine Treiber in den Weiten des Internets zu suchen. Auch alte Drucker funktionieren für die es keine Windowstreiber mehr gibt.
Wobei das XFCE-Druckertool bei Mint wirklich armselig ist. Aber die Weboberfläche von CUPS unter localhost:631 funktioniert prächtig. Und vor allem auch problemlos für Geräte, für die es seit Ewigkeiten keine Windowstreiber mehr gibt. Das nenne ich Nachhaltigkeit.
Thomas L. schrieb: > ...sorry die Verwirrung : Ich habe absichtlich den Post unter "Kinux" > gestartet - als "Eyecatcher" . Also der vermeintliche Schreibfehler war > gewollt ;). LINUX ... mit L ist gemeint - in dem Falle 'MINT' Ach, ich glaube, da wäre ein Eyecatcher gar nicht nötig gewesen -- und wenn, hätte es jedes der Worte "Linux", "Win" oder "Umstieg" genau so gut getan. Wie Du ja auch an einigen der... sagen wir mal: scherzhaft gemeinten Kommentaren erkennen kannst, triggern solche Threads häufig ein... sagen wir mal: besonderes Publikum. ;-)
mint schrieb: > Die Druckerinstallation unter Mint ist nach meinen Erfahrungen absolut > schmerzfrei. Funktioniert einfach. Egal ob über USB oder über LAN. Man > braucht auch keine Treiber in den Weiten des Internets zu suchen. > Auch alte Drucker funktionieren für die es keine Windowstreiber mehr > gibt. Dann versuche dich mal am HP Laserjet 1005... Was der unter Mint noch kann im Vergleich zu Windows spottet jeder Beschreibung... Die Probleme welche diese günstigen Drucker mitbringen sind bei Linuxjüngern durchaus bekannt. Ich habe heute einige Belichtungsvorlagen von Elektronikprojekten auf Folie gedruckt. Das wäre unter Linux nicht gegangen denn dort könnte ich weder das Druckmedium (Folie)noch die Auflösung einstellen.Sprint Layout geht ja auch nicht gescheit mit Mint. Auf den ersten Blick meint man das geht ,aber dann kommen die Fehler so kleinweise zu Vorschein. Wine ist halt nicht immer die Lösung. Kleine Anekdote: Heute hat mich zum fünften male in den letzten Tagen "Mikrosoft" angerufen. Ich legte dann immer sofort auf.Nur heute habe ich den Typen (gestern war das eine Lady)ordentlich geschockt indem ich ihm verklickert habe ,dass es bei mir kein Windows gibt sondern Linux. Dann hat er nach 3 Sekunden nachdenken aufgelegt...Endlich hat mir Linux was gutes gebracht und sofort funktioniert ohne "basteln".
Ohne jetzt alle Beiträge gelesen zu haben, das hole ich mal nach wenn ich Zeit habe. Mit dem Ende von Windows 7 habe ich nach Linux MINT gewechselt. In der ersten Zeit habe ich auch geflucht und gesucht, bis nach einem guten halben Jahr das Linux gar nicht mehr lief. OK, neu installiert jetzt läuft es. Ja, der Umstieg kann steinig sein. Aber er lohnt sich. Windows 10 habe ich auf der Arbeit, nee das will ich auf keinen Fall! Nur weil man es gewohnt ist und es "kennt"?
herbert schrieb: > Das wäre unter Linux nicht gegangen denn dort könnte ich weder das > Druckmedium (Folie)noch die Auflösung einstellen. Nur so: HPLIP hattest du aber auch installiert, oder? HP ist eigentlich so fast der einzige (großer) Druckerladen, der Linux unterstützt, früher nur indirekt (HPLIP gibt's schon lange), inzwischen haben sie das aber ganz offiziell verlinkt. Aber auch ohne HPLIP hatte ich auf meinem FreeBSD nie Probleme, bei HP-Druckern sowas wie Tonerdichte und Ausgabeschacht auszuwählen, CUPS (kommt übrigens von Apple) und .ppd-Files sei dank.
Jörg W. schrieb: > herbert schrieb: >> Das wäre unter Linux nicht gegangen denn dort könnte ich weder das >> Druckmedium (Folie)noch die Auflösung einstellen. > > Nur so: HPLIP hattest du aber auch installiert, oder? Natürlich nicht, denn dann würde der Drucker ja vollständig funktionieren. Der Hersteller des Druckers sagt jedenfalls, der Drucker sei unter Linux vollständig unterstützt ("Support Level: Full").
Jörg W. schrieb: > Nur so: HPLIP hattest du aber auch installiert, oder? Alles da auch Cups...kann zwar was drucken , aber null,null was einstellen. Ich habe das nicht mehr weiterverfolgt,das hat Gründe aber für menschliche Dinge ist hier der falsche Platz. Da Sprint mit Wine auch nicht ohne Fehler läuft liegt es nahe, das erstellen von Layouts und drucken unter Windows zu machen. Toner ist teuer. Ein T. schrieb: > Natürlich nicht, denn dann würde der Drucker ja vollständig > funktionieren. Der Hersteller des Druckers sagt jedenfalls, der Drucker > sei unter Linux vollständig unterstützt ("Support Level: Full"). Träume weiter...
herbert schrieb: > kann zwar was drucken , aber null,null was einstellen Wie gesagt, entspricht überhaupt nicht meinen Erfahrungen mit HP-Druckern, und ich benutze solche seit Jahren. Der alte 2605 wurde ausgemustert, weil er irgendwann extrem streifig druckte, aber seine Tonerdichte ist (passendes Druckprofile ausgwählt natürlich) viel besser als die des neueren Druckers. Deshalb steht er in der Abstellkammer und wird vom Linux-Laptop angesteuert, wenn ich doch nochmal ein Layout selbst auf Folie drucken möchte.
herbert schrieb: > Alles da auch Cups Klar, CUPS ist ja ohnehin dabei. Aber wenn du kein PPD-File für den Drucker einrichtest, arbeitet er als Standard-Postscript-Drucker (Fallback-Variante), bei dem man natürlich keine Druckerspezifika auswählen kann.
Thomas Leu schrieb: > Ich habe diese Diskussion am 14.Mai gestartet.Jetzt haben wir den > 8.Juni.Ich denke es ist mehr als fair hier ein Feedback zu geben und ein > Fazit zu ziehen. Erstmal vielen Dank für die Rückmeldung. Die ist meistens recht interessant und einer der Vorteile u.a. dass man sich (als Leser) selbst ein wenig "rekalibrieren" kann. "Kinux" fand ich insofern auch bemerkenswert, weil es ja ein wenig den Vorurteil-Schnappmechanismus unterwandert a la "das hatten wir doch alles längst". Tatsächlich sind am laufenden Band Probleme zu klären, und da hilft es schon enorm, wenn man in einem großen Pool Erfahrungen zusammentragen kann wie auch (pragmatische) Kompromisse erkennen/abgucken kann.
herbert schrieb: > Jörg W. schrieb: >> Nur so: HPLIP hattest du aber auch installiert, oder? > > Alles da auch Cups...kann zwar was drucken , aber null,null was > einstellen. > Ich habe das nicht mehr weiterverfolgt,das hat Gründe aber für > menschliche Dinge ist hier der falsche Platz. Aha. Du hast die Installation also auf halber Strecke abgebrochen und beschwerst Dich jetzt darüber, daß Deine Installation nicht vollständig ist. Und natürlich, Überraschung, ist Linux daran schuld -- was sonst? Nun würde ich aber trotzdem nichts sagen, wenn ich dieses Verhalten bei Dir nicht schon in früheren Linux-Threads beobachtet hätte. Im ersten Deiner Linux-Threads hier hast Du auf die Frage, was denn die Logdateien zu Deinem Problem sagen, damit begonnen, die Hilfswilligen zu beschimpfen. Auch im weiteren Verlauf des damaligen Threads hast Du nicht etwa das getan, was Dir die unverständlicherweise immer noch Hilfswilligen empfohlen haben, sondern Dich stattdessen -- ebenso wie in etlichen weiteren Linux-Threads in diesem Forum -- in endlose, repetitive und langweilige Meckereien ergangen, wie doof und unzumutbar das alles sei und wie hochnäsig und böse die Linux-Community sei. Komischerweise klappen bei Dir häufig Sachen nicht, die bei anderen Linux-Benutzern reibungslos funktionieren. Sei mir bitte nicht böse, aber auf die Gefahr hin, mich zu wiederholen: ich habe das ganz starke Gefühl, daß zwischen Dir und Linux ein Kompatibilitätsproblem besteht. Linus Torvalds wurde vor Jahrzehnten gerne mit dem Sprüchlein zitiert "we are back at the times when men were men and wrote their own device drivers". Ganz so extrem ist es schon lange nicht mehr, aber eines hat sich nichts geändert: Linux ist ein System für Menschen, die Probleme selbst anpacken und lösen. Daß das geht, zeigen die positiven Erfahrungen des TO. > Da Sprint mit Wine auch nicht ohne Fehler läuft liegt es nahe, das > erstellen von Layouts und drucken unter Windows zu machen. Toner ist > teuer. Ja, das ist auch wieder so eine Sache mit der Kompatibilität... Wine ist eigentlich nie eine sinnvolle dauerhafte Lösung. Eine sinnvolle Lösung wäre, sich eine andere, Linux-kompatible Software zu suchen und sie zu erlernen, anstatt auf Biegen und Brechen an einer Software festzuhalten, die für dieses Betriebssystem grundsätzlich ungeeignet ist und auch mit Wine immer noch ein Fremdkörper bleibt. Es ist ja nicht so, als ob es für Linux keine Alternativen zu dieser Software gäbe. Aber Du willst wieder einmal unbedingt mit dem Kopf durch die Wand und beschwerst Dich dann, daß Wände hart und nicht gut für Deinem Kopf sind. Ohnehin scheinst Du mehr Energie zu investieren, Dich zu beklagen, als Du zur Lösung Deiner Probleme aufwendest. > Ein T. schrieb: >> Natürlich nicht, denn dann würde der Drucker ja vollständig >> funktionieren. Der Hersteller des Druckers sagt jedenfalls, der Drucker >> sei unter Linux vollständig unterstützt ("Support Level: Full"). > > Träume weiter... Tatsächlich habe ich bereits einen Laserjet 1005b (oder -w?) bei einer Freundin unter Ubuntu eingerichtet. Der funktioniert prima und mit allen Funktionen, die er beim Sohnemann der betreffenden Dame auch hat.
Ein T. schrieb: > Aha. Du hast die Installation also auf halber Strecke abgebrochen und > beschwerst Dich jetzt darüber, daß Deine Installation nicht vollständig > ist. Und natürlich, Überraschung, ist Linux daran schuld -- was sonst? Das was du hier als "wahre Begebenheit" zum besten gibst ist wieder mal typisch für die Kategorie "Linuxer", die man nur als schlechtes Beispiel benutzen kann und für sonst nichts. Ein T. schrieb: > Linux ist ein > System für Menschen, die Probleme selbst anpacken und lösen. Daß das > geht, zeigen die positiven Erfahrungen des TO. Das ging alles so "glatt" das ich diese Erzählung erstmal als "Fake" für mich markiert habe. Die Verbreitung von Linux auf Desktop-Rechnern ist eher ein Spiegel der praktischen Realität. Dinge die Gut sind und nichts kosten müssten doch massenhaft auf Rechnern laufen und Mikrosoft pleite sein. Ist es so? Nein ganz im Gegenteil.Linux ist was für Bastler von Bastlern. Ein halbes Jahr hinwerkeln bis es geht ist jetzt nicht der Traum eines Computernutzers der schlicht und einfach nur einen problemlosen Untergrund für seine gewohnte Anwendersoftware und Hardware benötigt. Ein T. schrieb: > Tatsächlich habe ich bereits einen Laserjet 1005b (oder -w?) bei einer > Freundin unter Ubuntu eingerichtet. Der funktioniert prima und mit allen > Funktionen, die er beim Sohnemann der betreffenden Dame auch hat. Kommt mir irgendwie sehr bekannt vor...naja, dann glaube ich das auch noch... Jetzt habe ich aber wichtigeres zu tun!
herbert schrieb: > Das was du hier als "wahre Begebenheit" zum besten gibst ist [...] Er hat zusammengefasst, was Du zuvor geschrieben hattest. > Die Verbreitung von Linux auf Desktop-Rechnern ist > eher ein Spiegel der praktischen Realität. Das stimmt. Die praktische Realität ist: 90% der Menschen haben das Wort "Linux" noch nie gehört, und von den übrigen haben 90% keine Ahnung, dass es auch auf dem Desktop ein sehr angenehmes System ist. > Dinge die Gut sind und nichts > kosten müssten doch massenhaft auf Rechnern laufen und Mikrosoft pleite > sein. Ach, der Mensch ist bekanntlich ein Gewohnheitstier. Das ist ja nicht neu. > Ist es so? Nein ganz im Gegenteil.Linux ist was für Bastler von > Bastlern. Das stimmt, und gleichzeitig ist es ein System von Profis für Profis. > Ein halbes Jahr hinwerkeln bis es geht ist jetzt nicht der Traum eines > Computernutzers der schlicht und einfach nur einen problemlosen > Untergrund für seine gewohnte Anwendersoftware und Hardware benötigt. Wenn man es richtig macht, geht das offenbar auch schneller. Das zeigen die Erfahrungen des TE, die er oben berichtet hat. > Das ging alles so "glatt" das ich diese Erzählung erstmal als "Fake" für > mich markiert habe. > [...] > Kommt mir irgendwie sehr bekannt vor...naja, dann glaube ich das auch > noch... Na klar, Herbert, die lügen alle. Nur Du nicht. > Jetzt habe ich aber wichtigeres zu tun! Lass' mich raten: vermutlich nicht, Deinen Drucker fertig zu installieren. Oder?
herbert schrieb: > Ein halbes Jahr hinwerkeln bis es geht Das ist aber kein Alleinstellungsmerkmal irgendeines Systems. ;-) Das kann man mit jedem schaffen …
Karl Käfer schrieb: > Na klar, Herbert, die lügen alle. Nur Du nicht. > >> Jetzt habe ich aber wichtigeres zu tun! > > Lass' mich raten: vermutlich nicht, Deinen Drucker fertig zu > installieren. Oder Dein Stil wie du Vorwürfe beiseite schiebst ähnelt dem von Sekten-Jüngern wenn man sie kritisiert. Jeder Psychologe wird dich sezieren und du wirst dann den Psychologen für unfähig erklären. > Lass' mich raten: vermutlich nicht, Deinen Drucker fertig zu > installieren. Oder? Mein Drucker tut unter Windows exakt das was ich verlange .Die Installation war "pipifax"und ohne zusammensuchen von Spezial-Informationen und Jahrelangen Bastel-Kenntnissen schnell erledigt. Linux ist für mich ein "Bausatz" den man erst zusammen frickeln muss. Wie viele hätte zb. dann einen Fernseher wenn der in Einzelteilen oder in Baugruppen geliefert wird?.Du hättest dann keinen und Millionen andere auch nicht.
herbert schrieb: > Mein Drucker tut unter Windows exakt das was ich verlange .Die > Installation war "pipifax"und ohne zusammensuchen von > Spezial-Informationen und Jahrelangen Bastel-Kenntnissen schnell > erledigt. Der Drucker in der Wohnung des im gleichen Haus lebenden Vermieters tauchte unter Linux überraschend und wie durch Zauberhand fertig nutzbar im recht frischen Linux Mint auf, ohne basteln und ohne irgendeine Aufforderung oder gar Installation meinerseits. Das war mir dann aber auch nicht recht.
:
Bearbeitet durch User
Jörg W. schrieb: > Das ist aber kein Alleinstellungsmerkmal irgendeines Systems. ;-) Das > kann man mit jedem schaffen … Kann man vor allem dann wenn ein OS nicht für den normalen Menschen gemacht ist sonder von Bastlern für Bastler. Die Verbreitung von Windows hätte nicht funktioniert wenn die Hürden ähnlich wären wie bei Linux. Weißt du, ein Freund von mir...Modellbauer fliegt Hubschrauber. Das ist nicht ganz einfach und erfordert viel Wissen und Training. Der zickt aber nicht rum und hält sich auch nicht für elitär.
herbert schrieb: > mint schrieb: >> Die Druckerinstallation unter Mint ist nach meinen Erfahrungen absolut >> schmerzfrei. Funktioniert einfach. Egal ob über USB oder über LAN. Man >> braucht auch keine Treiber in den Weiten des Internets zu suchen. >> Auch alte Drucker funktionieren für die es keine Windowstreiber mehr >> gibt. > > Dann versuche dich mal am HP Laserjet 1005... Was der unter Mint noch > kann im Vergleich zu Windows spottet jeder Beschreibung... Die Probleme > welche diese günstigen Drucker mitbringen sind bei Linuxjüngern durchaus > bekannt. Ich kenne natürlich nicht jeden Drucker. Aber die HP Laserjets sind eigentlich dafür bekannt problemlos unter Linux zu funktionieren. Selbst alte Schwergewichte wie Laserjet 3. Ich selbst habe momentan einen 1200 in Betrieb. Das schließt natürlich nicht aus, dass es irgend ein Modell gibt, wo die Installation nicht trivial ist. Zu 99.9% der Fälle ist das Problem aber wohl der User. Unter Windows gibt es definitiv mehr Drucker, die nicht funktionieren und die Installation ist fast immer aufwändiger.
(prx) A. K. schrieb: > Der Drucker in der Wohnung des im gleichen Haus lebenden Vermieters > tauchte unter Linux überraschend und wie durch Zauberhand fertig nutzbar > im recht frischen Linux Mint auf, ohne basteln und ohne irgendeine > Aufforderung oder gar Installation meinerseits. > > Das war mir dann aber auch nicht recht. Warum hackst Du Dich auch heimlich ins Netzwerk Deines Vermieters. ;-) Edit: bei meinem HP LJ 4000 war es genauso: nach der Installation des Systems war er komplett mit allen Features gebrauchsfertig eingerichtet.
:
Bearbeitet durch User
herbert schrieb: > Weißt du, ein Freund von mir...Modellbauer fliegt Hubschrauber. Das ist > nicht ganz einfach und erfordert viel Wissen und Training. Der zickt > aber nicht rum und hält sich auch nicht für elitär. Weißt du: ich nutze Linux und ich fliege RC-Hubschrauber. In beiden Bereichen gibt es eine Elite, zu der man sich hinarbeiten kann, wenn man das möchte, und das Zeug sowie die Zeit dazu hat. In beiden Bereichen braucht’s das aber nicht, um Spaß damit zu haben. Was also wolltest du ausgedrückt haben?
:
Bearbeitet durch User
Ein T. schrieb: > Warum hackst Du Dich auch heimlich ins Netzwerk Deines Vermieters. ;-) Der Hacker heißt cups-browsed und profitierte davon, dass der Vermieter der Ferienwohnung sein eigenes WLAN zur Verfügung stellte, statt ein separates zu definieren. Wenn man diesen in Ubuntu und Derivaten mitinstallierten Dämon nicht abmurkst, sammelt er völlig automatisch alle Drucker ein, die ihm auf Französisch einen guten Tag wünschen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein T. schrieb: >> Warum hackst Du Dich auch heimlich ins Netzwerk Deines Vermieters. ;-) > > Der Hacker heißt cups-browsed und profitierte davon, dass der Vermieter > der Ferienwohnung sein eigenes WLAN zur Verfügung stellte, statt ein > separates zu definieren. > > Wenn man diesen in Ubuntu und Derivaten mitinstallierten Dämon nicht > abmurkst, sammelt er völlig automatisch alle Drucker ein, die ihm auf > Französisch einen guten Tag wünschen. Aus Erfahrung weiß ich, daß er das auch mit Druckern tut, die ihn auf kroatisch, portugiesisch und deutsch ansprechen. Zum Glück ist das in meinem Falle nicht so schlimm, denn wenn meine "Ferienwohnung" den Hafen verlassen und das WLAN hinter sich gelassen hat, muß ich mir ohnehin keine Gedanken mehr über Drucker machen.
Ein T. schrieb: > die ihn auf kroatisch, portugiesisch und deutsch ansprechen Nein, Donbardan oder Bomdia reicht nicht, es muss schon Bonjour sein. Früher hätte der Drucker den Dämon sogar gleich zu einem Rendevous aufgefordert, aber das gab eine Ohrfeige.
:
Bearbeitet durch User
Ein T. schrieb: > Nun würde ich aber trotzdem nichts sagen, wenn ich dieses Verhalten bei > Dir nicht schon in früheren Linux-Threads beobachtet hätte. Im ersten > Deiner Linux-Threads hier hast Du auf die Frage, was denn die Logdateien > zu Deinem Problem sagen, damit begonnen, die Hilfswilligen zu > beschimpfen. Auch im weiteren Verlauf des damaligen Threads ... Oh da fühlt sich aber einer angepisst und hat erst mal in den Tiefen des Forums gewühlt. Besser wäre es natürlich gewesen auch mal eine andere Meinung zu aktzeptieren und einfach mal die Gründe die zu dieser Meinung geführt haben zu hinterfragen. Das scheint aber heutzutage nicht mehr en vouge zu sein - nicht nur im µC-Net. Ja, man findet irgendwann eine Lösung auch unter Linux, allerdings ist der Weg oft sehr steinig und komfortabel ist dann auch anders. Ich erinnere nur an das Drama den NVidia-Treiber unter Mint zum Laufen zu bekommen, da kommen dann so Hinweise wie kann man nur so eine alte Karte und so einen alten Rechner benutzen. Dabei heißt es doch immer Linux kommt mit alter Hardware wunderbar klar. Nein kommt es eben in meinem konkreten Fall eben nicht - Win XP bis Win10 hat mit dieser ollen Kiste keine Probleme und funktioniert einfach, da habe ich auch keine Woche gebraucht um den Treiber ans Laufen zu bekommen. Da wird jetzt sich gleich einer um die Ecke kommen und sagen das ist ein Einzelfall, mag alles sein, gibt es aber eben auch und wenn es dann einen betrifft ist es überhaupt nicht mehr lustig.
Beitrag #7094024 wurde von einem Moderator gelöscht.
Beitrag #7094102 wurde von einem Moderator gelöscht.
DPA schrieb: > Eigentlich solle ein Mod mal den Titel korrigieren! wth ist KINUX? (ausser ein saublöder Fiptehler der im Auge nervt)
Joachim B. schrieb: > wth ist KINUX? Ein dreckiger Clickbait: Thomas L. schrieb: > Ich habe absichtlich den Post unter "Kinux" > gestartet - als "Eyecatcher"
Jörg W. schrieb: > (prx) A. K. schrieb: >> Das war mir dann aber auch nicht recht. > > Zeroconf halt. Btw., das passiert natürlich unter MacOS genauso. Kaum verwunderlich, denn Zeroconf und auch CUPS kommen von da.
Wie ist das Experiment eigentlich ausgegangen? Bereits reumütig zu Windows zurückgekehrt? Oder ist Sux noch aktuell? Und wie unzufrieden bist du bis jetzt? :-)
Zeno schrieb: > Oh da fühlt sich aber einer angepisst und hat erst mal in den Tiefen des > Forums gewühlt. > Besser wäre es natürlich gewesen auch mal eine andere Meinung zu > aktzeptieren und einfach mal die Gründe die zu dieser Meinung geführt > haben zu hinterfragen. Das scheint aber heutzutage nicht mehr en vouge > zu sein - nicht nur im µC-Net. Gut analysiert! Vernünftige Menschen sehen das so,aber wenn jemand über das berechtigt schimpft was des Linuxers Lebensinhalt ist dann lassen die ihr "Programm" ablaufen wie halt bei mir. "Lügen" und falsche Unterstellungen als Waffe gegen den Feind dessen was mir lieb ist und viel bedeutet. Zeno meinte ja schon richtigerweise ,dass es für meine Ansichten Gründe gibt. Der wichtigste Grund ist der , dass das Leben für ein Experiment mit Linux viel zu schade ist. Ich habe unter Windows im Desktop-Bereich erheblich mehr Zeit für anderes. Wer nur Linux hat und sonst nichts ist froh um jede Macke bei der er sich beweisen kann, und um nach jedem behobenen Problem stolz auf sich wie Bolle zu sein.
herbert schrieb: > Wer nur Linux hat und sonst nichts ist froh um jede Macke bei der er > sich beweisen kann, und um nach jedem behobenen Problem stolz auf sich > wie Bolle zu sein. Dein dämliches Gesülze wird von ständiger Wiederholung nicht wahrer. Ich nehme aber an, dass du das weißt, und es dir nur um stumpfe Provokation geht. Man könnte sich nun fragen: was hat jemand davon? Die wahrscheinlichsten Antworten haben alle was mit persönlichen Defiziten zu tun … ich meine: dass du mit Linux nicht klargekommen bist heißt ja nun nicht, dass sich im Gegenzug jeder selbst als Elite betrachten würde, der keinerlei Probleme damit hätte (was die Mehrzahl der User ist, btw.). Dieses „Elite“ stammt nämlich alleine von dir – und scheint irgendwie ein verquerer Kompensationsmechanismus zu sein. Vielleicht etwas in der Art „wenn »die« keine Probleme damit haben, und ich nicht damit klarkomme, dann liegt das an »denen«, und insgeheim betrachten »die« sich als Elite und lachen über mich!!k“ – mag das hinkommen? Ich verrate dir mal was: mir geht’s mit Windows, wie’s dir wohl mit Linux ging: ich hab letztes WE einige Stunden in den Sand gesetzt, weil ich darunter bloß ein wenig Software auf ein anderes Laufwerk verschieben wollte, das ich nachträglich eingebaut habe. Hat mich ziemlich frustriert, insbesondere, dass das Ding sich einige Male aufgehängt hat, ohne dass man irgendwo hätte schauen können, woran es denn lag, und dass die betreffende Software sich dann, nachdem es dann doch mal geklappt zu haben schien, ohne Meldung seitens des Systems nicht starten ließ. Aber ich bin mir dessen bewusst, dass es vermutlich an meinen Defiziten mit diesem System lag, und ich fange nun, im Gegensatz zu dir, nicht an, gegen Leute zu spucken, die unerhörterweise kein Problem mit dem System haben, mit dem ich mich nicht so auskenne. Wieso fällt’s dir so schwer, zu erkennen, dass die Systeme nunmal verschieden sind, und Mensch sich nunmal am Anfang mit allen Sachen schwertut, mit denen er sich nicht auskennt? Und dass das nicht automatisch bedeutet, dass diese Sachen schlecht sind?
:
Bearbeitet durch User
Zeno schrieb: > Befürchte mal Dein Post wird wohl wieder eine Diskussionslawine Win vs. > Linux los treten. Könnte man wohl meinen. Ach, ich sehe es eher so das er teilweise schon Recht hat. Die Community kann schon arrogant sein. Der Umstieg gelingt nur wenn entweder genug eigenes Verständnis vorhanden ist oder jemand da ist der es gut erklärt. Immer und überall ist das so. Der Unterschied, mit Windows sind die meisten aufgewachsen und haben irgendwann irgendwo von irgendwem in irgendeiner Form "gelernt" damit umzugehen. Bei Linux, weil es nie "Dominant" Präsent war wie Windows, sieht das eben völlig anders aus.
:
Bearbeitet durch User
Kilo S. schrieb: > Der Unterschied, mit Windows sind die meisten aufgewachsen und haben > irgendwann irgendwo von irgendwem in irgendeiner Form "gelernt" damit > umzugehen. Ich denke auch, dass das den größten Anteil hat. Ich bin mit Unixen aufgewachsen (und zwar mit welchen, wo man zum Teil noch viel mehr selbst Hand anlegen musste – DG/UX, kennt heute keiner mehr), und ich grummele jedes Mal, wenn mir jemand ein Windows vorsetzt, wie umständlich das da alles ist. Frage mich dann, wie man mit sowas produktiv arbeiten können soll, wenn man jetzt schon zum fünften Mal am Tag das Ding neu booten muss, weil irgendwas installiert worden ist … Man sollte einfach akzeptieren können, dass andere Systeme manche Dinge anders lösen.
:
Bearbeitet durch Moderator
Jack V. schrieb: > Joachim B. schrieb: > >> wth ist KINUX? > > Ein dreckiger Clickbait: > Thomas L. schrieb: > >> Ich habe absichtlich den Post unter "Kinux" >> gestartet - als "Eyecatcher" Dann ist ja eindeutig um was es hier geht: Trolling und Linux-Bashing. Von wegen HP Drucker funktioniert unter Linux nicht.
Timo k. schrieb: > Dann ist ja eindeutig um was es hier geht Nur für jemanden, der den Thread nicht gelesen hat. Ansonsten wüsstest du, dass der TE inzwischen durchaus zufrieden mit seiner Linux-Wahl ist. Der nicht funktionierende HP-Drucker wurde von jemandem ganz anderen in den Ring geworfen.
Jörg W. schrieb: > Der nicht funktionierende HP-Drucker wurde von jemandem ganz anderen in > den Ring geworfen. Dann lies nochmal den Eingangspost!!! Dass ein weiterer Troll behauptet dass sein Drucker nicht funzt ist sekundär. Denn nur der Eingangsposter ist für den Titel des Threads verantwortlich.
Soso schrieb: > Dass ein weiterer Troll behauptet dass sein Drucker nicht funzt ist > sekundär. Denn nur der Eingangsposter ist für den Titel des Threads > verantwortlich. Ps: Der "Troll" schenkt dir was für deine Bildung...Auszüge aus diversen Foren... Ich versuche, meinen HP LaserJet P1005-Drucker unter Linux Mint Debian Edition 201204 zum Laufen zu bringen. Er hat sich im Grunde von selbst installiert und ist mit dem lokalen Host verbunden, druckt aber nicht - schade! Hallo, ich habe LM 17.1 und einen Laserjet 1005. Wenn ich versuche, eine Testseite zu drucken, erscheint ein Popup-Fenster mit der Meldung, dass der Vorgang gestartet wurde, aber eigentlich passiert nichts mit dem Drucker. Keine Bewegung, kein LED-Blinken, nichts. Einige Sekunden später erscheint sogar ein Popup, dass der Job abgeschlossen ist. Das ist absurd. Ich habe Linux Mint 17 und einen HP P1005. Die Hardware ist neu Mit dem Drucker ist nichts falsch - druckt perfekt von einer alten XP-Maschine. Bis dies gelöst ist, muss ich Druckdateien auf die XP-Maschine verschieben, um sie drucken zu lassen. Buchstäblich ein Zug.Hinweis: Ich war ein großer Linux-Fan, aber ehrlich gesagt bin ich frustriert über Linux als allgemeinen Ersatz für Windows und würde es dem durchschnittlichen Computerbenutzer nicht empfehlen. Es ist nur für diejenigen, die mit ihrer Maschine spielen möchten, bereit sind , schlechtes Benehmen in Kauf zu nehmen und "Foren" darüber zu konsultieren, wo niemand genau das gleiche Problem hat - anstatt einer einfachen Dokumentation, die zu einer Lösung führt.
Soso schrieb: > Dann lies nochmal den Eingangspost!!! Ja, und? Inzwischen hat er seine Probleme offenbar gelöst: Beitrag "Re: Umstieg auf Kinux von Win" Das Eingangsposting ist aber bis auf das "Kinux" nun wahrlich nicht provokant verfasst. Das auf die gleiche Stufe zu stellen wie Herberts Behauptung, der (andere) Drucker würde unter Linux eh gar nicht funktionieren, ist ziemlich daneben.
herbert schrieb: > Es ist nur für diejenigen, die mit ihrer Maschine spielen möchten Wenn du dich einfach mal derartiger völlig unsinniger Schlussfolgerungen enthalten würdest, könnte man mit dir – so du es willst – über technische Details diskutieren. So kommt jedes deiner Postings in diesem Stil einfach nur als Trollerei rüber, weil du letztlich implizierst, dass alle diejenigen, die mit anderen Systemen arbeiten, Leute seien, "die mit ihrer Maschine spielen möchten". Das ist schlicht und ergreifend anmaßend. Nur, weil du etwas nicht hinbekommen hast (warum auch immer, keiner streitet ab, dass du ein Problem damit hattest) lässt noch lange nicht den Schluss zu, dass es nun allen anderen auch so gehen müsste.
Jörg W. schrieb: > Wenn du dich einfach mal derartiger völlig unsinniger Schlussfolgerungen > enthalten würdest, könnte man mit dir – so du es willst – über > technische Details diskutieren. So kommt jedes deiner Postings in diesem > Stil einfach nur als Trollerei rüber, weil du letztlich implizierst, > dass alle diejenigen, die mit anderen Systemen arbeiten, Leute seien, > "die mit ihrer Maschine spielen möchten". Das ist schlicht und > ergreifend anmaßend. > > Nur, weil du etwas nicht hinbekommen hast (warum auch immer, keiner > streitet ab, dass du ein Problem damit hattest) lässt noch lange nicht > den Schluss zu, dass es nun allen anderen auch so gehen müsste. Lieber Jörg! In deinem Eifer mir was zu "geigen" ist dir völlig entgangen, dass ich in meinem Posting "Auszüge " aus Linux Foren wortwörtlich zitiert habe und alles gar nicht O-Ton von mir ist. Sorry aber etwas mehr Aufmerksamkeit kann man von einem "Moderator" schon verlangen...und weniger Parteilichkeit den das ist der Job den man moderieren nennt.
herbert schrieb: > ich habe LM 17.1 und einen Laserjet 1005. Wenn ich versuche, eine > Testseite zu drucken, erscheint ein Popup-Fenster mit der Meldung, dass > der Vorgang gestartet wurde, aber eigentlich passiert nichts mit dem > Drucker. Keine Bewegung, kein LED-Blinken, nichts. Einige Sekunden > später erscheint sogar ein Popup, dass der Job abgeschlossen ist. Naja, unter WIN würde ich nachsehen, ob der Haken bei Offline gesetzt ist. Was sagt die Warteschlange? Ich habe jetzt mal auch meinen Drucker unter Mint-18 angeschaut. Wenn ein Drucker unter Linux läuft, kann man genau so stolz sein, wie wenn er unter dem WIN-treiber läuft. Es ist das Mindeste vom Mindesten. Nun habe ich mir mal den Treiber von OKI unter XP angesehen. Wesentlich mehr Einstellungen. Obwohl beim Laser die begrenzt sind. Bei einem Tintenstrahler sind die Möglichkeiten gewaltiger. Das gibt es nur mit dem Herstellertreiber unter WIN. Ganz zu schweigen von der Wartungskonsole für den Drucker. Einstellungen des Druckers verwalten oder auch z.Bsp. die Trommelreinigung gibt es bei Linux nicht. Auch nicht bei den rudimentären WIN Treibern. Und wenn man den Status abfragen will, außer einem verlorenem Blatt und einer sinnlosen Antwort ist nichts geschehen.
Zeno schrieb: > Ein T. schrieb: >> Im ersten >> Deiner Linux-Threads hier hast Du auf die Frage, was denn die Logdateien >> zu Deinem Problem sagen, damit begonnen, die Hilfswilligen zu >> beschimpfen. > Oh da fühlt sich aber einer angepisst und hat erst mal in den Tiefen des > Forums gewühlt. An jenen Thread erinnere ich mich auch, ohne zu suchen. Das ist untypisch für mich, normalerweise vergesse ich so etwas sehr schnell.
Kilo S. schrieb: > Ach, ich sehe es eher so das er teilweise schon Recht hat. Die Community > kann schon arrogant sein. Das stimmt, beruht aber nach meiner Beobachtung meistens auf Gegenseitigkeit. Der Ton macht die Musik, nicht wahr? > Der Umstieg gelingt nur wenn entweder genug eigenes Verständnis > vorhanden ist oder jemand da ist der es gut erklärt. Immer und überall > ist das so. Es gibt unter Linux eine Unmenge an guter Dokumentation in fast jeder Detailtiefe, die man sich wünschen kann. Bücher wie Linux for Dummies, den Kofler, die Man- und Infopages, HOWTOs, die Dokumentation unter /usr/share/doc, Webseiten die dem Thema gewidmet sind, Mailinglisten und ihre Archive, und natürlich Foren wie dieses. Der Wissenstransfer wird leider schwierig, wenn das Gegenüber nicht zuhören, keine Dokumentation lesen und nichts von dem tun will, was ihm empfohlen wird. > Der Unterschied, mit Windows sind die meisten aufgewachsen und haben > irgendwann irgendwo von irgendwem in irgendeiner Form "gelernt" damit > umzugehen. > > Bei Linux, weil es nie "Dominant" Präsent war wie Windows, sieht das > eben völlig anders aus. Es ist ja nicht so, als ob die Linux-User das nicht wüssten. Deswegen helfen die allermeisten wirklich gerne, wenn sie freundlich gefragt werden und der Frager ein wenig Bemühen und Eigeninitiative erkennen lässt. Mir in all den Jahren jedenfalls noch nie jemand blöd gekommen.
Timo k. schrieb: > Dann ist ja eindeutig um was es hier geht: Trolling und Linux-Bashing. > Von wegen HP Drucker funktioniert unter Linux nicht. Ich sehe nicht, dass der TO ein Troll wäre. Im Gegenteil hat er sein Problem gut beschrieben und dann gefragt, ob das womöglich ein Versionsproblem oder ein Fehler sei. Mit etwas Unterstützung ist es ihm dann gelungen, seinen Drucker anzusprechen und zu benutzen, und am Ende hat er sich noch einmal zurückgemeldet und erklärt, sein Umstieg sei erfolgreich verlaufen und er mittlerweile glücklich. Also wenn das das typische Verhalten eines Trolls ist, dann möchte ich bitte mehr Trolle.
Karl Käfer schrieb: > Es gibt unter Linux eine Unmenge an guter Dokumentation in fast jeder > Detailtiefe, die man sich wünschen kann. Stimmt, manches geht sogar tiefer ins Detail als man in dem Moment überhaupt benötigen würde. Manches allerdings auch nicht tief genug. Da sehe ich aktuell so ein kleines "Fummelproblem" beim Image von Openwebrx. Die "Konfiguration" unter den Pfaden zu finden die in der Dokumentation abgegeben sind ist.. nun ja, einfach nicht möglich denn sie sind ja gar nicht vorhanden! Ich Versuche seit bestimmt einer Woche das Image auf meinem Pi so umzustricken das der Fifi (sogar offiziell Unterstützt) darauf läuft. Finde allerdings die Konfigurationsdatei nicht in der ich die Soundkarte anpassen muss damit das auch läuft. Übrigens mir braucht auch keiner sagen das die webUI normalerweise diesen Job übernimmt und das File Basierende system abgelöst hat, das weiß ich bereits. Dabei klingt die Anleitung eigentlich ganz "einfach"... Vor allem weil man ja nach >10 Jahren Nutzung von Linux schon irgendwie "drin" ist und mit dem System ganz gut klar kommt. https://github.com/jketterl/openwebrx/wiki/FiFi-SDR-device-notes Also manchmal kann Linux selbst für "Alte Hasen" sehr anstrengenden sein.
:
Bearbeitet durch User
herbert schrieb: > Zb. Drucker und Scanner. Ich hatte keine lust > die auf den Müll zu werfen um dann teure Drucker zu kaufen die mit > Linux Treibern geliefert werden. herbert schrieb: > Dann versuche dich mal am HP Laserjet 1005... Was der unter Mint noch > kann im Vergleich zu Windows spottet jeder Beschreibung... Die Probleme > welche diese günstigen Drucker mitbringen sind bei Linuxjüngern durchaus > bekannt. https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index Model Name Min. HPLIP Version Chrome OS Support Driver Plug-in8 Support Level9 Print Mode Scan to PC3 PC Send Fax5 Connectivity USB Network Parallel1 Note HP LaserJet 1005 Printer 2.7.12 No Yes Full (End of support) Mono No No USB 8 ("Yes") A downloadable driver plug-in is Yes for printing support. ("Optional") A downloadable driver plug-in is optional for printing support and may increase the speed, quality, or other aspect of printed output. ("No" or "None") A driver plug-in is not Yes nor available. Driver plug-ins are released under a proprietary (non-open) license and are not part of the HPLIP tarball release. For more information, please refer to this KB article 9 For a definition of Support Levels, please refer to this KB article. Support Level Definitions: "Full": All device functions and features which are available from HPLIP are supported, provided your device supports these features. HP personnel monitor Launchpad forum posts and attempt (but cannot guarantee) to answer questions posted for this support class. See this KB article for full list of HPLIP features. See this page to check the support level of your product and for a complete list of functions and features your device will deliver with HPLIP. "Full - End-of-Support": The HP product has reached the end of support life, meaning the HPLIP solution is considered “As-is”. No further HPLIP code changes will be implemented by HP. While monitoring of Launchpad posts by HP personnel will continue, follow-up by HP personnel on these products will be extremely limited. Community members are encouraged to assist others with issues on these printers. Patches provided to HP to address issues on these products will be considered (but not guaranteed) for inclusion in future HPLIP releases. As of the end-of-support date, device functions and features available from the product and available from HPLIP should continue to function but cannot be guaranteed to continue to work in subsequent HPLIP releases. See this KB article for full list of HPLIP features. D.h. unter https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index und den dort verlinkten Seiten sieht ma was mit hplip unter Linux unterstützt wird und was nicht. Wenn einem das nicht reicht, sollte man den Drucker entweder unter Linux nicht verwenden und einen anderen kaufen oder man sollte bei Windows bleiben. Es gibt genug Drucker, die unter Linux gut funktionieren und leicht einzurichten sind. Ein Drucker der früher mal für eine Sun-Workstation angeschafft wurde, funktioniert auch nicht automatisch unter Win 10.
Kilo S. schrieb: > Ich Versuche seit bestimmt einer Woche das Image auf meinem Pi so > umzustricken das der Fifi (sogar offiziell Unterstützt) darauf läuft. Ich habe ein ähnliches Problem mit meinem BananaPi. Da versuche ich seit mehreren Wochen den 1-Wire-Treiber zum Laufen zu bringen. Laut den Beschreibungen ist das gar kein Problem, da muß man sich nur die BPI-Tools runterladen und die fex-Datei editieren. Dummerweise gibt es die bei mir nicht. Gibt aber einen schlauen Menschen der ein Kernelmodul geschrieben hat, welches für meine Zwecke genau passend ist. Also das Dingens kompiliert (direkt auf den Pi) hat auch funktioniert, das böse ERwachen kommt danach, der Kernel kann es nicht laden - "Exec format Error". Google befragt - Modul und Kernel haben nicht die gleiche Version. Allerdings spucken modinfo und uname -r die gleiche Version aus. OK da der kernel nicht der Neueste ist könnte man ja mal ne aktuelle Distribution versuchen. Also neues Image direkt von Sunxi (Hersteller) herunter geladen und auf die SD geschrieben. ERgebnis bleibt schon beim Booten hängen - "Scanning btrfs-volumes .. " oder so ähnlich. Ich habe aber derartiges nicht. Erst durch Entfernen der btrfs-progs via chroot bekommt man das Ding zum Booten. Da bleibt er schon berim nächsten hängen. Er versucht ein Resizing der SD-Karte was nicht gelingt nach 8 min geht es dann weiter und man bekommt sogar einen Loginprompt. Das Modul läßt sich jetzt auch kompilieren und funktioniert sogar voila. Jetzt muß mit dieser Version nur noch der Rest im Speziellen die Software für den Wettersatellitenempfang funktionieren. Also erstmal neu booten und dabei prüfen ob auch das automatische Laden des Moduls funktioniert. Da kommt auch schon das nächste Problem um die Ecke - "Error sync SD-card ....". Nach 5min Wartezeit ist auch diese Klippe umschifft und er bootet sogar wieder. Kommt allerdings wieder nur bis zum Resizing, 8min warten dann geht es weiter. Die Startscripte sind natürlich auch nicht mehr das was sie mal waren, vieles läuft jetzt über systemctl, da muß man erst mal herausfinden wer dafür verantwortlich ist. Irgendwann habe ich es geschafft das Resizing abzuschalten, jetzt ist nur noch das Syncproblem da. Das hält sich sich hartnäckig und tritt auch beim Benutzen von fdisk auf. Das läßt vermuten das der Fehler irgendwo in den Tiefen des Systems sitzt. In der Community ist dieser Fehler durchaus bekannt, allein es hapert an einer passablen Lösung.
Karl Käfer schrieb: > Also wenn das das typische Verhalten eines Trolls ist, dann möchte ich > bitte mehr Trolle. :-))
Hallo, Karl Käfer schrieb: > Es gibt unter Linux eine Unmenge an guter Dokumentation in fast jeder > Detailtiefe, die man sich wünschen kann. In der aktuellen c't ist eine Artikelserie über Quantencomputer erschienen. In einem Artikel sind die Grundzüge der Funktionsweise dieser Rechner erklärt. Da mich das interessiert, habe ich mir den Artikel durch gelesen. Es ist das erste mal gewesen, das ich von der Beschreibung eines technischen Sachverhaltes nicht das Allergeringste verstanden habe. Und genau so dürfte es einem Großteil (Behauptung ohne Beweis: > 90%) aller Benutzer von Linux gehen, die nicht aus der "EDV-Ecke" kommen. Denen nutzt es überhaupt nichts das es Unmengen an Information zur Lösung ihrer Probleme gibt, da sie aus Verständnisgründen nicht in der Lage sind diese Informationen zu nutzen. Und diese Informationen sind für Außenstehende oft schwer zu finden. Hinzu kommt das es viel Grundlagenwissens bedarf um ein wirkliches Verständnis in Linux-Dingen zu entwickeln, das für "Linuxer" selbstverständlich, für Außenstehende dagegen nicht vorhanden ist. Natürlich kann man auch dieses Grundlagenwissen wiederum erlernen, aber während der "Linuxer" diese Grundlagen wie ein Werkzeug ständig anwendet, benötigt der reine Linux-User so was vielleicht nur einmal und hat das dann sofort wieder vergessen. Und so geht das dann bei jedem Problem. Da kann ich schon verstehen wenn Leute entnervt sind, wenn sich scheinbar so triviale Dinge wie die Einrichtung eines Druckers zu einer Odyssee durch die Informationsberge der weit verteilten Linus-Dokumentation entwickeln. rhf P.S. Ich habe hier einen MFC-Drucker von Brother, der problemlos unter Windows (kein Wunder) als auch unter Linux funktioniert, da Brother für ihre Drucker mit entsprechende Treiber zu Verfügung stellt.
Roland F. schrieb: > Und genau so dürfte es einem Großteil (Behauptung ohne Beweis: > 90%) > aller Benutzer von Linux gehen, die nicht aus der "EDV-Ecke" kommen. > Denen nutzt es überhaupt nichts das es Unmengen an Information zur > Lösung ihrer Probleme gibt, da sie aus Verständnisgründen nicht in der > Lage sind diese Informationen zu nutzen. Und diese Informationen sind > für Außenstehende oft schwer zu finden. Welches besondere Grundlagenwissen soll das sein, was der Anwender wissen muss? Außer etwas vom heutigen Allgemeinwissen reicht vollkommen. Mir scheint du verwechselst den Anwender mit dem Programmierer/Entwickler.
Gast schrieb: > Mir scheint du verwechselst den Anwender mit dem > Programmierer/Entwickler. Nö der Roland verwechselt da gar nichts.
Hallo, Gast schrieb: > Außer etwas vom heutigen Allgemeinwissen reicht vollkommen. Was verstehst du unter Allgemeinwissen in Bezug auf Linux? rhf
Kilo S. schrieb: > Da sehe ich aktuell so ein kleines "Fummelproblem" beim Image von > Openwebrx. Wenn die Dokumentation einer Anwendung inkorrekt ist, dann ist das ein Problem der Anwendung und / oder ihrer Dokumentation. Es ist sicherlich kein Problem eines der Betriebssysteme, unter denen die Anwendung laufen könnte. Wenn Photoshop unter Windows nicht läuft, schimpft ja auch keiner über Windows. Okay, jedenfalls nicht deswegen. ;-)
Zeno schrieb: > Ich habe ein ähnliches Problem mit meinem BananaPi. Da versuche ich seit > mehreren Wochen den 1-Wire-Treiber zum Laufen zu bringen. Laut den > Beschreibungen ist das gar kein Problem, da muß man sich nur die > BPI-Tools runterladen und die fex-Datei editieren. Das ist dann wohl ein Problem mit diesen BPI-Tools, oder? > Dummerweise gibt es > die bei mir nicht. Gibt aber einen schlauen Menschen der ein Kernelmodul > geschrieben hat, welches für meine Zwecke genau passend ist. Also das > Dingens kompiliert (direkt auf den Pi) hat auch funktioniert, das böse > ERwachen kommt danach, der Kernel kann es nicht laden - "Exec format > Error". Google befragt - Modul und Kernel haben nicht die gleiche > Version. Ich würde ja eher auf das Binärformat tippen, aber... Nebenbei bemerkt gibt es im Linux-Kernel schon seit vielen Jahren ein Modul für Onewire. Es heisst w1 und ich selbst habe es schon mehrmals sowohl auf x86-Rechnern und auf dem RasPi erfolgreich eingesetzt -- auf einem meiner Pis läuft es, schon über mehrere Updates hinweg, seit mindestens fünf Jahren stabil und zuverlässig. > Das Modul läßt sich jetzt auch kompilieren und funktioniert sogar voila. > Jetzt muß mit dieser Version nur noch der Rest im Speziellen die > Software für den Wettersatellitenempfang funktionieren. Wenn diese Software Schwierigkeiten macht, dann ist der Hersteller der Software der richtige Ansprechpartner für Dich. Das hat aber mit Linux nichts zu tun. Im Übrigen, bitte verzeih, erscheint mir Dein Denkansatz etwas merkwürdig: erst kaufst Du Dir ein exotisches Bastelmodul aus China, und beschwerst Dich dann über das Gebastel. Wenn Du stattdessen einen RasPi erworben hättest, dann gäbe es eine weit grössere Community und eine deutlich bessere Unterstützung. Wenn ich einen Modellbausatz kaufe kann ich mich hinterher doch nicht beschweren, dass ich die Teile zusammenkleben und lackieren muss?!
Roland F. schrieb: > Und genau so dürfte es einem Großteil (Behauptung ohne Beweis: > 90%) > aller Benutzer von Linux gehen, die nicht aus der "EDV-Ecke" kommen. > Denen nutzt es überhaupt nichts das es Unmengen an Information zur > Lösung ihrer Probleme gibt, da sie aus Verständnisgründen nicht in der > Lage sind diese Informationen zu nutzen. Und diese Informationen sind > für Außenstehende oft schwer zu finden. Nicht nur ich, sondern auch andere Teilnehmer dieses Forums empfehlen in solchen Fällen das Standardwerk "Linux" von Dr. Michael Kofler. Das deckt verschiedene Distributionen ab und enthält alles, was Einsteiger und Fortgeschrittene wissen müssen. Und nach der Lektüre wissen auch Bastler und Profis, wo sie die weiteren Informationen finden können, wenn sie die brauchen. > Hinzu kommt das es viel Grundlagenwissens bedarf um ein wirkliches > Verständnis in Linux-Dingen zu entwickeln, das für "Linuxer" > selbstverständlich, für Außenstehende dagegen nicht vorhanden ist. 99,9% der Linux-Nutzer werden dieses Grundlagenwissen niemals brauchen und müssen es sich deswegen auch nicht aneignen. Um ein Auto zu fahren, muss ich nicht wissen, wie die Einspritzanlage den korrekten Zündzeitpunkt errechnet. Wenn ich die Leistung des Motors verbessern will, dann brauche ich dieses Wissen, und es ist eine feine Sache, wenn dieses Wissen (sogar kostenlos) erhältlich ist.
Kilo S. schrieb: > Karl Käfer schrieb: >> Es gibt unter Linux eine Unmenge an guter Dokumentation in fast jeder >> Detailtiefe, die man sich wünschen kann. > > Stimmt, manches geht sogar tiefer ins Detail als man in dem Moment > überhaupt benötigen würde. Manches allerdings auch nicht tief genug. Man kann es halt nicht allen Recht machen -- und zuviel Information ist doch immer noch besser als zuwenig, oder? Als ich das letzte Mal eine Windows-Hilfe benutzt habe -- das wird zu Zeiten von NT4 gewesen sein --, wurden mir drei Fragen vom Typ "ist Ihr Computer eingeschaltet" und "haben Sie den Monitor mit dem Computer verbunden" gestellt und mir dann geraten, meinen Systemadministrator zu fragen. Diesen habe ich dann natürlich auch befragt, konnte mir selbst aber leider keine hilfreiche Antwort geben. Ist die Windows-"Hilfe" mittlerweile besser geworden? Immerhin scheint mir, daß die Flut der bunten Heftchen mit "PC" im Namen und "Windows" auf der Titelseite am hiesigen Kiosk seitdem nicht abgenommen hat -- es scheint also immer noch einen großen Bedarf zu geben. ;-) > Da sehe ich aktuell so ein kleines "Fummelproblem" beim Image von > Openwebrx. Verzeihung, aber das ist wohl ein Problem von Openwebrx, oder?
Karl Käfer schrieb: > Das ist dann wohl ein Problem mit diesen BPI-Tools, oder? Nö, wenn es bei der installierten Distribution die Dateien nicht gibt können die BPI-Tools wenig dazu. Karl Käfer schrieb: > Ich würde ja eher auf das Binärformat tippen, aber... Ist mir egal was da am End nicht funktioniert - es funktioniert nicht obwohl es auf dem Pi, gegen die passenden Kernelheader kompiliert wurde. Ich stehe mit dem Problem nicht alleine da, da gibt es durchaus noch mehr User mit dem gleichen Problem - sagt zumindest Google. Karl Käfer schrieb: > Nebenbei bemerkt gibt es im Linux-Kernel schon seit vielen Jahren ein > Modul für Onewire. Es heisst w1 und ich selbst habe es schon mehrmals > sowohl auf x86-Rechnern und auf dem RasPi erfolgreich eingesetzt Ist mir bekannt und funktioniert auch auf mehreren Pi's bei mir. BananaPi ist aber nicht gleich RaspberryPi - da gibt es einige Unterschiede, das geht schon bei der Defaultfunktion der GPIO-Pins los. Da ist eben der Defaultpin für 1-Wire unterschiedlich. Wenn an Stelle des RPi nun ein BPi werkelt muß man halt den 1 Wire Port des BPi auf den den selben Pin wie beim RPi legen, wenn man nicht die ganze Verkabelung ändern will. Bei dem von mir verwendeten Modul funktioniert das sehr gut. Bei 1W-Modulen funktioniert es leider nicht immer zuverlässig. Das klassische 1W Modul müßte ich ebenfalls erst kompilieren, da es kein passendes Binärpackage in der Distribution gibt. Und auch das führt am Ende zum gleichen Fehler. Egal welches Modul ich aus den den Quellen der Distribution baue, keines funktioniert. Karl Käfer schrieb: > Wenn diese Software Schwierigkeiten macht, dann ist der Hersteller der > Software der richtige Ansprechpartner für Dich. Das hat aber mit Linux > nichts zu tun. Ja toll. Die Sunxi Seite und das Forum habe ich schon durchforstet. Wenn's eng wird schweigt man sich halt aus. Karl Käfer schrieb: > Im Übrigen, bitte verzeih, erscheint mir Dein Denkansatz etwas > merkwürdig: erst kaufst Du Dir ein exotisches Bastelmodul aus China, und > beschwerst Dich dann über das Gebastel. Wenn Du stattdessen einen RasPi > erworben hättest, dann gäbe es eine weit grössere Community und eine > deutlich bessere Unterstützung. Wenn ich einen Modellbausatz kaufe kann > ich mich hinterher doch nicht beschweren, dass ich die Teile > zusammenkleben und lackieren muss?! An dem Denkansatz ist gar nichts merkwürdig. Ich hatte an dieser Stelle zuvor einen Pi. Leider hat er sich in unregelmäßigen Abständen (das waren Zeiträume von wenigen Stunden bis 1-2 Monate) aufgehangen bzw. war dann über Netzwerk nicht mehr erreichbar - bei Headless ein Nogo. Ich verschiedene Distributionen und RPi Varianten probiert. Keine Variante hat zuverlässig funktioniert. Dem Fehler war auch nicht mit umfangreichen Logging auf die Schliche zu kommen. Selbst der Watchdog (System unter bestimmten Bedingungen einfach neu starten) brachte keine zuverlässige Lösung. Es lag auch nicht an der SD da wurde nicht geschrieben (angeschlossene SSD, Daten via Netz auf Server). Community - ich lach mich kaputt. Da ist das Problem zwar bekannt, da wurde auch heftig diskutiert und es wurden auch Lösungsansätze gezeigt, es hat leider nichts richtig gegriffen. Ja und wenn man auch in der Community nicht mehr weiter weis, schweigt man sich halt aus. RPi ist wohl an dieser Stelle (Wettersatellitenempfang) keine wirkliche zuverlässige Dauerlösung. Der "Bastel-BPI" tut seit über einem Jahr völlig klaglos. Scheint offensichtlich doch nicht so schlecht zu sein. Bei Problemen steht man halt ziemlich allein da und braucht halt Geduld um das Problem zu lösen. Der Wildwuchs bei den ganzen Distris tut ein übriges, so das es eben keine allgemeingültigen Lösungswege gibt, da jeder irgend eine Kleinigkeit anders macht. Ändert aber am Ende nichts daran das Linux ein Frickelsystem ist und bleibt. Vieles ist zwar gut gedacht, aber am Ende nur halbherzig umgesetzt - OSS like halt. Da muß ich doch nur in den Parallelthread schauen, da geht es mal wieder um das alte leidige Thema Linux vs. NVidia. Was kommt dort als Lösungsansatz: Ja dann nimm doch nur die Intelonboardgrafik, die reicht doch für die meisten Dinge - gehts noch.
Zeno schrieb: > Ja und wenn man auch in der Community > nicht mehr weiter weis, schweigt man sich halt aus. > RPi ist wohl an dieser Stelle (Wettersatellitenempfang) keine wirkliche > zuverlässige Dauerlösung. Ich nutze den Pi auch nicht mehr für Always-On-Scenarien, aus den von dir geschilderten Gründen. Für Medienspieler und Retrokonsolen die nur wenige Stunden laufen finde ich ihn aber nach wie vor ganz OK.
Zeno schrieb: > RPi ist wohl an dieser Stelle (Wettersatellitenempfang) keine wirkliche > zuverlässige Dauerlösung. Ob das irgendwo an den verwendeten Programmen liegt? Wir haben hier einen, der eine Remote-Console eines Servers aus dem Internet absichert. Läuft halt nicht viel drauf, nur OpenVPN und sshd. Der hat sich in zwei Jahren Betrieb einmal aufgehangen. Da er in einem Rechenzentrum ist, wo normalerweise niemand vor Ort ist, haben wir ihn nur vom Personal powercyceln lassen und nicht versucht, irgendwas zu analysieren. Ist allerdings jetzt kein "heißer Scheiß", irgendein alter 2er Pi.
Wir haben im Unternehmen seit Jahren ein paar Pis mit Browser an Präsentationsbildschirmen im Dauereinsatz laufen. Funktioniert recht gut, ist aber natürlich keine kritische Anwendung.
:
Bearbeitet durch User
Le X. schrieb: > Ich nutze den Pi auch nicht mehr für Always-On-Scenarien, aus den von > dir geschilderten Gründen. Naja kann man nicht generell sagen. Ich habe 3 Pi's headless (2x Wetterstation, 1x Überwachung der E-Anlage) 24/7 am laufen und die tun klaglos. Vielleicht ist ja auch auch die SDR-Software und SW zum Rendern der Satellitenbilder anspruchsvoller. Könnte aber auch das für's SDR zuständige Kernelmodul Probleme machen. Ich habe die Ursache leider nicht wirklich finden können. Irgendwann habe ich aufgegeben - man muß ja auch mal zu Potte kommen. Jörg W. schrieb: > Ob das irgendwo an den verwendeten Programmen liegt? Naja das vermute ich halt auch. Es wird wohl nicht an den Programmen selbst liegen, sondern wohl eher am RPi selbst. Ob da die Rechenleistung nicht ausreichend ist oder einfach das Systemdesign nicht passt - ich hab's nicht heraus gefunden. Der BPI tut klaglos, allerdings sind Support, Distris und auch die Community eher mäßig. Hinzu kommt das einige Seiten von Sunxi für den Durchschnittseuropäer eher nicht lesbar sind.
(prx) A. K. schrieb: > Wir haben im Unternehmen seit Jahren ein paar Pis mit Browser an > Präsentationsbildschirmen im Dauereinsatz laufen. Funktioniert recht > gut, ist aber natürlich keine kritische Anwendung. Ist ja nicht weiter spektakulär und da denke ich das das der RPi problemlos macht. Wie gesagt bei meiner Wetterstation läuft er ja auch problemlos. Aber da ist halt auch nicht viel drauf. Ein kleines Progrämmle zum Auslesen der Daten und RRD-Tool. Das Ganze wird mit einem Cronjob und einem Shellscript gesteuert.
Zeno schrieb: > Ob da die Rechenleistung nicht ausreichend ist oder einfach das > Systemdesign nicht passt - ich hab's nicht heraus gefunden. Wenn er natürlich mächtig rechnen muss, kann es sein, dass er dann überhitzt? Das würde zumindest "Aufhängen" erklären (und ist natürlich nicht dem OS anzulasten). Solche Probleme hatten wir zumindest bei den (sehr billigen) Nano-Pis. War extrem exemplarabhängig.
Zeno schrieb: > Das läßt vermuten das der Fehler irgendwo in den Tiefen des Systems > sitzt. In der Community ist dieser Fehler durchaus bekannt, allein es > hapert an einer passablen Lösung. Probier doch mal ne neue SD-Karte, wirst es nicht glauben:"hat mich auch geholfen". Ahjo, die 16GB Karte bei mir war einfach am ende. Seltsame Sache, aber seit ich das ganze neu auf eine frische 32GB geschrieben habe, war auch die /var/lib/openwebrx/settings.json an ihrem Platz. Der gleiche Versuch auf die alte 16GB Karte blieb erfolglos! Seit ich dazu im Bereich SDR noch "device":"hw:FiFiSDR,DEV=0", stehen habe funktioniert das alles wie es soll. Tja, so einfach kann's sein.
Ein T. schrieb: > Verzeihung, aber das ist wohl ein Problem von Openwebrx, oder? Nein, war ein defektes Speichermedium. Jetzt läuft es gut, selbst die CPU Last ist mit dem Raspi 2b+ niedriger als mit dem RTL.
Jörg W. schrieb: > Wenn er natürlich mächtig rechnen muss, kann es sein, dass er dann > überhitzt? Ich habe mal zu TEstzwecken ein umfangreiches Logging implementiert und da so Sachen wie CPU-Auslastung, Betriebsspannung, Temperaturen und was man sonst so noch auslesen kann mal mit protokolliert. Da waren keine Auffälligkeiten. Die Abstürze passierten auch nicht unbedingt wenn das Teil mit dem Empfang und Rendern von Satellitenbildern beschäftigt war, das konnte man an Hand des letzten Eintrags im Logfile sehen. Es ist bekannt das der Pi gelegentlich Probleme mit dem bei neueren Linux benutzten Devicetree hat und der im Pi verbaute Broadcomchip auch ab und an Zicken macht. Ersteres kann man beim Pi ja problemlos abschalten. Habe ich gemacht und da war dann auch ne leichte Besserung feststellbar. Ich tippe mal auf das Kernelmodul für SDR-Chip. Vielleicht kommt dieser auch nur nicht mit dem benutzten SDR-Stick klar. Ich weis es nicht. Mit dem Banana Pi läuft es jetzt. Nun soll der halt noch eine kleine Zusatzaufgabe übernehmen und ein paar DS1820 abfragen. Prinzipiell läft das ja jetzt auch auf einem BPI zum Testen, aber mich stört eben noch der Fehler mit dem "Timeout Sync SD-Card". Ich hätte es gern das es glatt läuft, damit ich mich auf das Ganze auch verlassen kann. Irgendwann werde ich es schon hin gefrickelt bekommen. Frickeln ist ja nicht unbedingt negativ, zumindest dann nicht wenn man bereit ist sich mit der Materie zu beschäftigen. Aber eben nicht für den Normaluser der will sein System einfach nur benutzen und nicht Tage damit zubringen den Drucker oder die Graka einzurichten.
Kilo S. schrieb: > Probier doch mal ne neue SD-Karte, wirst es nicht glauben:"hat mich auch > geholfen". Ich habe mehr als eine probiert. Im finalen System wird die eh nur noch zum Booten gebraucht, da das Rootsystem auf einer SSD ist, was ja beim BPI M2U mit SATA-Anschluß kein Problem ist.
Zeno schrieb: > Ich tippe mal auf das Kernelmodul für SDR-Chip. Gut möglich. Ein Kerneltreiber hat natürlich schon das (Fehler-)Potenzial, einen System-Hänger zu produzieren. > Vielleicht kommt dieser > auch nur nicht mit dem benutzten SDR-Stick klar. Die Teile sind ja nun auch nicht gerade die allertollsten Qualitätsprodukte – das meine ich jetzt weniger hinsichtlich der Verarbeitung, sondern auch der verwendeten ICs.
Zeno schrieb: > Karl Käfer schrieb: >> Das ist dann wohl ein Problem mit diesen BPI-Tools, oder? > Nö, wenn es bei der installierten Distribution die Dateien nicht gibt > können die BPI-Tools wenig dazu. Also wenn es sich um diese (https://github.com/BPI-SINOVOIP/bpi-tools) bpi-tools handelt, sehe ich da nichts von "fex"-Dateien. Diese Dokumentation hier (https://linux-sunxi.org/Fex_Guide) weist jedoch darauf hin, daß diese "fex"-Dateien wohl ein Vorläufer des modernen "Device Tree" sind, wozu die Seite des Herstellers diese (https://linux-sunxi.org/Device_Tree), diese (https://linux-sunxi.org/New_Device_page) und diese (https://linux-sunxi.org/New_Device_howto) Dokumentation anbietet, wenn ich das richtig verstanden habe. Keine Ahnung, ob Dir das hilft, aber vielleicht findest Du auf den Seiten oder den Links darin eine Information, die Dein Problem beheben könnte. > Ist mir egal was da am End nicht funktioniert - es funktioniert nicht > obwohl es auf dem Pi, gegen die passenden Kernelheader kompiliert wurde. Auch dazu habe ich auf einer der oben verlinkten Seiten etwas gefunden, die erste davon sagt: "Note: The mainline Linux kernel makes no use of FEX / script.bin, and relies on the device tree model instead (.dtb files)." > Karl Käfer schrieb: >> Nebenbei bemerkt gibt es im Linux-Kernel schon seit vielen Jahren ein >> Modul für Onewire. Es heisst w1 und ich selbst habe es schon mehrmals >> sowohl auf x86-Rechnern und auf dem RasPi erfolgreich eingesetzt > Ist mir bekannt und funktioniert auch auf mehreren Pi's bei mir. > BananaPi ist aber nicht gleich RaspberryPi - da gibt es einige > Unterschiede, das geht schon bei der Defaultfunktion der GPIO-Pins los. Hm, okay, ich benutze Onewire nur mit einem USB-Master (DS9490R), bei GPIOs ist mir die ganze Sache mit dem Timing bei OneWire zu kritisch. Aber wie dem auch sei: Du verwendest da anscheinend ein Kernelmodul von einem Drittanbieter auf einem System, dessen Hersteller nach meinem Eindruck keine besonders gute Dokumentation anbietet, und hälst das für ein Linux-Problem? Ich meine, Du hattest Dich in diesem Thread ja an einer Stelle eingeschaltet, als es um angebliche oder reale Linuxprobleme ging. Was die Fehlersuche auf dem RasPi angeht, so empfehle ich, einmal dessen serielle Konsole einzuschalten und an einen Rechner anzuschließen, der deren Ausgaben loggt. So bin ich mal einem RasPi 1 auf die Schliche gekommen, dessen Kernel unregelmäßig so hart einfror, daß er nicht einmal mehr auf die SD-Karte schreiben konnte. Mit der seriellen Konsole bin ich dahinter gekommen, es war das Kernelmodul eines TP-Link TL-WN321G, den ich wegen des externen Antennenanschlusses verwendet habe. Ein Tausch dieses Adapters hat den Fehler dann behoben, seitdem läuft der RasPi störungsfrei.
Zeno schrieb: > Naja kann man nicht generell sagen. Ich habe 3 Pi's headless (2x > Wetterstation, 1x Überwachung der E-Anlage) 24/7 am laufen und die tun > klaglos. Vielleicht ist ja auch auch die SDR-Software und SW zum Rendern > der Satellitenbilder anspruchsvoller. Ach ja, da fällt mir noch etwas ein. Unter den meisten Linuxsystemen (und vielen UNIXen) gibt es den System Activity Reporter, unter Linux im Paket sysstat. Der beinhaltet ein Programm, das in regelmäßigen Abständen die Performancecounter des Kernels ausliest und unter /var/log/sysstat in Binärdateien loggt, die dann mit dem Frontend sar(1) und / oder dem Programm sadf(1), welches zusätzliche Ausgabeformate wie XML und JSON anbietet, ausgelesen und angezeigt (oder weiterverarbeitet) werden können. Ich habe recht gute Erfahrungen damit gemacht, mir mit sadf(1) JSON-Daten ausgeben zu lassen, die in ein Elasticsearch zu schreiben und mit Kibana anzusehen, aber es gibt natürlich noch unzählige weitere Möglichkeiten. Um Performanceproblemen auf die Spur zu kommen, kenne ich nichts Besseres, auch wenn die Bedienung und die Konzepte oft an jene klassischen UNIX-Werkzeuge erinnern, von denen sie abgeschaut worden sind. HTH!
Kilo S. schrieb: > Ein T. schrieb: >> Verzeihung, aber das ist wohl ein Problem von Openwebrx, oder? > > Nein, war ein defektes Speichermedium. Dann, Verzeihung, verstehe ich auch in diesem Falle nicht ganz, warum Du das an einer Stelle erwähnt hast, als es um angebliche oder reale Linuxprobleme ging. Für defekte Hardware kann man doch wohl kaum das Betriebssystem verantwortlich machen?
Zeno schrieb: > Irgendwann werde ich es schon hin gefrickelt bekommen. Frickeln ist ja > nicht unbedingt negativ, zumindest dann nicht wenn man bereit ist sich > mit der Materie zu beschäftigen. Aber eben nicht für den Normaluser der > will sein System einfach nur benutzen und nicht Tage damit zubringen den > Drucker oder die Graka einzurichten. Naja, sorry, aber "Normaluser" werden sicherlich keine exotische SBC-Hardware aus China kaufen und darauf Dinge wie SDR betreiben, und ebensowenig werden sie eine uralte und vom Hersteller nicht mehr unterstützte Grafikkarte betreiben wollen.
Karl Käfer schrieb: > Ach ja, da fällt mir noch etwas ein. Unter den meisten Linuxsystemen > (und vielen UNIXen) gibt es den System Activity Reporter, unter Linux im > Paket sysstat. Der beinhaltet ein Programm, das in regelmäßigen > Abständen die Performancecounter des Kernels ausliest und unter > /var/log/sysstat in Binärdateien loggt ... Wurde alles gemacht. Das Ganze hat mich ein gutes jahr beschäftigt. Wasa es am Ende war weis ich nicht ist mir auch egal, da mit dem BananaPi das Problem behoben ist. Dafür gibt es jetzt ein anderes Problem. Bin zwar an der Lösung dran, aber es ist halt zerrig. Das man Kernelmodule nach dem Kompilieren nicht mehr laden kann habe ich noch nie gehabt. Es betrifft alle Kernelmodule. Ich habe ja auch schon den Kernel neu kompiliert. Bekomme ihn aber nicht wirklich ans Laufen. Mittlerweile ist der Kram bei den Pi's so unübersichtlich geworden, das es eben nicht mehr ausreicht den Kernel auszutauschen. Trotzdem sage ich mal danke für Deine Mühe. Karl Käfer schrieb: > Du verwendest da anscheinend ein Kernelmodul von > einem Drittanbieter auf einem System, dessen Hersteller nach meinem > Eindruck keine besonders gute Dokumentation anbietet Das Kernelmodul ist schon in Ordnung, habe das ja auch auf einer anderen Distri (auf mehreren Pi's) problemlos zum Laufen bekommen. Das Problem ist bei diesen Distris das Thema mit dem "Timeout sync SD-card" beim Shutdown. Da dieses Problem auch z.B. bei fdisk auftritt möchte ich halt damit nicht ein System betreiben welches 24/7 laufen soll. Ich befürchte das da noch andere Ungereimtheiten sind und ich damit mir andere Probleme einhandle. Das Problem beim BananaPi, speziell beim M2U, ist halt auch das man da nicht sonderlich wählerisch sein kann. Da gibt es einige Sonderanpassungen am OS, wo ich nicht mehr durch sehe.
Karl Käfer schrieb: > Naja, sorry, aber "Normaluser" werden sicherlich keine exotische > SBC-Hardware aus China kaufen und darauf Dinge wie SDR betreiben, und > ebensowenig werden sie eine uralte und vom Hersteller nicht mehr > unterstützte Grafikkarte betreiben wollen. Hör doch endlich mal mit dieser Leier auf. Wenn's unter Linux nicht läuft ist entweder die HW exotisch oder veraltet. Dabei wird doch von den Fanboys immer wieder betont wie toll doch die Unterstützung von Linux für ältere HW ist. Nein sie ist es nicht und am Ende ist Linux nicht besser als jedes andere OS - eben nur anders. Auf so kleinen Bretteln wie den Pi's, egal ob Raspi, Orange, Banana und wie sie alle heißen hat man halt keine Wahl. Da gibt es im wesentlichen nur Linux oder Android und bei letzterem kommt man vom Regen in die Jauche. Nei Linux hat natürlich seine Schwächen und die tun sich nur Leute an die um das System nicht drum herum kommen oder die im unixoiden Umfeld groß geworden sind. Denk einfach mal darüber nach warum Linux im Desktopbereich bei knapp 2% rum dümpelt.
Zeno schrieb: > Denk einfach mal darüber nach warum Linux im Desktopbereich bei knapp 2% > rum dümpelt. Das Thema ist doch mehr als ausgelutscht: weil auf 98% der an Consumer verkauften Rechnern Windows vorinstalliert ist, es so für die meisten der heutigen Nutzer der erste Kontakt mit der Maschine war, es für die meisten „Nur-Anwender“ keinen Grund gab, das System zu wechseln und sie sich eben an Windows gewöhnt haben. Umlernen ist etwas, das $Mensch äußerst schwer fällt, viel schwerer, als etwas Neues zu lernen, und deswegen ist’s für manche Leute, denen es mit Win10 oder Win11 dann doch tatsächlich mal mit der Bevormundung reicht, trotzdem nicht möglich, auf ein anderes System zu wechseln. Nicht, weil das andere System komplizierter oder auch nur schlechter wäre, sondern weil es anders ist.
Jack V. schrieb: > deswegen ist’s für manche Leute, denen es mit > Win10 oder Win11 dann doch tatsächlich mal mit der Bevormundung reicht Die wechseln dann auf Mac. ;-)
(prx) A. K. schrieb: >> deswegen ist’s für manche Leute, denen es mit >> Win10 oder Win11 dann doch tatsächlich mal mit der Bevormundung reicht > Die wechseln dann auf Mac. ;-) Was allerdings nicht weniger Umlernen ist, wenn man von Windows kommt …
Jack V. schrieb: > Das Thema ist doch mehr als ausgelutscht: weil auf 98% der an Consumer > verkauften Rechnern Windows vorinstalliert ist, es so für die meisten > der heutigen Nutzer der erste Kontakt mit der Maschine war, es für die > meisten „Nur-Anwender“ keinen Grund gab, das System zu wechseln und sie > sich eben an Windows gewöhnt haben. Ja, und man sollte die Leute auch in Ruhe lassen mit ihrem Windows. Wenn der Nachbar wieder kommt, seinen vom Nachwuchs ruinierten Rechner geradebiegen zu lassen, spart man mit der Antwort "bei Windows kann ich Dir nicht helfen, ich habe Linux" eine Menge Arbeit. > Umlernen ist etwas, das $Mensch äußerst schwer fällt, viel schwerer, als > etwas Neues zu lernen, und deswegen ist’s für manche Leute, denen es mit > Win10 oder Win11 dann doch tatsächlich mal mit der Bevormundung reicht, > trotzdem nicht möglich, auf ein anderes System zu wechseln. Nicht, weil > das andere System komplizierter oder auch nur schlechter wäre, sondern > weil es anders ist. Dann ist der Leidensdruck nicht hoch genug. Nur weil bei Windows etwas anders ist als bei Linux, ist noch lange gesagt, daß es bei Windows richtiger wäre.
Jack V. schrieb: > Das Thema ist doch mehr als ausgelutscht: weil auf 98% der an Consumer > verkauften Rechnern Windows vorinstalliert ist, ... Die Antwort ist nicht weniger ausgelutscht - schuld sind immer die anderen. Also nichts neies.
Willi schrieb: > ist noch lange gesagt, daß es bei Windows > richtiger wäre. Hat auch niemand behauptet, denn wie schrieb ich: Zeno schrieb: > am Ende ist Linux > nicht besser als jedes andere OS - eben nur anders. Es gibt halt nur einen Unterschied zwischen den Systemen : Kein System hat so viele Fanboys, die sich bei jeder Kritik an ihrem ach so tollen System gleich angepisst fühlen.
Jörg W. schrieb: >> Die wechseln dann auf Mac. ;-) > > Was allerdings nicht weniger Umlernen ist, wenn man von Windows kommt … Was sich aber in Grenzen hält. An den Grundfesten des Systems muß da definitiv keine Hand anlegen, das System funktioniert halt einfach. Das und die Stabilität sind ganz gewiß auch der Tatsdache geschuldet, das Mac eben nicht jede x-beliebige HW unterstützt. Man muß sich halt beim Kauf schon entscheiden was man HW haben möchte, denn Nachrüsten des Rechners selbst ist mittlerweile nicht mehr möglich. Dafür erhält man im Gegenzug ein sehr stabiles System. Natürlich ist auch nicht alles Gold was glänzt und auch beim Mac gibt es Dinge die nicht so gut gelöst sind und wo man sich fragt was hat man sich dabei gedacht.
Zeno schrieb: > An den Grundfesten des Systems muß da definitiv keine Hand anlegen, das > System funktioniert halt einfach. An den Grundfesten des Systems muss man allerdings auch bei halbwegs brauchbarer Hardware und einer gängigen Linux-Distro keine Hand anlegen. Die funktioniert genauso einfach. Fummelig wird es nur, wenn man diesen Pfad verlässt (wie eben bei den SDR-Sticks). > Das und die Stabilität sind ganz gewiß > auch der Tatsdache geschuldet, das Mac eben nicht jede x-beliebige HW > unterstützt. Sehe ich auch so. Wenn Linux (oder andere Opensource-Systeme) nur auf so stark eingegrenzter Hardware laufen würden, würde sich erstens jeder drüber aufregen :-), und zweitens wären sie da genauso felsenfest. Allerdings läuft eben eine popelig-billige USB-Webcam (die einzige, die ich in der Corona-Lockdownzeit unter 100 Euro ergattern konnte) zwar problemlos an einem Linux, mit dem nötigen Lesen der Doku unter FreeBSD, aber schlicht und ergreifend gar nicht am Mac. Wenn man Facetime damit starten will, rödelt es herum und tut nichts, bis man sie entnervt aus dem USB-Slot rauszieht … ist halt keine von Apple zertifizierte Hardware. (Habe noch nicht versucht, den USB-Analyzer drauf anzusetzen. Ist auch nicht so wichtig, es gibt ja 'ne ordentliche eingebaute Kamera.) Ansonsten wirkt das System in sich "schlüssig", was ja letztlich (aufgrund entsprechender Design Guides etc.) bei Apple schon immer so war. Wenn man sich bei Opensource auf nur ein Desktopsystem festlegt (ob nun Gnome oder KDE spielt nicht die große Rolle), ist das dort durchaus ähnlich, bei Windows wirkt manches irgendwie "gestückelt" dagegen. Beim Touchpad setzen Macbooks schon seit 10 Jahren einen Standard für gute Bedienbarkeit, eine Maus braucht man am Mac eigentlich nur, wenn man CAD bedienen will.
Jörg W. schrieb: > Wenn man sich bei Opensource auf nur ein Desktopsystem festlegt > (ob nun Gnome oder KDE spielt nicht die große Rolle), ist das dort > durchaus ähnlich, bei Windows wirkt manches irgendwie "gestückelt" > dagegen. Es geht gar nicht so sehr darum ob ein oder 2 Desktopsysteme, oder gar noch ein drittes was mit wenig Systemressourcen zurecht kommt. OSS krankt meiner Meinung nach daran, das es zwar sehr viele gute Ideen und Ansätze gibt, die dann leider oftmals halbherzig umgesetzt werden oder auf halber Strecke stehen bleiben. Hinzu kommt dann noch, das einige in der Szene die Nase recht hoch tragen und jeglichen kritischen Hinweis ignorieren. Am Ende schadet das der gesamten OSS-Szene, was eigentlich schade ist, da dort doch ein beachtliches Potenzial vorhanden ist. Es wäre halt schon wichtig das Ganze irgendwie zu bündeln und zu kanalisieren. Ich habe allerdings auch keine Lösung parat wie man da gewisse Standards schaffen kann, aber es wäre halt schon nötig das man dies tut. Debian und die Free BSD Szene machen es eigenlich vor. Da läßt man sich mit neuen Releases eher Zeit und setzt dafür auf Stabilität. Manches ist dort vielleicht nicht so schick und wirkt vielleicht eher etwas altbacken, aber es funktioniert eben.
Eigentlich hatte ich Macs ja bloss erwähnt, weil Apple längst dort ist, wo Microsoft hinsichtlich Bevormundung hin will. ;-)
Zeno schrieb: > Das man Kernelmodule nach > dem Kompilieren nicht mehr laden kann habe ich noch nie gehabt. Es > betrifft alle Kernelmodule. Ich kann mich da dunkel an zwei Vorfälle erinnern, die sind aber lange her. Wenn ich mich richtig erinnere, war es einmal ein Wechsel des Compilers und damit auch des Binärformates (a.out auf ELF?) und bei dem anderen Mal wurde nicht die richtige Symboltabelle benutzt. Es kann aber auch sein, dass mich meine Erinnerungen trügen, das ist nur Stochern im Nebel. > Ich habe ja auch schon den Kernel neu > kompiliert. Bekomme ihn aber nicht wirklich ans Laufen. Das sollte natürlich auch nicht passieren. Sehr seltsam, was ist denn passiert? > Trotzdem sage ich mal danke für Deine Mühe. Immer gern, kein Thema. > Karl Käfer schrieb: >> Du verwendest da anscheinend ein Kernelmodul von >> einem Drittanbieter auf einem System, dessen Hersteller nach meinem >> Eindruck keine besonders gute Dokumentation anbietet > > Das Kernelmodul ist schon in Ordnung, habe das ja auch auf einer anderen > Distri (auf mehreren Pi's) problemlos zum Laufen bekommen. Also mit dem Kernel dieses Sunxi-Linux für den BananaPis scheint jedenfalls irgend etwas ein bisschen... merkwürdig zu sein, oder siehst Du das anders? Wer weiß, was die an dem Mainline-Kernel herumgebastelt haben, damit er auf ihren Boards läuft. > Das Problem > ist bei diesen Distris das Thema mit dem "Timeout sync SD-card" beim > Shutdown. Da dieses Problem auch z.B. bei fdisk auftritt möchte ich halt > damit nicht ein System betreiben welches 24/7 laufen soll. Ich befürchte > das da noch andere Ungereimtheiten sind und ich damit mir andere > Probleme einhandle. Klar, das verstehe ich gut. Andererseits benötigt ja gerade OneWire ein äußerst präzises Timing. Mir ist unklar, wie das von diesem Kernelmodul gemacht wird. Die nach meiner Erinnerung übliche Vorgehensweise wäre es, eine Task (tq_struct) mit einem Zeiger auf die auszuführende Funktion zu bauen und diese mit queue_task() in die Struktur tq_timer einzuklinken, so dass sie dann beim nächsten Timer-Interrupt ausgeführt und dann aus tq_timer entfernt wird. Für periodische Tasks muss der Task seine tq_struct dann wieder mit queue_task() in tq_timer hängen, um beim nächsten Timer-Interrupt wieder ausgeführt zu werden. Wie oben schon erwähnt, ist das OneWire-System ziemlich empfindlich hinsichtlich seines Timings, weswegen ich erwarten würde, dass die Entwickler eines solchen Kernelmoduls dasselbe sehr häufig ausführen wollen. Ähnliches gilt womöglich -- darin kenne ich mich allerdings gar nicht aus -- auch für das Kernelmodul Deiner SDR-Hardware. Aber wenn eine oder beide meiner Vermutungen zutreffen, dann kann es natürlich sein, dass die Module zusammen die Last innerhalb des Kernels so erhöhen, dass der I/O-Scheduler nicht immer genug Zeit bekommt, seine Arbeit vor dem Ablauf eines Timeout zu erledigen. Das ist zwar auch nur Stochern im Nebel, aber vielleicht hilft es ja. > Das Problem beim BananaPi, speziell beim M2U, ist halt auch das man da > nicht sonderlich wählerisch sein kann. Da gibt es einige > Sonderanpassungen am OS, wo ich nicht mehr durch sehe. Ja, scheint so. Dass ich beim Nachschauen in den Sunzi-Materialien hin und wieder auch chinesische Schriftzeichen in den Kommentaren gesehen habe, macht die Sache obendrein sicher nicht gerade einfacher. :-(
Zeno schrieb: > Hör doch endlich mal mit dieser Leier auf. Wenn's unter Linux nicht > läuft ist entweder die HW exotisch oder veraltet. Bitte entschuldige, aber genau so ist es doch. Single-Board-Computer mit Linux sind ohnehin nicht allzu weit verbreitet, und unter diesen seltenen Exemplaren sind die Raspberry Pi wohl die mit Abstand verbreitetsten. Alternative SBCs wie der BananaPi, aber auch der OrangePi, die Modelle von Odroid und Ähnliche sind sogar unter den SBC nochmals exotischer. Und Du siehst ja selbst, dass da anscheinend merkwürdige Dinge mit dem Kernel gemacht werden, und zumindest auf Deinem BananaPi manche Dinge nicht funktionieren, die es anderswo klaglos tun. Nur wenig anders gelagert sehe ich Deine Probleme mit einer Grafikkarte, die ihren Zenit schon seit einer Weile überschritten hat und deren Hersteller auf der einen Seite beschlossen hat, den Support dafür einzustellen, und auf der anderen Seite (bis vor kurzem) an der Entscheidung festgehalten hat, den Kernelentwicklern keine Informationen zur Entwicklung freier Kernelmodule zu geben. Soweit ich weiß, sind Linux und die Kernelentwickler weder für diese Entscheidungen von Nvidia noch dafür verantwortlich, daß Du die Grafikkarte trotz ihres EOL-Status partout nicht gegen eine unterstützte austauschen magst. Nicht böse sein, aber da sehe ich das Problem vor allem in dem Zusammentreffen der kritikwürdigen Entscheidungen seitens Nvidia mit Deinem Dickkopf. Ich sehe nicht, daß das ein Linuxproblem wäre, zumal so etwas auch unter anderen Systemen passieren kann und es bereits geschehen ist, dass ein Hardwarehersteller seine Unterstützung einstellt und eine funktionsfähige Hardware dadurch schwer bis gar nicht mehr brauchbar gemacht hat. > Dabei wird doch von > den Fanboys immer wieder betont wie toll doch die Unterstützung von > Linux für ältere HW ist. Solche Fanboys kenne ich nicht und kann mich deshalb auch nicht dazu äussern, was diese Menschen betonen oder nicht. Was ich allerdings weiss, ist, daß Linux hier wunderbar auf mehreren älteren Rechnern läuft. Aber das bedeutet natürlich nicht, dass Linux auf jedem alten Rechner mit jeder Hard- und Softwarekombination und -Konfiguration funktioniert. Das wäre zwar schon, unterliegt aber Sachzwängen wie den Entscheidungen mancher Hard- und Softwarehersteller. Und, wie im oben bereits angesprochenen Fall, auch des Benutzers. > Nein sie ist es nicht und am Ende ist Linux > nicht besser als jedes andere OS - eben nur anders. Das kann man sicherlich aus unterschiedlichen Perspektiven sehen, die zwangsläufig aber auch von den eigenen Sichtweisen und Vorlieben abhängen. Ich persönlich sehe deswegen sicherlich einige Vorteile von Linux, die andere nicht sehen oder die für sie unwichtig sind. Richtig ist jedoch, dass Linux kein Wunderheilmittel für alle Wehwehchen ist und vermutlich auch niemals sein wird. Dasselbe gilt aber auch für alle anderen mir bekannten Betriebssysteme. > Nei Linux hat natürlich seine Schwächen und die tun sich nur Leute an > die um das System nicht drum herum kommen oder die im unixoiden Umfeld > groß geworden sind. Aber es hat eben auch seine Stärken, die sich vielen "normalen Benutzern" -- also jener überwiegenden Mehrheit, die keine größeren Anforderungen an ihren Rechner und ihr System haben -- nicht erschliessen. Na und? Ich kann damit sehr gut leben. > Denk einfach mal darüber nach warum Linux im Desktopbereich bei knapp 2% > rum dümpelt. Du meinst, dass das nicht daran liegt, dass Windows auf 99% der verkauften Rechner bereits vorinstalliert und offenbar zumindest gut genug ist, dass ein Grossteil seiner Nutzer sich zwar hie und da nach einer Alternative sehnt, der Leidensdruck aber nur bei sehr wenigen gross genug ist, sich dann wirklich auf eine Alternative mit einer bisweilen schmerzhaften Umstellung einzulassen? Du meinst, es bestehe kein Zusammenhang mit der Tatsache, dass 90% der Anwender noch nie bewusst was von Linux gehört haben und sogar die, die es haben, es fast alle nur mit Servern und seltener auch mit Embedded-Geräten assoziieren? Und Du meinst, dass auch die Tatsache, dass manche Hard- und Softwarehersteller ein eher... distanziertes Verhältnis zu Linux haben und ihre Produkte weder dafür anbieten wollen, noch die Community bei der Entwicklung kompatibler, linuxfähiger Produkte unterstützen wollen? Entschuldige, aber... wenn Linux so schlecht wäre, wie Du suggerierst, dann hätte es vermutlich kaum nahezu den kompletten Server- und einen Grossteil des Embedded-Marktes übernommen, und wäre nicht auf dem Mars gelandet. Und wenn es wirklich so schlecht wäre, wie Du suggerierst: warum willst Du es dann benutzen, und warum machst Du es nicht einfach besser, wenn Du seine Schwächen so genau kennst? Linux ist schließlich OpenSource-Software, und die lebt bekanntlich vom Mitmachen. Mit Deiner Expertise wärst Du der Community bestimmt sehr herzlich willkommen.
(prx) A. K. schrieb: > Jack V. schrieb: >> deswegen ist’s für manche Leute, denen es mit >> Win10 oder Win11 dann doch tatsächlich mal mit der Bevormundung reicht > > Die wechseln dann auf Mac. ;-) Die Macs sind immerhin deutlich bekannter als Linux-Rechner, und Apple macht sogar Werbung für seine Macs. Hast Du schon einmal Werbung für Linux gesehen, vor allem: Werbung für Linux auf dem Desktop? Die gibts nichtmal auf dem Linux-Magazin.
Zeno schrieb: > Jörg W. schrieb: >>> Die wechseln dann auf Mac. ;-) >> >> Was allerdings nicht weniger Umlernen ist, wenn man von Windows kommt … > Was sich aber in Grenzen hält. > An den Grundfesten des Systems muß da definitiv keine Hand anlegen, das > System funktioniert halt einfach. Das kommt darauf an, was man damit machen möchte. Jüngst habe ich Teilnehmer eines Lehrgangs dabei unterstützt, Python, Pandas, Seaborn, Plotly Express, PySpark, Mongodb, R, Rstudio und einige weitere Pakete zu installieren. Herrje... ganz so einfach, wie Du denkst, ist das auf den Macintoshes leider auch nicht immer.
Jörg W. schrieb: > Allerdings läuft eben eine popelig-billige USB-Webcam (die einzige, die > ich in der Corona-Lockdownzeit unter 100 Euro ergattern konnte) zwar > problemlos an einem Linux, mit dem nötigen Lesen der Doku unter FreeBSD, > aber schlicht und ergreifend gar nicht am Mac. Das habe ich jüngst auch mit einer billigen Webcam unter Windows erleben müssen. Meine Liebste hatte von mir eine Logitech C920 bekommen und wollte sie an ihrem Windows10 betreiben. Leider mussten wir feststellen, dass Microsoft mittlerweile keines der Videoformate mehr unterstützen wollte, die die Webcam liefert, und das Netbook meiner Liebsten leider zu wenig Leistung hat, um den Videostream live umzurechnen. Sehr ärgerlich, sie benutzt jetzt meinen alten Dell E6530 -- unter Kubuntu Linux läuft das neun Jahre alte Maschinchen mit dieser Webcam perfekt!
Beitrag #7097538 wurde vom Autor gelöscht.
Karl Käfer schrieb: > Jüngst habe ich Teilnehmer eines Lehrgangs dabei unterstützt, Python, > Pandas, Seaborn, Plotly Express, PySpark, Mongodb, R, Rstudio und einige > weitere Pakete zu installieren. Das sind ja nun aber nicht gerade die "Grundfesten des Systems" – egal auf welchem System. Unter MacOS würde man für sowas entweder zu Homebrew oder Macports greifen.
Karl Käfer schrieb: > Meine Liebste hatte von mir eine Logitech C920 bekommen und > wollte sie an ihrem Windows10 betreiben. Die lächelt mich stets an, wenn ich mich an den Firmen-PC setze und tut in Windows 10, was sie tun soll. Ist freilich nicht mehr der jüngste, der zuständige Microsoft-Treiber, denn der ist von 2006.
:
Bearbeitet durch User
Jörg W. schrieb: > Unter MacOS würde man für sowas entweder zu Homebrew > oder Macports greifen. So ist es. Karl Käfer schrieb: > Das kommt darauf an, was man damit machen möchte. Jüngst habe ich > Teilnehmer eines Lehrgangs dabei unterstützt, Python, Pandas, Seaborn, > Plotly Express, PySpark, Mongodb, R, Rstudio und einige weitere Pakete > zu installieren. Herrje... ganz so einfach, wie Du denkst, ist das auf > den Macintoshes leider auch nicht immer. Das sind aber alles Dinge die der Standard-Mac-User i.d.R nicht verwendet. Das was Du da beschreibst hört sich irgenwie nach Pythonkram an. Auf dem Mac spielt das eher eine untergeordnete Rolle. Der Mac spielt seine Stärken wohl eher im Grafik-/Designbereich aus und Leute die den Mac dafür benutzen um ihr Geld damit zu verdienen tun das professionell und setzen da auch auf professionelle SW (z.B. Photoshop). Die Leute die Softwareentwicklung machen, wissen in aller Regel wie man so etwas auf den Mac bekommt. Der Rest nutzt den Mac zum Surfen, füe E-Mail, ab und an mal ein Brieflein schreiben, Fotos verwalten und um mal in die Ferne zu glotzen. Dafür muß er nichts intallieren, da alles was dafür nötig ist bereits auf Mac installiert ist. Den Normalmacuser fühlt sich von Apple auch nicht sonderlich gegängelt, er will mit dem System einfach nur "arbeiten" und das funktioniert für den Normaluser nahezu perfekt.
Zeno schrieb: > Le X. schrieb: >> Ich nutze den Pi auch nicht mehr für Always-On-Scenarien, aus den von >> dir geschilderten Gründen. > Naja kann man nicht generell sagen. Ich habe 3 Pi's headless > ... > Ich habe die Ursache leider > nicht wirklich finden können. Irgendwann habe ich aufgegeben - man muß > ja auch mal zu Potte kommen. Anderes Netzteil getestet? Anderer Pi, gleiches Modell, getestet? (vielleicht ist das RAM defekt und der Fehler tritt nur selten auf) PI Kühlkörper verpasst? Anderes Pi Modell ausprobiert? > Jörg W. schrieb: >> Ob das irgendwo an den verwendeten Programmen liegt? > Naja das vermute ich halt auch. Es wird wohl nicht an den Programmen > selbst liegen, sondern wohl eher am RPi selbst. Ob da die Rechenleistung > nicht ausreichend ist oder einfach das Systemdesign nicht passt - ich > hab's nicht heraus gefunden. Auf dem Pi läuft halt auf dem VideoCore ein eigenes OS und über das hast du von Linux aus keine Kontrolle. Da könnte der Fehler auch liegen. Insofern ist ein RPI für always on eigentlich nicht geeignet. Da fehlen auch noch so andere Sachen, wie bspw. Redundanz bei Ausfall, ECC RAM usw.
Nano schrieb: > Insofern ist ein RPI für always on eigentlich nicht geeignet. > Da fehlen auch noch so andere Sachen, wie bspw. Redundanz bei Ausfall, > ECC RAM usw. Nicht „always on“ mit „high availability“ verwechseln. Die von dir genannten Sachen sind für Letzteres von Bedeutung. Das größte Hindernis für „always on“ wäre wohl der Verschleiß der SD-Karte, und dem kann man entgegenwirken Hier werkelt ein Pi4, der seit seiner Anschaffung im Oktober ’19 bis auf Reboots beim Kernelupdate durchgängig läuft. Ohne spezielle Maßnahmen, von SD-Karte, passiv gekühlt, mit dem ARM-Port von Arch – mag sein, dass er dafür nicht ausgelegt ist, aber Probleme gibt’s damit auch nicht.
Wie wär's mit einem Pi mit Browser im Kiosk Mode, der eine Uptime von 700 Tagen hat?
:
Bearbeitet durch User
Zeno schrieb: > Karl Käfer schrieb: >> Das kommt darauf an, was man damit machen möchte. Jüngst habe ich >> Teilnehmer eines Lehrgangs dabei unterstützt, Python, Pandas, Seaborn, >> Plotly Express, PySpark, Mongodb, R, Rstudio und einige weitere Pakete >> zu installieren. Herrje... ganz so einfach, wie Du denkst, ist das auf >> den Macintoshes leider auch nicht immer. > Das sind aber alles Dinge die der Standard-Mac-User i.d.R nicht > verwendet. > Das was Du da beschreibst hört sich irgenwie nach Pythonkram an. Auf dem > Mac spielt das eher eine untergeordnete Rolle. Für mich sieht das alles nach Software zur Datenanalyse und Visualisierung aus, und dafür sind die neuen M1-Macs mit ihrer hohen Rechenleistung geradezu prädestiniert. Wenn man im OSS-Umfeld häufiger auf Veranstaltungen unterwegs ist, sieht man dort in den letzten Jahren immer mehr Macintoshes. Offensichtlich hat sich die Zielgruppe seit MacOS/X stark vergrößert und umfaßt heute nicht mehr nur Grafiker und Musiker, sondern eben auch Entwickler. Komisch, auf der einen Seite argumentierst Du mit einem angeblichen "Standard-Mac-User", der dies oder jenes mit seinem Rechner macht oder auch nicht, während Du das auf der anderen Seite für Deine doch ziemlich speziellen Anwendungsfälle (SDR und 1-Wire, uralte hochproprietäre Grafikhardware) und Linux nicht gelten läßt -- weil irgendwelche Fanboys irgendetwas gesagt haben sollen. Ist das nicht ein bisschen inkonsistent, inkonsequent und unfair?
(prx) A. K. schrieb: > Wie wär's mit einem Pi mit Browser im Kiosk Mode, der eine Uptime von > 700 Tagen hat? Ich denke, niemand bezweifelt dass es PIs gibt die diese Uptimes haben. Tatsächlich gibt es aber auch PIs die regelmäßig neu gestartet werden müssen. Und deren Betreiber nützt es herzlich wenig wenn die einzigen Aussagen die man aus der Community kriegt regelmäßig lauten: "Probier mal ne andere SD-Karte." "Probier mal ein anderes Netzteil." "Ich weiß gar nicht was du hast, also bei meiner Oma läuft der Pi seit 1987 ohne Probleme". Wenn man hinreichend Ressourcen (Zeit und Hardware) auf den Pi wirft geht halt auch irgendwann der Preisvorteil vom Pi verloren.
Ein T. schrieb: > Offensichtlich hat sich die Zielgruppe seit MacOS/X stark vergrößert Denke ich auch. Als Jordan Hubbard (FreeBSD-Mitgründer) uns vor 18 Jahren auf dem EuroBSD-Kongress OSX vorgestellt hat (und die von ihm mit begründeten Macports), berichtete er, dass eben auch bei den Apple-Entwicklern ein Umdenken nötig war: dass ein Anwender sowas wie ein Terminal in Griffweite haben möchte, war in der vorherigen Mac-Welt ziemlich undenkbar. (Auch bei vielen Windows-Usern heißt das Ding ja "DOS-Fenster", obwohl es mit MS-DOS seit cmd.exe wahrlich nichts mehr zu tun hat.) Den Effekt sieht man wohl inzwischen: das System ist für die Standardaufgaben sehr solide und ohne Wenn und Aber praktisch von jedem benutzbar (das Festzurren auf ausgewählte Hardware macht das natürlich einfacher als bei anderen OSes). Andererseits öffnet sich einem durch die Unix-Grundlage die gesamte Welt der Opensource-Software, und zwar (in der Gesamtheit, nicht in jedem Detail) um Welten einfacher, als wenn man versucht, sowas auf Windows zu machen.
Le X. schrieb: > Wenn man hinreichend Ressourcen (Zeit und Hardware) auf den Pi wirft > geht halt auch irgendwann der Preisvorteil vom Pi verloren. Klar. Aber der Pi ist explizit als Bastelrechner konzipiert, und sich zuerst ein Bastelgerät zuzulegen und sich dann darüber zu beschweren, daß man basteln muß, erscheint mir auch ein bisschen widersinnig. Und auch sonst ist es nach meinen Erfahrungen so, daß die Qualität der Hardware signifikante Auswirkungen auf die Stabilität des Gesamtsystems hat -- you get what you pay for. Wer einen absolut stabilen Minirechner haben will, findet bei den Industriesystemen sicher etwas, das zu seinen Anforderungen paßt, aber dann natürlich zu einem anderen Preis.
Jörg W. schrieb: > Ein T. schrieb: >> Offensichtlich hat sich die Zielgruppe seit MacOS/X stark vergrößert > > Denke ich auch. Als Jordan Hubbard (FreeBSD-Mitgründer) uns vor 18 > Jahren auf dem EuroBSD-Kongress OSX vorgestellt hat (und die von ihm mit > begründeten Macports), berichtete er, dass eben auch bei den > Apple-Entwicklern ein Umdenken nötig war: dass ein Anwender sowas wie > ein Terminal in Griffweite haben möchte, war in der vorherigen Mac-Welt > ziemlich undenkbar. (Auch bei vielen Windows-Usern heißt das Ding ja > "DOS-Fenster", obwohl es mit MS-DOS seit cmd.exe wahrlich nichts mehr zu > tun hat.) Bei den DOS-basierten Windows-Systemen war die "MS-DOS Eingabeaufforderung" (damals noch command.com, IIRC) sogar noch direkt unter Start -> Programme zu finden. MS hat seinerzeit gedacht, daß Kommandozeilen ohnehin überflüssig seien und nur für eine Abwärtskompatibilität notwendig, hat sie bei den NT-basierten in Start -> Zubehör versteckt und erklärt, früher oder später wolle man dieses Relikt ganz entfernen, und ein reines grafisches System wie das damalige MacOS umsetzen. Wenige Jahre später begannen sie zu bemerken, daß viele Leute Linux und die *BSDs auch wegen seiner leistungsfähigen Kommandozeilen und der daraus resultierenden sehr guten Automatisierbarkeit benutzt haben. Auch MacOS/X kam in dieser Zeit heraus und brachte Apple-untypisch eine Kommandozeile mit. Es hat dann eine Weile gedauert -- auch wegen der engen Integration mit dem .NET-Framework -- bis bei Microsoft ein Umdenken stattfand, und sie mit der Powershell dann doch wieder eine neue und sehr viel leistungsfähigere Kommandozeilenumgebung (als cmd.exe) geliefert haben. > Den Effekt sieht man wohl inzwischen: das System ist für die > Standardaufgaben sehr solide und ohne Wenn und Aber praktisch von jedem > benutzbar (das Festzurren auf ausgewählte Hardware macht das natürlich > einfacher als bei anderen OSes). Andererseits öffnet sich einem durch > die Unix-Grundlage die gesamte Welt der Opensource-Software, und zwar > (in der Gesamtheit, nicht in jedem Detail) um Welten einfacher, als wenn > man versucht, sowas auf Windows zu machen. Auch in diesem Bereich hat Microsoft ja mittlerweile umgedacht und dem NT-Kernel beigebracht, ELF-Binaries auszuführen. Das war die Basis für das "Windows Subsystem for Linux" (WSL bzw. heute WSL2), in dem sich tatsächlich originale Binärpakete aus dem Ubuntu-Universum installieren und betreiben lassen. Das scheint auch ziemlich gut zu funktionieren -- unsere C- und C++-Entwickler kompilieren mittlerweile die Linuxversion des Rechenkernels unserer Software unter WSL2. Ob das nun dauerhaft ein Weg sein wird oder, wie ein anderer User hier vermutete, ein weiterer Angriff auf Linux nach dem Motto "lieber Kunde, nimm doch lieber Windows, da hast Du das Beste beider Welten", läßt sich aber noch nicht sagen...
Ein T. schrieb: > und sie mit der Powershell dann doch wieder eine > neue und sehr viel leistungsfähigere Kommandozeilenumgebung (als > cmd.exe) geliefert haben. Und mittlerweile hat MS auch noch ein "Windows Terminal" hinzu gefügt, u.A. um die Fenster besser zu verwalten. https://de.wikipedia.org/wiki/Windows_Terminal
Mein Backup Server ist ein RPI. Da hängen 2 Festplatten daran. Die haben keinen Anschluss für ein Netzteil. Da musste ich mit der Stromversorgung natürlich kreativ werden. Also 2 USB Netzteile genommen, und parallel geschaltet. (Ihr kennt die Kabel mit 2 USB-A und einem anderen Stecker? Die können oft nicht nur Strom zum Gerät liefern.). Seither läuft es problemlos. Vorher hat es aber auch gewarnt, zu wenig Strom, wenn man ins dmesg geschaut hat. Aber seit das gefixt wurde - nie Probleme gehabt, während Jahren. Richtige PCs brauchen halt von sich aus schon stärkere / andere Netzteile. Vermutlich kommen bei den meisten die Probleme mit dem PI nur daher. SD Karten die sich verabschieden, Systeme die sich Zerschiessen oder Aufhängen - kann durchaus alles an sowas liegen. Das hat also nichts mit Bastelsystem zutun. Professionelle PCs, die man überlastet, haben genau die gleichen Probleme. Und Software läuft da auch keine andere. Als OS hab ich Devuan drauf getan.
Ein T. schrieb: > Es hat dann eine Weile gedauert -- auch wegen der > engen Integration mit dem .NET-Framework -- bis bei Microsoft ein > Umdenken stattfand, und sie mit der Powershell dann doch wieder eine > neue und sehr viel leistungsfähigere Kommandozeilenumgebung (als > cmd.exe) geliefert haben. Nur, dass die so völlig anders ist alles alles andere (also command.com, cmd.exe, Bourne shell), dass man eigentlich nichts mehr darin wiederfindet. Selbst das simple Setzen oder Abfragen einer Environment-Variablen ist völlig anders. Warum zum Geier™ man dann auch noch in Pipes zwischen Prozessen hinein pfuschen musste und deren Datenströme "uminterpretiert", erschließt sich mir in keiner Weise. Mit der Suche danach habe ich mal einen Tag vertrödelt: beim Empfänger der Pipe kam nicht das an, was der Absender gesendet hat. (WSL) > Das scheint auch ziemlich gut zu funktionieren -- > unsere C- und C++-Entwickler kompilieren mittlerweile die Linuxversion > des Rechenkernels unserer Software unter WSL2. Nur, dass das Terminal da genauso Sch*** ist wie sonst auch unter Windows. Copy&paste ist ein purer Graus. Am einfachsten geht's halt nach wie vor unter X11, einfach mit links markieren und mit der Mitte kopieren, keine Fingerei mit Tasten. Mac geht noch, durch die von Control separate Command-Taste kollidiert halt Cmd-C nicht mit dem Ctrl-C, welches die Shell für sich braucht.
🐧 DPA 🐧 schrieb: > Richtige PCs brauchen halt von sich aus schon stärkere / andere > Netzteile. Ein M1 Macbook kann man problemlos aus einem 5V/2A-USB-Netzteil betreiben :-) (natürlich ohne die Batterie dabei zu laden), USB-C sei dank. Fand ich interessant, alle anderen Laptops wollen bei USB-C auch USB-PD unbedingt sehen.
Jörg W. schrieb: > Nur, dass die so völlig anders ist alles alles andere (also command.com, > cmd.exe, Bourne shell), dass man eigentlich nichts mehr darin > wiederfindet. Selbst das simple Setzen oder Abfragen einer > Environment-Variablen ist völlig anders. Warum zum Geier™ man dann auch > noch in Pipes zwischen Prozessen hinein pfuschen musste und deren > Datenströme "uminterpretiert", erschließt sich mir in keiner Weise. Mit > der Suche danach habe ich mal einen Tag vertrödelt: beim Empfänger der > Pipe kam nicht das an, was der Absender gesendet hat. Najaaa... also ich habe nicht allzu viel davon gesehen, aber was ich gesehen habe, war stellenweise ziemlich... unschön, in meinen Augen. Freunde von mir schwören auf das Teil und finden es toll, aber da ich weder mit Windows und deswegen schon gar nicht mit der Powershell arbeite, kann ich mir nicht wirklich ein Urteil erlauben. Aaaber... so vom Kern her finde ich die Idee, (.NET)-Objekte anstelle von einfachem PlainText zwischen den Komponenten einer Pipe zu übergeben, gar nicht so übel. Du bist doch auch so ein alter UNIX-Hase wie ich und weißt, welche Klimmzüge wir hin und wieder unternehmen müssen, damit die Textausgabe des einen Programms sauber in die Texteingabe der nächsten Komponente in der Kette ist. Das funktioniert natürlich nur, wenn man ein einheitliches Framework mit zu einander passenden Schnittstellen hat, wie Microsoft eben mit .NET. Ein anderer Aspekt, der zumindest bei der Verarbeitung größerer Datenmengen über Shellpipes eine Rolle spielen kann (ich hab's nicht gemessen), ist die Performance. Die Daten eines Programms liegen in dem Programm ja üblicherweise als Objekte oder Strukturen vor und müssen bei klassischen UNIX-Shellprogrammen erst einmal in ein Format gegossen und ausgegeben, und von dem nächsten Programm in der Pipe danach wieder eingelesen und in die internen Strukturen umgewandelt werden. Formatierung mit printf(3) ist ressourcenseitig nicht ganz billig, und sie beispielsweise mit scanf(3) oder gar über (F)Lex/{Yacc, Bison} oder einen anderen Parser wieder einzulesen ist auch ziemlich aufwändig. Keine Ahnung, wie die Powershell das genau macht (vielleicht weiß einer der Anwesenden hier ja mehr), aber bereits fertig allokierte Objekte mit Eigenschaften und Methoden als Zeiger zu übergeben, ist jedenfalls bedeutend weniger aufwändig. > Nur, dass das Terminal da genauso Sch*** ist wie sonst auch unter > Windows. Copy&paste ist ein purer Graus. Am einfachsten geht's halt nach > wie vor unter X11, einfach mit links markieren und mit der Mitte > kopieren, keine Fingerei mit Tasten. Mac geht noch, durch die von > Control separate Command-Taste kollidiert halt Cmd-C nicht mit dem > Ctrl-C, welches die Shell für sich braucht. "\(".)/" Keine Ahnung, ich arbeite nicht mit Windows und nur selten mit Macs.
Ein T. schrieb: > Aaaber... so vom Kern her finde ich die Idee, (.NET)-Objekte anstelle > von einfachem PlainText zwischen den Komponenten einer Pipe zu > übergeben, gar nicht so übel. Ich erwarte aber eben von einer Pipe, dass hinten das ankommt, was man vorn reinschiebt. Das ist bei der Powershell nicht der Fall. Ganz konkret: der Absender produziert PCAP-Daten, der Konsument soll Wireshark sein (Option -i -). Wireshark kann dann mit dem Datenmüll, den ihm die Powershell am Ende des Rohrs anbietet, schlicht nix anfangen. :-o Abhilfe: plain old cmd.exe, und voila, alles geht wie erwartet.
Zeno schrieb: > Karl Käfer schrieb: >> Naja, sorry, aber "Normaluser" werden sicherlich keine exotische >> SBC-Hardware aus China kaufen und darauf Dinge wie SDR betreiben, und >> ebensowenig werden sie eine uralte und vom Hersteller nicht mehr >> unterstützte Grafikkarte betreiben wollen. > > Hör doch endlich mal mit dieser Leier auf. Wenn's unter Linux nicht > läuft ist entweder die HW exotisch oder veraltet. Dabei wird doch von > den Fanboys immer wieder betont wie toll doch die Unterstützung von > Linux für ältere HW ist. In dem Fall hast du Unrecht, denn es ist ein Fakt, dass die Unterstützung für alte HW unter Linux besser ist, als bei Windows. Du bist hier leider Opfer des Fehlschlusses weil du hier an NVidia denkst. NVidia ist eine komplexe Ausnahme, einen Grafikkartentreiber programmiert man nicht so einfach nach, noch schwerer ist es, die Funktionsweise einer modernen GPU per reverse Engineering herauszufinden. Bei Windows laufen die wenigsten Altgeräte aus der Zeit von Windows 95,98,ME, Windows NT 4, Win2000, WinXP, Vista oder gar Win 7 unter einem modernen Windows 10 oder gar 11. Die Chancen, dass das alte Zeug unter Linux läuft ist da weitaus größer und das ist auch recht leicht an der Menge der unterstützten Treiber und Chips usw. herauszufinden. NVidida ist eine Sonderrolle, weil NVidia nie viele Infos für die GPUs rausgerückt hat. Die TDFX Treiber für Voodoo Karten laufen unter einem modernen Kernel dagegen immer noch und jetzt versuch mal eine Voodoo 3 unter Windows 10 zum Laufen zu bekommen.
Jack V. schrieb: > Nano schrieb: >> Insofern ist ein RPI für always on eigentlich nicht geeignet. >> Da fehlen auch noch so andere Sachen, wie bspw. Redundanz bei Ausfall, >> ECC RAM usw. > > Nicht „always on“ mit „high availability“ verwechseln. Letzteres meine ich mit "always on". Ein Rechner, den ich nämlich nach jedem Kernelupdate einmal reboote, ist nämlich nicht always on, sondern er ist in den n Sekunden eben nicht on. Aber ist ja auch egal, ich denke es ist klar, was damit gemeint ist. Es ergibt sich auch aus dem Kontext.
Jörg W. schrieb: > Ein T. schrieb: >> Aaaber... so vom Kern her finde ich die Idee, (.NET)-Objekte anstelle >> von einfachem PlainText zwischen den Komponenten einer Pipe zu >> übergeben, gar nicht so übel. > > Ich erwarte aber eben von einer Pipe, dass hinten das ankommt, was man > vorn reinschiebt. Das sehe ich natürlich genauso. > Das ist bei der Powershell nicht der Fall. Das weiß ich nicht, weil ich sie nicht benutze. Daher will ich mich auf Dein geschätztes (und immer sehr kompetentes) Urteil verlassen. > Ganz konkret: der Absender produziert PCAP-Daten, der Konsument soll > Wireshark sein (Option -i -). Wireshark kann dann mit dem Datenmüll, den > ihm die Powershell am Ende des Rohrs anbietet, schlicht nix anfangen. > :-o Oh, das ist natürlich großer Mist, andererseits habe ich das Gefühl, daß das kein besonders gutes Beispiel ist. Die Voraussetzung -- und eine der Kernideen der Powershell -- ist ja, daß die beteiligten Komponenten das .NET-Framework nutzen. Inwiefern Dein Absender das tut, weiß ich nicht, aber Dein Empfänger Wireshark tut das meines Wissens jedenfalls auch in der Windows-Version nicht. > Abhilfe: plain old cmd.exe, und voila, alles geht wie erwartet. Vielleicht gibt es ja einen Grund, warum Microsoft die cmd.exe immer noch nicht aus seinen Systemen entfernt hat und sie sogar noch weiterentwickelt, wie ich aus unbestätigten Quellen gehört habe. Möglicherweise weiß auch Microsoft, daß es da noch eine Menge Software in der Welt gibt, die nicht das .NET-Framework benutzt und deswegen im Zusammenhang mit der Powershell nicht richtig funktioniert? Ich weiß es nicht, aber es bezahlt mich auch niemand dafür, es zu wissen. ;-) Nichtsdestotrotz macht die anscheinend problematische Umsetzung der Powershell die Idee, Objekte statt PlainText weiterzugeben, aber doch nicht schlechter, oder?
Ein T. schrieb: > Die Voraussetzung -- und eine der Kernideen der Powershell -- ist ja, > daß die beteiligten Komponenten das .NET-Framework nutzen. Das wäre ja so, wie wenn Sun eine eigene Shell rausgebracht hätte, die dann erwartet, dass alle aufgerufenen Kommandos Java benutzen …
Ein T. schrieb: > Nichtsdestotrotz macht die anscheinend problematische Umsetzung der > Powershell die Idee, Objekte statt PlainText weiterzugeben, aber doch > nicht schlechter, oder? Viele Leute sehen irrtümlich in der Powershell eine Alternative zur Unix-Shell. Das ist aber Unfug. Wenn man kann, installiert man sich Unix-Werkzeuge die es auf verschiedenen importfreundlichen Wegen für Windows gibt, neuerdings auch WSL. Problematisch wirds, wenn man diese Möglichkeit(en) nicht hat. Man könnte sich aber anschauen, wie "Dos"-Admins/Profis arbeiten. Wenn aber jemand einen guten Workflow mit der Powershell gefunden hat, ist das vermutlich erstmal unabhängig von der Frage, wie Datentypen bzw. Datenströme verwaltet werden - vermute ich jetzt mal. Die Hintergundüberlegung, das die "Objektbezogenheit" der Powershell gewissermaßen die Modularität der Werkzeuge in der Unix-Shell ersetzt, ist eher albern - und ehrlich gesagt auch nicht sonderlich inspirierend. Interessant vielleicht eher für Leute, die mit C++, Java oder C# Schnittstellentechnisch mit der Konsole rummachen - aber so eine schöne Schnittstelle, wie beim Emacs mit Lisp gibt es da eher nicht. Aber so müsst man hier vergleichen: Ist die Powershell eine Alternative für einen Workflow mit Emacs, Lisp, Linux? Wenn man in Windows in der Powershell den ghci aufruft, und den Watcom-Vi als Editor einstellt, dann kommt da irgendwie auch (am Ende) Murks heraus. Deswegen habe ich u.a. auf Linux gewechselt, um zu schauen, ob die Haskell-Programme da besser funzen. Haskell hat natürlich noch andere Probleme, so ist das für mich nur ein kleiner Schritt. Schrittweise Optimierung sozusagen ;)
rbx schrieb: > Viele Leute sehen irrtümlich in der Powershell eine Alternative zur > Unix-Shell. Das ist aber Unfug. Das wiederum ist schade, denn ein paar nette Dinge haben sie drin, die cmd.exe nicht hat – man kann bspw. "cd ~" machen und landet in seinem Nutzerverzeichnis, sogar "pushd" gibt es, allerdings kein "dirs". Unix-Shell ist für Windows halt eben auch nicht immer so praktisch.
Jörg W. schrieb: > Unix-Shell ist für Windows halt eben auch nicht immer so praktisch. Vor allem, weil bei Windows die Werkzeuge nicht ganz so standardisiert sind, wie bei Unix. Man sucht sich halt zusammen, was man so findet, das ist nicht immer einfach, aber mit der Zeit kommt so einiges zusammen. Mit Hilfe von Cygwin kann man aber auch Emacs/Lisp/Linux-/Unixkonsole-Workflow nutzen (und noch einiges mehr).
Jörg W. schrieb: > Ein T. schrieb: >> Die Voraussetzung -- und eine der Kernideen der Powershell -- ist ja, >> daß die beteiligten Komponenten das .NET-Framework nutzen. > > Das wäre ja so, wie wenn Sun eine eigene Shell rausgebracht hätte, die > dann erwartet, dass alle aufgerufenen Kommandos Java benutzen … Nicht ganz... Java ist immerhin eine Programmiersprache und wäre im .NET-Universum wohl am Ehesten mit C# vergleichbar. .NET ist aber eine umfangreiche Bibliothek von Komponenten, die von verschiedenen Programmiersprachen aus genutzt werden können. So eine Komponentenbibliothek gab und gibt es bei Java nicht. Aber selbst wenn Deine Annahme zuträfe, was sie aus den erwähnten konzeptionellen Unterschieden zwischen einer Programmiersprache und einem systemnahen Framework nicht kann, spricht doch nichts dagegen, ein solches Framework auch unter UNIXen bereitzustellen. Und dann ein Kommandozeilensystem zu entwickeln, das das Framework benutzt und in Pipes anstelle von Text allokierte Objekte übergäbe. In welcher Sprache eine solche UNIX-Komponentenbibliothek entwickelt würde, spielt dann auch keine große Rolle mehr, schließlich gibt es ja beispielsweise für Java mittlerweile auch einige andere Sprachen, die Java-Objekte benutzen können, zum Beispiel Jython oder meines Wissens auch Kotlin, Scala und Julia. Solange dabei die Schnittstellenspezifikationen eingehalten werden, würde das in einem Java-Universum (G~tt bewahre...) also keine größere Rolle spielen, in welcher dieser Sprachen die Komponenten eines solchen Frameworks entwickelt würden. Wie gesagt, Microsofts Powershell ist das Eine, die Idee der Weitergabe allokierter Objekte das Andere. Daß Microsoft dabei natürlich wieder einmal sein eigenes Zeugs entwickeln mußte und von verschiedenen Konventionen abweichen mußte oder, besser: wollte, liegt in der Natur des Wettbewerbs, in dem Microsoft sich befindet oder wähnt. Das macht einige der Ideen aber nicht weniger gut, finde ich.
Jörg W. schrieb: > Das wiederum ist schade, denn ein paar nette Dinge haben sie drin, die > cmd.exe nicht hat – man kann bspw. "cd ~" machen und landet in seinem > Nutzerverzeichnis ›cd ~‹ Vier Zeichen. Das ist aber ziemlich geschwätzig ;-)
rbx schrieb: > Viele Leute sehen irrtümlich in der Powershell eine Alternative zur > Unix-Shell. Das ist aber Unfug. Wenn man kann, installiert man sich > Unix-Werkzeuge die es auf verschiedenen importfreundlichen Wegen für > Windows gibt, neuerdings auch WSL. Nunja, die Powershell ist soweit ich weiß kein Ersatz für eine UNIX-Shell, sondern eine Software, die unter Windows ähnliche Aufgaben wahrnehmen soll wie die Shell unter UNIXoiden. Dabei (und vermutlich deswegen) hat die Powershell einige Dinge von den UNIX-Shells abgekupfert, etwa die Funktion einer Pipe, und auch das Zeichen, das unter vielen UNIX-Shells dafür verwendet wird. Andererseits hat Microsoft auch ein paar neue Ideen hineingebracht, eben zum Beispiel, daß dort Objekte anstelle von Textdaten weitergegeben werden -- was Microsoft deswegen machen konnte, weil sie bereits ein sehr stark auf ihr Betriebssystem zugeschnittenes Framework aus vielen aufeinander abgestimmten Komponenten hatten, eben .NET. > Problematisch wirds, wenn man diese Möglichkeit(en) nicht hat. Man > könnte sich aber anschauen, wie "Dos"-Admins/Profis arbeiten. Aus berufenem Mund -- zwei enge Freunde und einige weniger enge Bekannte von mir arbeiten bei Microsoft -- weiß ich, daß einige von ihnen die Powershell benutzen, meistens um genau die Dinge zu tun, für die wir UNIX-Freunde unsere Shell nehmen. > Die Hintergundüberlegung, das die "Objektbezogenheit" der Powershell > gewissermaßen die Modularität der Werkzeuge in der Unix-Shell ersetzt, > ist eher albern - und ehrlich gesagt auch nicht sonderlich inspirierend. Da die Powershell wohl sehr eng an das .NET-Framework gebunden ist, war eine Modularisierung wie in der UNIX-Welt sicherlich kein Entwicklungsziel. Und wir sollten vielleicht nicht vergessen, daß Microsoft die Powershell zu einer Zeit entwickelt hat, als Linux bei Microsoft -- vor allem dort, wo Automatisierung seit jeher eine besonders große Rolle spielt, nämlich auf Serversystemen -- noch als einer der gefährlichsten Wettbewerber galt. Ich könnte mir vorstellen, daß man die Kompatibilität an dieser Stelle nicht allzu groß machen wollte. > Interessant vielleicht eher für Leute, die mit C++, Java oder C# > Schnittstellentechnisch mit der Konsole rummachen - aber so eine schöne > Schnittstelle, wie beim Emacs mit Lisp gibt es da eher nicht. Puh... ich benutze den Emacs jetzt seit schätzungsweise 30 Jahren, aber mit Lisp konnte ich mich immer noch nicht recht anfreunden. ;-) > Wenn man in Windows in der Powershell den ghci aufruft, und den > Watcom-Vi als Editor einstellt, dann kommt da irgendwie auch (am Ende) > Murks heraus. Die Powershell ist eben keine UNIX-Shell und sollte das auch nicht sein. Aber die Funktion, die ihr zugedacht ist, ähnelt der von UNIX-Shells ja durchaus. Auch der Glasgow Haskell Compiler und der Watcom-Vi sind keine .NET-Werkzeuge, sondern UNIX-Tools, und dafür wurde die Powershell nicht erfunden und nicht gemacht. Wie gesagt, die Powershell ist primär ein .NET-Tool oder, um es diesmal etwas anders zu sagen: die Powershell ist eine Kommandozeile für .NET-Komponenten. > Deswegen habe ich u.a. auf Linux gewechselt, um zu schauen, ob die > Haskell-Programme da besser funzen. > Haskell hat natürlich noch andere Probleme, so ist das für mich nur ein > kleiner Schritt. Schrittweise Optimierung sozusagen ;) Herzlich willkommen unter Linux, und viel Spaß und Erfolg mit Haskell! ;-)
Karl Käfer schrieb: > Single-Board-Computer mit > Linux sind ohnehin nicht allzu weit verbreitet Also die Raspberry Pi Szene würde ich nicht unbedingt als klein einschätzen. Gerade durch dieses kleine Brettel haben doch viele erst angefangen sich mit Elektronik und µC zu befassen. Ich würde sogar behaupten wollen, das gerade Arduiono, Raspberry und Co. die "Makerszene" maßgeblich mit hervorgebracht haben. Durch diese Bretteln sind viele erst einmal überhaupt in die Lage versetzt worden, auch mal ein größere Elektronik/µC-Projekt anzugehen. Ob das immere gut ist und am Ende in eine sinnvolle Richtung geht, steht erst mal auf einem anderen Blatt. Definitiv ist man bei diesen Bretteln näher an der Hardware als bei jedem anderen PC. Für kleinere Serverprojekte und Steuerungsaufgaben im Home- und Bildungsbereich sind sie definitiv gut geeignet. Karl Käfer schrieb: > Wie oben schon erwähnt, ist das OneWire-System ziemlich empfindlich > hinsichtlich seines Timings, weswegen ich erwarten würde, dass die > Entwickler eines solchen Kernelmoduls dasselbe sehr häufig ausführen > wollen. Die 1-Wire Module an sich laufen sehr stabil. Ich habe da einen Pi für meinen Bodentemperatursensor und für die Messung der Wassertemperatur im Pool. Das Teil läuft seit ca. 7 Jahren ohne Ausfälle. Allerdings schreibe ich auch nicht auf die SD. Die Daten werden per NFS auf meiner NAS in einer DB gesichert. Der Pi bereitet auch die Daten für die Webseite auf. Karl Käfer schrieb: > Entschuldige, aber... wenn Linux so schlecht wäre, wie Du suggerierst, > dann hätte es vermutlich kaum nahezu den kompletten Server- und einen > Grossteil des Embedded-Marktes übernommen, und wäre nicht auf dem Mars > gelandet. Ich suggeriere gar nichts. Ich habe auch nicht behauptet das es schlecht ist. Server werden in aller Regel von Leuten bedient die sich mit der Materie auskennen und auch die Zeit und das Wissen haben Probleme zu beseitigen. Ebenso bei Embedded, dort wird entweder das System von Leuten installiert, die sich mit dem System aus kennen und den Enduser (der FB, des Handys etc.) interessiert es nicht was da im Hintergrund werkelt, so lange es so werkelt wie er es erwartet. Der will einfach nur die HW benutzen. Der andere Teil der mit Embedded arbeitet ist zumindest erst mal bereit steinige Wege zu gehen um ans Ziel zu kommen und beschäftigt sich deshalb mit der Thematik.
Ein T. schrieb: > während Du das auf der anderen Seite für Deine doch ziemlich > speziellen Anwendungsfälle (SDR und 1-Wire, uralte hochproprietäre > Grafikhardware) Was ist an SDR speziell? Gar nichts. Was ist an 1-Wire speziell? Ebenfalls nichts. Und die uralte hochpropietäre Grafikhardware funktioniert mit anderen OS, u.a. Win10 aber auch einem RedHat-Linux, völlig problemlos.
Le X. schrieb: > Tatsächlich gibt es aber auch PIs die regelmäßig neu gestartet werden > müssen. Und deren Betreiber nützt es herzlich wenig wenn die einzigen > Aussagen die man aus der Community kriegt regelmäßig lauten: > "Probier mal ne andere SD-Karte." > "Probier mal ein anderes Netzteil." > "Ich weiß gar nicht was du hast, also bei meiner Oma läuft der Pi seit > 1987 ohne Probleme". Du sagst es.
Ein T. schrieb: > Aber der Pi ist explizit als Bastelrechner konzipiert, und sich > zuerst ein Bastelgerät zuzulegen und sich dann darüber zu beschweren, > daß man basteln muß, Es beschwert sich keiner über den Pi. Wenn ich dort dann etwas kompiliere, wie in meinem Fall ein Modul, und selbiges wird dann vom Kernel nicht geladen, dann kann der Pi ziemlich wenig dazu. WEnn rs dann in Abhängigkeit von der aufgespielten OS Version dann doch funktioniert, dann ist das doch ganz offensichtlich keine Sache der Hardware. Und wenn dann in dieser OS Version wiederum andere Dinge nicht funktionieren, die nachweislich zuvor funktioniert haben, dann kann auch dafür die HW herzlich wenig dazu. Das sind Dinge die im OS faul sind. Ob das nun am System selbst oder an denjenigen liegt die die Distribution zusammengestrickt haben interressiert den der es am Ende benutzt herzlich wenig. Und noch was zur Konzeption des Raspberry. Der ist eigentlich nicht als Bastelrechner konzipiert worden. Das Ding ist eigentlich als "Bildungsrechner" für jedermann entwickelt worden (s. hier https://de.wikipedia.org/wiki/Raspberry_Pi). Zum richtigen Bastelrechner wurde das Ding eigentlich auf Grund der herausgeführten GPIO's. Damit wurde der Rechner auch für viele Bastler interessant, weil sich damit verschiedenste HW-Komponenten ansteuern lassen und zudem die Programmierung der GPIO-Ports mit der Wiring-Pi Bibliothek recht einfach gehalten wurde (man kann schon mit mit einfachen Bash-Befehlen die Ports ansprechen).
Jörg W. schrieb: > Am einfachsten geht's halt nach > wie vor unter X11, einfach mit links markieren und mit der Mitte > kopieren, keine Fingerei mit Tasten. Beim aktuellen Mint, welches ich vor einem knappen Monat installiert habe, hat man genau diese tolle Funktionalität per default abgeschalten, ebenso wie Funktionstasten, die ebenfalls vom Terminal abgefangen werden. Das hat zur Folge das der Midnightvommander im Terminalfenster quasi unbrauchbar ist. Man kann das allerdings im Terminalprogramm selbst einstellen, so das man die gewohnte Funktionalität wieder hat. Allerdings muß man die Einstellungen erst mal finden. Jörg W. schrieb: > Mac geht noch, durch die von > Control separate Command-Taste kollidiert halt Cmd-C nicht mit dem > Ctrl-C, welches die Shell für sich braucht. Beim Mac kommt man da auch ohne Tastatur aus. Einfach mit gedrückter linker Maustaste markieren, Rechtsklick > Kopieren und Linksklick > Einsetzen und das Markierte wird am Cursor eingefügt.
Zeno schrieb: > Karl Käfer schrieb: >> Single-Board-Computer mit >> Linux sind ohnehin nicht allzu weit verbreitet > Also die Raspberry Pi Szene würde ich nicht unbedingt als klein > einschätzen. Das kommt darauf an, wie man das betrachtet. Allerdings bin ich nebenberuflich Datenanalyst und habe deswegen einfach mal nach "number of raspberry pis sold" und "number of computers worldwide" bei Google eingegeben. Für die Anzahl der RasPis kommen dann 38 Millionen Geräte (2021) und für die Anzahl der Computer insgesamt etwa 2 Milliarden (2019). Wenn diese Zahlen auch nur halbwegs stimmen, dann haben die RasPis etwa zwei Prozent am weltweiten Rechnerbestand. (Wenn Du bessere Daten hast, bitte immer her damit.) Hm, zwei Prozent... das kenne ich doch irgendwoher? Ach ja, diese Sache mit der Verbreitung von Linux: Immer wenn so ein Spezialist glaubt, damit könne man die Linux-Community damit ärgern, sagt er, dass Linux nur zwei Prozent Marktanteil bei den Desktops habe -- als ob wir das nicht wüssten und als würden viele von uns das nicht sogar ganz gut finden, wenn die DAUs und Nörgler die Support-Hotlines von MS und Apple nerven, anstatt uns. ;-) Wenn Du jetzt keine besseren Daten liefern kannst als Google, dann möchtest Du mir bitte einmal erklären: warum sind zwei Prozent Marktanteil bei Linux-Destops völlig irrelevant, zwei Prozent bei RasPis dagegen eine signifikante Grössenordnung? (Und hinzu kommt, daß ich zwar einen Desktop, zwei Laptops und einen Server, jedoch im Moment elf RasPis in meinem Netz betreibe, aber wir wollen nicht kleinlich sein.) > Gerade durch dieses kleine Brettel haben doch viele erst > angefangen sich mit Elektronik und µC zu befassen. > [...] > Für kleinere Serverprojekte und > Steuerungsaufgaben im Home- und Bildungsbereich sind sie definitiv gut > geeignet. Ja, natürlich, alles was Du in diesem Absatz sagst, ist vollkommen richtig. Und für genau diesen Bedarf ist der RasPi ja auch entwickelt worden. Das "Pi" steht sogar für Python, mithin eine Programmiersprache, die -- wir mir jüngst erklärt wurde -- "richtige Entwickler" ohnehin nicht benutzen wollen würden, auch wenn sie bei den Stackoverflow-Umfragen der letzten Jahre immer als "most wanted" genannt wird. Das erklärte Ziel von Eben Upton, dem Gründer des Projekts hinter dem RasPi, war meines Wissens, wieder etwas weiter in der Zeit zurück zu gehen und etwas wiederzubeleben, das meiner- und vielleicht auch Deinereins noch beim Basteln, Hacken und Löten an ehrwürdigen Modellen wie dem VC-20 und dem C64 erlebt haben. > Karl Käfer schrieb: >> Wie oben schon erwähnt, ist das OneWire-System ziemlich empfindlich >> hinsichtlich seines Timings, weswegen ich erwarten würde, dass die >> Entwickler eines solchen Kernelmoduls dasselbe sehr häufig ausführen >> wollen. > Die 1-Wire Module an sich laufen sehr stabil. Ich habe da einen Pi für > meinen Bodentemperatursensor und für die Messung der Wassertemperatur im > Pool. Das Teil läuft seit ca. 7 Jahren ohne Ausfälle. Allerdings > schreibe ich auch nicht auf die SD. Die Daten werden per NFS auf meiner > NAS in einer DB gesichert. Der Pi bereitet auch die Daten für die > Webseite auf. Naja, NFS... hüstel... ach, lassen wir das. ;-) Aber wie gesagt, ich benutze selbst Onewire, und das Timing ist und bleibt leider kritisch. Deswegen benutze ich passende USB-Module, um meine Busse anzusteuern, und bisher kann ich nicht über Instabilitäten klagen. Mein Verdacht ist allerdings nicht einmal, dass die w1-Kernelmodule instabil seien. Im Gegenteil würde ich sogar vermuten, dass die ähnlich stabil und rund laufen wie meinen Erfahrungen zufolge der Rest des Linux-Kernels. Mein Verdacht ist eher, dass das Onewire- und das SDR-Kernelmodul sich vielleicht gegenseitig beißen könnten. Mit lediglich SDR ist Deine Büchse doch rund gelaufen, oder? Und: hast Du es mal alleine mit Onewire versucht, also ohne SDR? Hast Du den RasPi womöglich auch mal ohne beides ausprobiert, rennt er dann stabil? Zudem will so ein SDR-Gerät vermutlich Spannung und Strom, Onewire ebenfalls. Ich weiss natürlich nicht, wie Du das gelöst hast, aber wie ein großer Teil der heute 536999 Threads hier im Forum zeigt, kann Elektronik eine ziemliche Zicke sein und RasPis vertragen eine Unterversorgung mit Spannung bzw. Strom auch nicht so gut. Und zuletzt sind RasPis ja Geräte, die oft mit bloßen Händen angefasst werden. Das ist für elektronische Bauelemente jetzt auch nicht immer so gut, deshalb hängen die Profis sich ein antistatisches Erdungsarmband um, bevor sie Elektronik anfassen. Du sagst selbst, dass Du mehrere RasPis betreibst, und zum Teil schon seit Jahren stabil und ohne Ausfälle. Offensichtlich geht das also, und kann demzufolge offenbar kein grundsätzliches Problem des RasPi an sich oder seines Linuxsystems sein, oder siehst Du das anders? Trotzdem schimpfst Du über Linux. Sorry, aber wenn bei mir etwas nicht funktioniert, das ansonsten reibungslos und stabil funktioniert, dann suche ich das Problem nicht bei Komponenten, die sonst problemlos laufen. Wenn mir so etwas passiert, dann suche ich nach Unterschieden, mithin: nach den Dingen, die an dem instabilen System anders sind als bei meinen stabilen Systemen. > Ebenso bei Embedded, dort wird entweder das System von > Leuten installiert, die sich mit dem System aus kennen und den Enduser > (der FB, des Handys etc.) interessiert es nicht was da im Hintergrund > werkelt, so lange es so werkelt wie er es erwartet. Der will einfach nur > die HW benutzen. Der andere Teil der mit Embedded arbeitet ist zumindest > erst mal bereit steinige Wege zu gehen um ans Ziel zu kommen und > beschäftigt sich deshalb mit der Thematik. Embedded ist aber nichts für Enduser, auch wenn Arduino, RasPi und Co. viele Leute dazu gebracht haben, mit Elektronik und Linux und Co. zu spielen. Aber wer damit anfängt, verlässt damit automatisch den Status "Enduser" und wird "Entwickler" oder "Admin". RasPis, Odroids, Banana-, Orange- und andere Pis sind nicht für Enduser gedacht, sondern für Menschen, die erkunden sollen, wie etwas funktioniert, wissen wollen, wie sie etwas bestimmtes erreichen können, die etwas erforschen, entwickeln und Probleme lösen wollen. Genau für solche Menschen sind diese Geräte gedacht. Weiter oben hast Du Dich beklagt, dass OpenSource so unkoordiniert sei, und Dich dafür ausgesprochen, die Ressourcen besser zu bündeln. Auch wenn ich verstehe, was der Hintergrund Deiner Ausführungen ist, würde das Deine Probleme wahrscheinlich nicht lösen, aber das ist nicht einmal mein Punkt. Mein Punkt ist, dass Du damit mehrere der wesentlichen Funktions- und Kooperationsprinzipien von OpenSource für unsinnig erklärst -- und dies insbesondere vor dem Hintergrund von Linux, dessen Begründer es bis heute geschafft hat, seine Leute weitgehend zusammen zu halten. In anderen OpenSource-Bereichen ist das nämlich nicht so. Im BSD-Umfeld waren es erst einige FreeBSD-Entwickler, die mit der Entwicklung des Projekts unglücklich waren und deswegen NetBSD gegründet haben. Damit wiederum war Theo unzufrieden, deswegen hat er OpenBSD gegründet. Und als wäre das nicht genug, kamen dann neue Akteure mit kommerziellen Interessen ins Spiel, etwa Windriver. Auch sonst ist das mit diesem Linux häufig eine Geschichte von Auseinanderdriften und Konsolidierung. Das nicht bei jedem User beliebte systemd-Initsystem, das über die reine Systeminitialisierung allerdings weit hinausgeht, ist nicht jedermannes Freund. Ich persönlich fand schon den Ansatz gut, und mittlerweile, da es seine Kinderkrankheiten weitestgehend auskuriert hat, mag ich es richtig gerne. Aber Du könntest ja mal mit unserem hochgeschätzten Kollegen DPA darüber sprechen, der mag da kein gutes Haar dran lassen. Am Ende ist es aber trotzdem so, dass alle großen Distributionen heute auf systemd setzen und ich mich mittlerweile nicht mehr damit herumplagen muss, für zehn Linuxsysteme zehn SysV-Initskripte zu schreiben. Linux is user-friendly. It is just picky about its friends. ;-)
Karl Käfer schrieb: > Wenn Du bessere Daten hast, bitte immer her damit.) Allerdings wurden 2020 ungefähr so viele Pis wie Macs verkauft.
Zeno schrieb: > Was ist an SDR speziell? Gar nichts. Schade, dass diese Website keine Möglichkeit bietet, Umfragen zu erstellen. Meine persönliche Vermutung wäre, dass sogar auf dieser spezialisierten Seite höchstens zehn Prozent der Benutzer einmal was von SDR gehört, und maximal zwei Prozent der Benutzer etwas damit gemacht haben. Nicht speziell? Hm. > Was ist an 1-Wire speziell? Ebenfalls nichts. Schade, dass diese Website keine Möglichkeit bietet, Umfragen zu erstellen. Meine persönliche Vermutung wäre, dass sogar auf dieser spezialisierten Seite höchstens zwanzig Prozent der Benutzer einmal was von SDR gehört, und maximal zehn Prozent der Benutzer etwas damit gemacht haben. Nicht speziell? Hm. > Und die uralte hochpropietäre Grafikhardware funktioniert mit anderen > OS, u.a. Win10 aber auch einem RedHat-Linux, völlig problemlos. Lustig, auch mit DeadRat? Offensichtlich kein Linuxproblem, oder? (Hinweis: RedHat bezeichnet gemeinhin ein Linuxsystem. Bitte korrigier mich wenn ich falsch liege.)
Karl Käfer schrieb: > als ob wir das > nicht wüssten und als würden viele von uns das nicht sogar ganz gut > finden, wenn die DAUs und Nörgler die Support-Hotlines von MS und Apple > nerven, anstatt uns. ;-) Siehste, da ist diese Arroganz der Linuxleute schon wieder - auch wenn Du das mit einem Lächeln sagst
Zeno schrieb: > Und noch was zur Konzeption des Raspberry. Der ist eigentlich nicht als > Bastelrechner konzipiert worden. Das Ding ist eigentlich als > "Bildungsrechner" für jedermann entwickelt worden (s. hier > https://de.wikipedia.org/wiki/Raspberry_Pi). http://youtu.be/JVU5QBg5l6g https://www.youtube.com/watch?v=UCt6d0SCxO4 > Zum richtigen Bastelrechner wurde das Ding eigentlich auf Grund der > herausgeführten GPIO's. Deiner Unterscheidung zwischen Lern- und Bastelrechner kann ich nicht folgen. Ich erinnere mich auch an ein frühes Interview von Eben Upton, in dem er erklärte, das Konzept sei, den Kids wieder Löten und Basteln an Computern beizubringen, weil sie leider nurmehr Steckkarten in passende Slots stecken könnten. Leider finde ich das Zitat nicht mehr und bin auch zu faul für weitere Recherchen, aaaber: die Sache mit den GPIOs hatte schon einen tieferen Sinn, und der war, dass das Ding eben auch zum Basteln taugen sollte. (Wenn Du ganz oben das Video schaust, wirst Du übrigens auch sehen, dass die ersten Prototypen noch AtMegas auf Streifenplatinen waren.)
Karl Käfer schrieb: > Wenn Du jetzt keine besseren Daten liefern kannst als Google, dann > möchtest Du mir bitte einmal erklären: warum sind zwei Prozent > Marktanteil bei Linux-Destops völlig irrelevant, zwei Prozent bei RasPis > dagegen eine signifikante Grössenordnung? (Und hinzu kommt, daß ich zwar > einen Desktop, zwei Laptops und einen Server, jedoch im Moment elf > RasPis in meinem Netz betreibe, aber wir wollen nicht kleinlich sein.) Na was jetzt betreibst ist natürlich Erbsenzählerei. Du willst jetzt nicht allen Ernstens Desktopcomputer und diese Checkkartencomputer miteinander vergleichen? Das sind 2 verschiedene Paar Schuhe. Schön für Dich das Du so viel Rechentechnik Dein Eigen nennst - ich bin beindruckt. Was willst Du damit sagen?
Karl Käfer schrieb: > Mein Verdacht ist eher, dass das Onewire- und das SDR-Kernelmodul sich > vielleicht gegenseitig beißen könnten. Mit lediglich SDR ist Deine > Büchse doch rund gelaufen, oder? Und: hast Du es mal alleine mit Onewire Na dann verdächtige mal weiter. Auf dem Teil wo der SDR läuft läuft kein 1-Wire und auf der Kiste wo ich gerade 1-Wire teste läuft kein SDR. > versucht, also ohne SDR? Hast Du den RasPi womöglich auch mal ohne > beides ausprobiert, rennt er dann stabil? Wenn ich einen Pi einsetze, dann hat der in aller Regel eine Aufgabe. Wenn er diese nicht erfüllen kann, dann ist er schlichtweg ungeeignet und wird gar nicht zum Einsatz kommen. Meine Probleme sind reine SW-Probleme und zwar im konkreten Fall das Linux für den BananaPi. Da sind die verfügbaren Distris einfach nur schlampig zusammen gestellt. Man bekommt es ja hin, aber es braucht Zeit. Ärgerlich ist dabei, das man an Dinge Hand anlegen muß wo es > Zudem will so ein SDR-Gerät vermutlich Spannung und Strom, Onewire > ebenfalls. Ich weiss natürlich nicht, wie Du das gelöst hast, aber wie > ein großer Teil der heute 536999 Threads hier im Forum zeigt, kann > Elektronik eine ziemliche Zicke sein und RasPis vertragen eine > Unterversorgung mit Spannung bzw. Strom auch nicht so gut. Ja klar will so ein SDR-Stick Strom mit Gas funktioniert er leider nicht - ist in den heutigen Zeiten auch besser so. Rechnen wir doch einfach mal die Stromverbräuche meines Satellitenempfängers nach: - BananaPi alleine max. 0,8A - der SDR-Stick ca. 0,3A - die SSD um die 0,5A Das macht zusammen 1,6A. Das ganze wird von einem Netzteil 5V/2,4A versorgt, mit anderen Worten das System wird nicht an Luftknappheit leiden. Zudem speise ich den SDR-Stick nicht direkt vom USB-Port sondern direkt vom Netzteil. Gleiches gilt für die SSD.
Karl Käfer schrieb: >> Und die uralte hochpropietäre Grafikhardware funktioniert mit anderen >> OS, u.a. Win10 aber auch einem RedHat-Linux, völlig problemlos. > > Lustig, auch mit DeadRat? Offensichtlich kein Linuxproblem, oder? > (Hinweis: RedHat bezeichnet gemeinhin ein Linuxsystem. Bitte korrigier > mich wenn ich falsch liege.) Nö nicht lustig, die Leute bei RedHat haben ganz offensichtlich ihre Hausaufgaben gemacht und eine funktionierende Linux-Distribution heraus gebracht, die sogar mit probitärer HW funktioniert. Das haben die aber schon immer gekonnt. Meine erste Linuxdistribution mit der man wirklich arbeiten konnte - einfach installieren ohne Frikelei - war auch eine RedHat. Nimm einfach mal Deine Nase wieder ein bischen runter die Leute bei RH machen schon eine ordentliche Arbeit.
Ein T. schrieb: > Herzlich willkommen unter Linux, und viel Spaß und Erfolg mit Haskell! Danke sehr. Zumindest kann man bei Haskell sagen, dass da eher Typen, Listen und mathematische Genauigkeit eine Rolle spielen, während bei der Powershell die "Objekte" wohl eher zur Formatierung, also für eher oberflächliche Dinge genutzt werden. Natürlich ist -h reading nicht oberflächlich, aber so meine ich das nicht. Ich denke da eher ein meine Mutter, die mit großer Motivation ihre Blumenvasen, mit den künstlichen Blumen drin, mal hier oder da hinstellt, je nach Tageslaune - für das Angehen einfacher, aber wichtiger Alltagsanforderungen kaum noch in der Lage ist. Auf jeden Fall sind Typen, Listen oder mathematische Genauigkeit keine so schlechten Eigenschaften für Steueraufgaben in der Serverwelt. Schaut man sich mal so um, rund um Haskell, SSH, Putty-Alternativen, dann landet man nach einer Art accept-Marathon für Internetseiten-Nutzung u.a. hier: https://www.netzwelt.de/download/netzwerk/terminal/index.html Aber es gibt heutzutage doch echt viele irgendwie blöd gemachte Internetseiten - unabhängig von lesenswerten Inhalt.
Zeno schrieb: > Karl Käfer schrieb: >> als ob wir das >> nicht wüssten und als würden viele von uns das nicht sogar ganz gut >> finden, wenn die DAUs und Nörgler die Support-Hotlines von MS und Apple >> nerven, anstatt uns. ;-) > Siehste, da ist diese Arroganz der Linuxleute schon wieder - auch wenn > Du das mit einem Lächeln sagst Nur von unten sieht Niveau wie Arroganz aus.
Zeno schrieb: > Na dann verdächtige mal weiter. Auf dem Teil wo der SDR läuft läuft kein > 1-Wire und auf der Kiste wo ich gerade 1-Wire teste läuft kein SDR. Das las sich oben anders, und dieser bereits weiter oben geäußerten Vermutung hast Du nicht widersprochen. Zeno schrieb: > Meine Probleme sind reine SW-Probleme und zwar im konkreten Fall das > Linux für den BananaPi. Da sind die verfügbaren Distris einfach nur > schlampig zusammen gestellt. Du schimpfst oben aber nicht über die Zusammensteller, sondern über Linux. Zeno schrieb: > Nö nicht lustig, die Leute bei RedHat haben ganz offensichtlich ihre > Hausaufgaben gemacht und eine funktionierende Linux-Distribution heraus > gebracht, die sogar mit probitärer HW funktioniert. Ach, mit RedHat Linux funktioniert es also. Trotzdem schimpfst Du über Linux, obwohl das ja nun ganz offensichtlich nicht das Problem ist.
Karl Käfer schrieb: > Das las sich oben anders, und dieser bereits weiter oben geäußerten > Vermutung hast Du nicht widersprochen. Lesen kannst Du also auch nicht. Noch mal extra für Dich: Ich möchte auf dem BPi, wo derzeit ein SDR dran werkelt - übrigens seit gut 2 Jahren ohne Probleme - zusätzlich noch noch 3 DS1820 betreiben. Damit das Vorhaben gelingt braucht es Unterstützung für 1-Wire. Also habe ich einen 2. BPi genommen, die Karte des laufenden BPi dupliziert und versuche nun das Modul zum Laufen zu bekommen, was bisher nicht wirklich funktioniert. Karl Käfer schrieb: > Ach, mit RedHat Linux funktioniert es also. Trotzdem schimpfst Du über > Linux, obwohl das ja nun ganz offensichtlich nicht das Problem ist. Ja konntest Du oben nachlesen und haste ja auch schon mit Nase hoch kommentiert. Karl Käfer schrieb: > Nur von unten sieht Niveau wie Arroganz aus. Was bist Du eigentlich für ein arrogantes ...?
Zeno schrieb: > Also habe ich > einen 2. BPi genommen, die Karte des laufenden BPi dupliziert und > versuche nun das Modul zum Laufen zu bekommen, was bisher nicht wirklich > funktioniert. Hast du nicht noch ’nen Raspberry Pi liegen? Damit ginge das wohl recht problemlos: https://www.waveshare.com/wiki/Raspberry_Pi_Tutorial_Series:_1-Wire_DS18B20_Sensor
Jack V. schrieb: > Hast du nicht noch ’nen Raspberry Pi liegen? Damit ginge das wohl recht > problemlos: Ja habe ich. Es geht aber nicht darum einen weiteren Pi zu installieren, sondern den BPi, der sich zudem noch örtlich in der Nähe der Sensoren befindet für die Auswertung selbiger zu benutzen. Ja ich könnte auch einfach ca. 25m Kabel verlegen und könnte dann die Sensoren an einem vorhandenen RPi anschließen der schon einige DS1820 bedient. Aber warum sollte ich das tun, wenn der BPi das genauso gut kann und ich dorthin nur knapp 5m Kabel benötige. Da es sich bei den auszulesenden Sensor um eine kombinierte Sensoeinheit handelt, ist es auch nicht dem 1-Wire Bus getan. Da kommen noch ein paar Sachen dazu, die aber bereits funktionieren.
Zeno schrieb: > Aber warum sollte ich das tun, wenn der BPi das genauso gut > kann Schriebst du nicht weiter oben, dass er genau das derzeit nicht kann?
Jack V. schrieb: > Schriebst du nicht weiter oben, dass er genau das derzeit nicht kann? Jein, beim aktuell laufenden Kernel kann ich neu kompilierte Module nicht. Mit einer anderen Distribution würde dies prinzipiell funktionieren, die hat aber an ander Stelle Probleme (sync disc) und da weis ich nicht ob ich mich darauf verlassen kann.
Beitrag #7118824 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.