Posts by peuler

Siehe auch diesen Artikel in Heise+.

Ich hätte noch eine Ergänzung zu dem Punkt, der mit den Worten beginnt: "Bei Fragen zum Programmieren..."

Mir fällt oft auf, dass bei Compiler-Sprachen (zum Beispiel C, C++) sehr selten Angaben zum Aufruf des Compilers + Linkers zu finden sind. Das wäre für mich zumindest interessant zu wissen, weil gerade Anfänger gerne die Compiler-Warnings entweder nicht aktivieren oder ignorieren was ich für falsch halte. Auch habe ich Fälle gesehen, dass nicht erkannt wurde, dass lediglich der Compiler gestartet wurde aber das Linken eben nicht (die Suche nach einem ausführbaren Programm kann dann keinen Erfolg haben). Wenn man nun den Aufruf des Compilers sehen würde, könnte man auch hier Rückschlüsse auf Fehler ziehen.

Wurde schon einmal versucht mit journalctl etwas herauszufinden?

Um den genauen Zeitpunkt des Stillstandes zu ermitteln bzw. festzuhalten würde ich mir ein kleines Shell-Script bauen, das einfach alle 1-5 Sekunden mit dem touch-Befehl immer wieder die gleiche Datei anlegt. Nach dem Aufhängen des Pi und anschließendem Neustart kannst Du dann mit Blick auf die Datei dann auf wenige Sekunden eingrenzen, wann das Aufhängen genau passiert ist (ls --full-time <Datei>).

Ich bin kein Experte betreff systemd vs initv, das sei vorab erwähnt; das initv kenne ich garnicht. Aber beim Experimentieren und Anwenden von systemd ist mir aufgefallen, dass es für mich eher leicht zu verstehen ist und dass ich recht schnell zu brauchbaren Ergebnissen gekommen bin. Ich habe mir mal zu einem sehr oberflächlichen Vergleich die Start-Skripte von smstools angeschaut, die auf dem initv aufsetzen. Tja, habe die Finger davon gelassen weil nichts durchschaut und verstanden.

Fazit: für einen Einsteiger wie mich ist systemd eher geeignet und die Funktionsweise ist eher nachvollziehbar.

Betreff dem Argument "wenn es nicht kaputt ist, muss es auch nicht repariert werden": Warum kauft Ihr alle 3-5 Jahre neue Computer? Weil die kaputt sind oder weil sie einfach veraltet sind den Anforderungen nicht mehr gerecht werden?

Es sieht danach aus, dass Du nicht den kompletten Quellcode gepostet hast. Im Post #1 hat Dein Quellcode 12 Zeilen aber die Compiler-Meldung bezieht sich auf Zeile 18. Da passt was nicht zusammen. Daher mein Vorschlag, dass Du mal den kompletten Quellcode hier postet. Den kann man dann herunterladen und durch den eigenen Compiler schicken.

Als Ergänzung zum Beitrag #4 würde ich auch Telegram empfehlen. Der Versand von SMS kann via einem angeschlossenem UMTS-Stick erfolgen. Teile eines Lösungsvorschlags kannst Du hier nachlesen.

Quote from concept2018

Der Hinweis mit dem WLAN-Access-Point ist gut ! wenn jetzt noch ein Tutorial mit 2 Pi´s und gegenseitigem Steuern z.B. Led´s

vorhanden ist ---- dan hätte ich es.

Ist Dir soeins bekannt ?

Nein, mir ist solch ein Tutorial nicht bekannt, das Dein gesamtes Projekt abbildet. Daher noch einmal mein Hinweis, dass Du mit dem Access-Point erst einmal anfängtst und wenn das steht, dann setzt Du die Anwendungsschicht oben drauf.

Gleich zu Anfang möchte ich nicht-fachlich antworten, dass mir der Tonfall mancher Schreiber als Reaktion auf Deinen "grössten anzunehmenden Forumsfehler" auch nicht passt: Leben und leben lassen!

Zum fachlichen, Teil 1:

