| 1 |
allgemeine Kategorie / Tutorials / Btrfs Speicherplatz belegung Grafisch darstellen |
am: Heute um 09:14:43 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Hallo Suletuxe,
ich habe mich wieder etwas tiefer mit dem Dateisystem Btrfs beschäftigt. Dieses Mal wollte ich herausfinden, wie mein System Daten und Dateien physisch auf dem Datenträger allociert. Ich wollte besser verstehen, wie ein Copy-on-Write (COW) Dateisystem im Laufe der Zeit fragmentiert und ob das für mich relevant wird, vor allem weil ich plane, Btrfs auch auf HDDs einzusetzen.
TLDR;
Ich habe mir per btrfs-heatmap die physische Belegung meines Laptops anzeigen lassen, um Fragmentation, Chunk-Verhalten und die Arbeitsweise von Btrfs über die Zeit zu beobachten. Zusätzlich habe ich mir einen systemd-Service samt Timer gebaut, der täglich eine Heatmap erzeugt.
Hauptteil:
Um mir wortwörtlich ein besseres Bild zu machen, habe ich mein Btrfs-Dateisystem mit dem Tool btrfs-heatmap grafisch darstellen lassen.
Bild Dateisystem Übersicht:
Bild Dateisystem Übersicht
Die obere Grafik wird über eine Hilbert-Kurve dargestellt. Diese Kurve ermöglicht es, lineare Daten platzsparend in einem Quadrat abzubilden. Die erste physische Adresse liegt unten links, schlängelt sich dann nach oben und endet unten rechts.
Zur Illustration:
Die Farbbedeutungen in der Übersicht:
- Blau = Metadaten
- Weiß = allocierter Speicher
- Schwarz = unallocierter Speicher
Das dargestellte Bild zeigt Btrfs im SSD-Modus. Hier kümmert sich Btrfs weniger darum, Daten zusammenhängend abzulegen, da Fragmentation auf SSDs praktisch keine Rolle spielt. Besonders gut erkennbar ist, dass sich Metadaten am Anfang des Datenträgers sammeln. Dieser Bereich ist bereits so stark gefüllt, dass Btrfs etwa in der Mitte der Platte einen neuen Metadaten-Chunk allociert und begonnen hat, ihn zu beschreiben.
Man sieht außerdem im oberen linken Bereich größere unallocierte Lücken innerhalb bereits allocierten Regionen. Vermutlich hatte ich dort große Dateien abgelegt, die einen gesamten Chunk (ca. 1 GiB) vollständig gefüllt hatten und beim Löschen wieder komplett freigegeben wurden. Da Btrfs versucht, Chunks möglichst vollständig zu füllen, bevor neue angelegt werden, entstehen solche großen freien Bereiche.
Wichtig ist die Unterscheidung zwischen Chunk-Allocation und Datei-Fragmentation. Chunk-Lücken bedeuten nicht automatisch, dass Dateien fragmentiert sind. Innerhalb eines Chunks kann eine Datei dennoch an vielen Stellen verteilt liegen oder sich sogar über mehrere Chunks erstrecken. Für eine möglichst zusammenhängende Ablage sorgt btrfs filesystem defragment. Das habe ich in einem eigenen Beitrag genauer beschrieben:
BTRFS – balance vs defragment oder was sind diese Chunks und Extents für …
Zum Vergleich habe ich die Metadaten-Chunks vom Anfang und aus der Mitte der Platte im Detail aufgenommen:
Metadaten-Chunk 1
Metadaten-Chunk 2
Was die Farben im Detail bedeuten, steht in der btrfs-heatmap-Dokumentation
Gerade Metadaten-Chunks fragmentieren stark. Das ist logisch, da dort die meisten Änderungen stattfinden. Daten selbst bewegen sich bei einem COW-Dateisystem dagegen kaum – es werden eher neue Extents angehängt. Metadaten müssen jedoch ständig aktualisiert werden, um auf neue Daten zu zeigen.
Um die Entwicklung des Dateisystems über längere Zeit zu beobachten, habe ich mir einen systemd-Service mit Timer gebaut, der täglich eine neue Heatmap erstellt. Sobald ich genug Bilder gesammelt habe, werde ich daraus ein Daumenkino basteln, um Chunk-Bewegungen sichtbar zu machen.
Systemd Service:
Hier der systemd-Service (Template) für die tägliche Heatmap:
[Unit]
Description=Generiert eine Heatmap eines Btrfs Dateisytems unter / gemountet ist.
[Service]
Type=oneshot
WorkingDirectory=/home/%i/Bilder/btrfs-heatmap
Group=%i
ExecStart=/usr/bin/btrfs-heatmap /
ProtectSystem=strict
ReadWritePaths=/home/%i/Bilder/btrfs-heatmap
PrivateTmp=true
PrivateDevices=true
LockPersonality=true
ProtectClock=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectControlGroups=true
RemoveIPC=true
RestrictSUIDSGID=true
RestrictRealtime=true
SystemCallFilter=@system-service @basic-io @file-system ~@privileged
IPAddressDeny=any
NoNewPrivileges=true
RestrictFileSystems=btrfs
|
|
Datei: /etc/systemd/system/btrfs-heatmap@.service
[Unit]
Description=Startet 1x am Tag den btrfs-heatmap@.service
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
|
|
Datei: /etc/systemd/system/btrfs-heatmap@.timer
Zur Nutzung legt man im Heimatverzeichnis den Ordner $HOME/Bilder/btrfs-heatmap an. Dieser ist der einzige Pfad, in dem der Service schreiben darf. Anschließend aktiviert man den Timer. Hinter dem @-Zeichen im Servicenamen steht der Benutzername, damit systemd die Pfade korrekt ersetzt.
So wüdre der Timer aktiviert werden:
# Falls die zwei Dateien grade Frisch angelegt worden sind einmal Daemon neu starten
sudo systemctl daemon-reload
sudo systemctl enable --now btrfs-heatmap@sebastian.timer
|
|
Der erste lauf würde dann am nächsten Tag statfinden. Möchte man gleich ein Bild Anfertigen dann einmal bitte den Service direkt starten:
sudo systemctl start btrfs-heatmap@sebastian.service
|
|
Fazit:
Die Heatmaps geben ein sehr anschauliches Gefühl dafür, wie Btrfs intern mit Chunks, Metadaten und Daten arbeitet. Gerade langfristige Beobachtungen zeigen gut, welche Bereiche sich dynamisch verändern. Der tägliche systemd-Export erleichtert das enorm und erlaubt spannende Auswertungen über Wochen oder Monate.
Quellenangabe:
LG
Sebastian |
   |
