Forum: PC Hard- und Software Linux RAM Disk im Dateimanager für normale User


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Albert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

ich versuche unter Debian 10 mit Mate Desktop eine RAM Disk ohne Cache 
für normale User einzurichten.

Meine /etc/fstab
ramdisk    /tmp/ramdisk    ramfs    noauto,user,size=256M,mode=0770    0    0

Dann als User in der Bash
mkdir /tmp/ramdisk
mount ramdisk

Ein Laufwerk wird mir im Dateimanager leider nicht angezeigt und wenn 
ich über das Dateisystem zum Ordner /tmp/ramdisk navigiere und versuche, 
dort Dateien einzufügen, bekomme ich die Fehlermeldung, dass am Ziel 
nicht genügend Platz frei ist (0 Bytes verfügbar).

Wie kann ich die RAM Disk einrichten und ohne Reboot auch im 
Dateimanager als Laufwerk benutzen?

Vielen Dank und viele Grüße
Albert

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Leg den Mountpoint nach /media. Dortige Mounts werden auf dem Desktop 
und im Nemo gezeigt. Solche in /mnt und /tmp jedoch nicht (Mint 19).

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Was zeigt denn df an?
ramfs sollte man eigentlich eher nicht benutzen, denn es hat den 
Nachteil, dass es wachsen kann, bis der RAM-Speicher voll ist und der 
Rechner unbenutzbar wird. Eine mount-Option "size" gibt es dafür nicht. 
Besser tmpfs, bei dem das geht.

von Albert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Mountpoint /media war schon mal hilfreich. Mit den 
Dateimanagern scheint es Probleme mit RAMFS zu geben. Anders als bei 
MATE kann ich unter XFCE die Fehlermeldung mit "Trotzdem kopieren" 
übergehen. Vielleicht handelt es sich ja um eine schlecht kommunizierte 
Barriere, damit User das System nicht versehentlich durch Überschreiten 
des Speichers zum Absturz bringen. Mit dem Terminal geht es als user 
übrigens einwandfrei.

df zeigt bei mir keine eingebundenen Laufwerke mit RAMFS an, es werden 
nur die mit TMPFS korrekt angezeigt und die lassen sich auch normal mit 
den Dateimanagern nutzen.

Kann man bei TMPFS sicherstellen, dass nur im RAM gearbeitet wird und 
nicht z.B. der swap genutzt wird?

Vielen Dank für eure Hilfe
Albert

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
Albert schrieb:
> Kann man bei TMPFS sicherstellen, dass nur im RAM gearbeitet wird und
> nicht z.B. der swap genutzt wird?

ist nicht Zielführend, wobei das (unbekannte) Ziel relativ egal ist.
Was hilft es dir, wenn bei Speicherknappheit zwar die Daten im RAM 
gelockt sind, aber dein Anwendungsprogramm dafür praktisch von HDD und 
nicht aus dem RAM läuft?

Zum Vermeiden von Paging auf die Platte: Großzügig bemessenes 
"zram-swap"(*), HDD-Swap abschalten oder mit sehr niedriger Prio, und an 
der vm-"swappiness" drehen (nahe bei, aber größer als 0).


*) debian: "zram-tools" installieren, config in /etc/default/zramswap

: Bearbeitet durch User
von Andreas M. (amesser)


Bewertung
1 lesenswert
nicht lesenswert
Warum brauchst Du überhaupt eine Ramdisk? Im übrigen sollte /tmp bei 
Debian standardmäßig schon eine Ramdisk (tmpfs) sein, da das bei systemd 
schon lange die Standard-Einstellung ist.

von Karl K. (karl2go)


Bewertung
-2 lesenswert
nicht lesenswert
Soweit ich das in meinen Docs zum Raspi sehe, musst Du erst den 
Mountpoint im Filesystem erzeugen

sudo mkdir /tmp/ramdisk

und denn in /etc/fstab

tmpfs /tmp/ramdisk tmpfs nodev,nosuid,relatime,size=256M 0 0

dann mounten mit

sudo mount -a

Beim Neustart wird es automatisch gemountet.

