Typepad hizmetinin kapanması ve alan adı taşıma rehberi
(ttimo.typepad.com)- Typepad’in kapanması nedeniyle mevcut blog sahipleri, giriş ve dosya erişimi engellenmiş durumdayken alan adı ve içerik taşıma konularını kendileri netleştirmek zorunda
- Hizmetin kapanış tarihi 30 Eylül 2025; bu tarihten sonra hesap girişi artık sunulmayacak
- Kapanış tarihinden sonraki dönemi de kapsayacak şekilde yıllık ücret ödeyen müşterilere orantılı geri ödeme yapıldı; geri ödeme kaydı görünmüyorsa bankayla kontrol etmek gerekiyor
- Tüm blog verileri silinecek; kişisel verilerle ilgili talepler dışında erişim uzatma veya kurtarma yolu sunulmayacak
- Typepad Domains üzerinden kayıtlı alan adları 27 Ekim 2025’te Reseller Club’a taşınacak; yeni bir platforma bağlamak için mevcut Typepad CNAME kaydının kaldırılması gerekiyor
Hizmet kapandıktan sonra hesap ve veri işlemleri
- Typepad’in hizmet kapanış tarihi 30 Eylül 2025
- Kapanış tarihinden sonra kullanıcılar artık hesaplarına giriş yapamayacak
- Kapanış tarihinden sonraki dönemi de kapsayacak şekilde yıllık hizmet ücreti ödeyen müşterilere orantılı geri ödeme yapıldı
- Ekstrede geri ödeme görünmüyorsa bankayla iletişime geçmek gerekiyor
- Kayıtlı geçerli bir kredi kartı yoksa geri ödeme işlenmemiş olabilir
- Kapanıştan sonra dosya erişimi durdurulacak ve ayrıca uzatma sunulmayacak
- Tüm blog verileri silinecek; kişisel verilerle ilgili talepler privacy@newfold.com adresine iletilmeli
Typepad Domains taşıma süreci ve yeni blog bağlantısı
- Typepad Domains, LogicBoxes’ın bir bayisidir; Typepad Domains’te kayıtlı tüm alan adları 27 Ekim 2025’te başka bir LogicBoxes iş ortağı olan Reseller Club’a taşınacak
- İlgili kullanıcılar Reseller Club’dan ek bilgilendirme e-postası alacak
- Alan adını LogicBoxes’tan başka bir yere taşımak gerekli değil; bundan sonra Reseller Club üzerinden yönetmeye devam edilebilir
- Alan adını yeni bir blog hizmetine veya platforma bağlamak için Typepad’i gösteren mevcut CNAME kaydını kaldırıp yeni hizmetin gereksinimlerine göre ayarlamak gerekiyor
- 27 Ekim 2025’ten önce Typepad Domains’e giriş yaparak ayarlanır
- 27 Ekim 2025’ten sonra Reseller Club’a giriş yaparak ayarlanır
- Typepad Domains dışında başka bir kayıt kuruluşu kullanılıyorsa, ilgili kayıt kuruluşunda Typepad’i gösteren CNAME kaydı kaldırılmalı ve yeni blog hizmetini veya platformunu gösterecek şekilde ayarlanmalı
- Belirli bir blogu arayan okuyucular, blogun nerede yeniden yayımlandığını öğrenmek için ilgili blog yazarıyla doğrudan iletişime geçmeli
- Ek sorular Network Solutions üzerinden telefon veya sohbet yoluyla iletilebilir
1 yorum
Hacker News yorumları
İncelenmekte olan bir yama var: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
https://issues.redhat.com/browse/RHEL-42410 nedeniyle başladı ve RHEL 9'da nedense daha az göze çarpan bir grafik yığını kararlılığı sorunuydu
En azından ilk yamanın, yani getenv iş parçacığı güvenliği düzeltmesinin glibc 2.41'e girmesini umuyorum; geri portlamanın da oldukça güvenli olacağını düşünüyorum
setenv tarafı görece daha kolay, çünkü glibc zaten ortam değişkeni dizgelerini asla serbest bırakmıyor; zor olan eşzamanlı unsetenv
Anlık görüntü yaklaşımı olmadan getenv, gerçekten ayarlanmış ortam değişkeni değerini döndürmek yerine null işaretçi döndürebilir
getenv'e kilit koymak istemiyorum; çünkü setenv kullanılmadan çağrılan getenv çok uzun zamandır async-signal-safe kabul ediliyor ve kilit eklemek uygulamaları bozabilir
environ işleyişini düzeltmek, vfork+execve nedeniyle bellek sızıntısından kaçınmayı karmaşıklaştırdığı için biraz daha tartışmalı; ancak bu ek düzeltmeler grafik yığını kararlılığı için daha az kritik
Uzunluk çok artarsa setenv çalıştıran iş parçacığı yeni bir hashmap oluşturabilir ve eski işaretçiyi yenisiyle atomik olarak değiştirebilir
İki iş parçacığının aynı anda yeniden hash etmesini önlemek için şu anda yeniden hash yapılıp yapılmadığını gösteren atomik bir bayrak kullanılabilir
Bu sırada başka bir iş parçacığı setenv çağırırsa ek değişkenler listeye eklenir ve daha sonra bir setenv çağrısı olduğunda işlenir
Yeterince çok iş parçacığı hızla setenv çağırırsa liste sonsuza kadar büyüyebilir; ama setenv sık çağrılan bir şey olmadığı için işaretçinin atomik olarak değiştirilmesinin sadeliğine değer gibi geliyor
On yıllardır duran ayağın altındaki mayın olması can sıkıcı
Bugünlerde Linux'ta Steam'in bu kadar iyi çalışmasına gerçekten minnettarım
Bizim için bu gerçeği mümkün kılmak adına arka planda harcanan emeği hafife almıyorum
Onun üzerine bir oyun kasası kurmak istiyorum
Bazzite ile idare edebilirim ama açıkçası SteamOS kullanmak istiyorum
Açılışta tüm ortam değişkenlerini okuyup setenv'i asla kullanmamak en iyi uygulama değil mi diye düşünüyorum
setenv'in anlamlı olduğu tek yer yeni bir süreç başlatırken; o durumda bile mevcut environ'un kopyasından yeni bir environ oluşturup yeni değerleri güncellemek daha doğru görünüyor
getenv/setenv'i süreçler arası iletişim mesajlaşma mekanizması gibi kullanmak, Linux'ta tarihsel olarak iş parçacığı güvenli olmamasının yanı sıra gizli bellek sızıntısı olasılıkları gibi birçok soruna davetiye çıkarıyor
Yazıda macOS'te iş parçacığı güvenli denirken bu nokta göz ardı ediliyor gibi
Java dediğin şekilde yapıyor; ancak getenv() isteyen bir kütüphaneyi kullanan JNI kodunda sorun hâlâ ortaya çıkıyor
Asıl soru şu: Bir iş parçacığında
setenvçağırıp bu değişikliğin zaten var olan diğer iş parçacıklarına da uygulanmasını gerçekten istediğiniz bir durum var mı?Yine de GLIBC tehlikeli fonksiyonları oldukça iyi belgeliyor; bu yüzden doğrudan kilitleme veya kopyalama eklemek mümkün
setenv'in environ dizisini değiştirmesini bekleyen programlar mutlaka vardır ve bunu yalnızca posix_spawn/execve'ye geçirilen opak bir işaretçi olarak ele almıyor olabilirler
İş parçacığına özel setenv için iş parçacığına özel environ değişkeni de gerekir
Ama POSIX ile pek uyuşmuyor; çünkü environ başlıklarda bildirilmiş değil ve programcının kaynakta
extern char **environ;bildirimini kendisinin yazması bekleniyorBu bildirim, environ'un iş parçacığı yerel değişkeni olmasıyla uyumlu değil
Yazı da Steam istemcisindeki süregelen sorunlar bağlamında bu konuyu ele alıyor
Benim durumumda çalışan iş parçacıklarının hepsi çalışma kuyruğunda uykuda olduğu için sorun olmuyor; ama teknik olarak bir iş parçacığında ortam değişkeni ayarlayıp zaten çalışmakta olan başka bir iş parçacığından okumak istediğim bir durum
Hangi iş parçacığı kütüphanesinde paylaşımlı bellek ya da mesaj iletimi yok, bilmiyorum
Muhtemelen çoğunlukla ana sürecin HTTPS_PROXY gibi bir değişkeni değiştirdiği ve diğer iş parçacığında TCP soketi açmadan önce o değişkeni kontrol eden bir kütüphanenin çalıştırıldığı türden durumlarda ortaya çıkıyor
Bu arada, Mac’te belleği sızdırma kararı aslında yaklaşık 26 yıl önce FreeBSD’ye kadar uzanıyor: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
OSX bunu devraldı; Windows’un setenv’inin de lisans nedeniyle BSD soyundan geliyor olması şaşırtıcı olmaz
26 yıl önce bile bu API’nin bozuk olduğu biliniyordu, ama hatalı programları daha da bozacak atalet yüzünden düzeltilmedi
Kendi sürecinizin ortam değişkenlerini değiştirmeniz neredeyse hiç gerekmemeli
Alt süreçler için uygun exec fonksiyonlarını kullanabilirsiniz; bunun dışında ise global bir değişkeni değiştirip uzaktaki kodun onu yeniden okuyup doğru işleyeceğini ummak yerine açık bir API çağırmalısınız
Mevcut API ile evet, ama API’yi çok az değiştirince mümkün hale geliyor
getenv() döndürmeden önce değeri
strdup()edebilir ve programcının kullanım sonrası belleği serbest bırakmasını sağlayabilirsinizDeğerin değişebileceğini düşünüyorsa programcının getenv()’i yeniden çağırması gerekir; bu da makul bir ödün gibi görünüyor
Bu değişiklik, eski programlar getenv() çağrısından sonra
free()yapmadığı her seferde bellek sızdırırdı; ama mevcut sürüm de bellek sızdırdığı için belirleyici bir sorun gibi görünmüyorBonus olarak yeni sürüm,
strdup()’ı bir mutex ile sarıp setenv() tarafında da benzer şekilde davranarak thread-safe hale getirilebilirBir meslektaşının setenv’i “en kötü Linux API’si” diye adlandırdığı söyleniyor; peki setenv gerçekten bir Linux API’si mi?
Linux tarafından tanımlanmış değil, POSIX’te yer alıyor; Linux çekirdeği tarafından da uygulanmış değil, tamamen kullanıcı alanında bulunuyor
Asıl yazının yazarı ve meslektaşı Valve’da Steam’i destekliyor gibi görünüyor; bağlam bu
Meslektaşının onu en kötü olarak adlandırmasının nedeni POSIX belirtimi değil
POSIX yalnızca bu fonksiyonun thread-safe olmak zorunda olmadığını söylüyor; thread-safe yapılmasını engellemiyor
Sorun, Valve’ın Steam’i desteklediği tüm Linux dağıtımlarında kullanılan C kütüphanesi olan glibc’nin somut uygulaması ve bu dağıtımların hepsinin “Linux” diye gruplanması
libc isterse bunu thread-safe hale getirebilir
Go gibi diller bu işlevi kendi içinde uyguladığı için böyle bir kısıta sahip değil
POSIX belgesinin kendisi de bu sınırı hesaba katıyor: “The setenv() function need not be thread-safe.”
Linux’ta nethack ve satranç oynayarak büyümüş biri olarak Steam’in varlığı bile şaşırtıcı
Ama Steam istemcisi gerçekten tuhaf
Aylarca düzgün çalışıp sonra birden oyun başlamıyor ya da bir şey çalışmıyor; tekrar çalışması için tüm dosyaları silmek veya yeniden kurmak gibi garip şeyler yapmak gerekiyor
Mantıklı değil ve Steam istemcisi çürüyor gibi hissettiriyor
Birbirinden farklı tasarım ilkelerinin karıştığı bir çorba; yeni özellikler de tamamen farklı UI ve UX ile sonradan ekleniyor
İstemcinin çoğu webview, yavaş ve hatalarla dolu; içeride çok eski ve güvensiz bir Chromium sürümü kullanıyor
Launcher hâlâ 32 bit bir program
Yine de üzücü olan, diğer launcher’ların daha da kötü olması
Hatta yalnızca Linux kullanmaya başladıktan sonra bunları daha az yaşar oldum
Hem Steam istemcisine hem de Linux programlamaya göz atma imkânı veren gerçekten ilginç bir içerik
Her sürüm için ayrıntılı sürüm notları yazmanın zor olduğunu anlıyorum, ama bu tür işleri öğrenince “çeşitli yaygın çökme düzeltmeleri” ifadesi müthiş bir azımsama oluyor
“glibc’de bu sorun çözülebilirse işlevsel ödünler gerekebilir ve ‘imkânsız’ POSIX belirtiminden biraz ayrılan opt-in bir mekanizma olabilir. Makul bir öneri sunulabilirse uzun vadede ilerletilebilir” kısmının gerçekten yapılmasını isterim
Neden bu kadar çok setenv(3) kullandıklarını gerçekten merak ediyorum
Aklıma gelen başlıca kullanım, exec(3) gibi bir şeyi çağırmadan önce ortam değişkeni ayarlamak; ama burada durum bu değil gibi
Yazıda alt süreç başlatırken exevpe kullandıkları söyleniyor, o zaman setenv(3) kullanmayı gerektiren ne kalıyor merak ediyorum
nm -Dile setenv/unsetenv/putenv kullanılıp kullanılmadığını kontrol edebilirsiniz; benim~/.cargo/bin/*dizinime kabaca bakınca bile bunları kullanan çok fazla program varTek thread’li olabilirler, ama gelecekte de hep öyle kalacaklarını kim garanti edebilir?
Düşününce, sembol listesiyle pthread_create de tespit edilebilir
Bu tür sembollerden çağrı ağacına kadar iz süren statik ikili analiz yöntemleri de olsa ilginç olurdu
Ancak
**environkullanılıp kullanılmadığını kontrol etmenin bir yolunu göremiyorum. Derleyici bunu herhangi bir şeye dönüştürebilir