trueten.de

Kurze aber wichtige Durchsage: Telegram wurde letztens gehackt, (Telegram Combolists) dabei sind 361,468,099 Passwörter usw. erbeutet worden. Bitte ändert das Passwort (Menü/Privatsphäre und Sicherheit/zweistufige Bestätigung und dort auf zusätzliches Passwort erstellen). Am besten per Keepass(XC),  KeePassDX (Android) oder Keepass2Android oder bei IOS KeePassium, Strongbox oder ähnlichem Passwortsafe ein sicheres Passwort erstellen und dort einsetzen. Speichern in Keepass nicht vergessen! Darüber hinaus ist es eine gute Idee, bei https://haveibeenpwned.com nach eigenen Daten (Mail, Telefonnummern etc.), die in Hacks auftauchen nachzuschauen und sich auch bei Neuentdeckungen benachrichtigen zu lassen.

Das Telegram seine Benutzer nicht aktiv per Systemnachricht über das Sicherheitsleck informiert hat, ist dann auch nochmal ein ganz anderes Thema...

---

Weil man in den zahlreichen Anleitungen, wie man ethercalc mit nginx hinter einen Reverse Proxy setzt nicht enthalten ist, wie auf man diesen SSL verschlüsselt zugreifen kann dachte ich mir, ich mach das und blogge das auch gleich mal. Erstens weil ich ein Gedächtnis wie ein Sieb habe, zweitens als Fingerübung und drittens, weil das vielleicht jemand brauchen kann. Als SSL Zertifikat verwende ich das freie von Let's encrypt.

Die "# managed by certbot" Zeilen werden durch den certbot automatisch hinzugefügt. Also diese nicht einfach kopieren ;-) Die Konfguration in dem Beispiel setzt weiterhin voraus, daß ethercalc bereits installiert ist und auf Port 8000 lauscht. Zudem ist eine (sub)Domain ethercalc.domainname.de angenommen. Diese ist durch die eigene Domain zu ersetzen.

Zum Herumspielen habe ich hier einen ethercalc Server aufgesetzt. Nach 144 Stunden = 6 Tagen werden inaktive Spreadsheets gelöscht - also vorher lokal sichern!
Für die Aufrechterhaltung, Pflege und Datensicherung gebe ich keinerlei Gewähr!

Bei mayfirst.org ist eine virtual host Konfiguration verfügbar.

upstream ethercalc {
  server 127.0.0.1:8000; # Auf Port 8000 lauscht in diesem Beispiel ethercalc
}

server {
    server_name ethercalc.domainname.de;

    location / {
        proxy_pass http://ethercalc/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forward-Proto http;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }

    listen 443 ssl; # managed by Certbot - über diesen Standard port für https ist der Reverse Proxy erreichbar
    ssl_certificate /etc/letsencrypt/live/ethercalc.domainname.de/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ethercalc.domainname.de/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = ethercalc.domainname.de) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name ethercalc.domainname.de;
    return 404; # managed by Certbot

}

Ich freue mich über eine Unterstützung via Paypal über Liberapay oder auch ein paar Satoshis an: bc1qgthwzrszw48lw9jl8zjg94fp6w6xfkw0929vg0

---

Einmal mehr zeigt das heute zugegangene Urteil des VGH, dass es bei Stuttgart21 um mehr geht als um einen fehlgeplanten Bahnhof. Indem sich das Gericht die komplizierte Sache leicht machte und den Klagenden schlichtweg die Klagebefugnis verweigerte, verstellt es den Weg einer rechtsstaatlichen Klärung der schwerwiegenden Vorwürfe wegen lebensgefährdenden Mängeln beim Brandschutz in den S21-Tunneln.

Überraschend hatte der Verwaltungsgerichtshof (VGH) in Mannheim unmittelbar nach der gestrigen Verhandlung in Abwesenheit der Verfahrensbeteiligten die Klagen der Schutzgemeinschaft Filder e.V. (SGF) und dreier Privatpersonen gegen die Planfeststellungsbeschlüsse zum mangelhaften Brandschutz- und Rettungskonzept der S21-Tunnel zurückgewiesen und keine Revision zugelassen - trotz Ankündigung, man werde die Entscheidung sorgfältig beraten und am Donnerstag bekanntgeben.

