Posts by RaspberryBaum

Oh Mann, genau...
Danke sehr!!!!

Ich werd' mir da jetzt gleich mal ein Lesezeichen setzen, damit mir sowas nicht nochmal passiert...

hallo an alle!

Ich bin vor kurzem rein zufällig über einen Beitrag von Meigrafdt gestoßen, wie man einen 3B "glauben" lässt, er sei ein 2B, so dass er weniger Strom verbraucht, kein WLAN und Bluetooth mehr hat und überhaupt nichts mehr kennt, was nur der 3B und der 2B nicht hat.

Ja, also nurnoch ein schnellerer 2B ist...

Ja, und jetzt, wo ich das grad bräuchte, find ich's nicht mehr :s ... HAB DEN nAMEN VOM tHEMA VERGESSEN!

Kann mir da jemand weiterhelfen?

Danke schon mal im Vorraus!

Okay, vielen Dank für die guten Ratschläge!
Ich besorg mir dann mal ein besseres Netzteil (ist vielleicht auch noch irgendwo bei uns eins zu finden.

Ah, Ok. Danke sehr!

Wie viel Volt/Ampere sollte das Netzteil denn etwa heben? Sollte ja auch nicht zuviel haben...

Hallo an alle!
Ich habe kürzlich meinen neuen Raspberry Pi 3B einweihen wollen und dazu eine SD mit Raspbian genommen, die zuvor schon auf meinem 2B einwandfrei funktioniert hat. Auf dem 3B allerdings leuchtet das Lämpchen rot und der Bildschirm zeigt einen Riesen-Regenbogen. Bei Ein- und Wiederausnehmen der SD ändert sich daran nichts, so dass ich vermute, dass der Pi die SD nicht als solche erkennt. Könnte das daran liegen, dass ich die SD zuvor für den 2B verwendete und der 32-Bit und der 3B 64-Bit ist? Auf dem 2B funktioniert die SD aber bei gleichem Netzteil, Kabel, Bildschirm etc aber weiterhin einwandfrei.

Wäre nett, wenn mir da jemand helfen könnte.

Eben. Nur... Wie deaktiviere ich die? Es gibt da bei ner Menge Geräten reihenweise Optionen unter Namen wie "WLAN deaktivieren" etc., die es nicht wirklich deaktivieren, sondern nur teilweise etc.

Ich meinte nur, dass nicht überall, wo "WLAN deaktivieren" drufsteht, auch WLAN deaktiviren drin ist.
Automatisch zusammengefügt:[hr]
War an migrafdt gerichtet.
Automatisch zusammengefügt:[hr]
Äh... an raspiprojekt, meinte ich.

Hallo an alle!

Ich gedenke zur Zeit (dh ich spiele mit dem Gedanken), aufgrund der erhöhten Geschwindigkeit des Raspberry Pi 3 Modell B vom Raspberry Pi 2 Modell B auf diesen umzusteigen; dh mir einen Raspberry Pi 3 Modell B zusätzlich zum Raspberry Pi 2 Modell B zuzulegen.

Dieser verfügt allerdings (wie allseits bekannt...) über integrietes WLAN, was sich damit beißt, dass ich die Pis unter anderem deshalb bevorzuge, weil sie sich durch NICHTausstatten mit einem WLAN-Stick (wenn man also einfach keinen verwendet...) sauber vom Internet (und etwaigen zwielichten Gesellen, die darin ihr Unwesen treiben...) trennen lassen, ohne bei jeder Gelegenheit selbst bei Abstellen des WLANs über irgendwelche Benutzeroberflächen im Internet die Uhrzeit abzufragen. Was in Zeiten von dekadenten Betriebssystemen (ich verweise hier auf Windoof... ) ja nichtmehr selbstverständlich zu sein kann.

Ich sehe also einen Hauptvorteil von den Pis darin, dass man sie, wenn man sie nicht im Netz haben will, durch simples "Ziehen" des WLAN-sticks davon fernhalten kann (und zwar wirklich sauber per physikalische Barriere...), sodass für mich das integrierte WLAN eher suboptimal ist.

Daher meine Frage:
Lässt sich das irgendwie so abschalten, dass der Pi nichts mehr vom Internet bekommt (per se also entweder nichtsmehr an Signalen empfangen kann oder alles, was er empfangen könnte, ignoriert) ? Dass er sich also sauber vom Internet fernhält, ohne regelmäßig irgendwelche "Ausnahmsweise-Internetzugriffe" zu machen?

Ich verwende Raspbian und bin mir leider nicht so sicher, wie man da überhaupt mit dem 3B ins WLAN kommt, geschweige denn verhindert, es zu kommen.

Ok. Danke, hast Recht.

Vielen Dank für die Erklärung (bezüglich der Übertragungsschritte). Was das Kreuzen der Kabel angeht: Ich habe damit eigentlich genau das gemeint, was du gemeint hast, als du sagtest, eine zweite Leitung solle einfach einen GND-Pin des Einen mit einem des Anderen verbinden. Soll ja kein Pi gegrillt werden.

Zufällig hab ich auch direkt zwei Jumperkabel gefunden. Werd also bei nächster Gelegenheit gleich mit dem Programmier-teil beginnen.
Automatisch zusammengefügt:[hr]
War an Andreas gerichted.

OK...
Du meinst also, statt so ein RS232-Kabel zu verwenden, sollte ich sowas improvisieren. Statt also so ein Kabel, wie man es kauft, anzuschließen, sollte ich mit zwei Kabeln (einfache Dräte, sozusagen...) zwei Pins der Pin-leisten der Pis miteinander verbinden (also kreuzen), oder?
Das ist eigentlich genau das, was ich mit meinem Kommentar sagen wollte. Da RS232-Kabel, wie man sie im Handel kriegt, eigentlich aus einem Bündel von 9 Drähten bestehen, von denen die meisten für mich überflüssig sind.

Das heißt, dass ich mich schlecht ausgedrückt habe, und du mich deshalb schlecht verstanden hast, und mir dabei zufällig genau das geraten hast, was ich meinte (nur weitaus besser erklärt). Danke für den Link!

Ich war in letzter Zeit lange nichtmehr online (hatte ne Menge Zeug am Hut...) und bin grad erst wieder online gegangen. Hab die neuen Vorschläge also erst überflogen. Ich halte nach wie vor jar's Vorschlag für den Besten, weil er der Einzige ist, der, genau wie ich es bezwecken wollte, nur einen Weg lässt und damit eine physikalische Barriere. Dazu meine "Improvisations-Idee":

Die RS232-Kabel, um die es dabei geht, haben ja im Allgemeinen 9 Pins. Von denen ist einer für die Datenübertragung von a nach b, einer für die von b nach a und der Rest für unterschiedliche "Bist du bereit"- Signale gedacht. Nur: wenn das nur in eine Richtung gehen soll, könnte (oder sollte...) man an sich ja die Datenübertragung von b nach a weglassen. Und damit fallen die ganzen "Bist du bereit"- Pins ja eh in ihrem Sinn weg; schließlich soll b entweder pausenlos auf das, was a ihm schickt, lauschen; und tut b es nicht, dann nur, weil irgendwas schief läuft, und dann kann es a eh egel sein, ob b kein Interesse an seinem Zeug mehr hat, was heißt, dass a auch dann getrost weiterschicken kann.

Also könnte man das ganze Prinziep an sich ja auf einen Pin beschränken: Der Sicherheits-Pi setzt die zu versendenden Dateien mittels einem Sender-programm in Bits um, gibt diese als Spannungen an diesem einen Pin aus, von wo sie zum Internet-Pi kommen, der sie einliest, wieder zu einer Datei zusammensetzt und abspeichert.
Statt so ein Kabel mit mehreren Pins zu nehmen, könnte man dann eigentlich improvisieren und lediglich einen Pin vom Sicherheits-pi mit einem vom Internet Pi verbinden.
Automatisch zusammengefügt:[hr]
Nur so... Ich bin mir grad nicht mehr sicher (ich arbeite relativ wenig mit diesen Pins...), aber KANN ein Pi überhaupt die über einen von seinen Pins ankommende Spannung "messen"? Also einlesen und protokollieren? Oder erkennt er sie nicht und kann lediglich welche geben? Wenn er nicht erkennen würde, ob der Sicherheits-Pi ihm über den dafür gedachten Pin Strom geben würde, wäre auch meine improvisierte Version von jar's Methode nonsense...
Automatisch zusammengefügt:[hr]
Also: Drähtchen von einem Pin von Pi A an einen von Pi B, über das die Daten-bits in Spannungen zugeschickt werden, und ein selbstgefrickeltes Sender- und Empfängerprogramm-
Ginge das, oder stelle ich mir das zu einfach vor?

Zu __deets__:
Eine physikalische Barriere ist eigentlich genau das, was ich damit erreichen wollte/ will. Um sozusagen 100% Hackersicherheit zu erhalten. Weil, wie du bereits so treffend feststelltest, selbst der beste Hacker keine physikalischen Barrieren überwinden kann. Das meine ich auch mit #19: dass ich eine Verbindung suche, die bereits durch die Hardware auf nur eine Richtung beschränkt ist. Ich habe mich da allerdings zugegebenermaßen echt schwammig ausgedrückt.

Das ist übrigens auch der Grund, weshalb ich ursprünglich an eine Funkverbindung dachte: Weil da der "Sicherheitspi" den Sender und der "Internetpi" den Empfänger haben könnte. Ist allerdings logischerweise (wie meigrafd bereits feststellte) denkbar ungeeignet, um komplexere Dateien zu übertragen.

Und zu jar:
Ich habe deinen Vorschlag, den du da in #5 gebracht hast, relativ schnell (zu schnell...) verworfen, weil du da von "kreuze [...] und umgekehrt" gesprochen hast, was mich auf eine zwangsläufig beidseitige Verbindung schließen ließ... Ich sollte mir da nächstens echt bischen mehr Zeit nehmen...

Ich werd mir deinen Vorschlag jetzt unbedingt nochmal genauer ansehen.... Wenn ich das richtig verstanden habe, meinst du, ich solle die Daten von diesen "Output-Stängeln" seitlich bei Pi 1 (deren terminus technikus mir bis dato unbekannt war) auf die "Input-Stängel" seitlich bei Pi 2 übertragen, oder? Sorry, aber über Begriffe stolper ich immer wieder. Wenn es das ist, was du meinst, und ich hänge nur "Output-Stängel" von Pi 1 an "Input-Stängel" von Pi 2, dann wäre das doch ebenfalls eine physikalische Beschränkung auf eine Richtung, also eine entsprechende Barriere, oder?

Danke für die Antwort. Und nochmal sorry, dass ich deinen Vorschlag derart verworfen habe. Ich werde deinen Rat, denke ich, befolgen. Hab ihn vorher wohl ziemlich übersehen.

Also nochmal sorry für meine Ignoranz.
Automatisch zusammengefügt:[hr]
Und die "sensiblen Daten" würden natürlich nicht direkt auf der Speicher-SD vom Pi, sondern an einen daran angeschlossenen USB mit regelmäßigem Backup landen. Der übrigens gepanzert ist und aus ca. 8 Meter Höhe auf Beton fallen könnte, ohne sich dabei was zu tun.
Automatisch zusammengefügt:[hr]
Wobei nicht zu übersehen ist, dass ich letzteres sogar eigenständig getestet habe.

OK...
Als Antwort auf eure Kritik:

Dass ich ein zu unübersichtlich schreibe, stimmt ( meigrafd). Dass ich zu viele" A"s und "B"s benutze, stimmt ebenfalls; das merkt man daran, dass du -glaube ich- in deiner Antwort "a" und "b" genau andersherum als ich gebraucht hast. Was aber meine Schuld ist. Zur Distanz zwischen beiden Pis (wegen Kabel und so): die lägen -wie gesagt- direkt nebeneinander. Also zwischen 50- und 5cm. Was wiederum belegt, dass ich mich unklar ausdrücke.

Zu jar: Du sagtest, dein erster Vorschlag sei rein Hardware gewesen. Ich sehe allerdings keinen Vorschlag von einem "jar". Entweder, ich übersehe da gerade etwas sehr rabiat (was durchaus sein kann...), oder du hast mir da als "Andreas" geschrieben. Ich habe daraufhin aber direkt __deets__'s Vorschlag gelesen, der mit den Worten "statt aber so etwas SELBST zu frickeln" ausdrückte, sein Vorschlag sei so etwas wie eine don't-do-it-yourself-methode des Vorherigen, was mich dazu brachte, insbesondere die in seinem Vorschlag angesprochenen Dinge (SSH bzw SFTP oder RSYNC) zu googeln. Die Resultate (ein weiterer Beleg dafür, dass man bei jeder Recherche entweder die Ungesichertheit von Internetinformationen oder GidF kennen lernen muss...) sprachen leider allesamt von einer übers Internet laufenden Methode (wobei ich selbst natürlich nicht wissen konnte, was SSH etc. sind, denn dann hätte ich hier ja auch nicht gefragt...), und mir selbst kam leider nicht der Gedanke, dass das Internet, wenn es "Internet" sagt, meistens nur versucht, Alternativen, die es zu ihm gibt, zu verschleiern, und in Wirklichkeit "Netzwerk" meint.

Und nochmal zu Kabeln & Co (siehe miegrafd): Das geht (räumlich) schon, denn beide Pis liegen direkt nebeneinander.

Also was ich eigentlich vorhabe:

Ich dachte mir, es wäre praktisch, wenn ein Pi, den man für Internetzugriffe verwendet, so "eingerichtet" wäre, dass er keine sensiblen Daten (also am Besten gar keine Dateien, mit denen man irgendwie arbeitet und die potentiell "wertvoll" sind, wie z.B. längere Texte...) enthält, da diese von etwaigen Viren beschädigt oder von Angreifern geraubt werden könnten.
Wenn trotzdem jemand reingelangt und "randaliert", könnte dadurch relativ wenig kaputt gehen (wo wenig ist, ist wenig gefärdet...). Allerdings wäre es schade ums Betriebssystem und etwaige Browser, die man sich dazu geladen hat. Also dachte ich mir, es wäre günstig, wenn der Pi nach jeder Benutzung (egal was passiert, also solange sich keiner an der Hardware vergreift...) wieder exakt derselbe ist wie zuvor. Indem z.B. die SD, die das Betriebssystem enthält, schreibgeschützt ist und alles, auf das Zugriff benötigt wird, bei jedem Boot im Arbeitsspeicher landet. Dann könnten etwaige Eindringlinge sich nur an der Kopie vorhandener Verzeichnisse im Arbeitsspeicher vergreifen, und da die und alle vorgenommenen Änderungen, Neuspeicherungen etc. nach dem Runterfahren vom RAM gelöscht werden, wäre die SD sicher vor Schäden.

Auf meine Anfrage dazu unter "Betriebssystem im Arbeitsspeicher ausführen" hat miegrafd mir eine hervorragende Antwort, nämlich bei jedem Boot var/log/ in den RAM zu verlegen, geboten.

Auf jeden Fall ist das eine hervorragende Idee, wie ich finde. Internet und "wertvolles Datengut" fein voneinander getrennt zu halten. Machen bekanntlich viele so. Den Pi für die Speicherung und Bearbeitung sensibler Dateien würde ich allerdings natürlich völlig ohne "Internet-Zugriffs-USB" lassen, sodass ich nichtmal versehentlich damit ins Netz kann.

Problem: Wenn man dann irgendwelche Dateien (im Sinne von Text usw.) "mit ins Internet nehmen" muss, um sie z.B. hochzuladen oder zu publizieren, muss man diese entweder direkt auf dem fürs Internet bestimmten Pi anlegen, wo man sie aber langfristig nicht speichern kann, was bei längeren Texten insbesondere aufgrund ihrer "Herstellungszeit" und ihrer Ausspähbarkeit während dieser unpraktisch wäre, oder aber man zieht sie vom Pi, der für sensible Informationen bestimmt ist, auf eine SD und von der im schreibgeschützten Zustand über einen Adapter auf den "Internet-Pi".

Problem dabei: Es ist langfristig extrem zeitaufwendig, das Zeug, das man ins Internet haben will (auch, um es z.B. zu verschicken, wobei man es, wenn es sehr sensibel ist, ja auch bereits auf dem "Sicherheits-Pi" verschlüsseln könnte), jedes mal mit einem umständlichen "auf die SD- SD raus- SD schreibschützen- SD rein- von der SD"-Manöver vom Sicherheits-Pi auf den Internet-Pi zu ziehen. Deshalb will ich eine Verbindung zwischen beiden aufbauen, über die Daten vom sicheren Pi auf den potentiell unsicheren Pi mit Internet-Anschluss übertragen werden können. Und deshalb sollte die Verbindung ja auch eine "Einbahnstraße" sein: Damit der Pi, der ans Internet geht, keine Lese- oder Schreibzugriffe auf den anderen Pi vornehmen kann und der Pi, der NICHT ans Internet geht, keine Lesezugriffe auf Daten, auf die der Andere Schreibzugriff hat, durchführen kann.

Danke für die guten Ratschläge. Ich habe mir die Möglichkeiten angesehen/ durchdacht und bin an folgendem Punkt hängengeblieben: Beide Ratschläge basieren auf einer Benutzung des Internets. Das ist an sich erstmal die beste Lösung, die mir zur Zeit zur Verfügung steht, ich wollte aber nochmal fragen: Gibt es auch eine Möglichkeit, das ganze mit einer "Hardware-Verbindung" zu machen? Die Idee (was ich eigentlich schon vorher hätte erwähnen sollen...) war nämlich eigentlich, a potenziell sensible Daten anzuvertrauen bzw. diese auf a zu bearbeiten und zu speichern, und für etwaige Internetzugriffe, die mit den Daten auf a erfolgen sollen (wenn Teile davon z.B. ins Netz geladen werden sollen...), b zu verwenden, diesen jedoch sozusagen von a aus "fernzusteuern". Wenn die Verbindung zwischen a und b übers Internet funktioniert, wäre das ganze irgendwie umsonst, da es letztlich dazu dienen soll, a vom Internet vollständig fernzuhalten und zugleich zu ermöglichen, Dateien, die ins Netz sollen, auf b zu bringen, von wo ich sie dann hochladen würde. Sozusagen will ich b vorschicken, sodass a sicher vor Angriffen aus dem Internet ist und höchstens b die ganze Scheiße abbekommt, da ja lediglich b ans Netz geht. Deshalb sollte die Verbindung ja auch unbedingt in Form einer Einbahn-Straße vorliegen: damit b keine Daten von a einlesen kann/ betrachten kann, die etwaige Angreifer aus dem Netz nicht in die Hände kriegen sollten, und a nichts von b einlesen kann, da b a -wenn es gehackt wird- schließlich einen Virus vor die Nase setzen könnte.

Internet <--> b <--a

Problem:
Wenn a und b übers Internet kommunizieren, bringt das Ganze nichts, da a ja eigentlich gerade KEINEN Internetanschluss haben soll.

Ich weiß, ich hätte vorher erwähnen sollen, wie ich mir das eigentlich denke. Tut mir leid. Hat trotzdem irgendjemand eine Ahnung, wie man von a Dateien nach b kriegt, OHNE a ans Netz zu lassen?
Kann übrigens verstehen, wenn jetzt alle, die mir geantwortet haben, ziemlich wütend auf mich sind. Ich hätte meine Frage präziser erläutern müssen.
Automatisch zusammengefügt:[hr]
a und b lägen übrigens räumlich direkt beieinander.

Hallo an alle!
Ich habe derzeit ein ähnliches Problem wie Siegal; ich will nämlich zwei Raspberry Pis (nennen wir sie der Einfachkeit halber einfach a & b...) so miteinander verbinden, dass Pi a Dateien in ein Verzeichnis in einem tmpfs im Arbeitsspeicher von Pi b verlegen kann (oder sonst irgendwie Dateien Pi b zur Verfügung stellen kann, die von diesem möglichst leicht abgerufen werden können...), aber weder a noch b in der Lage sind, Dateien des jeweils anderen auszulesen, und b in keinster Weise Dateien nach a verlegen kann (da b potentiell in die Hände unliebsamer Hacker fallen könnte und es daher ungünstig wäre, wenn b Dateien a "zum Einlesen vor die Nase setzen" könnte bzw. Dateien aus a einlesen (und somit kopieren...) könnten). Um auf jeden Fall auf Nummer sicher zu gehen, sollte diese Verbindung solcherart sein, dass allein die Beschaffenheit der Hardware es b oder a nicht gestattet, anders als vorgesehen vorzugehen (also sozusagen eine Verbindung, die WIRKLICH nur in eine Richtung funktioniert). Ich habe zuerst daran gedacht, das Zeug von a nach b per Funk zu schicken, aber das wäre (dem Impuls nach zu urteilen) vermutlich erstens eine "Holzhammermethode", und zweitens weiß ich nicht, wie b komplette per Funk verschickte Dateien überhaupt annehmen/ einlesen bzw. elegant darauf zugreifen kann... und ob man komplette Dateien überhaupt per Funk verschicken kann... und ob das dann auch eine SICHERE Verbindung wäre...

Ich wäre sehr erfreut, wenn mir da jemand sagen könnte, was da am besten geeignet wäre (es würde mir jede Menge Suchen und Durchwühlen verschiedener Möglichkeiten ersparen.)

Danke . Du hast mir sehr geholfen.

Zu read-only-systemen: Ich habe eine einfache Anleitung (-> https://www.joachim-wilke.de/b…15/04/14/archlinuxarm-ro/ <- ; Strategie 2) gefunden, um jene Verzeichnisse des verwendeten Betriebssystems (im Beispiel ArchLinux), auf die auf jeden Fall Schreibzugriff benötigt wird, auf einen USB-Stick zu verschieben, indem ein Symlink auf den USB gesetzt wird. Wenn man sie damit auf den Arbeitsspeicher anstelle des USB-Sticks verweisen würde und es so einrichten würde, dass sie bei jedem Bootvorgang erneut dorthin verschoben werden, und wenn man den Arbeitsspeicher durch Anschließen irgendeines Moduls dafür entsprechend erweitern würde, könnte man die verwendete SD doch eigentlich schreibschützen (vorausgesetzt, man nutzt ein älteres Modell des Raspberry Pi, das mit SDs statt MicroSDs arbeitet) und so den gewünschten Effekt dessen, dass man nach jedem Ab- und Wiedereinschalten wieder dasselbe vor sich hat, erzielen. Nur - funktioniert das so, wie ich mir das grad vorstelle, und wenn ja, wie verschiebt man das Zeug auf den Arbeitsspeicher anstelle des USBs? Beim USB geht das mit "/mnt/usbstick/src", wobei "usbstick" der Name vom USB ist und src (sofern ich alles richtig verstanden habe) der Name des zu verschiebenden Verzeichnisses ist. Was "sagt" man, wenn man Arbeitsspeicher statt USB-stick meint? Hat der auch einen bestimmten "Namen"?

Danke an alle, die evtl antworten werden.
Automatisch zusammengefügt:[hr]
Das Ergebnis soll sein, den RPi so zu verwenden, dass keiner (also nicht mal solche, die ihn benutzen, also in ihm drin sind, wie z.B. ich oder etwaige Hacker, falls welche reinkommen sollten), in der Lage ist, Änderungen vorzunehmen, die beim nächsten Abschalten- und Wiederhochfahren noch da sind. Sozusagen sollen unerwünschte Veränderungen jedes Mal, wenn ich abschalte, wieder "rausgekickt" werden, weil sie schließlich alle auf dem Arbeitsspeicher gespeichert werden müssen, der ja bekanntlich flüchtig ist.
Automatisch zusammengefügt:[hr]
Und ich habe also garnicht vor, bleibende Dateien auf dem Pi zu verwalten (im Sinne von Schreiben, speichern usw.), insofern spielt die Tatsache, dass dies damit unmöglich gemacht wird, keine Rolle. Es würde mir also reichen, damit ins Internet zu kommen und evtl. auch Dateien auf dem üblichen Weg von einem USB in dieses zu verschieben (auf gmx und so).
Automatisch zusammengefügt:[hr]
Dateien, die ich vom RPi ins Internet verschieben muss, würde ich dann einfach von einem anderen Computer auf eine zweite SD ziehen, diese dann schreibschützen und sie von der dann auf den RPi ziehen. Anschließend würde ich sie natürlich wieder "entschützen"

Ginge da nicht auch so eine Art "Rahmen", den man für die Überkopier-angelegenheit usw. um ein bereits existentes Betriebssystem "drumherumlegt"? Der dann dafür sorgt, dass dieses im Arbeitsspeicher läuft und dorthin gebooted wird?

Danke für die Antwort.
Automatisch zusammengefügt:[hr]
Ich will die SD natürlich nicht nach dem Einlegen in den pi, sondern VORHER schreibschützen (nur falls es so geklungen haben sollte, als hätte ich vor, sie jedes mal nach dem Einlegen schreibzuschützen, und nachher wieder zu "entschützen"). Meine Überlegung war, dass eine schreibgeschützte SD keine Änderungen annimmt (was an sich ja selbsterklärend ist...); da sie so allerdings auch nicht für einfache Vorgänge wie z.B. Internetzugriffe zu verwenden ist, wollte ich das Betriebssystem einfach für jede Benutzung erneut auf den pi kopieren lassen, da es dort ja nach jedem Abschaltvorgang vollständig gelöscht wird und so ebenfalls keine bleibenden Änderungen vorgenommen werden können. Ginge meine Idee, wenn der Arbeitsspeicher größer (=groß genug) wäre? Ich habe nämlich von jemandem gehört, bei Computern mit größerem Arbeitsspeicher sei dies möglich, bzw. er habe es bei diesen genau so gemacht, wie es mir für den Raspberry Pi vorgestellt habe.