Nach meinem Eindruck versuchst Du großem Besteck (Zitat: "Mit einem ... Python-Programm ... klappt die Verbindung") Dich dem Thema zu nähern anstatt von der Basis aus zu beginnen. Darauf zielte mein Hinweis auf bluetoothctl ab. Ich würde mich mit bluetoothctl beschäftigen um die Basis zu legen und mir dann dass Python-Programm anschauen. Kennst Du Dich mit Python aus und kannst aus dem Quelltext nachvollziehen, woran es klemmt? Auch dass zählt zur Basis.

Zum fachlichen, Teil 2:

Man kann einen Pi (egal ob er einen WLAN-Dongle hat oder ob er einen festverbauten hat) auch so aufsetzen, dass er als WLAN-Access-Point ähnlich einem Router zu hause arbeitet. Daher mein Vorschlag, dass Du noch mal in die folgende Richtung nachdenkst: Setze einen Pi als WLAN-Access-Point auf und verbinde die beiden Pis per WLAN. Anschließend kannst Du mit den klassischen Netzmitteln die beiden kommunizieren lassen. Du wirst auch hier im Forum Anleitungen finden, wie das mit dem Access-Point klappt. Deine Logik mit den Codes musst Du dann als Anwendungsschicht oben drauf setzen, was sich aber mit relativ einfachen Mitteln auch mit Bash-Skripten lösen lässt. Als Alternative zu den Bash-Skripten kannst Du auch Teile von diesem nutzen.

Zusammenfassung: Fange mit der Basis an und dann arbeitest Du Dich Schritt für Schritt nach oben zur Anwendung durch. Dann wirst Du auch wieder Bäume sehen und am Ende einen gut aufgewachsenen Wald-bestimmt sogar mit einer Lichtung, in der Du Dich dann wohl fühlst. Dann hast Du auch keinen Grund "alles hinzuschmeissen".

Vielleicht hilft Dir das Programm bluetoothctl weiter. Damit kannst Du Verbindungen zwischen dem Pi und einem anderen Bluetooth-Device aufbauen. Wenn Du mit dem Desktop (Pixel) arbeitest, kannst Du in der oberen Leiste am rechten Rand mit dem Bluetooth-Symbol auch Verbindungen erkennen.

Ich selbst bin kein Bluetooth-Experte aber mir ist mehrfach untergekommen, dass die Nutzung von Bluetooth als Kommunikationsmedium nicht so rasend einfach zu realisieren ist. Daher meine Frage: Muss es unbedingt Bluetooth sein? Wäre auch WLAN/LAN möglich? Das hätte den Vorteil, dass Du eine gute Unterstützung aufgrund der Netzwerk-Programme hättest, die mit dem Pi mitkommen.

Vielleicht berichtest Du noch etwas ausführlicher, um was bei Deinem Projekt geht, das dürfte andere hier mehr motivieren, hier gedanklich einzusteigen.

Eine Alternative zu Pushbullet wäre Telegram: Wenn Dein ESP ins WLAN kommt und Zugang zum Internet bekommt, könnte er eine Chat-Nachricht absetzen und Dein Smartpfhone bekommt diese Nachricht in seinem Telegram-Client angezeigt. Allerdings könnten mehrere Sekunden vergehen, bis der ESP ins Internet kommt und die Nachricht abgesetzt bekommt. Aber ein Versuch wäre es wert.

Eine andere Alternative wäre fetchmail. Habe hier mal eine Blanko-Konfigurationsdatei namens fetchmailrc angehängt und ein Blanko-Parser-Script namens fetchmailparser.sh. Dieses Script holt das Subject und den Absender aus der Mail und setzt daraus eine neue Datei zusammen. Mit diesem Mechanismus ist es bestimmt auch möglich, eine Datei auf einen Drucker zu schicken, nachdem die Datei heruntergeladen wurde.

fetchmailrc:

fetchmailparser.sh:

Deaktiviert : Man kann diese Neuigkeit auch aus einer anderen Richtung betrachten: Bin auf dem Raspberry mit dem Debian-Image gestartet, das es bei der Raspberry Foundation zum Herunterladen gespeichert ist und habe mir anschließend in einem virtuellem PC die Desktop-Variante installiert. Damit hatte ich das gleiche Look&Feel von Linux einmal auf dem Pi und dann auf einem PC; zum Üben ist die PC-Variante einfach unkritischer und schneller neu installiert.