Damit hat das Gericht ausgiebig Gebrauch gemacht von den gesetzlichen Spielräumen, Klägerrechte zu beschneiden, z.B. über extrem kurz bemessene Fristsetzungen. Recht und Rechtsprechung höhlen so den Rechtsschutz und damit den Rechtsstaat immer mehr aus. So wurde die Klagebefugnis sowohl der SGF als auch dreier namens des Aktionsbündnisses klagender Privatpersonen verneint und damit jegliche Erörterung der baulichen Mängel verweigert. Die auf Forderung des Gerichts benannten und zahlreich erschienen Sachverständigen waren umsonst angereist. Offensichtlich hatte sich das Gericht von vornherein die Mühe erspart, sich überhaupt mit deren Argumente befassen. Dazu Bündnissprecher Dieter Reicherter: „Damit verletzen die beteiligten Behörden ihr Pflichten zur sorgfältigen Prüfung der Unterlagen und Abwägung der Grundrechte auf Leben und Gesundheit“.

So geriet schon die Verhandlung zur Farce. Den Privatpersonen wurde das Klagerecht abgesprochen, weil sie nicht mehr betroffen seien als jede andere Bürger*in. Auch dass der an den Rollstuhl gefesselte Kläger Karlheinz Scherwinski hilflos betroffen sei, wenn ein Zug in dem 60km (geplant 110km), großen Tunnelnetz in Brand geriete, beeindruckte das Gericht nicht. Ebenso kalt wurde ignoriert, dass Scherwinski auf diese Weise weitgehend von der Nutzung der Bahn ausgeschlossen würde. Passend dazu ist ausgerechnet das VGH-Gerichtsgebäude nicht behindertengerecht ausgestaltet: Nur mit großen Umwegen konnte der Kläger mit seinem Rollstuhl überhaupt ins Gebäude gelangen. In die Toilettenkabine konnte er mit dem Rollstuhl gar nicht einfahren.

Auf die von Rechtsanwalt Dr. Eisenhart von Loeper engagiert vorgetragene Frage, wo wenn nicht beim obersten Verwaltungsgericht des Landes die betroffenen Bürger gegen ein offensichtlich lebensgefährliches Brandschutz- und Rettungskonzept klagen könnten, gab es keine Antwort. Auch dass bei einem Brandfall im Tunnel die Menschen nicht rechtzeitig vor Ausbreitung der tödlichen Rauchgase evakuiert werden könnten, blieb ohne Reaktion. Immerhin kann es im Fildertunnel, in dem gleichzeitig 3 Züge hintereinander fahren können sollen, bei voller Besetzung um Gesundheit und Leben von bis zu 11 000 Menschen gehen.

Frank Distel, stellvertretender Vorsitzender der Schutzgemeinschaft Filder: „Empörend, wie der VGH mit völlig einseitiger Auslegung der Satzung unseres Umweltfachverbands unsere Klageberechtigung gegen ein beim Brandschutz nicht zu verantwortendes Fehlprojekt verneint.". Auch dass die Freiwilligen Feuerwehren des Filderraums infolge mangelhafter Planung bei der Brandbekämpfung im Fildertunnel Lebensgefahren ausgesetzt würden, beeindruckte das Gericht nicht.

Der VGH hat mit der Nichtzulassung der Revision gegen seine Urteile gleich noch weitere juristische Hürden aufgebaut. Da es hier um die rechtliche Effizienz des grundrechtlichen Schutzes von Leib und Leben geht, prüfen die beim VGH unterlegenen Kläger den Gang zum Bundesverfassungsgericht.

Quelle: Pressemitteilung Aktionsbündnis

---

Wird Stuttgart21 ähnlich wie Berlins Großflughafen BER über gravierende Sicherheitsmängel im Brandschutz stolpern? Konkret geht es bei der Klage am Dienstag, 21. November, um 14:00 Uhr beim VGH um die Frage: Hat die DB das Eisenbahn-Bundesamt (EBA) zur Erlangung der Baugenehmigung für die rund 60 km Tunnelröhren getäuscht? Mit diesem Vorwurf sehen sich die Kläger in guter Gesellschaft mit Ministerpräsident Kretschmann. Der hatte öffentlich geäußert, bei dem Projekt werde „getrickst und getäuscht“. Seine Vernehmung zu diesem Vorwurf wurde beantragt. Die Kläger, die als Umweltvereinigung anerkannte Schutzgemeinschaft Filder e.V. sowie drei Privatpersonen, werfen dem EBA vor, bei den Planfeststellungsverfahren habe es seine Prüfungspflichten sträflich vernachlässigt und Behauptungen der Bahn unbesehen übernommen. Ziel der Klage ist die wesentliche Änderung der Planfeststellung in puncto Brandschutz und, wenn dies bautechnisch nicht möglich ist, wie die Bahn bereits erklärt hat, die Aufhebung der Planfeststellung. Dies käme einem Baustopp bei Stuttgart21 gleich.

