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.

Sauerei sowas. Wird Zeit für eine Sonderabgabe für junge Leute!

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.

Mir hat ein Dozent sich aus dem Grund mal verweigert, das Kurspasswort für die Vorlesungsmaterialien mitzuteilen. Ich war an dem Termin als das mitgeteilt wurde nicht in der Vorlesung weil ich eben arbeiten musste, was von dem Dozenten mit dem Kommentar "ja das ist dann eben sehr schlecht" versehen wurde.

Es kommt aber auch sicher auf Studiengang und Hochschulort an wie (un-)gern das gesehen ist.

In Bayern setzt man lieber auf mobile Windräder, a.k.a. Flugtaxis.

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.