Category Archives: German

COVID-19-Fallzahlen: bitte zitiert nicht die JHU. Sondern die Landesministerien.

Liebe ARD Tagesschau/Tagesthemen und liebes ZDF heute journal: Ihr macht einen fantastischen Job in der COVID-19-Berichterstattung. Danke dafür!

Aber eine Bitte habe ich an Euch und an viele andere deutsche Medien: bitte zitiert nicht die Johns Hopkins University (JHU), wenn Ihr die aktuellen Fallzahlen von bestätigten COVID-19-Infektionen für Deutschland berichtet.

Die Zahlen selbst sind gut. Die Quelle “JHU” jedoch sorgt für ziemlich viel Verwirrung. Bitte zitiert stattdessen unsere Gesundheitsämter und Landesministerien: gleiche Zahlen, korrekte Quelle, weniger Verwirrung. Das versuche ich in diesem Beitrag zu erklären.

Dass viele Bürger sich fragen woher die Diskrepanz zwischen den JHU-Zahlen und den vom Robert Koch-Institut (RKI) veröffentlichten Zahlen kommt, wisst Ihr selbst.

Auch ich habe mich gefragt, warum das heute journal die JHU und nicht das RKI zitiert. In Anbetracht der Unterschiedlichkeit der Zahlen wollte ich das gerne von Euch erklärt bekommen.

Das heute journal ist darauf mit einem Beitrag in der Sendung vom 19.03. eingegangen (kann man in diesem Tweet noch einmal sehen). Aber ich wurde enttäuscht: uns wurde gesagt, dass die JHU sich auf Quellen wie “WHO, CDC, ECDC, NHC, DXY, …” beziehen würde. Wir blieben ratlos. Das war keine plausible Erklärung für die Diskrepanz der Datensätze und für die Entscheidung JHU statt RKI zu zitieren.

Kurzer Exkurs zur genannten Diskrepanz, am Beispiel vom 21. März. Der RKI Situationsbericht zum 21.03.2020 sagt: 16.662 bestätigte Fälle. Die JHU behauptet am heutigen Abend des 21. März: etwa 22.000 bestätigte Fälle. Vergleichbar? Im RKI Situationsbericht steht, dass er dem Datenstand vom 21.03.2020 um 0:00 Uhr entsprechen soll. Also sollte man diese Zahl mit dem letzten Stand der JHU-Daten vom 20.03. vergleichen. Schauen wir nach: time_series_19-covid-Confirmed.csv, Zeile 13, im git repository CSSEGISandData/COVID-19 auf GitHub. Da steht für den 20.03. die Zahl 19.848.

Eine faire Frage ist also: “Warum berichtet das RKI für das Ende des Tages des 20. März etwa 16.600 Fälle, während die JHU für den gleichen Zeitpunkt etwa 19.800 Fälle berichtet?”

Darauf gibt es meiner Meinung nach eine klare und zufriedenstellende Antwort: die JHU-Daten entsprechen aktuellen und offiziellen Daten der Landesministerien. Die RKI-Daten sind geprüfte und verzögert veröffentlichte Daten der selben Landesministerien.

jeder von uns kann sich zu jedem Zeitpunkt des Tages die kleine Mühe machen und die jeweils aktuellen COVID-19-Fallzahlen der einzelnen 16 Bundesländer nachlesen. Ich mache das hier mal vor, mit aktuellen Zahlen von sechs Bundesländern (während ich diesen Text schreibe):

Das Prinzip ist klar. Diese Fallzahlen-Portale und Statistiken der einzelnen Länder sind schon recht gut gemacht. Danke, liebe Landesministerien! Hier verlinke ich noch ein paar mehr davon.

Wenn ich jetzt die Bevölkerung über den aktuellen Stand der bestätigten COVID-19-Fallzahlen in den genannten sechs genannten Ländern informieren wollte, dann könnte ich doch einfach aufsummieren und schreiben: etwa 17.400 Fälle, Stand 21.03. (vormittags/mittags). Quelle: Gesundheitsministerien der Bundesländer.