In der maßgeblichen EBA-Tunnelrichtlinie wird verlangt, dass das Rettungskonzept Selbst- und Fremdrettung gewährleisten muss. Dabei müssen Einzelheiten schon vor Erlass des Planfeststellungsbeschlusses festgelegt werden. Konkret geht es um den Fall, dass ein Zug in Brand gerät und in einer der 60 Tunnel-Kilometer (geplant sind weitere 45km) liegenbleibt. Die Röhren müssten zwingend so gebaut werden, dass sich die Zuginsassen vor Ausbreitung der tödlichen Rauchgase selbst retten könnten. Denn Feuerwehr und Rettungskräfte können nicht rechtzeitig zur Unglücksstelle gelangen.

Zwar hat die Bahn behauptet, in etwa 11 Minuten könnten sich die als Maximalzahl angenommenen 1757 Menschen aus einem Zug selbst retten. Allerdings hat sie im Verfahren inzwischen eingeräumt, dass in der Mobilität eingeschränkte Personen (Behinderte, Alte, Familien mit Kindern) hierbei nicht berücksichtigt wurden. Ferner hat sie zugegeben, dass sich diese Prüfung gar nicht auf einen Brandfall bezogen habe. Insbesondere aber hat sie nicht geprüft, wie viel Zeit zur Rettung bei einem Zugbrand überhaupt zur Verfügung steht. Die Kläger werden mithilfe von Sachverständigen, darunter die renommierte Brandschutzsachverständige Prof. Dr. Kathrin Grewolls, nachweisen, dass sich im Brandfall die tödlichen Rauchgase schneller ausbreiten als sich die Zuginsassen retten können, so dass die S21-Tunnel für sie zu einer unentrinnbaren Todesfalle würden.

Anders als bei vergleichbaren Eisenbahntunneln im In- und Ausland wurden bei den S 21- Tunnel aus Kostengründen die Tunnelquerschnitte und damit die Rettungswege zu klein bemessen. Dies bedeutet schnellere Rauchausbreitung und längere Evakuierungszeiten. Mit 500m sind die Abstände zwischen den Querschlägen zur Flucht in die Parallelröhre viel zu groß für eine rechtzeitige Eigenrettung. Bei der Zahl der zu Rettenden wird noch von 1757 Personen ausgegangen, obwohl die neu angeschafften Doppelstockzüge 3681 Menschen transportieren können. Der Sachverständige Dr. Christoph Engelhardt errechnet im Vergleich z.B. zum Katzenbergtunnel ein 16fach erhöhtes Risiko für das Scheitern einer rechtzeitigen Evakuierung.

Immer wieder gibt es Berichte über stundenlange Evakuierungen aus liegengebliebenen Zügen. Dass im Brandfall ein Bruchteil dieser Zeit ausreichen soll, ist nicht nachvollziehbar, insbesondere nicht für die Selbstrettung Mobilitätseingeschränkter. Hierzu haben die Kläger die Vernehmung des niedersächsischen Landtagsabgeordneten Grosch beantragt, der mit seinem Rollstuhl 2 Stunden lang nicht aus einem ICE evakuiert werden konnte. Dazu der Kläger Karlheinz Scherwinski: „Als Rollstuhlfahrer brauche ich die Bahn. Wegen des hohen Risikos im Brandfall sähe ich mich von der Bahnnutzung ausgeschlossen“.

Die Kläger sind sich der juristischen Schwierigkeiten bewusst, weil Gerichte in vergleichbaren Fällen bislang Privatpersonen trotz existentieller Betroffenheit die Klagebefugnis abgesprochen haben. In ihrem Kampf für den Schutz grundgesetzlich garantierter Rechte sehen sie sich aber bestärkt durch die Entscheidung des Bundesverfassungsgerichts, das einzelnen betroffenen Menschen Klagerechte gegen unzureichende Klimaschutzmaßnahmen zugesprochen hat. Dieter Reicherter, Sprecher des Aktionsbündnisses gegen Stuttgart 21 und einer der Kläger: „Dies muss insbesondere gelten, wenn die Behörden ihre Pflicht zum Schutz der Grundrechte vernachlässigen.“