Andreas M. schrieb:
> Warum brauchst Du überhaupt eine Ramdisk?

Ich hab zum Beispiel auf den Raspi eine, in der Kamerabilder und Daten 
geloggt werden, auf die andere Programme zugreifen, die aber nicht 
dauerhaft gehalten werden müssen.

Da werden Snapshots der Kamera gespeichert, um daraus einen 
Zeitraffer-Film zu machen. Danach können die wieder weg.

von Albert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Zum Vermeiden von Paging auf die Platte: Großzügig bemessenes
> "zram-swap"(*), HDD-Swap abschalten oder mit sehr niedriger Prio, und an
> der vm-"swappiness" drehen (nahe bei, aber größer als 0).

Verstehe ich das richtig, dass man mit genug RAM nur den HDD-Swap 
abschalten muss? Laut "swapon --show" gibt es bei mir nur die bei der 
Installation angelegte Swap-Partition sdb3. Reicht also ein "swapoff 
/dev/sdb3" direkt vor dem Mounten des tmpfs Laufwerks? Die vm.swapiness 
scheint das Verhalten zu beeinflussen, wann geswapt wird, aber es kann 
vermutlich nur der eingerichtete HDD-Swap (z.B. /dev/sdb3) genutzt 
werden?

Karl K. schrieb:
> sudo mkdir /tmp/ramdisk

Andreas M. schrieb:
> Im übrigen sollte /tmp bei
> Debian standardmäßig schon eine Ramdisk (tmpfs) sein, da das bei systemd
> schon lange die Standard-Einstellung ist.

Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja 
der Wechsel auf /media.

Vielen Dank für eure Tipps
Albert

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Wenn kein Swap da ist, kann nicht geswappt werden.
Wann du das abschaltest, ob du das tmpfs vorher oder nachher mountest 
ist egal.
Wenn du den Swap später wieder einschaltest, kann er auch wieder 
verwendet werden. Auch hier ist der mount-zeitpunkt des tmpfs egal.

Aber die Plan das Swapping für die Ramdisk abzuschalten deutet für mich 
erstmal darauf hin, dass sich bei dir irgendeine fehlerhafte fixe Idee 
festgesetzt hat (*), vermutlich wegen Unverständnis der 
Linux-Speicherverwaltung.

Albert schrieb:
> mit genug RAM

swappt er die Ramdisk sowieso nicht auf die Platte. Du hast also nicht 
genug Ram. Dann ist es aber schlecht, ihm das Swapping generell zu 
verbieten.

Deshalb mein Vorschlag mit dem ZRam und dem beibehalten der HDD als 
"last Resort".



Edit (*): Soll das vielleicht irgendein Sicherheits-Feature werden, dass 
die User ihren Pr0n nicht auf der Festplatte verewigen? Da würde ich dir 
eher zu einer verschüsselten Swap-Partition raten (+verschlüsseltes 
Root+Home natürlich).

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Albert schrieb:
> Verstehe ich das richtig, dass man mit genug RAM nur den HDD-Swap
> abschalten muss?

Nö, warum sollte man das müssen? Wenn man genug RAM hat, wird sowieso 
nicht ausgelagert.

Und wie Ernst schon schreibt:

Εrnst B. schrieb:
> Was hilft es dir, wenn bei Speicherknappheit zwar die Daten im RAM
> gelockt sind, aber dein Anwendungsprogramm dafür praktisch von HDD und
> nicht aus dem RAM läuft?

Falls nicht genug RAM da ist, willst du nicht, dass er die Daten der 
RAM-Disk zwingend dort drin hält. Mit eingeschaltetem Swap würde das 
nämlich bedeuten, dass die Programme ausgelagert und damit elends 
langsam ausgeführt werden, so dass deine superschnelle RAM-Disk nix mehr 
bringt. Und ohne Swap kommt der OOM-Killer und schießt dein Programm 
einfach ab, wenn mehr Platz benötigt wird. Also lass das System sich 
lieber darum kümmern.
Einzig die schon angesprochene swappiness umzustellen, könnte sich 
lohnen, um dem System Präferenzen zwischen Festplatten-Cache und 
Auslagerung zu geben.