Oder nicht? Eine plausible, vertrauenswürdige Quelle. Im Gegensatz zur mysterischen, nicht direkt plausiblen Quelle “JHU”.

Wenn man jetzt noch die 10 anderen Länder dazurechnet kommt man auf den derzeitigen Stand (während ich schreibe) von etwa 22.000 bestätigten Fällen (weiter oben haben wir die Zahl schon gesehen: das ist das was die JHU derzeit berichtet während ich das hier schreibe).

Meines Wissens nach ist das genannte Vorgehen (Konsultation der Ländesbehörden) genau das, was ZEIT ONLINE und Berliner Morgenpost akribisch mehrfach am Tag tun. Die erhaltenen Daten pflegen sie sofort in ihre Visualisierungen ein:

Und die Zahlen des RKI? Es schreibt selbst:

“Zwischen dem Bekanntwerden eines Falls vor Ort, der Meldung an […], der Eingabe der Daten in […] und von dort an das RKI liegt eine gewisse Zeitspanne. Die kann gemäß den Vorgaben im Infektionsschutzgesetz zwei bis drei Arbeitstage lang sein.”

Schlussfolgerung 1: Die Landesministerien veröffentlichen, gut aufbereitet, zu jedem Zeitpunkt ihren aktuellen Datenstand. Aggregiert von den ihnen jeweils unterstellten Gesundheitsämtern. Das sind offizielle Zahlen. Und wahrscheinlich auch ganz gute (belastbare) Zahlen. Aber auch diese Zahlen sind natürlich schon verzögert gegenüber den Meldungen der Gesundheitsämter!

Schlussfolgerung 2: Ich denke, dass wir die Zahlen von ZEIT ONLINE und Berliner Morgenpost jeweils guten Gewissens benutzen können. Denn sie repräsentieren meinen Stichproben nach exakt die Veröffentlichung der Landesministerien.

Schlussfolgerung 3: das RKI prozessiert die Daten langsam und erzeugt gegenüber den Landesministerien eine Verzögerung in der Veröffentlichung der Daten von weiteren 1 bis 2 Tagen. Warum das so ist: unklar. Eine eingehende Prüfung der Daten? Vielleicht. Dafür hätte ich gerne eine bessere Erklärung!

Schlussfolgerung 4: Tagesschau und heute journal: bitte nennt als Quelle für die aktuellen Fallzahlen die Landes(gesundheits)ministerien bzw. die Gesundheitsämter. Das ist korrekt und stiftet weniger Verwirrung.

Vielleicht könntet Ihr auch noch zusätzlich ZEIT ONLINE oder die Berliner Morgenpost zitieren, die die Konsultation für uns vornehmen und die jeweils aktuelle Summe für uns bereithalten.

Danke.

Randnotiz 1: ich hatte darüber schon vor ein paar Tagen geschrieben und versucht die Gedanken hier ein bisschen klarer zu sortieren.

Randnotiz 2: ich arbeite an https://github.com/jgehrcke/covid-19-germany-gae. Eine konsolidierte und automatisiert konsumierbare Datenquelle der aktuellen Fallzahlen in Deutschland, der individuellen Bundesländer, inkl. Zeitverlauf in der Vergangenheit.

Deutschlands Covid-19 Fallzahlen des RKI (und der WHO) haben inzwischen 2-3 Tage Verzögerung zu den Daten der Gesundheitsämter

Die einzelnen Schritte des Datenflusses:

  1. Bekanntwerden eines Falls
  2. Meldung an das Gesundheitsamt
  3. Eingabe der Daten in eine Software
  4. Übermittlung an die zuständige Landesbehörde
  5. Übermittlung an das RKI
  6. Übermittung an die WHO.

Alle Schritte bis auf den Letzten sind vom RKI so dokumentiert.

