Sonntag, 1. März 2020

Die „gesunden“ Corona-Kranken

In den nächsten Tagen wird man Drosten zufolge sehen, »dass neue Fälle und kleine Fallgruppen wie die Pilze aus dem Boden schießen werden«. Deutschland wird dabei vermutlich eine europäische Spitzenposition einnehmen, »weil unsere Bevölkerung sehr reisefreudig ist«. […]

Das beleuchtet die neue Qualität der sich in Europa ausbreitenden Epidemie: Die einzelnen Fälle sind nicht mehr auf einen bekannten Ursprungspatienten zurückzuverfolgen. Zwischen den bekannten Fällen liegen immer mehr unerkannte Infektionen mit vermutlich milder Symptomatik, die gar nicht in den Blick des Gesundheitssystem gekommen sind. Das sind die aus dem Boden hervorschießenden »Pilze« des Professors Drosten, die anscheinend wohl oder übel kommen werden.

Es wird eine ganz normale Pandemie

Will heissen: Es scheint Leute zu geben, die Corona in sich tragen, sich aber nicht (derart) krank fühlen, dass sie überhaupt an eine Corona-Infektion denken.

Beruhigend für all die, die bis jetzt nicht abschätzen können, ob die eigene Corona-Infektion nach einem kleinen Husten vorbei ist, oder uns eben doch für drei Wochen die Lunge aus dem Körper hustend und fiebrig flachlegt.

Beunruhigend für all die alten Leute über 60, welche statistisch einer deutlich höheren Corona-Sterblichkeit entgegensehen. Denn diese könnten von den gesund erscheinenden Corona-Kranken angesteckt werden und schlimmstenfalls an den von der Krankheit verursachten Komplikationen sterben.

A propos …

Bei Tichy drüben sehen sie schon den perfekten Sturm auf Deutschland zukommen:

Das Coronavirus und die wohl im Entstehen begriffene neue Migrationswelle über die Türkei und den Balkan treffen in Europa und insbesondere in Deutschland auf Gesellschaften, die mit existentiellen Bedrohungen und Krisen keine Erfahrungen mehr haben.

Quelle: Zwei Krisen auf einmal

Sind wir gespannt, wie sich diese zwei Ausnahmeereignisse auf die Abstimmung zur BGI vom 17. Mai 2020 auswirken werden.

Tags: , , , , , ,
Labels: Gesellschaft, Schweiz

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Was die Grünen [schon] alles verbieten woll(t)en

Angeregt von Manfred Messners Ich gestehe: Auch ich lese „Tichys Einblick“ und „Achse des Guten“ regelmässig habe ich auch damit begonnen, die Artikel der beiden Web-Sites täglich automatisiert in Instapaper zu bookmarken.

Und gelegentlich lese ich den einen oder anderen Artikel nun sogar. Ich mache das hier öffentlich, auf die Gefahr hin, dass mir ab heute Freundschaften gekündet, hier im Blog Hasskommentare hinterlassen oder sogar Morddrohungen gegen mich ausgesprochen werden.

Aber als Historiker bin ich in Quellenkritik ausgebildet und traue mir zu, Fake News, Ausländerhetze und was den Kollegen dort drüben sonst noch alles unterstellt wird, auszumachen. Ich sollte in der Lage sein, die interessanten, nützlichen Inhalte zu extrahieren, ohne gleich am äussersten rechten Rand der Gesellschaft aufzuwachen.

Und nützliche Artikel gibt es dort tatsächlich hie und da, zum Beispiel dieser:

Was die Grünen alles verbieten woll(t)en