Für mich war es als Einsteiger nicht so recht durchschaubar, dass es ein Debian auf x86/amd64-Basis gibt und dann eine Ableitung des Debian auf ARMHF-Basis dazu, die aber nicht von der Debian-Homepage herunterzuladen ist sondern eben von der Foundation. Noch dazu kommt, dass es ein weiteres Raspbian gibt, dass von einer weiteren Organisation bereitgestellt wird.

Für jemanden, der Debian auf x86/amd64-Basis nutzt und nun das gleiche OS und das gleiche Look&Feel auf dem Pi haben will, ist die vom TO beschriebene Entwicklung ein Segen. Richtig ist aber auch, dass ich mit der Version von der Foundation sehr zufrieden bin und auch erst mal keinen Anlass sehe, von der Version wegzugehen. Aber im Sinne von Standards wäre es klasse, wenn es möglichst wenige Debians für den Pi gäbe, optimalerweise nur 1, dass alles kann. Naja, Träumen und Hoffen ist ja erlaubt.

@hailogugo:

Zunächst sei positiv erwähnt, dass Du Dir die Mühe gemacht hast, eine Anleitung zu schreiben. Du solltest Dir vor Augen halten, dass diejenigen, die Deine Tippfehler wie das mit "SSID =" selbst erkennen, eher nicht Deine Anleitung lesen: solche Kollegen schütteln solche Themen von alleine aus dem Ärmel. Und diejenigen Leser, die Deine Anleitung nun anwenden wollen und solche Fehler nicht erkennen, scheitern damit. Und das sorgt für Frust. Meine Vorredner wollen Dich sicherlich nicht ärgern sondern zur Vermeidung von Enttäuschung beitragen. Nimm' das Feedback als Chance, die Anleitung zu verbessern, so einfach wäre es.

Daraus folgt: entweder exakt und eindeutig oder garnicht beschreiben. Oder anders ausgedrückt: "Gut gemeint" ist das Gegenteil von "gut".

Zu Post # 09:

Die von mir kritisierten Eigenschaften des Linux haben auch ihre positiven Seiten, die ich auch sehe und nachvollziehen kann. Die Linux-Gemeinde hat es ja selbst in der Hand, daran etwas zu ändern und es gibt viele Gründe, warum das System so aussieht wie es ist - und eben auch andere Systeme so aussehen, wie sie sind.

Ich hatte nicht vor, ein Bashing zu starten sondern wollte einfach nur einen persönlichen Kommentar loswerden um Vorhandenes in Frage zu stellen mit dem Ziel, es zu verbessern. Das wurde hier mehrfach auch so erkannt, was ich prima finde.

Quasi als mein persönliches Schlusswort habe ich dieses: Das beste System ist für mich nicht dasjenige, dass technisch allen anderen in dieser oder jener Hinsicht überlegen ist. Für mich ist das beste System dasjenige, mit dem ich mich am besten auskenne.

Ohne eine komplette Angabe des Quelltextes ist es aussichtslos, den Fehler nachzustellen. Am einfachsten postet Du mal, wo Du den Quelltext her hast bzw. den Quelltext selbst.

Quote from linusg

Sorry, aber das liegt wohl an dir! Wenn du das Telegram HTTP-API meinst, das ist nun wirklich bis ins letzte Detail dokumentiert. Jeder mögliche Parameter, JSON Rückgaben etc.

Ich schließe nicht aus, dass mir Grundlagen fehlen, die andere Personen haben und dass ich deswegen mit der Doku nicht klar gekommen bin. Habe auch aus anderer Ecke mitbekommen, dass die Doku nicht die tollste ist. Damit ist das Thema auch für mich dann mal durch.

Zum Thema "Quelltexte durchwühlen": Github ist voll von Programmen, die keine Dokumentation enthalten und nur zu kapieren sind, wenn man den Sourcecode anschaut. Konkretes Beispiel, in das ich viele Stunden gesteckt habe ist telebot.

Ein anderes negatives Beispiel ist die Api zu Telegram-Bots. Die Doku dazu ist vom Ansatz her richtig aber leider im Detail so schlecht, dass ich nur durch das Anschauen von Beispielsourcen dahinter gekommen bin, wie sie funktioniert.