Jeder dieser Schritte involviert eine Brieftaube und braucht ein bisschen Zeit :-).

So steht im Situationsbericht 58 der WHO, dass wir am 18.03. etwa 7100 bestätigte Covid-19 Fälle in Deutschland hatten.

Die Gesundheitsämter hatten aber schon am 17.03. mehr als 9000 Fälle registriert, am 18.03. deutlich über 12000. Konkret heißt das, dass die von der WHO veröffentlichte Zahl für den 18.03. eher der bekannten Zahl vom 16.03. entspricht.

Ich denke nicht, dass die Daten solange geprüft werden müssen. Ich denke, dass wir den Zahlen der Landesbehörden trauen können (das sind offizielle Zahlen; Beispiel einer Pressemitteilung des Landes Berlin vom 18.03.). Warum werden diese Daten so lange prozessiert?

Wenn diese daten wirklich so lange prozessiert werden müssen — warum werden sie dann nicht rückdatiert? Das wäre den Konsumenten der Zahlen gegenüber nur fair.

In der jetzigen Phase des exponentiellen Wachstums ist es sehr wichtig zu wissen, dass die Deutschland-Zahlen des RKI und der WHO eine erhebliche Verzögerung aufweisen. Eine Verzögerung von 2-3 Tagen entspricht der derzeitigen Verdopplungszeit der gemessenen Zahl der Covid-19 Fälle in Deutschland (Plot).

Das RKI sagt übrigens “In der aktuellen Lage erfolgt die Übermittlung deutlich schneller als im Routinebetrieb”.

Und:

“Zwischen dem Bekanntwerden eines Falls vor Ort, der Meldung an […], der Eingabe der Daten in […] und von dort an das RKI liegt eine gewisse Zeitspanne. Die kann gemäß den Vorgaben im Infektionsschutzgesetz zwei bis drei Arbeitstage lang sein.

(https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/Fallzahlen.html)

Update: eine hilfreiche Diskussion zu diesem Thema findet ihr in https://github.com/CSSEGISandData/COVID-19/issues/1008.

 

Systemdatenträger wechseln ohne “Augen zu und durch”-Mentalität

Einleitung

In diesem Artikel beschreibe ich wie man Windows in wenigen Schritten von einem Speichermedium zum Anderen überträgt — mit professionellen Werkzeugen. Das ist ein kritischer Prozess. Aber ein simpler Prozess, den man verstehen kann und sollte, bevor man ihn einleitet. Wie immer gibt es zahlreiche schändliche Anleitungen da draußen, bei denen dieser Prozess nicht hinreichend erklärt und irgendwelchen bunten Klick-Tools überlassen wird. Das Problem dabei: der Vorgang wird dem Nutzer übersimplifiziert präsentiert. Wichtige Entscheidungen trifft die angepriesene Software selbst, essentielle Details werden vom Nutzer ferngehalten. Aber im Bereich von Datenträgerstrukturen gibt es zu viele potentielle Komplikationen, deren Behandlung man keiner Pseudointelligenz oder auch der “Holzhammermethode” überlassen darf:

Holzhammermethode, zweckentfremdet von http://www.datamartist.com.

Holzhammermethode, zweckentfremdet von datamartist.com.

In professionellen Umgebungen wird ein solcher Migrationsprozess normalerweise akribisch geplant und jeder Schritt mit dem einen dafür etablierten Werkzeug ausgeführt. Ergebnis: die Migration gelingt schnell und zuverlässig.

In privaten Umgebungen herrscht Unsicherheit, man kennt die technischen Details nicht und folgt gerne einer simplen Abstraktion des Problems. Es herrscht Augen zu und durch-Mentalität. Grafisch hübsch aufgemachte Software-Assistenten suggerieren schließlich eine gewisse Sicherheit. Doch Hoffnung ist keine Strategie. Das etwas andere Ergebnis: mit einiger Wahrscheinlichkeit geht etwas schief und man verbringt Stunden oder Tage mit einer chaotischen Phase der Problemlösung, bei der vielleicht Dritte mit einbezogen werden müssen.