: Bearbeitet durch User
von Andreas M. (amesser)


Bewertung
1 lesenswert
nicht lesenswert
Albert schrieb:
> Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja
> der Wechsel auf /media.

Das Konzept "Laufwerke" existiert unter Linux nicht. Das unter /media 
gemountete Dateisysteme zufälligerweise in Deinem Linux-Dateimanager 
explizit erscheinen ist ein spezifisches Verhalten Deines Dateimanagers. 
Dieses lässt sich aber nicht so ohne weiteres auf jeglichen 
Linux-Dateimanager verallgemeinern. (Es gibt unter Linux nicht "den" 
Dateimanager)

Was genau willst Du eigentlich damit erreichen? Für was willst Du die 
Ramdisk benutzen bzw. warum brauchst du unbedingt eine ramdisk dafür? 
Warum muss das "im Dateimanager erscheinen"?

von 🐧 DPA 🐧 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Wenn man genug RAM hat, wird sowieso nicht ausgelagert.

Hängt das nicht von der eingestellten swappiness ab?

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Albert schrieb:
>> Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja
>> der Wechsel auf /media.
>
> Das Konzept "Laufwerke" existiert unter Linux nicht. Das unter /media
> gemountete Dateisysteme zufälligerweise in Deinem Linux-Dateimanager
> explizit erscheinen ist ein spezifisches Verhalten Deines Dateimanagers.

/media ist normalerweise für Wechselmedien (per pmount oder einem 
graphischen Pendant) gedacht.

> Dieses lässt sich aber nicht so ohne weiteres auf jeglichen
> Linux-Dateimanager verallgemeinern. (Es gibt unter Linux nicht "den"
> Dateimanager)

Ja. Meiner zeigt auch mount-Points außerhalb von /media an. Ob er Dinge 
in /tmp auch anzeigen würde, weiß ich aber nicht. Für von Hand temporär 
gemountete Dateisysteme nutze ich in der Regel /mnt.

> Was genau willst Du eigentlich damit erreichen? Für was willst Du die
> Ramdisk benutzen bzw. warum brauchst du unbedingt eine ramdisk dafür?
> Warum muss das "im Dateimanager erscheinen"?

Für mich wäre die Frage, warum es so unbedingt nicht auslagern darf, 
selbst wenn das bedeutet, dass die Stabilität des Systems gefährdet ist.

🐧 DPA 🐧 schrieb:
> Rolf M. schrieb:
>> Wenn man genug RAM hat, wird sowieso nicht ausgelagert.
>
> Hängt das nicht von der eingestellten swappiness ab?

Es hängt von der Nutzung des Platten-Cache und der swappiness ab. 
Kopiert man viele Dateien umher, wird ggf. Auslagerung betrieben, um 
mehr Platz für den Cache zu bekommen. Mit der swappiness kann ich 
steuern, wie sehr er das macht. swappiness=0 bedeutet, erst dann 
auslagern, wenn's gar nicht anders geht. Ich würde dann zumindest das 
nehmen, statt swap ganz abzuschalten.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh 
allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix 
weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen 
Unterschied zwischen RAM-Disk und SSD.
Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts 
dauerhaft gespeichert haben will.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts
> dauerhaft gespeichert haben will.

Oder wenn man es mit einem schreibschwachen Medium wie einer µSD-Card zu 
tun hat, also bei Raspberry & Co.

von LOL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Peter D. schrieb:
> Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh
> allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix
> weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen
> Unterschied zwischen RAM-Disk und SSD.
> Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts
> dauerhaft gespeichert haben will.

Das wäre mir neu. Ja, sowohl Linux als auch Windows cachen massiv. Bei 
Linux wird der komplette freie RAM für den Cache benutzt, um bereits 
angeforderte Daten weiterhin vorzuhalten oder spekulativ vorauszulesen.

Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen 
Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig 
wird zwar ins RAM geschrieben, zeitgleich aber auf Platte. Und "fertig" 
bekommt ein Programm erst gemeldet, wenn die Daten auf der Platte 
angekommen sind (writethrough).

