Dirks Logbuch

Da bin ich wieder ...

Ja, guter Plan, das fehlt in der heutigen Zeit: Positives Denken.

IBMs Abschied von einer Vision oder warum es sinnvoll sein kann, aus dem Homeoffice zurück zu einer Bürokultur zu kommen (ich kann das aus eigener Erfahrung unterschreiben).

IP-Adressen sollten anonymisiert werden, wenn man die Logs länger benötigt, sonst ist alles gut. Was darf ich als Website-Betreiber überhaupt noch?.

Der magische Meilenstein zeigt wie weit man kommen kann, wenn man im Selbstudium das Programmieren erlernt.

Very good screen multiplexer and worth a look. Why should you learn tmux?.

Hilf mit die OpenStreetMap zu vervollständigen mit Street Complete auf dem Android-Smartphone ist das keine Sache und macht Spass.

Ein Multi-Messenger, den ich mir unbedingt anschauen muss: Franz und die Kommunikation.

Mitarbeiter, die länger als zwei Jahre in einer Firma bleiben, verdienen langfristig 50 Prozent weniger, es war schon immer klar, dass man nirgends bessere Gehaltserhöhungen bekommt als durch den Wechsel des Arbeitgebers, aber diese Summe ist wirklich viel.

Heute ist es soweit, dieses Blog - Dirks Logbuch - hat heute seinen zwölften Geburtstag. Ich hätte nie gedacht, dass es so lange überlebt, bin aber sehr glücklich, dass es noch da ist.

Seit dem ersten Tag läuft es mit der "besten Blogsoftware der Welt" Serendipity und es wäre gelogen, wenn ich sagen würde, dass ich nie auch nach anderer Blogsoftware geguckt habe. Aber Serendipity bietet alles, was ich brauche und ich komme damit hervorragend zurecht.

Ich habe vieles mit dem Blog ausprobiert, viele Artikelformate, zeitweise sogar einen (oder mehrere) Artikel pro Tag, aber jetzt bin ich in geregeltem Fahrwasser und mache wöchentlich meinen Linkdump und dann noch Artikel, wenn mir der Sinn danach steht, ohne Auflagen und ohne Verpflichtungen.

Natürlich habe ich auch mit der Software alles mögliche ausprobiert und verschiedene Designs gehabt. Es wäre an der Zeit mal neu anzufangen und die Installation gerade zu ziehen, aber dazu fehlt mir der Wille.

An dieser Stelle darf nicht unerwähnt bleiben, dass ich diesen Gedenktag (zufällig) mit anderen Ereignissen teile.

Towel Day, year 2001, age 16 years
Geek Pride Day, year 2006, age 11 years
Nerd Pride Day, year 2006, age 11 years
Star Wars Premiere, year 1977, age 40 years
Dirks Logbuch, started 2005, ago: 12 years

(Ausgaben aus meinen Skript daterem).

Very interesting project with a very helfpul developer, Markdown Presentations for Everyone.

Die Letzte - schöne Kolumne über Leichtigkeit und Termine ...

Wird leider viel zu selten thematisiert: Die Schattenseite der Remote Work.

New distro’s coming to Bash/WSL via Windows Store - the rise of a pretty much interesting ecosystem.

Braucht man das, wenn es die Dienste bereits gibt? Whatsapp und Messenger direkt im Browser.

Microsoft hält USB C für nicht massentauglich. Tja, aller Anfang ist schwer.

Aus der Reihe "schlechtes Marketing", heute: Deutsches Serial.

Momentan häufen sich die Anfragen nach Artikeln oder Vorträgen oder Tests bei mir.

Danke!

Ich freue mich riesig darüber, dass Ihr meine Meinung für so interessant haltet, dass Ihr sie hören oder veröffentlichen wollt. Aber leider werde ich wenigstens bis Ende Juni nichts mehr zusätzlich annehmen können. Die Dinge, die ich zugesagt habe, erfülle ich gerne und hoffentlich auch gut, aber mehr geht im Moment nicht.

Da hoffe ich einmal auf Euer Verständnis.

Leider muss ich jetzt doch etwas längeres dazu schreiben, weil mich die polemisierenden Nachrichten nerven.

Kurz zusammengefasst:

Ich habe kein Mitleid mit Firmen, die von Wannacry betroffen sind. Mein Mitleid geht an die Menschen, die nichts damit zu tun hattem wie beispielsweise Patienten von Krankenhäusern.

