Yes they are wrong. A contribution may consist of “merely” a bug report. Even just asking questions may indicate that the UX or documentation is lacking.

No? This will search the logfiles (if irssi is configured to create those at all) for a pattern. This still requires that you had to have an irssi client running and connected to the server/channel in question, during the time the user is afk. Which is why others recommend e.g. setting up ZNC.

There are also mutt and neomutt.

I personally have been using the latter for years, but it requires some time to setup and tweak until it fits your purposes.

Documentation is top-notch though, and customizability a first-class concern.

Ich kann bzw. werde nur zu dem zweiten Punkt etwas sagen. Hier wurde ja keine kryptografische Verschlüsselung “gebrochen”, sondern es wurde eine Umleitung (der “Man in the middle”) eingeführt, eingehende Daten vom Client (Nutzer) mitgeschnitten und an den Server weitergeleitet.

Das können sowohl Nutzer als auch Serveradmins merken, theoretisch. Nutzerseitig geht man im Moment eben noch davon aus, dass nur solche CAs vom Browser als Vertrauenswürdig eingestuft werden, die bestimmte Mindestkriterien erfüllen. Das ist heute bereits nicht perfekt, wie etwa hier dazu angemerkt wurde.

Aber zumindest ist es nach heutigem Stand für diese CAs verpflichtend, dass sie sich an den “Certificate Transparency Log”-Standard halten. Ungewöhnliche Logeinträge haben die Server-Admins in dem verlinkten Artikel auch bemerkt und auf crt.sh verwiesen, sie hatten aber kein automatisches Monitoring dafür.

Wenn man eine Domain verwaltet, kann man nach unauthorisiert ausgestellten Zertifikaten Ausschau halten. Das kann man entweder selbst irgendwie implementieren. Oder man nutzt halt vorhandene Dienste wie hier beschrieben, bei welchen man automatisch alarmiert wird.

Ob das deswegen eine gute Idee ist sei mal dahingestellt. Davon abgesehen dass die Provider sich eine “Verwertung” rausnehmen (war zumindest mein letzter Informationsstand bei Gmail). Bei dem letzten Okta-Sicherheitsvorfall war z.B. auch ein Problem, dass Leute Credentials von anderen Services in ihrem Google Account gespeichert hatten und dieser mutmaßlich gepwnt wurde.

Für das dezentrale Verteilen von “Dritt-Credentials” braucht es einen guten Grund und der Benutzer muss sich darüber vor allem im Klaren sein. Hier bei Outlook ist das durch die unklare Kommunikation wohl nicht der Fall, sonst wären jetzt nicht alle überrascht.

Laut einem Nutzerkommentar auf Heise (also aus erster Quelle!) ist dieses Outlook nur eine gewrappte Webapp und lädt, wenn man offline ist, nicht mal die UI.

Schade, dass der Domaininhaber anscheinend erfolgreich verklagt worden ist.

Ich benutze seit Jahren borgbackup, nachdem ich zuerst mit rsync und dann rsnapshot angefangen hatte. Automatisches Backup erfolgt denke ich entweder über udev-Regeln (Backup beim Anschließen), oder in regelmäßigen Intervallen (benutze ich nicht) wie z.B. hier beschrieben.

Borg hat im Gegensatz zu rsync rsnapshot den Vorteil, dass auf der Sub-File-Ebene dedupliziert wird, d.h. nur weil eine Datei sich an einer Stelle geändert hat, wird der Rest der Datei nicht nocheinmal kopiert. Das einzige was ich zusätzlich empfehlen würde, wäre von vornherein mit compression --zstd,9 oder so zu arbeiten.

I used tmsu (“tag my shit up”) for a while, but it required too much discipline and then I dropped it.

In addition, tools like fzf for fuzzy file-search (comes with shell integration to e.g. replace the default history search in bash) and ripgrep-all made this kind of organization unnecessary for me. It now suffices to have a vague idea where a thing is located and I can do a brute-force search in a few seconds.

The next-level filesystem argument is brought forward every few months, but I’m not buying it.

and then suddenly there’s the perfect use case

Yeah but like WHAT?