Eine grundsätzliche Ursache dieses Gefälles zwischen professioneller und privater Umgebung ist sicherlich der Mangel an Detailwissen in Letzterer. Damit einher geht aber — und das ist das eigentliche Übel — fehlende Anerkennung, dass ein solcher Prozess akribisch geplant werden muss. Ich schreibe das hier auf Deutsch und mit dieser kleinen Einleitung, um in meinem direkten Umfeld ein besseres Bewusstsein für diese Thematik und Problematik zu schaffen.

Es wird unten stehend demonstriert, wie ein solcher Prozess zuverlässig umgesetzt werden kann. Als Beispiel dient ein Spezialfall, den die meisten Windows-Nutzer zu Hause haben. Die Grundidee — Detailplanung und die verwendeten Ansätze und Werkzeuge — sind jedoch auch auf andere Situationen und Betriebssysteme anwendbar. Ihr werdet merken, wenn Eure Situation von der hier beschriebenen abweicht. Dann könnt Ihr mich gerne fragen. Dementsprechend erhebt die folgende Anleitung keinen Anspruch auf Vollständigkeit.

Migrationsprozess

1) Live-Linux präparieren (5 Minuten)

Ihr braucht einen USB-Stick mit einem modernen Live-Linux-System, welches die notwendigen Werkzeuge bereithält, um zuverlässig Daten auf Datenträgern zu analysieren und zu manipulieren. Ich empfehle die Linux-Distribution SystemRescueCD. Gibt es hier zum Herunterladen. Wie bekommt Ihr das auf einen USB-Stick, von dem der Rechner starten kann? Mit dem quelloffenen Rufus. Dort wählt Ihr “create a bootable disk” und bei “select ISO file” wird das SystemRescueCD-Abbild ausgewählt, was gerade heruntergeladen wurde.

2) Transfersystem vorbereiten (5 Minuten)

Der Quell-Datenträger (mit der bisherigen Windows-Installation) wird aus dem Produktivsystem herausgenommen. Der Ziel-Datenträger wird bereitgelegt.

Es wird ein Rechner gebraucht, in dem diese beiden Datenträger gleichzeitig angeschlossen werden. Dieser Rechner wird vom zuvor präparierten USB-Stick gestartet. Beim Start von SystemRescueCD wird der default Start-Modus gewählt, das Tastaturlayout (z. B. DE) definiert und die Desktop-Umgebung mittels startx gestartet.

In diesem Zustand ist der Zugriff auf alle Datenträger möglich. SystemRescueCD wagt jedoch keine autonomen Zugriffe. Ohne Anweisung wird kein einziges Dateisystem eingehängt. Insbesondere wird ohne konkreten Befehl auf keinen Datenträger schreibend zugegriffen. Das ist ein konzeptioneller Schutz vor ungeplanten Ereignissen.

3) Quelle und Ziel eindeutig identifizieren (2 Minuten)

Jedes Linux-Betriebssystem nummeriert die Datenträger intern durch. Jeder Datenträger und jede Partition ist per /dev/sd* lesend und schreibend erreichbar. Jetzt muss die Bezeichnung des bisherigen Windows-Datenträgers ausfindig gemacht werden. Es hilft eine Auflistung der verfügbaren Datenträger samt Partitionen. Ein praktischer Befehl ist fsarchiver probe simple, welcher in ein Terminal eingegeben wird. Das ist die Ausgabe in meinem Fall:

[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda             ] [KINGSTON SVP200S               ] [   111.79 GB] [  8] [  0]
[sdb             ] [WDC WD10EAVS-00D               ] [   931.51 GB] [  8] [ 16]
[sdc             ] [Samsung SSD 850                ] [   476.94 GB] [  8] [ 32]
[sdd             ] [RALLY2                         ] [     3.74 GB] [  8] [ 48]
[sde             ] [USB DISK                       ] [     7.55 GB] [  8] [ 64]
 