Zum Thema "Wiki in das OS einbauen": Richtig ist, dass ein Wiki von den Beiträgen aller User profitiert und die Vorteile von Verlinkung, Einbau von Dateien gängiger Formate wie Bilder und Videos erlaubt und vieles mehr. Warum sollte es nicht möglich sein, dass in dem OS ein Wiki-Server eingebaut ist (oder so etwas ähnliches), in den dann die Beiträge mit dem Installieren von Pakten eingebaut werden? Das ist ja nur ein Gedanke, wie man die reinen textbasierten Lösungen wie die man-Pages ergänzen kann.

Naürlich kann man auch auf PDF ausweichen kann (habe ich zum Beispiel gemacht) oder eine HTML-Seite bereitstellen, die ich im Browser anschauen kann.

Zum Thema Powershell: Richtig ist, dass dieses Tool die klassische Shell unter Windows ergänzt. Ich kenne aber niemanden, der diese nutzt. Für mich ist Windows mein Arbeitspferd und das wird es auch bleiben. Aber selbst nach rund 30 Jahren intensiver Windows-Nutzung sowohl privat als auch beruflich habe ich keinen Bedarf, die Powershell kennenzulernen.

Abschließend sei erwähnt, dass ich bewusst "Kommentar" in den Betreff eingebaut habe: damit sollte kenntlich gemacht werden, dass es sich hier nur um einen Auszug aus einem Gesamteindruck handelt und eben keine vollständige Abhandlung mit akademischen Anspruch handelt.

Quote from shindu

... Finde skript sprachen, außer javascript scheiße....

Solche Bemerkungen disqualifizieren Dich eindeutig. Deine gerade mal 5 Jahre als "java, c/c++ Entwickler" sind kein Argument, sich mit einer solche hohen Oktanzahl so im Ton zu vergreifen.

Zu Post #1:

Habe die gleiche SD-Karte im Einsatz und auch noch mehrere andere, kleinere wie größere. Es kann immer passieren, dass die Karte verschleißt und/oder einfach kaputt geht. Dagegen hilft nur, regelmässig Backups anzulegen (kein Backup = kein Mitleid). Habe 2 Pis seit fast 2 Jahren und bisher ist mir keine Karte kaputtgegangen, das mal am Rande.

Betreff dem Kühlkörper: er schadet nicht, er kann nur nutzen. Ich würde mir immer einen draufkleben, wenn einer verfügbar. Du kannst die CPU-Temperatur auch abfragen und damit beobachten.

Vor fast zwei Jahren habe ich mir den ersten Pi gekauft, eine moderne Nutzung meiner Musiksammlung sollte her. Es wurde dann ein Pi 2 mit einem Mediencenter drauf, CDs wurden zu hunderten digitalisiert und als MP3 auf dem eingelegten Datenträger abgelegt. Zeitgleich habe ich mir ein gebrauchtes Tablet geholt, damit ich mit Yatse die Musikdateien abspielen lassen kann. Das kleine Projekt hat einige Stunden gekostet und auch Spaß gemacht. Der eingeschlagene Weg hat sich als richtig erwiesen.

Nachdem ich da nun etwas Blut geleckt habe, kam das nächste Projekt: ich wollte „irgendwie“ meinen Windows-PC zu hause von der Ferne aus einschalten können, ohne dass ich den PC „am Internet hängen“ habe. Eine mögliche Lösung wurde auf Basis des Pi angedacht und realisiert.

Bei Beginn meines kleinen Projektes habe ich mich an ein Gespräch erinnert, dass ich Ende der 1990er Jahre mit meinem Chef geführt habe, es ging um Linux. Er vertrat die Ansicht, dass Linux die Zukunft gehört und dass dieses Betriebssystem die Computerwelt auf links drehen wird, die etablierten Konzerne werden sich noch umschauen. Meine Kette an Gegenargumenten war beliebig lange und (aus heutiger Sicht) dennoch nichtzutreffend. Beruflich hatte ich 2013 erstmals Kontakt mit Linux, davor waren es die Windows dieser Welt, DEC OpenVMS war genauso dabei wie OS/2 und AIX und dann noch Solaris. „Kennst Du eines – kennst Du alle“, so mein Gedanke und dann kam Raspian. Ich wollte auch mal wieder in C Programmieren auch wenn der letzte Compilerstart im letzten Jahrtausend stattfand. Also wurde der zweite Pi gekauft und los ging‘s.