Am selben Tag um 10:00 Uhr verhandelt der Verwaltungsgerichtshof zudem über eine weitere Klage der Schutzgemeinschaft Filder e.V. Diese wendet sich gegen eine Abänderung des Konzepts zur Verhinderung der Rauchausbreitung im Fildertunnel. Das Eisenbahn-Bundesamt hatte eine nachträgliche Änderung durch Einblasen von Luft und den Wegfall der vorgesehenen Rauchabschlusstüren genehmigt, obwohl damit die Evakuierung und auch die Sicherheit der Rettungskräfte beeinträchtigt wird.

Quelle: Pressemitteilung Aktionsbündnis

---

The default character limit for new toots in Mastodon is 500. But what if you want to increase or decrease it? With Mastodon version 4.2.*, the previous instructions for adjusting or increasing the number of characters in posts are obsolete. Basically, the compose.js file is now called differently and must be edited in a different path. I show how, with a big thank you to drakfrid, whose instructions I have adapted accordingly:

We will edit three different files, two which set the character limit on your instance, and one which tells other clients or apps what your custom character limit is (for those that support it).

1. Switch to the mastodon user

su - mastodon

2. Edit the file live/app/javascript/mastodon/features/compose/component/compose_form.js in your favourite text editor,

nano live/app/javascript/mastodon/features/compose/components/compose_form.js

find the number 500 (it should be written in two different locations). Change both of them to whatever you like.

3. Edit live/app/validators/statuslengthvalidator.rb,

nano live/app/validators/status_length_validator.rb

and once again find the number 500 (should exist only once) and change it to the same number as you wrote in the previous file.

4. Edit live/app/serializers/rest/instance_serializer.rb,

nano live/app/serializers/rest/instance_serializer.rb

and find the row starting with
:languages, :registrations,
(should be the ~8th row), and change it so it includes ”:maxtootchars” after ”:registrations”, such as
:languages, :registrations, :maxtootchars,
where the full row now looks something like
:languages, :registrations, :maxtootchars, :approvalrequired, :invitesenabled

At the end of the same file, above where it says private, add the following code:

def max_toot_chars
   <your value here>
end

and change <your value here> to the same value you wrote previously.

5. Enter the live directory and recompile Mastodon,

RAILS_ENV=production bundle exec rails assets:precompile

6. Switch to the root user (with exit), and restart the Mastodon services,

systemctl restart mastodon-sidekiq
systemctl reload mastodon-web

and optionally restart the streaming API server,

systemctl restart mastodon-streaming

And you’re done! You should now be able to see the new character limit on your Mastodon instance.

---

Bis vor ein paar Tagen ging ich davon aus, daß bei Browsern auf mobilen Endgeräten, sei es unter Android oder IOS, keine Addons oder zumindest nur wenige installiert werden können. Eine Bekannte hatte mich wegen der beliebten "Nervenschoner" Erweiterung gefragt. Wegen der Hinweise auf den Seiten der Verbraucherzentrale Bayern wähnte ich mich jedenfalls im Recht. Dort heißt es klar:

Mobile Geräte

Das Nervenschoner-Plugin gibt es leider nicht für mobile Geräte.

Google und Apple haben die Standard-Browser ihrer Betriebssysteme Android und iOS für Plugins gesperrt.

Allerdings, meinte die Bekannte, ein befreundeter IT Mensch würde das Gegenteil behaupten. Kannnichsein. Also habe ich mich auf die Suche gemacht und was soll ich sagen: Es ist möglich, allerdings wohl nur mittels der Firefox-Nightly unter Android. Für IOS habe ich leider noch keinen freien Slot für eine Testflight Version von Firefox bekommen, daher kann ich hierzu nichts abschließendes sagen. Lange Rede, kurze Lösung: @DreQueary zeigt in diesem Video, welchen Weg er eingeschlagen hat. Er verwendet dazu "Firefox-Nightly" aus dem Google App Store.

---