Wannacry hat mit Admins zu tun, die ihre Hausaufgaben nicht gemacht haben; mit Entscheidern, die kein Geld für ein Update bewilligen und mit Anwendern, die auf alles klicken, was klickbar ist und Warnhinweise ignorieren. Es hat nichts mit Windows vs. Linux zu tun. Ein ungepatchtes und nicht supportetes Linuxsystem ist auch ein Sicherheitsproblem.

Längere Version:

Soweit ich verstehe und aus diesem Link mitnehme, läuft die initiale Verbreitung folgendermassen:

Ein Benutzer bekommt per Mail eine Passwort geschützte ZIP-Datei in der ein Dokument ist. Wenn das Dokument geöffnet wird, wird eine unsignierte ausführbare Datei nachgeladen und diese ausführbare Datei enthält alles, was der Wurm braucht, Code zur Infizierung, Vervielfältigung und Verseuchung der Zielsysteme, wobei eine Schwachstelle in SMB ausgenutzt wird. Durch den User erreichbare Dateien (insbesondere Netzwerkshares) werden verschlüsselt.

Der Benutzer muss mehrfach bestätigen, dass er Dinge "wirklich" tun will (Ungeschützte Datei öffnen, Makros ausführen, Datei aus unsicherer Quelle ausführen).

Erste Möglichkeit, es gar nicht erst zu solchem einem Eklat kommen zu lassen, wäre beispielsweise die Schulung der Nutzer.

Für noch im Support befindliche Betriebssysteme, also nicht Windows XP, hat Microsoft bereits Mitte März dieses Jahres einen Patch veröffentlicht.

Zweite Möglichkeit, kritische Patches kurz nach Erscheinen einspielen.

Das hilft nicht, wenn man nur Windows XP hat und die Entscheider kein Geld für neue Lizenzen ausgeben wollen. Hier ist die dreckige Wahrheit: Der Unterhalt einer IT-Infrastruktur kostet Geld für Hardware, Softwarelizenzen und Support-Personal. Es liegen vier aktuell supportete Versionen zwischen XP und heute (Windows Vista, Windows 7, Windows 8 und Windows 10). Selbst, wenn man sich entscheiden würde, nur jede zweite oder dritte Inkarnation von Windows einzusetzen, hätte es mit dem rechtzeitig veröffentlichten Patch keine Probleme gegeben.

Es geht nicht um "XP ist Mist", es geht in diesem Fall um abgelaufenen Herstellersupport.

Von einem Oldtimer würde man auch nicht erwarten, dass er einen Airbag hat ...

Um in der Analogie zu bleiben: Windows XP hat 2001 das Licht der Welt erblickt, das ist vor 16 Jahren. Wie viele Geschäftsführer fahren 16 Jahre alte Autos? Ich kenne keinen. Geld für ein neues Auto wäre also da, aber nicht für Softwarelizenzen. Das passt nicht.

Dazu gibt es noch mehrere Möglichkeiten, technisch dem Problem beizukommen, gekapseltes E-Mail-System, Paketfilter, ... aber die sind meiner Meinung nach nicht mit vertretbarem Aufwand handhabbar.

Fazit:

Es führt nichts, gar nichts daran vorbei Anwender zu schulen. Selbst, wenn das zu Grunde liegende System von Windows auf irgendetwas anderes wechselt, hilft die Schulung, dass die gleichen Fehler nicht auf den neuen Systemen gemacht werden.

Ebenfalls ist es nötig, zeitnah kritische Patches einzuspielen. Selbst Unternehmen mit sehr konservativen Patchzyklen (ein Mal pro Jahr) kennen "Emergency-Patching".

Egal, welches System eingesetzt wird, es muss durch den Hersteller oder die Community unterstützt sein (ich kenne reichlich Menschen, die ein lange nicht mehr gewartetes Debian einsetzen).

• Wem die Supportzyklen zu kurz sind, muss auf etwas mit längeren Supportzyklen wechseln.
• Wer lizenzpflichtige Betriebssysteme (oder auch andere Software) einsetzt, muss diesen Kostenpunkt dringend in seinem Budget einplanen.

Wir hatten gestern einen Cloud-Provider zu Gast. Kurzer Check: Wie viele - zum Teil widersprüchliche - Definitionen des Begriffs "Cloud" kennt Ihr? Mir gefällt "Can't locate our users data" immer noch am Besten

Ernsthaft, "Cloud" beginnt bei einer VMWare-Umgebung und hört bei fehlertoleranten Systemen - insbesondere tolerant gegen Hardwareausfälle - noch lange nicht auf. Die gebräuchlichste und eine der sinnvollsten Definitionen kommt vom NIST: The NIST definition of cloud-computing (PDF).