Was ich dabei an Erfahrungen gesammelt habe, ließ mich immer wieder positiv erstaunen und vor Begeisterung sehr weit in meinem Schreibtischstuhl zurücklehnen. Ich hätte nicht gedacht, dass ein freies Betriebssystem so viele Perlen enthalten kann, ein paar Beispiele dafür mögen genügen. Der gcc Compiler & Linker ist für mich ein rattenscharfes Werkzeug, Geany als IDE hat mir den Einstieg erleichtert. Und diese IDE kann durchaus mit dem mithalten, was ich Ende des letzten Jahrtausends als IDE für OS/2-C/C++ erlebt habe (oder genauer: an was ich mich erinnern kann, hihi). Die GUI zum Raspian (also der Desktop) ist selbsterklärend und funktioniert für mich richtig klasse, mehr brauche ich nicht auf meinem Spiel- und Bastelrechner. Mit etwas Basiswissen über Netzwerke kann ich den Pi mit meinem Windows-PC kommunizieren lassen, Zugriff per RDP funktioniert schnell und zuverlässig. Hilfe gibt es nahezu unbegrenzt – nicht nur die Menge betreffend.

Es gab bisher auch einige Momente des blanken Entsetzens und der Enttäuschung. Das konsequente Verweisen auf man-pages hat mich gelegentlich zur Weißglut getrieben. Im 21. Jahrhundert sollte Einsicht bestehen, dass Dokumentationen ohne Bilder/Grafiken nicht mehr zeitgemäß sind. Es erscheint, dass die Erkenntnis „Bilder sagen mehr als Worte“ nicht überall angekommen ist. Warum gibt es kein Wiki, dass im OS fest eingebaut ist? Nahezu jedes Programm hat eine eigene Form, wie die Einstellungen (ini-Dateien) gespeichert werden. Bitter die Erkenntnis, dass ein Standard sich vermissen lässt. In Gedanken klopfe ich Bill Gates auf die Schultern, dass er mit der Registry einen anderen Weg eingeschlagen hat. Schön, dass die # der frei verfügbaren Pakete täglich wächst, unschön, dass es fast alles Kommandozeilenprogramme sind, die ausgeliefert werden. Die Nutzung einer GUI ist nicht nur Newstyle der Generation post Golf sondern bietet auch den Vorteil, dass die allermeisten Programme dadurch selbst erklärend sind. Von den allermeisten Kommandozeilenprogrammen kann ich das leider nicht behaupten. Zu freien Programmen liegt meistens auch der Quellcode nach kurzer Suche vor. Das ist eine prima Sache, wenn man sich für’s Programmieren interessiert; mir erscheint es so, dass es oft genug erforderlich ist, sich durch Quelltexte zu wühlen, weil eine Dokumentation, die den Namen verdient, nicht verfügbar ist. Da erinnere ich mich an Zeiten, als Apple noch Programme anderer Hersteller freigegeben hat, weil sie sich dem eigenen Standard an Qualität verpflichtet gefühlt haben. Es ist eine klasse Idee, dass man Raspian in jeglicher Hinsicht anpassen kann und es sehr granulare Möglichkeiten bietet, es für seine Bedürfnisse zu tunen. Unschön wird es nur, wenn es irgendwo klemmt und man von 100ste ins 1000ste schliddert.

Nun, nach rund 20 Jahren Linux hätte ich eigentlich gedacht, dass die große Gemeinde deutlich weitergekommen ist. Wenn ich mich speziell beim Raspberry darauf entsinne, dass es ein Lern- und Ausbildungscomputer ist, dann komme ich zu einem ganz anderen Schluss: Was für ein bockstarkes Teil mit sehr hohem Spaßfaktor und der Möglichkeit, die eigene Lernkurve beliebig steil verlaufen zu lassen. Danke an die Macher und Danke an all diejenigen, die dazu beitragen, dass der Lernstoff nicht ausgeht! Und danke an alle, die helfen, sich einsetzen, ihre Zeit investieren und auch einem alten Hasen wir mir Tipps und Ratschläge geben können und wollen - haltet durch, es lohnt sich!