Ich habe mitgeschrieben: Sobald Du Firefox Nightly heruntergeladen hast, tippst du auf die Drei Punkte im Programmfenster unten rechts. Gehe dann auf Einstellungen und dann scrollst Du ganz nach untern auf den Bildschirm, bis "Über Firefox Nightly". Antippen. Dann erscheint ein Versionshinweis mit dem blauen Firefox Logo. Tippe das 4 oder 5x an, bis eine Meldung erscheint, nachdem Du im Entwicklermodus bist. Danach startet Firefox Nightly neu, falls nicht kehrst Du zum vorigen Fenster zurüück.

Als nächstes benötigst Du einen Account bei Mozilla, um eine Add-on-Sammlung anlegen zu können, auf die Firefox dann zugreifen kann. Wenn Du Dich registriert hast, klickst du hier.

Gib der Sammlung einen beliebigen kurzen Namen, ein paar Zeichen, z.B. Test reichen. eine Beschreibung ist nicht nötig, einfach das Anlegen der Sammlung bestätigen, in der dann erscheinenden Eingabemaske dann den Namen des gewünschten Add-ons eingeben, in diesem Fall "Nervenschoner" und dann in der erscheinenden Liste das Add-on anklicken. Es erscheint dann folgender Bildschirm:


Die Sammlung ist mit diesem Plugin angelegt. Merke Dir Deine Sammlungsnummer, die Du gleich brauchst - im Beispiel gelb markiert (18047646). Nun wieder zum Browser. Sobald Firefox Nightly neu gestartet ist, gehst Du wieder über die 3 Punkte auf Einstellungen. Scrolle dann den Bildschirm runter, bis "Benutzerdefinierte Add-on-Sammlung" erscheint. Tippe das an. In das erscheinende Menü gibst Du ein:

(1. Zeile:) 18047646
(2. Zeile:) Test

Dann auf Ok. drücken. Firefox startet neu.

Dann kannst Du im Einstellungsmenü von Firefox-Nightly das ausgewählte Add-on aktivieren. Tippe dazu Auf Add-ons. Wenn Du auf den Add-on Namen tippst, kommst Du in die Einstellungen des jeweiligen Add-ons und kannst da herum erxperimentieren.

Kaputtmachen kannst du nichts.  Du kannst den Firefox Nightly auch als Standardbrowser einstellen, das geht auch über die Einstellungen im Programm.

---

Bei der Verwendung des Softwareinstallationsscriptes add-apt-repository - das im Paket software-properties-common enthalten ist - auf Debian 12 kommt es zu folgender Fehlermeldung:

sudo add-apt-repository ppa:bashtop-monitor/bashtop
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in
    sys.exit(0 if addaptrepo.main() else 1)
                  ^^^^^^^^^^^^^^^^^
  File "/usr/bin/add-apt-repository", line 345, in main
    shortcut = handler(source, *shortcut_params)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line 40, in shortcut_handler
    return handler(shortcut, *kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 86, in init
    if self.lpppa.publishdebugsymbols:
       ^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 126, in lpppa
    self.lpppa = self.lpteam.getPPAByName(name=self.ppaname)
                  ^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 113, in lpteam
    self.lpteam = self.lp.people(self.teamname)
                   ^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'people'

Was ärgerlich ist, kann doch mit diesem Script eine Softwarequelle einfach zu den Systemquellen des Rechners hinzugefügt werden ohne sich groß mit den nötigen gpg Keys usw. befassen zu müssen - diese werden nämlich gleich mit heruntergeladen und installiert. Ein guter Komfortgewinn für faule User. ;-)

Die Fehlermeldung kommt von der fehlenden Python Bibliothek python3-launchpadlib. Nach Installation derselben funktioniert add-apt-repository einwandfrei.

Nach einem Hinweis von dieser Quelle bearbeitet.

---

Bei der Installation eines NextCloud Servers nach der Anleitung von Rafael Nockmann auf einer Synology Diskstation fiel mir auf, daß die zum Betrieb notwendigen cronjobs nicht funktionieren. Synology biegt offenbar so einiges im DSM System um. Da dieses jedoch auf Linux basiert, gibt es Hoffnung. ;-)

Zum Glück braucht es für wiederkehrende Aufgaben wie in diesem Fall nicht zwingend den cron Daemon, auch über systemd gibt es die Möglichkeit, solche zu erledigen. Langer Vorrede kurzer Sinn:

1. per ssh auf die Diskstation einloggen und dann als root per sudo -iH weitermachen. Alternativ als normaler User arbeiten und vor die Befehle dann sudo stellen.