Der grösste Fehler, den die meisten Anbieter und Kunden von Cloudsystemen begehen, ist, dass sie den Fallacies of Distributed Computing auf den Leim gehen und Vorannahmen treffen, die nicht stimmen.

1. Das Netzwerk ist ausfallsicher
2. Die Latenzzeit ist gleich Null
3. Der Datendurchsatz ist unendlich
4. Das Netzwerk ist sicher
5. Die Netzwerktopologie wird sich nicht ändern
6. Es gibt immer nur einen Netzwerkadministrator
7. Die Kosten des Datentransports können mit Null angesetzt werden
8. Das Netzwerk ist homogen

Wer jetzt "Klar! Logisch!" denkt, gewinnt vermutlich auch im Bullshit-Bingo.

Alle anderen können sich dieses PDF einmal anschauen und versuchen zu verstehen: Fallacies of Distributed Computing Explained.

Gerade beim Outsourcen in eine Public oder Hybrid Cloud (gemäss NIST) sollten diese Trugschlüsse dringend berücksichtigt werden.

Wenn Ihr Cloud-Angebote vergleicht, vergleicht sie bitte auch mit Euren internen Systemen. Der im ersten Satz angesprochene Cloud-Provider bietet unter anderem eine mittlere Zugriffszeit von 5 ms auf Storage ... da ist unser internes System mit durchschnittlich 0.2 ms um den Faktor 25 schneller.

Woohoo! Dieses Mal mit richtig vielen Links.

Eine sehr schöne und übersichtliche Alternative zu AWstats oder das nicht sterbende Webalizer, Web-Stats mit GoAccess.

How to Password Protect a Vim File in Linux, bis jetzt habe ich immer vim.gpg benutzt, aber das scheint eine sinnvolle Alternative zu sein.

Ich halte für sehr gut, dass die Projekte entkoppelt werden Thunderbird bleibt bei Mozilla – und wird unabhängig.

Schüler wählen weniger extrem, was an sich schon eine gute Aussage ist, aber sie motivieren auch ihre Eltern zur Wahl zu gehen.

Ich halte das für ausgemachten Blödsinn, Netzwerk ist mehr als IP Adresse und Route setzen ... Die Zukunft des Netzwerk-Admins ist der Linux-Sysadmin.

Some things I've decided to do to improve my breaks and vacations, interesting, that work-life-ballance is best when separating work and life.

Das scheint mir dann doch ein Statement zu sein, was nur für den amerikanischen Markt gültig ist, Dumm durch Podcasts.

So klappt’s mit der Freundschaft unter Kollegen ... bin mir nicht sicher, ob man nicht nur einfach normal sein sollte.

Sometimes we need to be remembered how good things are, when you look at them from the outside: My First Experience with German Public Healthcare.

Die fünf grössten Passwort-Mythen, nachdenkenswert, dazu müssten die Herrsteller auch mal lange Passwörter mit Leer- und Sonderzeichen unterstützen.

Hmpf, als ob es nicht genügend Gründe gäbe, Wann ein Relaunch nötig ist.

Wie Ihnen private Aktivitäten zum Erfolg verhelfen, seien sie individuell, halten sie sich aber an folgende Regeln.

Da der Begriff immer häufiger benutzt wird, hier einmal eine nachvollziehbare Erklärung T-Shaped Professional – Einer für alle, alle für einen.

Freiheit im Beruf lässt sich nicht durch Standards regeln und auch nicht durch jeden Chef ...

"Und, was machen Sie beruflich?" - "Ich bin Pendler." - 8 Tipps für Ihren entspannten Arbeitsweg.

Zu viele Freunde verderben den Stream, dieses Social-Zeugs wird ja sowieso überbewertet.

Jip, ich nutze Gitea und kann es nur empfehlen (wer einen Account möchte, darf sich gerne melden) Gitea oder Gogs statt Github und Gitlab.

DevOps Saved My Life (Probably) - its a different Release Model which is responsible.

Hauptleseempfehlung der Woche: Über die Zukunft der Arbeit - Wir dekorieren auf der Titanic die Liegestühle um".

Am dritten und vierten Mai habe ich an den ersten DevOpsDays in Zürich-Winterthur teilgenommen. Diese Konferenzform hat in der Schweiz zum ersten Mal stattgefunden und die Organisatoren haben meiner Ansicht nach herausragende Arbeit geleistet.