Die Grünen setzen auf den Staat, und wenn vom Markt die Rede ist, dann meist in einem negativen Kontext. Und dass die Grünen eine Verbotspartei sind, ist keine Legende, wie Graw zeigt. Die Grünen forderten in den ersten beiden Jahren nach der Bundestagswahl 2017, also zur Halbzeit, in 26 Anträgen im Bundestag explizit Verbote, so etwa des Einsatzes gentechnisch veränderter Bäume. Nur die Linkspartei überbot sie mit noch mehr Verbotsanträgen (34), während die FDP im gleichen Zeitraum drei, die SPD zwei und die Union einen Verbotantrag einbrachten (S.96). Die Grünen wollten in ihrer Geschichte etliches verbieten, haben entsprechende Initiativen zumindest diskutiert oder fordern sie bis heute – vieles auf Bundes-, manches auf Landesebene. Es würde den Platz sprengen, all diese Ideen aufzuführen, von denen sicher nicht alle falsch sind – aber die Summe macht es. Verboten werden sollten:

  • Atomkraft,
  • Nachrüstung,
  • Volkszählung,
  • Privatfernsehen,
  • Kabelausbau,
  • Kasernierung von Wehrpflichtigen,
  • Flughafenprojekte,
  • Nachtflüge,
  • Kurzflüge,
  • Transrapid,
  • Autos in Innenstädten,
  • Verbrennungsmotoren (ab 2030),
  • Fracking,
  • Plastiktüten,
  • Plastikstrohhalme,
  • Kohle,
  • Schweröl,
  • Werbung für E-Zigaretten,
  • öffentlich zugängliche Zigarettenautomaten,
  • Limonadenverkäufe an Schulen,
  • Onlineshopping am Sonntag,
  • Zero-Rating beim Mobilfunk,
  • Heizpilze,
  • Paintball,
  • Ponyreiten auf Jahrmärkten,
  • Erste-Klasse-Abteilungen in der Bahn

usw.usf. (S. 95).

Quelle: Die Grünen: Partei der Verbote, des Moralismus und der Macht

Meine Prophezeiung: Je schneller die Grünen auch in der Schweiz klaren Wein einschenken und ihre ersten Verbote versuchen durchzudrücken, umso rascher wird die Partei wieder auf ihre ursprüngliche Wählerstärke schrumpfen. Denn sobald die Verbote auch von den städtischen Wählern verlangen, ihr Leben umzukrempeln, wird deren Unterstützung in den nächsten Wahlen rasch sinken. Den Lebensstil ändern? Ja, gerne, aber bitte einfach alle anderen.

Tags: , , ,
Labels: Politik

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Unter macOS High Sierra mit MacPorts, postfix und s-nail E-Mails versenden

Emails von der Kommandozeile versenden — was man bei Linux im Handumdrehen hinkriegt, erforderte bei mir unter macOS stundenlange Handstände.

MacPorts postfix anstelle macOS postfix

Doch jetzt habe ich den Kniff raus: Die von macOS mitgelieferte postfix-Installation habe ich schlussendlich ignoriert und auf das MacPorts postfix-Paket gesetzt.

MacPorts Variants nicht vergessen

Der erste Fallstrick lauert schon hier: Um heutzutage über einen Hoster E-Mails zu versenden, benötigt man zwingend SASL und TLS. Diese Features müssen als sog. MacPorts Variants explizit mitinstalliert werden, sonst landen sie nicht auf dem Mac:

# port install postfix +sasl +tls

Ansonsten meldet postfix:

...
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: smtp_sasl_auth_enable is true, but SASL support is not compiled in
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: TLS has been selected, but TLS support is not compiled in
...

Verzeichnisse und Pfade zur Sicherheit hardkodieren

Eine funktionierende postfix-Konfiguration mitsamt Installationsscript habe ich von meinen Linux-Servern herüberkopiert (diese Anleitung alleine würde das Format dieses Blog-Artikels sprengen). Die Konfiguration habe ich aber mit den MacPorts-Einstellungen ergänzt. Denke daran: Bei Linux liegen die Konfiguration sowie die Arbeitsverzeichnisse allesamt am erwarteten Ort (bspw. /etc/postfix/main.cf). Da wir unter macOS auf MacPorts setzen, liegt dieselbe Datei hier unter /opt/local/etc/postfix/main.cf. Deshalb habe ich zur Sicherheit in main.cf folgende von MacPorts vorgeschlagene Ergänzungen (siehe /opt/local/etc/postfix/main.cf.sample) hinzugefügt:

$ cat /opt/local/etc/postfix/main.cf
# Directories
queue_directory = /opt/local/var/spool/postfix
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
meta_directory = /opt/local/etc/postfix
manpage_directory = /opt/local/share/man
sample_directory = /opt/local/share/postfix/sample
readme_directory = /opt/local/share/postfix/readme
shlib_directory = no
html_directory = no

# Paths
sendmail_path = /opt/local/sbin/sendmail
newaliases_path = /opt/local/bin/newaliases
mailq_path = /opt/local/bin/mailq

# Log
maillog_file_prefixes = /var, /var/log/macports/postfix
maillog_file = /var/log/macports/postfix/postfix.log

# Other stuff ...
mail_owner = _postfix
setgid_group = _postdrop
default_privs = nobody
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
...

Logs in eine Datei schreiben

Weiter hatte ich während dem Debuggen so meine liebe Mühe, die Logging-Informationen zu finden, da diese an syslog gesendet werden und bei macOS dann in der Console.app landen. Deshalb habe ich im Gegensatz zu meinen Linux-Installationen auch noch die Konfigurationsdatei /opt/local/etc/postfix/master.cf anpassen müssen. Essentiell war es, die folgende Zeile einzufügen:

...
postlog   unix-dgram n  -       n       -       1       postlogd
...

Quelle: Postfix logging to file or stdout

Verhindern, dass fälschlicherweise die macOS postfix-Konfiguration geladen wird

Damit mir die Parallelinstallation von Postfix nicht in die Quere kommt und ich mir sicher war, dass die MacPorts-Installation von postfix tatsächlich die Konfiguration unter /opt frisst, habe ich kurzerhand den macOS postfix-Ordner verschoben:

# mv /etc/postfix /etc/postfix.bkp

Ob das wirklich nötig gewesen wäre sei dahingestellt; Vorsicht, wer das auf seinem System macht: Ich garantiere für nichts.

Postfix starten und stoppen

Die Postfix-Installation lädt man folgendermassen:

# port load postfix
# launchctl unload /Library/LaunchDaemons/org.macports.postfix.plist
# launchctl load -w /Library/LaunchDaemons/org.macports.postfix.plist

Die plist-Datei zeigt als symbolischer Link nach /opt/local/etc/LaunchDaemons/org.macports.postfix/org.macports.postfix.plist. In dieser Datei habe ich folgendes angepasst/ergänzt — das ist nicht zwingend nötig, sollte aber dazu führen, dass Postfix bei jedem Neustart automatisch gestartet wird. Ausserdem sollten im Fall von Start-Problemen Fehlermeldungen in eine Log-Datei geschrieben werden:

...
        <string>--pid=none</string>
    </array>
    <key>Disabled</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/var/log/launchd.macports.postfix.standard.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/launchd.macports.postfix.error.log</string>
</dict>
</plist>

s-nail verwendet standardmässig die macOS mail-Executables

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. MacPorts bietet hierzu s-nail an (Homepage des Entwicklers).

# port install s-nail

Als ich mit s-nail ein Test-Mail versenden wollte folgte eine weitere Hiobs-Botschaft:

$ echo "Test email" | mail user@domain.tld
unknown: fatal: open /etc/postfix/main.cf: No such file or directory
/Users/user/dead.letter 7/135
mail: ... message not sent

Ich übertreibe nicht, wenn ich sage, dass ich Stunden mit Debugging verbracht habe. Bis ich plötzlich realisierte, dass s-nail die offiziellen Mail-Executables mail, mailx und/oder sendmail unter /usr/bin verwendet. Der Lackmus-Test: Wenn ich diese Mail-Executables manuell aufrief, erschien ein- und dieselbe Fehlermeldung.

Dies obwohl meine Bash PATH-Variable /opt/local/bin und /opt/local/sbin vor /usr/bin und /usr/sbin nennt, verwendete s-nail aus irgendeinem Grund standardmässig die letztgenannten Pfade.

Wie sage ich s-nail aber, dass es stattdessen die MacPorts mail-Befehle verwenden soll? Folgende Anpassung in /opt/local/etc/mail.rc war nötig:

...
set mta=/opt/local/sbin/sendmail

Absender (From:) der E-Mails selber festlegen

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. Ich verwende in Bash-Scripts sehr oft folgendes Konstrukt, und ich wollte sicherstellen, dass die Scripts sowohl unter Debian GNU/Linux als auch macOS laufen (Argument -a):

$ echo -e "Test" | $(which mail) -a "From: DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Ich habe leider eine schlechte, aber auch eine gute Nachricht. Die gute: Man kann auch unter macOS den Absender setzen. Leider aber nicht mit demselben Befehl wie unter Debian GNU/Linux.

Bei s-nail muss ich leider ein anderes Argument verwenden:

$ echo -e "Test" | $(which mail) -r "DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Postfix hat Probleme mit selber gesetzter Absenderadresse und SPF Records

Doch nun trat bereits das nächste Problem auf, wie ein Blick in die leere INBOX und in /var/log/macports/postfix.log zeigte:

...
Mar 01 15:43:59 imac postfix/smtp[81049]: 4D0E3FBBE221: to=<user@domain.tld>, relay=s000.cyon.net[149.126.4.000]:25, delay=20, delays=0.03/20/0.03/0.04, dsn=5.0.0, status=bounced (host s000.cyon.net[149.126.4.000] said: 550 SPF: 1.2.3.4 is not allowed to send mail from emeidi.com (in reply to RCPT TO command))
...

Faszinierend. Unter Linux hatte ich eine solche Fehlermeldung noch nie gesehen. Ich verwende für den Versand „offizieller“ E-Mails jeweils emeidi.com als Absenderadresse.

Schlussendlich blieb nur die Holzhammer-Methode. Ich verschob alle Konfigurationsdateien, welche auf meinen Linux-Installationen nicht existierten, von /opt/local/etc/postfix in den Unterordner _old. Schlussendlich sah das Verzeichnis so aus:

$ find /opt/local/etc/postfix/opt/local/etc/postfix
/opt/local/etc/postfix/_old
/opt/local/etc/postfix/_old/access
/opt/local/etc/postfix/_old/access.sample
/opt/local/etc/postfix/_old/aliases
/opt/local/etc/postfix/_old/aliases.sample
/opt/local/etc/postfix/_old/bounce.cf.default
/opt/local/etc/postfix/_old/canonical
/opt/local/etc/postfix/_old/canonical.sample
/opt/local/etc/postfix/_old/generic
/opt/local/etc/postfix/_old/generic.sample
/opt/local/etc/postfix/_old/header_checks.sample
/opt/local/etc/postfix/_old/LICENSE
/opt/local/etc/postfix/_old/main.cf.default
/opt/local/etc/postfix/_old/main.cf.proto
/opt/local/etc/postfix/_old/main.cf.sample
/opt/local/etc/postfix/_old/master.cf.proto
/opt/local/etc/postfix/_old/master.cf.sample
/opt/local/etc/postfix/_old/relocated
/opt/local/etc/postfix/_old/relocated.sample
/opt/local/etc/postfix/_old/TLS_LICENSE
/opt/local/etc/postfix/_old/transport
/opt/local/etc/postfix/_old/transport.sample
/opt/local/etc/postfix/_old/virtual
/opt/local/etc/postfix/_old/virtual.sample
/opt/local/etc/postfix/header_checks
/opt/local/etc/postfix/main.cf
/opt/local/etc/postfix/makedefs.out
/opt/local/etc/postfix/master.cf
/opt/local/etc/postfix/postfix-files
/opt/local/etc/postfix/sasl
/opt/local/etc/postfix/sasl/outgoing
/opt/local/etc/postfix/sasl/outgoing.db

In sasl/outgoing entfernte ich zudem den TCP-Port nach der Server-Adresse, und master.cf ergänzte ich mit Zeilen, die bisher nur unter Linux existierten.

Heureka

Und jetzt endlich kann ich mir von der Kommandozeile aus E-Mails senden. Hat nur geschlagene sechs Stunden gedauert.

Tags: , , , , , , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Februar 2020