| 2 |
allgemeine Kategorie / Allgemeine Diskussionen / Erfahrungsbericht/Lernprozess Tonaufnahme mit PipeWire |
am: 22. November 2025, 11:54:04 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Hallo Suletuxe,
ich erweitere aktuell mein Verständnis rund um digitale Tonaufnahmen. Ausgelöst wurde das Ganze, weil ich das Audiosignal meines Notebooks für ein anderes Gerät aufzeichnen wollte. Damit ich nicht blind eine Aufnahme starte, habe ich mich zuerst mit den Grundlagen beschäftigt. Mein Ziel war eine Aufnahme in 3x bis 4x facher Geschwindigkeit, die ich anschließend wieder auf Normaltempo dehnen kann.
TLDR;
Ich erkläre hier kurz meinen Weg zu einer sauberen Aufnahme über PipeWire, warum ich 96 kHz als Sample Rate gewählt habe und wie ich das Signal direkt von der Quelle aufnehmen konnte.
Hauptteil:
Die Sample Rate beschreibt, wie oft pro Sekunde ein analoges Signal abgetastet wird. Für die Rekonstruktion einer Frequenz benötigt man mindestens das Doppelte ihrer höchsten vorkommenden Frequenz. Diese Regel nennt sich das Nyquist-Kriterium. Bei 48 kHz Sample Rate lassen sich daher Frequenzen bis etwa 24 kHz erfassen. Wird die Sample Rate zu niedrig gewählt, falten sich höhere Frequenzen in tiefere Bereiche zurück. Dieser Effekt ist als Aliasing bekannt.
Die Bittiefe bestimmt den Abstufungsgrad der Lautstärke (Amplitude). Je höher die Bittiefe, desto weniger Rundungsfehler entstehen. Diese Fehler machen sich als Quantisierungsrauschen bemerkbar. Da die menschliche Stimme grob im Bereich bis etwa 10 kHz liegt und typischerweise einen Dynamikumfang von ungefähr 50–70 dB hat, reicht eine Bittiefe von 16 Bit für Sprachaufnahmen üblicherweise aus.
Da ich meine Quelle mit vierfacher Geschwindigkeit abspielen wollte, erhöht sich die effektive Frequenzlage entsprechend. Um alle relevanten Frequenzen verlässlich abzudecken, muss ich die Aufnahme-Sample-Rate also ebenfalls erhöhen. Theoretisch würde eine Sample Rate von etwa 80 kHz reichen, praxisnah wählte ich 96 kHz als Standardwert mit etwas Luft nach oben.
Für die praktische Umsetzung musste ich verstehen, wie ich unter PipeWire das PCM-Signal direkt von der Quelle aufnehmen kann. Ein Node ist bei PipeWire ein Audiopunkt, der Daten liefert oder empfängt. Ein Sink nimmt Audio entgegen, ein Monitor-Port bietet Zugriff auf das Signal eines Sinks. Für meine Aufnahme wollte ich jedoch eine direkte Quelle (Node) und keinen gemischten Ausgang. Das ermöglicht eine stille Aufnahme, während das System weiterhin andere Sounds wiedergeben kann.
Die systemweite Sample Rate stellte ich über eine Drop-In-Konfiguration auf 96 kHz um. Anschließend nutzte ich pw-record aus dem Paket pipewire-audio, womit ich direkt die gewünschte Quelle abgreifen konnte.
Beispiele:
# pw-record mit direkter Quellenangabe
pw-record --target <Node-ID> --rate 96000 --channels 1 aufnahme.flac
# Beispielhafte Drop-In-Konfiguration für PipeWire (system.conf.d)
# /etc/pipewire/pipewire.conf.d/10-samplerate.conf
context.properties = {
default.clock.rate = 96000
default.clock.allowed-rates = [ 48000 96000 ]
}
|
|
Fazit:
Durch die moderne Informatonstechnologie ist es leicht möglich, sich auch in komplett neue Themenbereiche einzuarbeiten. Grundlagenwissen hilft enorm, um technische Entscheidungen bewusst zu treffen. Jetzt kann ich die Theorie in der Praxis weiter festigen und Erfahrungen sammeln. Sollte ich einzelne Aspekte falsch eingeordnet haben, freue ich mich über Hinweise, um mein mentales Modell weiter zu verfeinern.
Quellenangabe:
LG
Sebastian |
| |
| 3 |
allgemeine Kategorie / Installation, Einrichtung und Systempflege / yt-dlp benötigt eine externe JavaScript Runtime für den Youtube Support |
am: 14. November 2025, 19:08:12 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Bei einem Systemupdate ist mir eine neue optionale Abhängigkeit von yt-dlp aufgefallen. Die Einführung von yt-dlp-ejs hat einen technischen Hintergrund, der für viele Anwender relevant ist – insbesondere für Nutzer, die weiterhin zuverlässig YouTube-Videos extrahieren möchten.
TLDR;
Ab Version 2025.11.12 benötigt yt-dlp eine externe JavaScript-Runtime wie Deno für nicht-veralteten YouTube-Support. Das Paket yt-dlp-ejs bindet diese Runtime ein und sollte installiert werden, wenn YouTube-Unterstützung erforderlich ist.
Hauptteil:
Mit der Version 2025.11.12 hat das Projekt yt-dlp wesentliche Änderungen an der internen Verarbeitung der YouTube-Extraktion vorgenommen. Deno wird dabei als bevorzugte Laufzeitumgebung eingesetzt, da sie moderne JavaScript-Features vollständig unterstützt.
Für Arch-Linux-Nutzer wurde hierzu das Paket yt-dlp-ejs ergänzt. Dieses Paket fungiert als Schnittstelle zwischen yt-dlp und der externen Runtime. Bei Installation von yt-dlp-ejs wird Deno automatisch als Abhängigkeit eingerichtet. Erst damit steht der aktuelle, nicht-deprecated YouTube-Support zur Verfügung.
Für Nutzer, die regelmäßig YouTube-Inhalte extrahieren, ist die Nachinstallation daher sinnvoll. Zusätzlich empfiehlt sich die Installation als Abhängigkeit (--asdeps), damit die Paketverwaltung sauber bleibt und beim Entfernen von yt-dlp auch die zugehörigen Komponenten automatisch entfernt werden, sofern sie nicht anderweitig benötigt werden.
Beispiele:
Installation von yt-dlp-ejs als Abhängigkeit:
pacman -S --asdeps yt-dlp-ejs
|
|
Fazit:
Die Einführung einer externen JavaScript-Runtime in yt-dlp ist technisch nachvollziehbar und zukunftsorientiert. Für die meisten Anwender, die YouTube-Downloads nutzen, ist die Installation von yt-dlp-ejs empfehlenswert, da nur damit die vollständige Funktionalität erhalten bleibt.
Quellenangabe:
LG
Sebastian |
| |
| 4 |
allgemeine Kategorie / Allgemeine Diskussionen / SquashFS Tools 4.7.3 bis zu 1500x schneller und mit stdout Support |
am: 09. November 2025, 07:12:03 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Mit der Veröffentlichung von SquashFS Tools 4.7.3 hat sich einiges getan. Neben massiven Performance-Optimierungen bringt die neue Version auch praktische Erweiterungen für moderne Workflows mit. Besonders interessant ist die Möglichkeit, ein komplettes SquashFS-Dateisystem direkt an STDOUT zu streamen – also ohne temporäre Datei.
TLDR;
SquashFS 4.7.3 steigert die Leistung beim Lesen von Sparse Files um bis zu den Faktor 1500 und erlaubt nun, Dateisysteme direkt in eine Pipeline zu schreiben. Die Streaming-Funktion hat jedoch Einschränkungen und erfordert bei Bedarf eine Nachbearbeitung mit -fix.
Hauptteil:
SquashFS Tools 4.7.3 bringt eine deutliche Beschleunigung bei der Verarbeitung von Sparse Files. Durch die optimierte Nutzung der SEEK_DATA-Operation kann das Dateisystem Löcher in Dateien effizient überspringen. Dadurch ergibt sich je nach Struktur der Daten ein Leistungszuwachs von bis zu 240×. Wenn mehrere Datenblöcke als zusammenhängende Sparse-Bereiche erkannt werden, erhöht sich der Effekt auf bis zu 1500× im Vergleich zu früheren Versionen.
Neben diesen Optimierungen wurde auch die Funktionalität von mksquashfs erweitert. Das Tool kann nun Dateisysteme direkt an STDOUT streamen. Das ist vor allem in automatisierten oder speichersparenden Szenarien nützlich, beispielsweise für Backups oder Systemabbilder, die direkt über eine Pipeline übertragen werden sollen.
Einige technische Einschränkungen sind jedoch zu beachten:
- Beim Streamen ist keine Duplikaterkennung möglich.
- Der Superblock (Header) wird am Ende des Dateisystems geschrieben.
- Solche Abbilder können daher nicht direkt vom Kernel gemountet werden.
- unsquashfs kann diese Streams jedoch problemlos lesen.
Wer das gestreamte Abbild später mounten möchte, kann dies mit der neuen -fix-Option korrigieren. Sie verschiebt den Header an den Anfang der Datei und macht das Dateisystem wieder kernelkompatibel.
Beispiele:
Ein praktisches Beispiel für das neue Streaming-Feature:
# SquashFS-Dateisystem direkt nach STDOUT streamen und über ssh auf einem anderen Computer Speichern
mksquashfs directory - -stream | ssh phillip@192.168.178.1 dd of=image.sqfs
# Header nach vorn verschieben, um das Image mountbar zu machen
mksquashfs -fix image.sqfs
|
|
Fazit:
SquashFS Tools 4.7.3 zeigt, dass selbst ein ausgereiftes Dateisystem noch deutlich optimiert werden kann. Die Leistungssteigerung bei Sparse Files ist beeindruckend, und die neue Streaming-Funktion eröffnet flexible Anwendungsmöglichkeiten für fortgeschrittene Workflows.
Für meine Zwecke in der Langzeitarchivierung bleibt SquashFS weiterhin das bevorzugte Format. Die starke Kompression, eingebaute Deduplication und sequentielle Durchsuchbarkeit machen es klassischen Archivformaten wie tar, zip oder 7z weiterhin überlegen – vor allem, wenn es um Effizienz und Nachhaltigkeit geht.
Quellenangabe:
LG
Sebastian |
| |
| 5 |
allgemeine Kategorie / Installation, Einrichtung und Systempflege / Re:dracut optimierungen bei verwendung eines COW Dateisystems |
am: 27. Oktober 2025, 18:31:19 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Ich habe meinen Einleitungspost um folgenden Inhalt ergänzt:
Ich möchte noch folgende Ergänzung anmerken.
Nach längerer Verwendung der Option enhanced_cpio="yes" ist mir bei einer Neuinstallation meines Notebooks aufgefallen, dass ohne diese Option das Initramfs spürbar schneller geladen wird und somit der Bootvorgang insgesamt kürzer ausfällt.
Es gilt hierbei also folgendes abzuwägen:
Möchte man eine schnellere Erzeugung sowie eine optimale Deduplizierung des Initramfs, so ist enhanced_cpio zu bevorzugen – allerdings auf Kosten der Bootgeschwindigkeit.
Der Grund dafür liegt in der Arbeitsweise moderner CPUs. Diese können komprimierte Daten sehr schnell dekomprimieren, sodass der Flaschenhals meist bei der I/O-Leistung des Speichermediums liegt. Wird enhanced_cpio korrekt eingesetzt, fallen die erzeugten Initramfs-Dateien größer aus. Dadurch dauert das vollständige Einlesen vom Datenträger länger als bei stark komprimierten Varianten. Hinzu kommt, dass durch die erhöhte Anzahl an Extents (zusammenhängenden Datenblöcken) der Dateisystem-Overhead leicht zunimmt, was zusätzlich etwas Zeit kostet.
Der Vorteil des verbesserten Extent-Sharings durch enhanced_cpio zeigt sich daher vor allem in Umgebungen, in denen mehrere Initramfs für unterschiedliche Kernel vorgehalten werden. Diese können sich durch Reflink-Deduplizierung Speicherplatz teilen. Ebenso ist enhanced_cpio dann interessant, wenn die schnelle Erstellung eines Initramfs wichtiger ist als ein schnellerer Bootvorgang.
Daher lässt sich zusammenfassen:
- Bei mehreren Initramfs lohnt sich enhanced_cpio, da es Speicherplatz spart und die Erstellung beschleunigt.
- Bei wenigen oder nur einem Initramfs sollte man darauf verzichten, sofern Bootgeschwindigkeit im Vordergrund steht – es sei denn, die Generierungsgeschwindigkeit ist entscheidend.
|
|
|
| |
| 6 |
allgemeine Kategorie / Allgemeine Diskussionen / BTRFS langsam im kommen? |
am: 23. Oktober 2025, 14:22:39 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Mir fällt auf, dass Btrfs in letzter Zeit zunehmend auch bei Nutzern älterer Linux-Distributionen wie Debian an Bedeutung gewinnt. Das Thema scheint breiter diskutiert zu werden, was sich unter anderem daran zeigt, dass auf Plattformen wie gnulinux.ch mittlerweile Artikel erscheinen, die detailliert erklären, wie man ein Debian-System direkt auf Btrfs-Subvolumes installieren kann.
Dass die Debian-Community und verwandte Projekte diesem Ansatz nun zunehmend Beachtung schenken, zeigt, dass Btrfs langsam aus der Nische der experimentellen Systeme herauswächst. Distributionen wie openSUSE oder Fedora nutzen es bereits produktiv, und die technische Basis hat sich dort seit Jahren bewährt. Es bleibt spannend zu beobachten, ob Debian künftig ähnliche Integrationsmechanismen wie automatische Subvolume-Strukturen oder Snapshot-Unterstützung in seinen Installer aufnehmen wird.
LG
Sebastian
|
| |
| 7 |
allgemeine Kategorie / Allgemeine Diskussionen / Re:DDoS-Angriffe auf alle Arch-Server |
am: 19. Oktober 2025, 16:54:57 |
| Begonnen von Andreas | Letzter Eintrag von Andreas |
Ich verwende diese Videos schon lange. Sie sind wirklich sehr gut gemacht, auch meine Schüler mögen sie!
LG
Andreas |
| |
| 8 |
allgemeine Kategorie / Allgemeine Diskussionen / Microsoft 365 Education – Microsoft möchte keine verantworttung tragen |
am: 19. Oktober 2025, 11:39:40 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Ich habe auf Kuketz Blog folgenden Artkel gelesen:
Kommentar: Microsoft 365 Education – Auch in Deutschland will Microsoft nicht verantwortlich sein
Da steht im groben folgendes drin:
Die österreichische Datenschutzbehörde hat entschieden, dass Microsoft 365 Education Schüler*innen unrechtmäßig trackt und Daten ohne Rechtsgrundlage verarbeitet. Die »Education«-Version ist technisch identisch mit dem normalen MS365 und sendet trotz deaktivierter Optionen ständig Telemetrie an Microsoft. Schulen tragen offiziell die Verantwortung, haben aber keine Kontrolle über die Datenverarbeitung. Microsoft behält die technische Macht und nutzt Daten teils für eigene Zwecke. Das gleiche Problem betrifft auch Deutschland – dort fehlt jedoch der politische Wille, die Abhängigkeit von Microsoft zu beenden.
|
|
Der aktuelle Fall aus Österreich zeigt wieder deutlich, in welcher gefährlichen Abhängigkeit sich Schulen gegenüber Microsoft befinden. Die Datenschutzbehörde hat bestätigt, dass Microsoft 365 Education Schülerdaten rechtswidrig verarbeitet. Das angebliche „Education“-Angebot ist nichts anderes als das gewöhnliche MS365 – mitsamt aller Tracking- und Telemetrie-Funktionen.
Microsoft behält die volle technische Kontrolle, während die Schulen die rechtliche Verantwortung tragen, ohne die Datenverarbeitung wirklich nachvollziehen zu können. Genau diese Schieflage macht das Ganze so bedenklich.
Ich frage mich, warum Schulen freiwillig Verantwortung für Produkte übernehmen, deren Funktionsweise sie weder steuern noch kontrollieren können – zumal längst freie und datenschutzfreundliche Alternativen existieren.
LG
Sebastian |
| |
| 10 |
allgemeine Kategorie / Basiswissen / IT-Kompetenz (betriebssystemunabhängig) / Re:Basiskompetenz – Knowledge Distillation |
am: 18. Oktober 2025, 12:24:20 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Ich finde, der schnellste Weg, um festzustellen, ob man etwas wirklich verstanden hat, ist, es anderen zu erklären. Durch das Feedback der anderen kann man sehr gut reflektieren, wo noch Wissenslücken bestehen und gezielt nachbessern.
Zudem lernt man durch die Fragen anderer, besser zu filtern und zu priorisieren. So erkennt man, worauf bei einem Thema der Schwerpunkt liegt und welche Aspekte die meisten Rückfragen hervorrufen.
Nicht zuletzt wächst durch die Zusammenarbeit das Wissen aller Beteiligten, was grundsätzlich eine sehr positive Wirkung hat.
Um ein konkretes Beispiel zu zeigen, wie mein Lernprozess mithilfe von Logseq aussieht, habe ich aus meinem Material zum Thema „Fotosammlung in AVIFs konvertieren“, das ich auf Wikipedia und YouTube gesammelt habe, einen Screenshot eines Whiteboards in Logseq erstellt. Dort lässt sich gut erkennen, wie flexibel man Material in Logseq sammeln und verarbeiten kann.
https://drive.proton.me/urls/3VTGSKTPZM#RhRQQtVmSwaS
Obwohl man es auf dem Screenshot nicht direkt sieht, ist es wichtig zu erwähnen: Die Stichpunkte liegen nicht alle untereinander auf derselben Seite, sondern teilweise auf eigenen Seiten, um die Organisation zu verbessern. Sie werden nur an den passenden Stellen eingebettet. So bleibt jede Information atomar, und unnötige Duplikate werden vermieden. Das ist der große Vorteil von Themen- und Wissensverknüpfungen.
Das bedeutet nicht, dass ich schon alles vollständig verstanden habe, was ich notiert habe. Sobald ich ein Thema intensiver bearbeite (z. B. ICC-Profile), werde ich weitere Notizen hinzufügen und mein Verständnis vertiefen. Das Tolle an Logseq ist, dass man eine neue Seite zu einem Thema ganz einfach im Schreibfluss anlegen kann, indem man einen Begriff in eckige Klammern setzt. Auf dieser neuen Seite kann man dann weiterarbeiten und sie überall dort referenzieren, wo die Information benötigt wird.
LG
Sebastian |
| |
Zurück zur Foren-Übersicht.
|
|
|