Das Veranstaltungsformat gefällt mir sehr. Vorträge bis zum Mittagessen, danach - um einem Schnitzelkoma vorzubeugen - Ignite Talks (ein Format, das ich vorher noch nicht kannte, ich kenne nur Lightning Talks) und abschliessend zum Mitmachen Open Spaces (das kenne ich bereits von Barcamps).

Zu den einzelnen Programmpunkten werde ich in weiteren Artikeln noch Stellung beziehen, hier an dieser Stelle möchte ich nur zwei Punkte hervorheben.

Für mich ist sehr interessant zu sehen, dass die Hauptprobleme bei DevOps die Menschen sind und nicht die Technologie. Das ist sehr logisch, aber es ist vielen nicht bewusst. Zu den Menschen zählt auch Unternehmenskultur und festgefahrene Meinungen. Das wird von vielen Entscheidern anders veranstanden, aus diesem Grund ist es wichtig, das besonders hervorzuheben.

Passend dazu das HumanOps Manifest:

• Humans build and fix systems.
• Humans get tired and stressed, they feel happy and sad.
• Systems don't have feelings yet. They only have SLAs.
• Humans need to switch off and on again.
• The wellbeing of human operators impacts the reliability of systems.
• Alert Fatigue == Human Fatigue
• Automate as much as possible, escalate to a human as a last resort.
• Document everything. Train everyone. Save time.
• Kill the shame game.
• Human issues are system issues.
• Humans > systems
• Human health impacts business health.

In meinem Umfeld, System Engineering und Systemadministration, wird die DevOps-Bewegung wahrgenommen als (viele Entwickler vertreten das auch so, sie haben es eifnach nicht verstanden):

Jetzt haben wir Entwickler endlich Zugriff auf die Produktion, jetzt zeigen wir Euch, wo es lang geht und wie Agil funktioniert.

Dazu passt irgendwie gar nicht, dass bei den Entwicklern eines der Hauptthemen Bereitschaft ("On-Call" oder Pikett) war, etwas, das in der Systemtechnik schon seit Jahren kein Problem ist. Interessanterweise ist die Frage aufgetaucht, wie man denn in der Bereitschaft entscheiden sollte, was man tun darf und muss. Wenn die Entwickler der Software das nicht wissen, warum erwarten sie, dass die Ops-Leute das wissen (und seit Jahren praktizieren)? Auch dort steht ein Kulturwechsel an.

Zum Thema Bereitschaft mache ich noch einmal einen separaten Artikel.

Es ist gut, dass immer mehr verstanden wird, dass DevOps ein miteinander ist. Beide "Seiten" können von einander lernen.

Diesen Artikel habe ich schon sehr lange in der Pipeline. Das aktuelle Release von tasksh ist ein guter Anlass ihn auch zu veröffentlichen.

"Eigentlich" (tm) ist tasksh eine Hilfe für Tippfaule, die nicht immer das Kommando task tippen wollen, wenn sie mit ihren Aufgaben arbeiten.

Aber tasksh hat ein Killerfeature und das ist review, das Kommando tut genau das, was der Name auch impliziert. Es hilft Euch, regelmässig Eure Aufgabenliste durchzusehen. Das Feature gibt es seit Version 1.1.0, aktuell ist seit heute Nacht die Version 1.2.0.

Dazu speichert es in einem User defined Attribute den Zeitpunkt, wann das letzte Review stattgefunden hat und nimmt sich die Aufgabe erst dann wieder vor, wenn eine Woche (konfigurierbar!) vergangen ist.

Wenn nur Zeit ist, sich beispielsweise fünf Aufgaben anzusehen, dann kann man review auch mit dem Parameter 5 aufrufen, um die Anzahl der durchzusehenden Aufgaben zu beschränken.

Da ich gerne meine offenen Aufgaben einmal pro Woche durchschauen möchte, nutze ich nur aus diesem einen Grund tasksh.

Neben vielen anderen Pluspunkten ist die Shell etwas, was ich an Linux besonders mag.

Bis vor kurzem habe ich meine LaTeX-Präsentationen und andere Dokumente mittels Makefile und einer Endlos-Schleife entwickelt. Dokumentbetrachter wie beispielsweise Okular oder Evince (Adobe Reader kann es nicht) erlauben es, dass eine gerade angeschaute Datei verändert werden darf und zeigen die Veränderungen auch direkt an.

Dazu benutze ich ein (nahezu) generisches Makefile (make clean löscht beispielsweise alle Temporärdateien):


Und der Rest wird durch eine Endlossschleife erledigt:


Allerdings hat sich dieses Verfahren erledigt, nachdem ich bei Sujeevan von latexmk gelesen habe.