In wie vielen Schweizer Haushalten lauscht Kantar Media den Internet-Verkehr mit?

Einem Bekannten habe ich damit geholfen, sein Heimnetzwerk zu aufzubauen und helfe ihm bis heute dabei, es zu betreiben.

Vor einigen Wochen meldete sich der Bekannte bei mir und erzählte mir davon, wie er gerade einen Besuch von einem Mitarbeiter der Kantar Media Switzerland GmbH erhalten hatte.

Medienkonsum messen

Mein Bekannter hat sich seit längerem dazu bereit erklärt, für eine kleine Entschädigung eine Box des Unternehmens bei ihm in der Stube zu installieren, welche die gerade konsumierten Radio- und TV-Sendungen erkennt und diese an das Unternehmen zurückmeldet.

Ich vermute dies erfolgt mittels Fingerprinting des Audiosignals von Radio- und TV-Sendungen zusammen mit einem exakten Timing-Signal, in etwa vergleichbar mit der iPhone-App Shazam, welche einem sagt, wie das Lied heisst, welches man gerade im Radio oder in der Disco hört.

Ich mag mich diesbezüglich an Vorlesungen in meinem Studium der Medienwissenschaften erinnern, in welchen Matthias Friedrich Steinmann jeweils erzählte, wie er selber eine solche Firma aufgebaut und zum internationalen Erfolg geführt hatte. Abnehmer der von ihn erhobenen Daten waren die Radio- und Fernsehsender sowie die Werbeindustrie. Anhand der Zuhörer- und Zuschauerzahlen und deren Demographie konnte man den Preis für Werbeminuten berechnen und den beworbenen Unternehmen vorrechnen, wie viele Leute mit einer Werbung potentiell erreicht werden konnten.

Das unsichtbare Streaming

Beim letzten Besuch brachte der Kantar-Mitarbeiter ein neues, zusätzliches Kästchen mit. Auf Grund der digitalen Revolution konsumieren immer mehr Leute Streaming-Angebote über das Internet. Das neue Kästchen wird deshalb an das Netzwerk gehängt und erkennt, wenn im Haushalt Streaming-Angebote konsumiert werden und meldet Informationen dazu an das Unternehmen zurück. Dies ergänzt das bisherige Kästchen, welches den „konventionellen“ Radio- und TV-Konsum überwacht.

MITM Black Box?

„Spannend!“, dachte der Information Security Professional in mir. Und irgendwie war mir da schon bewusst, dass da etwas nicht ganz koscher sein konnte: Da kann meiner bescheidenen Meinung nach nur Packet Capturing zum Einsatz kommen, welches den gesamten ausgehenden Internet-Verkehr mitschneidet, in Echtzeit analysiert und aus den Paketen die URLs herausfiltert, welche auf den Konsum von Streaming-Angebote hindeuten. Diese Informationen werden per Internet in Echtzeit an Server des Unternehmens übermittelt, dort gespeichert und zu verkaufbaren Auswertungen verwurstelt. Wie das aber mit verschlüsseltem Verkehr (HTTPS) funktionieren soll, ist mir bis heute unklar (SNI?).

Hier ein Photo des ominösen Kästchens mit der Aufschrift „Kantar Media UK Ltd“, „Made in England“, „Model 5010-001“ einer Seriennummer sowie „CAN ICES-3 (B)/NMB-3(B)“:

Als ich dieses Gerät sah, war ich verwirrt: Ich hätte erwartet, dass es einen Ethernet-Eingang sowie einen Ethernet-Ausgang aufweist und zwischen den Router und das restliche Netzwerk gepatcht wird. Wie auf dem Photo sichtbar verfügt das Kästchen aber nur über einen Ethernetport.

IP-Konflikt

Ein Blick in das Log von arpwatch zeigte mir dann das Übel: Das Kästchen war mit der internen, nicht-öffentlichen IP-Adresse des Routers konfiguriert worden. Das arpwatch-Log war dementsprechend voll mit flip flops, sozusagen ein Abbild des Kampfes des EdgeRouters mit dem Kästchen über die Vorherrschaft der nun doppelt vorhandenen IP, die von zwei unterschiedlichen MAC-Adressen beansprucht wurde.