[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN] 
[loop0           ] [squashfs   ] [<unknown>        ] [   278.66 MB] [  7] [  0] 
[sda1            ] [ntfs       ] [System Reserved  ] [   100.00 MB] [  8] [  1] 
[sda2            ] [ntfs       ] [<unknown>        ] [   111.69 GB] [  8] [  2] 
[sdb1            ] [ntfs       ] [Software         ] [   196.16 GB] [  8] [ 17] 
[sdb2            ] [ntfs       ] [Daten            ] [   735.35 GB] [  8] [ 18] 
[sdd1            ] [vfat       ] [SYSRCD-4_4_      ] [     3.74 GB] [  8] [ 49] 
[sde1            ] [vfat       ] [<unknown>        ] [     7.55 GB] [  8] [ 65]

Beim Lesen der Ausgabe braucht man ein bisschen Kenntnis über die eigene Hardware: in der oberen Liste sollten Gerätebezeichnung und Datenträgerkapazität genügend Aufschluss geben. Der bisherige Windows-Datenträger von Kingston heißt in diesem Fall sda. Er ist per Dateisystempfad /dev/sda erreichbar.

In der unteren Liste sind die automatisch erkannten Partitionen aufgeführt. Die Partition sda1 ist eine 100 MB große Partition mit dem Namen “System Reserved …”. Diese wird für gewöhnlich von Windows 7 & 8 bei der Installation angelegt und übernimmt essentielle Aufgaben (sie wird im Betrieb von Windows nicht als normaler Datenträger angezeigt aber muss bei der Migration mitgenommen werden). Die Partition sda2 ist das, was man aus Windows-Sicht als Systemlaufwerk bezeichnen würde (meist Laufwerk “C:”). Bei beiden Partitionen hat fsarchiver wie erwartet erkannt, dass sie ein NTFS-Dateisystem enthalten. Es ist keine weitere Partition auf /dev/sda vorhanden. Die Bestandsaufnahme der Quelle ist somit abgeschlossen.

/dev/sdc ist der Datenträger, der zukünftig Windows tragen soll. Bisher ist keine Partition auf diesem Datenträger eingerichtet.

4) Die Transferstrategie festlegen

Die Strategie im Groben: Die Inhalte beider Quell-Partitionen (/dev/sda1 und /dev/sda2) sollen auf Block-Ebene auf den neuen Datenträger kopiert werden. Vorher bekommt der neue Datenträger eine frische Partitionstabelle. Der Bootloader wird vom alten Datenträger auf den Neuen kopiert.

Die Strategie im Detail:

  • Per GNU fdisk wird eine neue Partitionstabelle vom Typ msdos auf /dev/sdc erstellt, sodass die Situation vom alten Datenträger in den wesentlichen Punkten repliziert wird:
    • /dev/sdc1 erhält die selbe Startposition und Größe wie /dev/sda1.
    • In diesem Fall ist der neue Datenträger größer als der alte: /dev/sdc2 soll den Rest des Datenträgers füllen.
    • Beide Partitionen erhalten eine Markierung vom Typ 7 (HPFS/NTFS/exFAT).
    • /dev/sdc1 wird als aktiv markiert.
  • Der Master Boot Record wird per dd nur teilweise vom alten Datenträger auf den neuen kopiert (nur der Bootloader und die Datenträgersignatur, nicht jedoch die Partitionstabelle).
  • /dev/sda1 wird blockweise per dd nach /dev/sdc1 kopiert.
  • /dev/sda2 wird blockweise per dd nach /dev/sdc2 kopiert.
  • Das NTFS-Dateisystem welches auf /dev/sda2 befindet hat nun mehr Platz auf /dev/sdc2. Es wird per ntfsresize entsprechend darauf aufmerksam gemacht, sodass es den verbleibenden Platz innerhalb der Partition nutzen kann. Zur Vereinfachung dieses Schritts wird als Wrapper GParted benutzt. Beide Tools sind quelloffen und Industriestandard.