Seit dem reicht ein:

Nicht so viele Fundstücke dieses Mal, hoffentlich ist etwas für Euch dabei.

Der Artikel spricht mir komplett "aus der Seele", danke: Werbeanfragen….

Warum unsere Schulen NICHT auf Microsoft (oder Apple) setzen sollten - meine Meinung ist, dass Schulen Konzepte und keine Produkte vermitteln sollten.

Ich habe den Kampf nicht ganz gesehen, nur eine Zusammenfassung, aber ich mag sehr, wie beide Gegner miteinander umgegangen sind. Was Klitschkos Niederlage fürs Boxen bedeutet.

Netztest von «Connect», es ist schon spannend, was der Platzhirsch in der Schweiz aus dem dem zweiten Platz macht ...

Ich finde es sehr spannend zu sehen, wie die Jugendlichen heute mit Technik umgehen, „Wir haben zwei Computerräume, aber da gehen wir so gut wie nie hin“.

Wie Meetups, Barcamps und Konferenzen meine Arbeit erleichtern. Ja, ich finde es auch wichtig, mit Menschen ins Gespräch zu kommen.

Wenn man - wie beispielsweise ich - sehr (sehr) viel Open-Source-Software benutzt, kommt man irgendwann zu dem Punkt, dass man auch selber etwas beitragen möchte. Das ist viel leichter als man gemeinhin denkt. Aus diesem Grund habe ich im letzten Jahr auf der OpenRheinRuhr einen dazu passenden Vortrag gehalten.

Hier sind die Folien dazu (JavaScript):



Es gibt da leider zwei Dilemmata:

Aus Sicht des potentiellen Unterstützers: Gerade meine Fähigkeiten werden in dem Projekt, dass ich gerne unterstützen möchte, nicht benötigt. Gut, dann kann man sich immer noch in einem anderen Projekt engagieren, nur da dann leider nicht mit so viel Herzblut. Aber, wie im Vortrag erwähnt, es lohnt sich immer, Werbung für das Lieblingsprojekt zu machen.

Ärgerlich hier ist, dass man darüber nur sehr bedingt (kaum) Anerkennung bekommt und gerade diese Anerkennung eine der grössten Triebfedern ist.

Aus Sicht des Projektes ist es umgekehrt leider häufig so, dass gerade das eigene Projekt nicht so viel Liebe ab bekommt, wie man gerne hätte oder dass die gebrauchten Fähigkeiten so speziell sind, dass nur wenige Menschen beitragen können. Da ist dann leider auch schwierig, die eigenen Qualitätsmassstäbe herunter zu schrauben, um mehr Unterstützer zu bekommen.

Die Alternative wäre, jeden beitragen zu lassen und dann als Qualitätsverwalter die Leute in die richtige Richtung zu stossen. Das birgt wiederum die Gefahr, dass es mir dann irgendwie selber keinen Spass mehr macht.

Was also tun? Stabile Seitenlage?

Ich habe dafür keine Lösung, zumindest keine gute, die alle zufrieden stellt. Ich selber nutze privat (fast) ausschliesslich Open-Source-Software, kann mich aber "nur" in drei Projekten engagieren, obwohl es alle anderen auch verdient hätten.

Wenn Ihr Vorschläge und Ideen habt, schreibt sie gerne in die Kommentare.

In den "Core Utilities" der meisten Linuxdistributionen findet sich das Tool GNU time (ja, die Homepage ist ein bisschen, nun, ..., nichtssagend).

Das time-Kommando als eingebautes Kommando der Bash (oder anderer Shells) kennen viele, auch die charakteristische Ausgabe:



Ein wenig gesprächiger ist GNU time:



Im "verbose-Modus" kann man dann aber schon richtig ordentlich Informationen abgreifen:



Die manpage gibt noch weitere Optionen an.

In den letzten Jahren habei sich reichlich viele tar.bz2-Archive mit zum Teil über 100 Gigabytes bei mir angesammelt. Die mussten einmal dringend aufgeräumt werden.

Bei Aufräumen war mir Pipe Viewer eine grosse Hilfe. Na, ja, Hilfe ist vielleicht übertrieben, aber "subjektive Zeitverkürzung" hat auch ihren Wert.

Pipe Viewer macht genau das, was der Name vermuten lässt, es zeigt - unter anderem - den Fortschritt von Pipes an.



Der umgekehrte Weg ist komplexer, weil die Grösse der Daten an das Kommando übergeben werden muss.



Weitere sehr gute Beispiele finden sich auf der verlinkten Homepage.