Ja, einige Dinge werden je nach Dateisystem zu Transaktionen 
zusammengefasst geschrieben. Und einige Dateisysteme schreiben 
regelmäßig aktualisierte Daten/Metadaten erst aller xx ms, um die 
Schreiblast zu reduzieren. Beides ist aber explizit kein Schreibcache 
der erst schreibt "wenn nichts zu tun ist".

Im Gegenteil, Linux macht sogar einige Klimmzüge um den in HDD/SSD 
integrierten Schreibcache hart umgehen zu können (barriers etc.), wenn 
Daten des Dateisystems geschrieben werden sollen, damit die 
Fertigmeldung auch wirklich "feritg" bedeutet.

Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen 
beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s), 
sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99% 
fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte 
auf dem Medium ist.

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
LOL schrieb:
> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen
> Schreibcache im RAM, der beschleunigend wirkt (writeback).

Du kannst bei Linux exakt einstellen, wieviele KB wie lange im 
Schreibcache vorgehalten werden dürfen, bevor ein erzwungener Writeback 
auf die Platte erfolgt.

vm.dirty_writeback_centisecs, dirty_background_bytes, dirty_ratio usw.

Nur wenn die Applikation (z.B. Datenbanken) es explizit anfordert, wird 
auf den endgültigen Abschluss der Schreiboperation gewartet.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
LOL schrieb:
> Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen
> beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s),
> sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99%
> fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte
> auf dem Medium ist.

Ich kenne das eher so, dass der USB-Stick munter weiter blinkt, nachdem 
das Programm schon lange fertig ist. Und ein unmount braucht auch noch 
eine ganze Weile. Erst wenn der auch meldet, dass er fertig ist, sind 
die Daten wirklich auf dem Medium angekommen.

von LOL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> LOL schrieb:
>> Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen
>> beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s),
>> sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99%
>> fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte
>> auf dem Medium ist.
>
> Ich kenne das eher so, dass der USB-Stick munter weiter blinkt, nachdem
> das Programm schon lange fertig ist. Und ein unmount braucht auch noch
> eine ganze Weile. Erst wenn der auch meldet, dass er fertig ist, sind
> die Daten wirklich auf dem Medium angekommen.

Okay, dann macht meine GUI (Xfce/Xubuntu) das anders als deine GUI (oder 
Distribution). Ich warte bei 99% immer ewig. Das von dir beschriebene 
Verhalten führt zum Schreddern von Daten, wenn $User einfach den Stick 
herausreißt. Muss aber eine Programmier/Distributionsentscheidung 
gewesen sein, der Kernel verhält sich so wie ich schrieb, es sei denn 
man fordert ihn zu Abweichungen auf.

Kann aber u.U. auch am Stick/Medium hängen:
Es gibt irgendein "Mode" bit, welches bei Massenspeichern gesetzt sein 
(kann) und den Stick entweder zum Wechseldatenträger oder zur Festplatte 
macht. Das verursacht unter Windows subtile Unterschiede beim Booten, 
unter Linux u.U. beim Cache-Verhalten.

Aber letztendlich wurde in dem Thread auch schon alles gesagt, was 
notwendig ist:

1.)
tmpfs verwenden

2.)
/tmp sollte idealerweise schon tmpfs sein und kann 50% RAM einnehmen

3.)
In /tmp eine weitere Ramdisk zu bauen ist deswegen nicht trivial, da die 
Unterverzeichnisse nach dem Neustart erst einmal weg sind und neu 
angelegt werden müssen. (Systemd service schreiben, /etc/fstab alleine 
reicht nicht).

4.)
/media ist der Ort, den die meisten GUIs nach Wechselmedien durchsuchen.

5.)
Um Schreibzugriffe zu sparen gibt es fertige Lösungen (zram, diverse 
Scripte aus der OpenWRT/Raspi Ecke)