2. mit nano /etc/systemd/system/nextcloudcron.service eine Datei mit folgendem Inhalt anlegen:

[Unit]

Description=Nextcloud cron.php job

[Service]

User=root

ExecStart=/bin/sudo -u http /usr/local/bin/php82 --define apc.enable_cli=1 /volume1/web/nextcloud_app/cron.php

KillMode=process

3. mit nano /etc/systemd/system/nextcloudcron.timer eine Datei mit folgendem Inhalt anlegen:

[Unit]

Description=Run Nextcloud cron.php every 5 minutes

[Timer]

OnBootSec=5min

OnUnitActiveSec=5min

Unit=nextcloudcron.service

[Install]

WantedBy=timers.target

4. mit systemctl enable nextcloudcron.timer die Änderungen aktivieren.

5. Diskstation neu starten und in NextCloud / Grundeinstellungen kontrollieren, ob der gewünschte Erfolg eingetreten ist.

6. Freuen :-)

Anmerkung: in nextcloudcron.service läuft der Dienst als Benutzer root, der per sudo den User http den Befehl /usr/local/bin/php82 --define apc.enable_cli=1 /volume1/web/nextcloud_app/cron.php ausführen lässt. Leider ist es - zumindest bei mir - nicht möglich, den Dienst als User http laufen zu lassen, ohne noch tiefer ins System einzugreifen.

Die Quelle: NextCloud

---

Hinweis: Einige der Links in diesem Beitrag beziehen sich auf Affilate-Links. Wenn Sie eines der verlinkten Produkte kaufen, unterstützen Sie mich. Das Produkt selbst wird Sie nicht mehr kosten als üblich. Vielen Dank dafür.

Note: Some of the links in this post refer to affilate links. If you buy one of the linked products, you support me. The product itself will not cost you more than usual. Thank you.

---

Der Facebook / META Konzern möchte mit dem #Projekt92 / #Barcelona / #threads.* an das Fediverse andocken. Erste Domains sind offenbar threads.net. (Wir verzichten auf die aktive Verlinkung) Nachdem zahlreiche Admins inzwischen erklärt haben, alle diesbezüglichen Aktivitäten und Domains zu blockieren, gibt es eine Sammlung von suspekten Facebook / META / threads Domains zum Download und anschließenden Import bei Mastodon. Wäre per regex sicher kürzer geworden, aber was soll's. Die Liste wird gepflegt und erweitert.

Die Vernetzung mit Meta soll nicht mehr automatisch erfolgen, sondern man kann sich jetzt dafür entscheiden, seinen Server mit "finanziellen Anreizen" mit Meta zu verbinden, wenn er "groß genug" ist.

Trotzdem lohnt es sich, diese Domains und IPs zu blockieren, nur für den Fall, dass sie es sich anders überlegen und um zu verhindern, dass META den Server ohne Zustimmung oder die der Nutzer:Innen ausspionieren.

Mehr dazu in diesem thread.

Wir sind seit dem 19. Juni 2023 im FediPact dabei und seit heute werden die og. Domains blockiert.

We block´d the #Barcelona Project aka threads.net and threads.instagram.com. We don‘t allow any #Facebook or #Instagram shit pollution at our #Instance.

If you are looking for a new home (instance/server) due to the whole Bruhaha over the #Meta move on the Fediverse, here is a link to the instances where you will be safe:

https://fedipact.online/

#FediBlockMeta #Meta #Project92 #Threads #Barcelona #Mastodon #FuckMeta

---

Wegen ein paar Jahrzehnte alter Leichen im Keller - genauer: inkonsistente Zeichensätze in der Blogdatenbank - kam es mit der gestrigen Umstellung der MariaDB Version auf 10.10 zu einigen seltsamen Zeichen, vor allem bei den (internationalen) Sonderzeichen.

Wir bitten das Ungemach zu entschuldigen. Inzwischen sollten die meisten Beiträge wieder korrekt dargestellt werden. Über Meldungen zur Sichtung übersehener Beiträge freuen wir uns.

Im Zuge der Durchsicht der Beiträge wurden auch gleich nochmal die Hashtags / Schlagwörter überarbeitet, korrigiert und in Teilen zusammengefasst. Ebenso wurden ein paar Links aus unserer Empfehlungsliste entfernt.

---