Ein Kollege vermutet, dass wenn das Kästchen genug lange im Netzwerk aktiv gewesen wäre, schlussendlich alle Clients das Kästchen als Gateway angesprochen hätten. Das Kästchen wiederum hätte den Verkehr dann über den echten Router ins Internet gelotst.

Zwischenfazit

Für mich war der Fall klar: Die MAC-Adresse des Geräts wurde im UniFi-Controller kurzerhand geblockt, und der Block ist bis heute aktiv.

Ich befürchte, dass diese Black Box in Haushalten von hunderten Familien in der Schweiz installiert ist und schön brav den gesamten Internet-Traffic der „Kunden“ mitschneidet.

Vermutlich sind sich die wenigsten Leute über die Sicherheits- und Datenschutzimplikationen im Klaren, auf welche sie sich mit der Installation dieses Trojaners eingelassen haben.

Vielleicht habe ich einfach eine zu blühende Phantasie und alles ist extrem simpel aufgebaut — die Logik im Kästchen schaut nur die Ziel-IP-Adressen an, und vielleicht noch die übertragene Datenmenge. Fertig. Damit lassen sich aber nur Aussagen machen wie „Mario Aeby, männlich, 39, verheiratet, wohnhaft in Bern in einem Zweipersonenhaushalt, Haushaltseinkommen 50’000 Franken, konsumiert an Abenden und Wochenenden zwischen 30 und 60 Minuten Amazon Prime, Netflix oder Apple TV“. Ob das dem Unternehmen reicht?

Läuft mit der Datensammlung aber etwas schief (absichtlich oder unabsichtlich), werden DNS-Queries mitgeschnitten und Firmware-Updates auf das Gerät gepusht, welche dann ein deutlich gläsernes Bild von mir zeichnen könnten. Mit nicht viel Aufwand könnte das Kästchen sogar verhindern, dass ich bestimmte Adressen ansurfen kann. So etwa wie es China seit Jahren mit dem Internetkonsum seiner Bevölkerung macht.

Und ja, vermutlich könnte ein Techniker im Fernwartungsmodus problemlos das LAN auskundschaften gehen, in welchem sich das Kästchen befindet.

Nachtrag

Höchstwahrscheinlich handelt es sich bei diesem Gerät um den Kantar Focal Meter. Das Unternehmen berichtet diesbezüglich:

Kantar’s Focal Meter collects data by intercepting web traffic from all devices connected to the home router, preserving respondent privacy by only reporting data from a specified list of BVOD and other online video sites.

Quelle: BARB commissions Kantar Focal Meter for deployment across UK Television Audience Measurement Panel

Mit einer Google-Suche stösst man dann auch auf ein Web Learning-Angebot, welches vermutlich nur für Kantar-Mitarbeiter gedacht ist. Die Homepage ist aber für jedermann frei zugänglich und zeigt neben einem Photos des Geräts auch ein interessantes Schema, bei welchem es sich aber nicht um den Aufbau des Focal Meters handelt, sondern des Virtual Meters (einer Software, die auf den Computern der Teilnehmer installiert wird).

Tags: ,
Labels: Security

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Februar 2020

Anstelle des Green Screens kommt in Hollywood jetzt der LED-Screen

Die Leute von ILM haben für die Star Wars-Serie The Mandalorian eine neuartige Technologie namens Stagecraft entwickelt, welche auf gigantischen LED-Screens beruht und die altbekannten Green Screens grösstenteils überflüssig macht.

Die exakte Position und Ausrichtung der Filmkameras wird im Raum bestimmt und das auf den LED-Screens anzuzeigende Bild mit der aus Computer-Spielen bekannten Unreal Engine im korrekten Blickwinkel entsprechend gerendert.

Im Grunde kehrt man also zurück zu den Matte-Paintings, welche nun aber als Lichtquelle dienen, animiert sein können und deren Blickwinkel man in Echtzeit anpassen kann.

