- Depolama kapasitesi defalarca artırılsa da kullanım da birlikte artıyor; 81 kişinin katıldığı bir Mastodon anketinde de yaklaşık yarısı diskinin %75'ten fazlasını kullanıyordu
- Boş duruma göre dolu duruma ulaşmanın daha çok yolu olduğuna dair entropi mantığı bunu kısmen açıklayabilir, ancak kullanıcı davranışını bütünüyle açıklamaz
- İnsanlar sınıra gelene kadar düzenlemeyi erteliyor, sonra da yalnızca o anda gereken kadarını siliyor; bu da diski sürekli doygun durumda tutuyor
- Yavaşlayan yazılımlar, biriken teknik borç, sıkışık yollar ve tıkışık takvimler de ancak acı eşiğe ulaştıktan sonra müdahale edilmesi şeklinde aynı örüntüyü gösteriyor
- Toplam kaynaktan daha küçük yapay kısıtları bütçe gibi belirlemek, erken optimizasyondan kaçınırken sorunları da sınır noktasına kadar sürüncemede bırakmamayı sağlayabilir
Depolama alanı neden sürekli doluyor?
- Kök sürücüde kullanılabilir 0.47TB alanın yalnızca 17GB'ı kalmış durumda; yani boş alan %3. Sonradan eklenen 12TB sürücüde de yalnızca 140GB, yaklaşık %1 boş yer kalmış
- Depolama alanı 1990'larda yaklaşık 80MB'den onlarca TB'a kadar defalarca katlandı, ama buna rağmen hâlâ büyük ölçüde dolu
- Hangi dosyaların temizlenebileceğini bulan yazılımların çok eskiden beri var olması da bu sorunun uzun süredir devam ettiğini gösteriyor
- Mastodon anketine yanıt veren 81 kişinin yaklaşık yarısı sabit disklerinin %75'ten fazlasını kullanıyordu; yani boş depolamadan çok dolu depolama daha yaygındı
- Boş diskten ziyade dolu disk oluşturan durumların sayısı daha fazla olduğundan, verinin boyutunu dikkate almadan durumlar rastgele değiştirilirse sistemin doluluğa yönelmesi şeklinde entropi temelli bir yorum yapılabilir
- Ancak disk, artık daha fazla veri depolayamayacak noktaya kadar sorun gibi hissedilmez; o noktada da ortalık o kadar dağılmış olur ki hangi dosyanın silinip silinmeyeceğine karar vermek zorlaşır
- Kullanıcı yalnızca biraz zaman kazandıracak kadar temizlik yapıp bırakır; bu yüzden disk kısa sürede yeniden sınıra ulaşır
- Depolama kapasitesi birkaç basamak büyütülse bile bu davranış değişmez
Acının eşik noktası ve yapay kısıtlar
- Sorunlara, ancak katlanılamaz bir düzeye geldiklerinde müdahale etme örüntüsü birçok alanda tekrar eder
- Yazılımlar, fazla yavaşlayana kadar optimize edilmez; bu yüzden çoğunlukla sürekli yavaş kalırlar
- Teknik borç, kod üzerinde çalışmak acı verici hâle gelip refactoring kaçınılmaz olana kadar birikir
- Daha az deneyimli geliştiriciler bazen doğrudan sıfırdan başlar; bunun sonucu olarak çoğu kod tabanı dağınık hâle gelir
- Yol ağları, ancak taşınamaz ölçüde sıkıştıktan sonra genişletilir
- Diyet, daha büyük pantolon almak gerekene kadar yönetilmez
- Tam zamanlı işi bırakıp serbest çalışmaya geçince yükümlülükler ve talimatlar ortadan kalksa bile takvim yine eskisi kadar, bazen daha da yoğun dolar
- Sınır noktasına kadar beklemek, işlerin ilerlerken parça parça çözülmesine kıyasla çok daha büyük bir birikim yaratır; ama öte yandan erken optimizasyon da istenen bir şey değildir
- Bu iki sorunu dengelemek için Jevons paradox kullanılarak toplam eldeki kaynaktan daha küçük fiilî kısıtlar konabilir ve optimizasyon bu çerçevede yapılabilir
- Kişisel finansta buna bütçe denir, ama aynı ilke diğer alanlarda tekrar tekrar gözden kaçar
- Yazılımı bir Raspberry Pi üzerinde dağıtıp orada bizzat kullanarak optimize etmek, onun Threadripper'da da hızlı çalışmasını sağlar
80×25terminalli Vim'de gezilebilen bir kod tabanı, güçlü modern IDE'lerde de gezilebilir olur
- Kaynaklar ve özellikler arttığında daha fazla iş yapılabilecekmiş gibi görünür, ama pratikte bazen aynı işi daha yüksek maliyetle yapmak anlamına gelir
1 yorum
Lobste.rs yorumları
Acı veren bir kısıtlamaydı ama bir müşteri destek talebi sınıfını tamamen ortadan kaldırdı. Rakipler Mac ve Linux’u destekleyip ya da yalnızca Windows çıkarıp UNIX desteği vadederken, kullanıcıların bitmek bilmeyen “Linux ne zaman?” sorularıyla uğraştıklarını görmek içimi rahatlatıyor. Hâlâ “BSD port’u ne zaman?” sorusunu alıyoruz ama yönetilebilir düzeyde.
En yeni SIMD komutları da eğlenceli, ama tüm optimizasyonlar için çıtayı 2015 model MacBook Pro’daki Intel Haswell ve AVX2 olarak alıyorum. O ortamda iyi çalışan kod bugün de aynı şekilde iyi çalışır.
256 GB’tan 512 GB’a her çıktığımda sakladığım içerik de beraberinde arttı. Klonlanacak depolar, indirilecek müzikler, arşivlenecek YouTube videoları ve filmler hiç bitmiyor; 720p’den 1080p ve 4K’ya geçtikçe dosya boyutları da büyüdü. Oyunlar da başka bir Steam oyununu kurmak için birini silmek zorunda kalacak kadar şişiyor. Sonuçta, daha büyük bir sepet elde edene kadar mevcut sepeti mümkün olduğunca doldurmaktan ibaret basit bir olgu mu diye merak ediyorum.
Ben beğendiğim depolara GitHub veya Codeberg gibi yerlerde yıldız veriyorum. Bir gün federasyon evreni gibi farklı Git forge’ları arasında da yıldızların paylaşılabilmesini ve GitHub, GitLab, Codeberg için ayrı ayrı hesap tutmak zorunda kalmamayı umuyorum. Depoların kaybolması ya da erişilemez hâle gelmesi ihtimaline karşı kodu bizzat klonlayıp saklayıp saklamadığını bilmek isterim.
/nixbölümü, tamamen yeni bir kurulumun hemen sonrası hariç neredeyse her zaman %90’dan fazla dolu. Nix, geliştiricinin bakış açısını açıkça gösteriyor: bellek yönetimine benzer şekilde, disk alanını yalnızca ihtiyaç olduğunda garbage collection ile geri kazanıyor. Birden fazla sürümün ara derleme çıktıları da muazzam yer kaplıyor.Medya sunucusu dolmuyor; çünkü eski diskler bozuldukça benzer fiyata daha büyük disklerle değiştirerek yıllar içinde yavaş yavaş büyüyen heterojen RAID kullanıyorum. Evdeki tüm CD ve DVD’leri dijitalleştirme girişiminden de vazgeçtim. Kayıpsız sıkıştırma kullanan ses CD’leri ve Wii oyunları buna değer, ama HD-DVD hiç mantıklı değil.
Değerli verilerin kaybolmaması için bunları genelde Nix’e kaydetmek ve Git kullanan proje klasörlerinde saklamak zahmetli. Böyle bir zaman makinesi düzeneğini yıllarca ayakta tutmak muazzam emek istedi, ama sürekli artan ölçeği ve karmaşıklığı yönetmenin tek yolu gibi geliyor.