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.
Angehängte Dateien:
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.