Die folgende Reportage geht ausführlich auf die (aktuellen) Limitationen der Technologie ein: Rechenkraft, aber auch die vorgängige Auswahl und Besuch der Landschaften für hochauflösende Photos und Vermessungen.

Die Vorteile hingegen überwiegen: Schauspieler können sich besser in das „Bühnenbild“ hineinversetzen, man benötigt keinen Green Screen mehr und hat somit auch potentiell keine grünen Artefakte mehr, die man nachher rausretuschieren muss — und generell ein deutlich verkürztes Post Processing. Der grösste Vorteil aus meiner Sicht:

We can create a perfect environment where you have two minutes to sunset frozen in time for an entire 10-hour day,

The Mandalorian: This Is the Way – The American Society of Cinematographers

Tags: , , , , , ,
Labels: Unterhaltung

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Februar 2020

Vin Jaune

Im Juni 2019 stolperte ich über einen Artikel in The Atlantic. Wissenschaftler haben herausgefunden, dass die Traubensorte Savagnin Blanc in Europa seit über 900 Jahren unverändert angepflanzt wird:

In a medieval cesspit in central France, archaeologists dug up a small, hard grape seed. They believed it to be 900 years old, based on the artifacts found nearby. When geneticists crushed up the grape seed, extracted its DNA, and compared it with modern grapes, they found a perfect genetic match in Savagnin Blanc—a grape still grown, still picked, and still made into wine in Europe today.

This grape, it turns out, has survived unchanged for almost a millennium. In a time that has spanned the Hundred Years’ War, the Enlightenment, the French Revolution, Napoleon, and two world wars, someone has always thought to take cuttings of Savagnin Blanc to keep planting into the ground anew.

Quelle: A Medieval Grape Is Still Used to Make Wine

Was mein Interesse weckte war der Hinweis auf einer Weinsorte, von der ich noch nie gehört hatte:

Savagnin Blanc is also known as Traminer Weiss, and it is still grown in a few European countries. But it is perhaps most famously used to make vin jaune or “yellow wine” from Jura in France. Vin jaune comes in a squat bottle called a clavelin and it has taken on a bit of a cult status. “It is probably the weirdest wine you’ll ever have,” Bonné says. “It is intensely yellow-colored. The best way I can describe it, it has almost no fruit characteristics. It’s nuts, almonds, and walnuts, and this very distinct, slightly acidic tang, too.”

Gestern kam mir dieser mysteriöse Wein wieder in den Sinn, und ich machte mich kurz vor Ladenschluss auf den Weg in den Globus Bern, um den teuersten Wein zu kaufen, den ich mir in meinem Leben geleistet habe:

Vin Jaune Arbois 2009 für 65 CHF; an Lager im Globus Bern-Marktgasse

(Vermutlich hätte es für die erste Degustation auch ein ähnliches Produkt aus dem Manor für die Hälfte des Preises getan. Doch diesen Wein müsste ich online bestellen und in die neue Filiale in Bern liefern lassen.)

Wieder zu Hause entdeckte Stephanie die Preisetikette, worauf ich mich genötigt sah, auf YouTube nach englischen Degustationsnotizen zu suchen. So war es mir möglich, ihr ohne grosse Worte zu erklären, was an diesem Wein so speziell sein soll:

(Schlechte Videoqualität, und das Intermezzo mit dem Mitarbeiter fand ich unpassend — aber immerhin ein englisches Video, welches einem den Geschmack des Weins näherbringt)

Nun warte ich auf die passende Gelegenheit, den (hoffentlich) edlen Tropfen zu geniessen.

Tags: , , , , , ,
Labels: Essen

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Offenbar kein Android TV 9 Pie für meinen Sony KD-65AG8

Sony hat kürzlich ein Update für seine Android TVs veröffentlicht, welches Android TV 9 bereitstellt. Das interessanteste neue Feature: Apple AirPlay- und Apple Homekit-Unterstützung.

Leider unterstützt mein kürzlich gekaufter Sony Bravia KD-65AG8 (OLED) das Update nicht. Der Grund liegt offenbar weder bei Sony noch bei Google:

Yeah Google requires 3 major updates, but unfortunately the MediaTek CPU chip inside the older TVs is discontinued so there’s no Android 9 support for it. Therefore Sony can’t install Android 9 on that CPU. Because Sony needs MediaTek to update the CPU’s software (Linux kernel version). :-/

Quelle: Firmware update: Welcome to Android™ 9 Pie for Sony’s 2018-2019 TVs (AF9, ZF9, AG9, ZG9, XG85/XG87 and XG95 Series) – Starting on 11th December 2019

Gemäss ZKelectronics handelt es sich um den MediaTek MT5891. Der Sony KD-65AG9 hat hingegen den MediaTek MT5893 verbaut (Quelle).

Tags: , , , ,
Labels: Unterhaltungselektronik

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Raspberry Pi zeigt ständig „Can’t update Chromium“ Overlay an

Mein Dashboard zu Hause läuft auf einem Raspberry Pi 3 mit Debian Buster 10.2. Der RPi lädt beim morgendlichen Neustart um Punkt 05:00 Uhr den Chromium-Browser, welcher die Web-Site mit dem Dashboard aufruft.

Seit ein paar Tagen zeigt Chromium oben rechts ein Layover mit folgender Meldung an:

Can’t update Chromium

Chromium couldn’t update to the latest version, so you’re missing out on new features and security fixes.

(da ich selber kein Photo des Dashboards angefertigt habe, verlinke ich hier auf einen Screenshot eines anderen Benutzers aus dem Internet)

Da Debian kein Update von Chromium anbietet, hilft ein apt-get upgrade chromium hier leider nicht weiter.

Das Symptom behebt man, indem man Chromium mit einem zusätzlichen Kommandozeilenargument startet — nachfolgend ein Auszug aus /home/pi/.config/lxsession/LXDE-pi/autostart:

...
@chromium-browser --no-default-browser-check --check-for-update-interval=604800 --disable-pinch --incognito --kiosk

Den Tipp mit --check-for-update-interval=604800 (Eintrag in der Liste der Kommandozeilenargumente) habe ich auf Stack Overflow in der Frage Disable “chrome is out of date” notification gefunden.

Da man als verantwortungsvoller SysAdmin entweder Debian unattended-upgrades respektive cron-apt (Vergleich) eingerichtet hat, oder sich zumindest automatisiert über Paket-Aktualisierungen informieren lässt, ist diese Symptombekämpfung vertretbar.

Die Entwickler von Chromium könnten sich meiner bescheidenen Meinung nach überlegen, ob es nicht besser wäre, nur dann eine Meldung anzuzeigen, wenn auch tatsächlich ein Update verfügbar ist. Denn die Meldung erscheint rein basierend auf dem Alter der Applikation, nicht basierend darauf, ob eine neue Version verfügbar ist:

there’s background process that checks the build date against the current time, and will start to complain if it’s more than 12 weeks ago.

Quelle: Debian Bug report logs – #943668 Getting „Can’t update Chromium“ notifications

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 23. Januar 2020

grep interpretiert Dateiinhalte fälschlicherweise als Binärdaten

Ein Bash-Script, welches täglich meine SVN-Logs auf unerwartete Zugriffe durchgeht, meldete mir gestern:

...
1  Binary  file  (standard  input)  matches
...

Dabei handelt es sich um eine Meldung von grep, mit welchem ich die Apache-Logs filtere. Offenbar enthält das Access Log von dieser Woche Inhalte, die grep glauben machen, dass es sich um eine Binärdatei und nicht um eine ASCII/UTF-8-Datei handelt. In Durchgängen in früheren Monaten und Wochen trat dieses Problem nicht auf.

Wenn man sich sicher ist, dass man grep ASCII-Daten füttert, kann man dies mit einem Argument forcieren:

$ grep --text README.txt

So klappt die Auswertung nun auch wieder mit meinem Bash-Script.

Nachtrag

Gemäss diesem Unix & Linux Stack Exchange-Artikel erachtet grep eine Datei als Binär, wenn es erstmalig auf das NUL-Zeichen trifft.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

Tags: , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen