Hinweis zur Einstellung des Typepad-Dienstes und zum Domain-Transfer
(ttimo.typepad.com)- Durch die Einstellung von Typepad müssen bestehende Blog-Betreiber selbst klären, ob und wie sie Domains und Inhalte übertragen, während Login und Dateizugriff gesperrt sind
- Das Dienstende ist der 30. September 2025; danach wird keine Kontoanmeldung mehr angeboten
- Kunden, die Jahresgebühren über das Einstellungsdatum hinaus bezahlt haben, erhielten eine anteilige Rückerstattung; wenn keine Rückerstattung sichtbar ist, sollte die Bank kontaktiert werden
- Alle Blog-Daten werden gelöscht; außer Anfragen zum Datenschutz werden weder Zugriffsverlängerungen noch Wiederherstellungswege angeboten
- Über Typepad Domains registrierte Domains werden am 27. Oktober 2025 zu Reseller Club übertragen; für die Anbindung an eine neue Plattform muss der bisherige Typepad-CNAME entfernt werden
Konten und Datenverarbeitung nach der Diensteinstellung
- Das Dienstende von Typepad ist der 30. September 2025
- Nach dem Einstellungsdatum können sich Nutzer nicht mehr in ihre Konten einloggen
- Kunden, die jährliche Servicegebühren für einen Zeitraum nach dem Einstellungsdatum bezahlt haben, erhalten eine anteilige Rückerstattung
- Wenn die Rückerstattung auf dem Kontoauszug nicht sichtbar ist, sollte die Bank kontaktiert werden
- Wenn keine gültige Kreditkarte hinterlegt ist, wurde die Rückerstattung möglicherweise nicht verarbeitet
- Nach der Einstellung wird der Dateizugriff beendet; eine separate Verlängerung wird nicht angeboten
- Alle Blog-Daten werden gelöscht; Anfragen zum Datenschutz sind an privacy@newfold.com zu richten
Transfer von Typepad Domains und Anbindung eines neuen Blogs
- Typepad Domains ist ein Reseller von LogicBoxes; alle bei Typepad Domains registrierten Domains werden am 27. Oktober 2025 zu einem anderen LogicBoxes-Partner, Reseller Club, übertragen
- Betroffene Nutzer erhalten dazu eine zusätzliche E-Mail mit weiteren Hinweisen von Reseller Club
- Es ist nicht nötig, die Domain von LogicBoxes zu einem anderen Anbieter zu transferieren; die Verwaltung kann danach weiterhin über Reseller Club erfolgen
- Um die Domain mit einem neuen Blog-Dienst oder einer neuen Plattform zu verbinden, muss der bisher auf Typepad zeigende CNAME-Eintrag entfernt und gemäß den Anforderungen des neuen Dienstes eingerichtet werden
- Vor dem 27. Oktober 2025 erfolgt die Konfiguration nach dem Login bei Typepad Domains
- Nach dem 27. Oktober 2025 erfolgt die Konfiguration nach dem Login bei Reseller Club
- Wer nicht Typepad Domains, sondern einen anderen Registrar nutzt, muss auch dort den auf Typepad verweisenden CNAME-Eintrag entfernen und auf den neuen Blog-Dienst oder die neue Plattform umstellen
- Leser, die einen bestimmten Blog suchen, müssen den Blogger direkt kontaktieren, um zu erfahren, wo der Blog erneut veröffentlicht wurde
- Für weitere Anfragen stehen Telefon oder Chat von Network Solutions zur Verfügung
1 Kommentare
Meinungen auf Hacker News
Es gibt einen Patch, der gerade geprüft wird: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
Auslöser war https://issues.redhat.com/browse/RHEL-42410; es handelte sich um ein Problem mit der Stabilität des Grafik-Stacks, das in RHEL 9 aus irgendeinem Grund weniger auffiel
Ich hoffe, dass zumindest der erste Patch, also der Fix für die Thread-Sicherheit von getenv, in glibc 2.41 landet, und Backports dürften ebenfalls recht sicher sein
setenv ist vergleichsweise einfach zu behandeln, weil glibc Strings für Umgebungsvariablen ohnehin nie freigibt; knifflig ist gleichzeitiges unsetenv
Ohne Snapshot-Ansatz kann getenv statt des tatsächlich gesetzten Werts einer Umgebungsvariable einen Null-Pointer zurückgeben
Ich möchte keine Sperre in getenv einbauen, denn getenv ohne setenv gilt seit sehr langer Zeit als async-signal-safe, und eine Sperre würde wahrscheinlich Anwendungen kaputtmachen
Die Korrektur der environ-Behandlung ist wegen vfork+execve etwas umstrittener, weil es kompliziert ist, Speicherlecks zu vermeiden; für die Stabilität des Grafik-Stacks sind diese zusätzlichen Fixes aber weniger wichtig
Wenn sie zu lang wird, könnte der Thread, der setenv ausführt, eine neue Hashmap erstellen und den alten Pointer atomar durch den neuen ersetzen
Ein atomarer Flag, der anzeigt, ob gerade rehashed wird, würde verhindern, dass zwei Threads gleichzeitig rehashen
Wenn in der Zwischenzeit ein anderer Thread setenv aufruft, werden zusätzliche Variablen an die Liste angehängt und bei einem späteren setenv-Aufruf verarbeitet
Wenn ausreichend viele Threads schnell setenv aufrufen, könnte die Liste unbegrenzt wachsen; aber setenv wird nicht oft aufgerufen, daher scheint die Einfachheit eines atomaren Pointer-Austauschs den Preis wert zu sein
Eine jahrzehntealte Tretmine – frustrierend
Ich bin wirklich dankbar, dass Steam heutzutage unter Linux so gut läuft
Ich halte die Arbeit im Hintergrund, die diese Realität für uns möglich gemacht hat, nicht für selbstverständlich
Ich möchte darauf einen Gaming-Tower aufbauen
Ich könnte mich mit Bazzite zufriedengeben, aber ehrlich gesagt möchte ich SteamOS
Ich denke, Best Practice ist, beim Start alle Umgebungsvariablen zu lesen und setenv nie zu verwenden
Der einzige Ort, an dem setenv sinnvoll ist, ist beim Starten eines neuen Prozesses; selbst dann scheint es richtiger, ein neues environ als Kopie des aktuellen environ zu erstellen und die neuen Werte dort zu aktualisieren
getenv/setenv als Messaging-Mechanismus für Interprozesskommunikation zu verwenden, bringt neben dem unter Linux historisch nicht thread-sicheren Verhalten auch mehrere andere Probleme mit sich, etwa die Möglichkeit versteckter Speicherlecks
Der Artikel scheint das zu ignorieren, wenn er sagt, dass es unter macOS thread-sicher sei
Java macht es so, wie beschrieben, aber bei JNI-Code, der eine Library nutzt, die getenv() will, gibt es weiterhin Probleme
Die eigentliche Frage ist: Gibt es wirklich Fälle, in denen man in einem Thread
setenvaufruft und tatsächlich möchte, dass diese Änderung auch für andere bereits existierende Threads gilt?Trotzdem dokumentiert GLIBC gefährliche Funktionen ziemlich gut, sodass man selbst Sperren oder Kopieren hinzufügen kann
Es gibt sicher Programme, die erwarten, dass setenv das environ-Array verändert, und es wahrscheinlich nicht nur als opaken Pointer behandeln, der an posix_spawn/execve übergeben wird
Für ein Thread-lokales setenv bräuchte man auch eine Thread-lokale environ-Variable
Das passt aber nicht gut zu POSIX, denn environ ist nicht in einem Header deklariert; Programmierer sollen in ihrem Source selbst
extern char **environ;deklarierenDiese Deklaration ist nicht kompatibel damit, dass environ eine Thread-lokale Variable ist
Der Artikel behandelt das auch als ein fortlaufendes Problem des Steam-Clients
In meinem Fall schlafen die Worker-Threads alle in der Run Queue, daher ist es kein Problem; technisch gesehen ist es aber ein Fall, in dem ein Thread eine Umgebungsvariable setzt und ein anderer, bereits laufender Thread sie lesen soll
Ich weiß nicht, welche Threading-Library keine Shared Memory oder Message Passing hätte
Vermutlich passiert das vor allem in Situationen, in denen der Hauptprozess eine Variable wie HTTPS_PROXY ändert und andere Threads eine Library ausführen, die diese Variable prüft, bevor sie einen TCP-Socket öffnet
Zur Einordnung: Die Entscheidung, auf dem Mac Speicher zu leaken, geht tatsächlich etwa 26 Jahre bis zu FreeBSD zurück: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
OSX hat das geerbt, und es wäre nicht überraschend, wenn auch Windows’
setenvaus Lizenzgründen aus der BSD-Linie stammt.Schon vor 26 Jahren wusste man, dass diese API kaputt ist, hat sie aber wegen der Trägheit, fehlerhafte Programme nicht noch stärker kaputtzumachen, nicht repariert.
Es sollte kaum je nötig sein, die Umgebungsvariablen des eigenen Prozesses zu ändern.
Für Kindprozesse kann man die passenden
exec-Funktionen verwenden; ansonsten sollte man eine klare API aufrufen, statt eine globale Variable zu ändern und zu hoffen, dass weit entfernte Codepfade sie erneut lesen und korrekt behandeln.Mit der aktuellen API stimmt das, aber mit einer sehr kleinen Änderung an der API wäre es möglich.
getenv()müsste den Wert vor der Rückgabe perstrdup()kopieren, und der Programmierer müsste den Speicher nach der Nutzung freigeben.Wenn man davon ausgeht, dass sich der Wert ändern kann, müsste der Programmierer
getenv()erneut aufrufen, aber das wirkt wie ein vernünftiger Kompromiss.Diese Änderung würde zwar bei jedem alten Programm Speicher leaken, das nach einem
getenv()-Aufruf keinfree()macht, aber die aktuelle Version leakt ebenfalls Speicher, daher scheint das kein entscheidendes Problem zu sein.Als Bonus könnte die neue Version
strdup()mit einem Mutex schützen undsetenv()ähnlich behandeln, sodass sie thread-sicher wird.Ein Kollege soll
setenvals „schlechteste Linux-API“ bezeichnet haben, aber istsetenvwirklich eine Linux-API?Sie wurde nicht von Linux definiert, steht in POSIX und wird auch nicht vom Linux-Kernel implementiert, sondern liegt vollständig im Userspace.
Der Autor des Originals und sein Kollege scheinen bei Valve an der Unterstützung von Steam zu arbeiten, also ist das der Kontext.
Der Grund, warum der Kollege sie als die schlechteste bezeichnet hat, ist nicht die POSIX-Spezifikation.
POSIX sagt nur, dass diese Funktion nicht thread-sicher sein muss; es verbietet nicht, sie thread-sicher zu machen.
Das Problem ist die konkrete Implementierung in glibc, der C-Bibliothek, die auf allen Linux-Distributionen verwendet wird, die Valve für Steam unterstützt, und diese Distributionen werden eben alle unter „Linux“ zusammengefasst.
Wenn libc wollte, könnte sie es thread-sicher machen.
Sprachen wie Go implementieren diese Funktion intern und haben diese Einschränkung daher nicht.
Auch die POSIX-Dokumentation selbst berücksichtigt diese Grenze: „The setenv() function need not be thread-safe.“
Für jemanden, der mit nethack und Schach unter Linux aufgewachsen ist, ist allein schon die Existenz von Steam erstaunlich.
Aber der Steam-Client ist wirklich seltsam.
Monatelang funktioniert alles, und plötzlich startet ein Spiel nicht mehr oder irgendetwas funktioniert nicht; dann muss man merkwürdige Dinge tun wie alle Dateien löschen oder neu installieren, damit es wieder läuft.
Das ergibt keinen Sinn und fühlt sich an, als würde der Steam-Client verrotten.
Es ist ein Sammelsurium miteinander vermischter Designprinzipien, und neue Funktionen werden einfach mit komplett anderer UI und UX angeflanscht.
Der Großteil des Clients besteht aus Webviews, ist langsam und voller Bugs und verwendet intern eine sehr alte und unsichere Chromium-Version.
Der Launcher ist immer noch ein 32-Bit-Programm.
Traurig ist nur, dass die anderen Launcher noch schlechter sind.
Seit ich nur noch Linux nutze, erlebe ich solche Dinge eher seltener.
Das ist wirklich spannender Einblick sowohl in den Steam-Client als auch in Linux-Programmierung.
Ich verstehe, dass es schwer ist, zu jedem Release ausführliche Release Notes zu schreiben, aber wenn man von solcher Arbeit erfährt, ist die Formulierung „verschiedene häufige Abstürze behoben“ eine gewaltige Untertreibung.
Den Abschnitt „Wenn sich dieses Problem in glibc lösen lässt, könnte das funktionale Kompromisse erfordern oder ein Opt-in-Mechanismus sein, der leicht von der ‚unmöglichen‘ POSIX-Spezifikation abweicht. Wenn jemand einen vernünftigen Vorschlag machen kann, könnte man das langfristig verfolgen“ würde ich mir wirklich umgesetzt wünschen.
Ich frage mich wirklich, warum setenv(3) so häufig verwendet wird.
Der wichtigste Anwendungsfall, der mir einfällt, ist das Setzen von Umgebungsvariablen vor einem Aufruf von etwas wie
exec(3), aber darum scheint es hier nicht zu gehen.Im Artikel steht, dass beim Starten von Kindprozessen
exevpeverwendet wird; ich frage mich also, wofürsetenv(3)dann noch gebraucht wird.nm -Dkann man prüfen, obsetenv/unsetenv/putenvverwendet werden, und schon ein grober Blick in mein~/.cargo/bin/*zeigt, dass sehr viele Programme so etwas nutzen.Sie könnten zwar single-threaded sein, aber wer kann garantieren, dass das auch in Zukunft so bleibt?
Wenn ich darüber nachdenke, ließe sich über die Symbolliste auch
pthread_createerkennen.Interessant wäre auch eine Methode zur statischen Binäranalyse, die von solchen Symbolen bis zum Call Tree weiterverfolgt.
Allerdings sehe ich keine Möglichkeit zu prüfen, ob
**environverwendet wird. Der Compiler kann das in alles Mögliche umwandeln.