Alle hier genannten Werkzeuge sind Teil der SystemRescueCD-Distribution.

5) Realisierung (5 Minuten Arbeit, X Minuten Warten)

  • Details der Partitionstabelle vom bisherigen Windows-Datenträger per fdisk -l auslesen:
    Device    Boot     Start       End    Blocks  Id System
    /dev/sda1 *         2048    206847    102400   7 HPFS/NTFS/exFAT
    /dev/sda2         206848 234438655 117115904   7 HPFS/NTFS/exFAT

    Beide Partitionen sind von Typ 7. /dev/sda1 ist Boot-markiert (“active”). Start und Ende sind präzise angegeben. Diese Parameter wollen wir exakt replizieren. Die einzige Änderung der neuen Tabelle gegenüber der Alten wird die Endmarkierung der Partition /dev/sda2 sein, da der neue Datenträger größer ist als der Alte.

  • Neue Partitionstabelle auf neuem Datenträger per fdisk /dev/sdc erstellen. fdisk wird schrittweise per Tastatur bedient:
    • o create a new empty DOS partition table
    • n add a new partition
    • p primary (0 primary, 0 extended, 4 free)
    • Partition number 1, first sector: 2048 (default), last sector: 206847
    • n add a new partition
    • p primary (0 primary, 0 extended, 4 free)
    • Partition number 2, first sector: default, last sector: default (bis zum Ende des Datenträgers)
    • mit Befehl t change a partition type wird Typ 7 für beide Partitionen gewählt.
    • mit Befehl a toggle a bootable flag wird Partition 1 aktiv markiert.
    • mit Befehl w write table to disk and exit werden die Änderungen geschrieben.
  • Bootloader und Datenträgersignatur blockweise kopieren (die ersten 446 Bytes des Datenträgers):
    # dd if=/dev/sda of=/dev/sdc bs=446 count=1
    1+0 records in
    1+0 records out
    446 bytes (446 B) copied, 0.00403888 s, 110 kB/s
  • kleine “System Reserved”-Partition blockweise kopieren:
    # dd if=/dev/sda1 of=/dev/sdc1
    204800+0 records in
    204800+0 records out
    104857600 bytes (105 MB) copied, 2.02602 s, 51.8 MB/s
  • Windows-Partition (“C:”) blockweise kopieren:
    # dd if=/dev/sda2 of=/dev/sdc2
    234231808+0 records in
    234231808+0 records out
    119926685696 bytes (120 GB) copied, 2271.83 s, 52.8 MB/s
  • NTFS-Dateisystem auf /dev/sdc2 vergrößern:
    • GParted starten.
    • /dev/sdc2 rechtsklicken und Check wählen.
    • In der Ausgabe kann man verfolgen, dass ntfsresize --force --force /dev/sdc2 aufgerufen wird. Es wird der Größenunterschied zwischen Dateisystem und Partition aufgeführt: Current volume size: 119926682112 bytes (119927 MB) vs. Current device size: 512004284416 bytes (512005 MB). Am Ende steht ein Successfully resized NTFS on device '/dev/sdc2'. Da keine Daten verschoben werden müssen, dauert dieser Vorgang nur wenige Sekunden.

Bei den obig angegebenen Schritten ist zu beachten, dass ein Vertauschen/Verschreiben bei den Gerätepfaden (/dev/sd*) unverzeihlich ist. Bitte drei mal denken und kontrollieren, bevor Ihr auf Enter drückt. Ansonsten habt Ihr ja sicherlich eine Sicherung Eurer persönlichen Daten.

6) Rückbau des Datenträgers in das Produktivsystem (5 Minuten)