von LOL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> LOL schrieb:
>> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen
>> Schreibcache im RAM, der beschleunigend wirkt (writeback).
>
> Du kannst bei Linux exakt einstellen, wieviele KB wie lange im
> Schreibcache vorgehalten werden dürfen, bevor ein erzwungener Writeback
> auf die Platte erfolgt.
>
> vm.dirty_writeback_centisecs, dirty_background_bytes, dirty_ratio usw.
>
> Nur wenn die Applikation (z.B. Datenbanken) es explizit anfordert, wird
> auf den endgültigen Abschluss der Schreiboperation gewartet.

Jain? Aber ja, das habe ich übersehen/vergessen, entschuldigung dafür.

Diese Optionen gibt es und die Beschreibung ist richtig, das Verhalten 
zeigt sich aber AFAIK nur für "Background Writes", d.h. wenn die 
Applikation nicht fsync, sync, O_direct oder fdatasync macht wenn 
wirklich geschrieben werden soll.
Das machen alle mir bekannten z.b. beim Speichern in Calc oder beim 
beenden - sogar Datenbanken (zumindenst fürs WAL).

Wenn die Anwendung das OS nicht auffordert zu schreiben, müssen die 
Daten auch nicht sofort geschrieben werden, das machen andere OS auch 
so, ja.

Schreibcache habe ich bei meinem Post als den Quark angesehen, den 
Raidkontroller machen, wenn sie Batteriegepuffert Gigabyteweise Daten 
vorhalten und mir erzählen, die seinen auf Platte.

Die genannten Optionen sorgen nach meinem Dafürhalten in der Praxis nur 
dafür, das alle Daten nach spätestens diesem Zeitraum/Volumen auf der 
Platte landen, egal ob angefordert oder nicht. Eine GUI beim Kopieren 
auf USB sollte definitiv sync anfordern.

Das ist eher so wie "BUFFERS=99,0" unter DOS, wenn man es nicht massiv 
anpasst.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Albert schrieb:
> ich versuche unter Debian 10 mit Mate Desktop eine RAM Disk ohne Cache
> für normale User einzurichten.

Bitte verzeih', aber warum möchtest Du das tun?

von Phil J. (exloermond)


Bewertung
1 lesenswert
nicht lesenswert
/dev/shm ?

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht *keinen*
> Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig
> wird zwar ins RAM geschrieben, zeitgleich aber auf Platte.

Verzeihung, aber ich fürchte, doch. Es sei denn, Du hast Deine Datei mit 
speziellen Flags für open(2), wie O_DIRECT geöffnet.

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh
> allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix
> weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen
> Unterschied zwischen RAM-Disk und SSD.

Das ist falsch. Viele Anwendungen (der Klassiker: Datenbanken) flushen 
ihre Daten mehr oder weniger regelmäßig [1]. Und dann werden die auf die 
Platte geschrieben, ganz egal wieviel RAM noch frei ist.

In manchen Situationen will man einfach eine RAMdisk haben. Der TE 
schildert seine Beweggründe ja nicht, insofern bin ich natürlich genauso 
skeptisch wie alle anderen hier.

Und die Fixierung auf irgendeinen verk*ckten Dateimanager und seine 
"Laufwerke" ist auch Blödsinn. Nicht zuletzt hat praktisch jedes Linux 
unter /dev/shm schon ein tmpfs mit standardmäßig 50% der RAM-Größe 
gemounted. Das ist auch für alle Anwender schreibbar.

[1] nicht notwendigerweise mit fsync(). Es gibt auch noch O_DIRECT und 
Konsorten.


LOL schrieb:
> Linux (und Windows AFAIK auch) hat mit voller Absicht keinen
> Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig
> wird zwar ins RAM geschrieben, zeitgleich aber auf Platte. Und "fertig"
> bekommt ein Programm erst gemeldet, wenn die Daten auf der Platte
> angekommen sind (writethrough).

Das ist in dieser Allgemeinheit falsch. write() und Co. schreiben 
erstmal nur in den buffer cache. Erst fsync() bzw. fflush() - je nachdem 
auf welcher Ebene du unterwegs bist - schreibt die Daten auf die Platte. 
Nur wenn du open() mit dem Flag O_DSYNC machst, umgeht Linux den buffer 
cache beim Schreiben. Mit O_DIRECT auch beim Lesen. man 2 open

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.