Der neue Datenträger mit der Windows-Installation wird in das Produktivsystem zurückgebaut. Per BIOS-Einstellung wird das Produktivsystem vom neuen Datenträger gestartet. Es sind keine weiteren Schritte erforderlich.

Fazit

Etwa 25 Minuten Arbeit für eine Betriebssystemmigration (+ Zeit für Datentransfer). Das ist schnell. Warum gewährleistet obige Strategie Zuverlässigkeit? Der durchgeführte Prozess stellt sicher, dass sich zwischen der alten und der neuen Situation nur zwei Kleinigkeiten geändert haben: die Bezeichnung des Datenträgers und die Größe des NTFS-Dateisystems in dem Windows (mehrheitlich) installiert ist. Aus Sicht des BIOS und aus Sicht des Betriebssystems ist der Rest des Gesamtsystems äquivalent zum vorherigen Zustand. Mit dieser Betrachtungsweise ist es leicht zu verstehen, dass die Migration mit hoher Wahrscheinlichkeit gelingt. Die präzise Kontrolle der Geschehnisse erleichtert auch eine etwaige Fehlersuche: gibt es nach Schritt 6 ein Problem, so muss es an einem der beiden geänderten Parameter liegen (in der Tat: UEFI Systeme mögen bedingt durch den Wechsel des Geräte-Namens bzw. der Geräte-ID einen weiteren kleinen Schritt erfordern).

Bei Eurem nächsten Wechsel des Systemdatenträgers solltet Ihr die Migration systematisch durchführen. Wenn Ihr den Prozess unter Kontrolle habt, dann gelingt er mit hoher Wahrscheinlichkeit. Traut lieber den quelloffenen Standard-Werkzeugen welche in professionellen Umgebungen eingesetzt werden als den großen Versprechungen von (kommerziell erhältlichen) Software-Assistenten für Privantanwender.

Leitung ahoi

Ich trinke seit Jahren hauptsächlich Wasser aus der Leitung. Im Büro und zu Hause. Du nicht? Zwei kleine Zitate von Martin Wagner (Toxikologe, Uni Frankfurt):

Das Leitungswasser, das wir untersucht haben, war nicht mit Umwelthormonen belastet. Warum nicht einfach das am strengsten kontrollierte Wasser in Deutschland trinken, nämlich das, was aus dem Hahn kommt? Das ist 1000- bis 5000-mal günstiger, muss nicht verpackt, mit hohem Energieaufwand abgefüllt und transportiert werden und verursacht keinen Plastikmüll. Für mich ist die Wahl da offensichtlich.

und

Grundsätzlich gelten für Leitungswasser strengere Richtlinien. Was viele nicht wissen: Mineralwasser darf nicht aufbereitet werden, Leitungswasser hingegen wird aufwendig kontrolliert und gereinigt. Dadurch ist die Belastung mit Pestiziden in der Regel niedriger und seltener. Auch eine hohe Keimbelastung, wie in einem der Wasser im Test, ist beim Leitungswasser deshalb äußerst unwahrscheinlich.

Quelle: Spiegel Online.

“Aber, aber!” mag manch einer sagen, “Ich brauche doch mein Mondwasser!”. Auch das kannst Du Dir selbst herstellen… :-)

Um Mondwasser herzustellen, muss einfach normales Wasser in eine Karaffe gefüllt werden und diese am Fenster aufgestellt werden. Besser ist es noch, wenn die Karaffe im Freien aufgestellt wird, damit sie auch direkt vom Mond angestrahlt werden kann. Stellt man die Karaffe in einer Nacht mit Vollmond auf, dann bekommt dieses Wasser sehr viel Energie vom Mond geliefert.

Ob das vielleicht die Bachblüten-Ilse geschrieben hat? Es gibt offenbar auch Mondkäse, Mondholz und Vollmondsalami zu kaufen. Die Quelle zu diesem Unsinn verrate ich jedenfalls nicht, das Internet sollte davor bewahrt werden.