25 October 2024

Yazılımların Karmaşıklaşması ve Platformların Gücü


Bilişim teknolojileri uzunca bir süredir gündelik yaşamın kritik bir parçası. Bir yandan, gündelik yaşamın giderek daha geniş bir alanını etkiliyorlar. Eğitimden sağlığa, altyapı hizmetlerinden sosyal ilişkilere kadar bilişim teknolojilerinin yaşamımızdaki yeri giderek genişliyor. Diğer yandan, bilişim teknolojilerinin yaşamımızdaki etkileri de derinleşiyor ve onlara bağımlılığımız artıyor.

19 Temmuz 2024’te yaşamın bir çok alanını etkileyen kaosun söz konusu genişleme ve derinleşmenin bir sonucu olduğunu düşünüyorum. Kaos, bilgisayar güvenliği hizmeti veren bir “endpoint protection” (uç nokta koruma) firması olan CrowdStrike’ın gönderdiği bir güncelleme ile başladı. CrowdStrike’ın güncellemesi sonucunda Microsoft Windows işletim sistemli bilgisayarlar çöktü ve bilgisayarların düzgün bir şekilde açılmasını engelleyen, Mavi Ölüm Ekranı olarak adlandırılan bir döngünün içine hapsoldular. Sağlık, eğitim, havacılık, bankacılık gibi çok farklı sektörlerde, milyonlarca bilgisayarı etkiledi; ameliyatlar ertelendi, uçaklar uçmadı, bankacılık işlemleri aksadı…

Görünürde olayın iki aktörü vardı: Microsoft ve Crowdstrike.

Microsoft’un kurumsal ve işletim sistemi güvenliğinden sorumlu başkan yardımcısı olan David Weston ağ günlüğünde (blog) CrowdStrike güncellemesinin 8,5 milyon Windows cihazını etkilediğini ve bunun da tüm Windows makinelerin %1’inden daha az olduğuna dikkat çekti. Yüzde küçük olmasına karşın birçok kritik hizmeti çalıştıran kuruluşun CrowdStrike kullanması sorunun ekonomik ve toplumsal etkilerini artırmıştı. Weston, bunun bir Microsoft olayı olmadığını vurguluyordu. Weston’a göre yazılım güncellemeleri kesintilere neden olsa da 19 Temmuz’da yaşananlar gibi olaylar “nadir”di. Bu nadir olay, geniş ekosistemlerin (küresel bulut sağlayıcıları, yazılım platformları, güvenlik satıcıları, diğer yazılım satıcıları ve müşteriler) birbirine bağlı doğasını ortaya koyuyordu (https://www.techtarget.com/searchsecurity/news/366596532/Microsoft-Faulty-CrowdStrike-update-affected-85M-devices).

Crowdstrike, hatasını kabul etti ve yaşanan ciddi aksaklıklar nedeniyle etkilenen kuruluşlardan özür diledi. Crowdstrike, DEF CON’da En Büyük Başarısızlık Ödülü‘ne layık görüldüğünde şirketin başkanı pek de gurur verici olmayan bu ödülü almak için sahneye çıktı ve amaçlarının insanları korumak olduğunu ama bunu doğru yapamadıklarını söyledi (https://turk-internet.com/crowdstrike-ceo-def-conda-en-buyuk-basarisizlik-odulunu-kabul-etti/). Sadece teknik açıdan değerlendirildiğinde bu olayda en büyük kusur Crowdstrike’taydı. Sonuçta krizi tetikleyen Crowdstrike’ın güncellemesiydi.

Bu olaydan bir ay önce Crowdstrike’ın Başkan Yardımcısı Drew Bagley, kuruluşların tüm bilişim teknolojileri sistemlerini tek bir satıcıya teslim etmelerinin risklerine değinmişti. İşletim sistemi, bulut, üretkenlik, e-posta, sohbet, işbirliği, video konferans, tarayıcı, kimlik, üretken yapay zeka ve giderek artan güvenlik için yalnızca tek bir sağlayıcıya bağımlı olmak ciddi riskler içeriyordu. Bagley’e göre bu, inşaat malzemelerinin, tedarik zincirinin ve hatta inşaat denetçisinin bile aynı olması anlamına geliyordu.

19 Temmuz’daki kaos önlenebilir miydi? Bunun için önerilen teknik çözümler var ve bu çözümler de çoğunlukla Crowdstrike’ın krizdeki rolü üzerine odaklanıyor. Ancak krizi salt teknik bir soruna indirgemeyi ve görünürdeki iki aktör üzerinden tartışmayı doğru bulmuyorum. Sonuçta, kuruluşların tek bir satıcıya olan bağımlılığı kendiliğinden değil karar verme yetkisinde olan aktörlerin inisiyatifiyle alındı. Bağımlılık ilişkilerini onaylayan aktörler belirli politik ekonomik koşullarda hareket ettiler.

Ne ilk ne de son kriz

Microsoft/Crowdstrike krizi Weston’un iddia ettiği gibi nadir bir olay olabilir. Ama ne ilk ne de sondu ve önümüzdeki yıllarda daha kritik krizlerle karşı karşıya gelebiliriz. 19 Temmuz krizi hakkındaki haberler sosyal medyaya düştüğünde akıllara ilk gelen bir siber saldırının olabileceğiydi. Daha sonra krizin bir güncellemeden kaynaklandığı ortaya çıktı ama insanların hemen bir siber saldırıdan kuşkulanmasına şaşırmamak gerekiyor. Nitekim Microsoft’un Azure platformu 30 Temmuz tarihinde bir DDoS saldırısına maruz kaldı.

Microsoft tarafından yapılan açıklamada hasarın boyutu ve kaç şirketin bundan etkilendiği hakkında bilgi verilmedi. Ama Azure App Services, Application Insights, Azure IoT Central, Azure Log Search Alerts, Azure Policy ve Azure portalının kendisi ile Microsoft 365 ve Microsoft Purview hizmetlerinin bir “alt kümesinin” saldırıdan etkilendiği belirtildi. Ayrıca DDoS savunmasında yapılan bir yapılandırma hatası, saldırıyı güçlendirmişti. Microsoft, Haziran’da da benzer bir saldırıyla karşı karşıya kalmış ve Microsoft hizmetleri kesintiye uğramıştı. turk-internet.com haber sitesinin siber güvenlik uzmanlarından aktardığı şu sözlerin son derece önemli olduğunu düşünüyorum (https://turk-internet.com/microsoft-10-saatlik-azure-kesintisi-icin-ddos-saldirisini-sucladi/):

“Microsoft’un buradaki tökezlemesi tüm sektör için bir uyarı çağrısıdır. Bir teknoloji devi bir DDoS saldırısıyla çevrimdışı kalabildiğinde, sağlam ve iyi test edilmiş savunmaların ne kadar kritik olduğunu gösterir. İronik olan, kendi koruma mekanizmalarının saldırının etkisini artırmasıdır. Bu, sizi yanlışlıkla kendi evinizin dışına kilitleyen süslü bir güvenlik sistemine sahip olmak gibidir. Bu, modern bulut ortamlarının karmaşıklığını ve güvenlik önlemlerinin titizlikle test edilmesi ihtiyacını vurgular.”

Teknoloji bağlamında, öncelikle nasıl bir dünyaya doğru yol aldığımız sorusunu tartışmalıyız. Bu yolda özellikle iki sürece dikkat etmek gerekiyor. Birincisi, teknolojik altyapılar giderek daha çok karmaşıklaşıyor ve bireysel müdahalelerin olanakları daha sınırlı hale geliyor. 41 yıl önce Özgür Yazılım Hareketi, “Ben değilse kim, hemen şimdi değilse ne zaman?” diyen Richard Stallman ile doğmuştu. 33 yıl önce de Linus Torvalds, özgür yazılımlar üzerinde yükselen Linux çekirdeğini yazarak GNU/Linux işletim sisteminin son kritik parçasını tamamlamıştı. Bu krizde, GNU/Linux kullanmak çözüm olabilir miydi?

Mac ve GNU/Linux işletim sistemli bilgisayarların krizden etkilenmediler. Çoğu durumda uç noktaların temel işlevselliğe ihtiyaç duyması nedeniyle buralarda GNU/Linux’un tercih edilmesinin daha iyi olabileceğini iddia edenler var (https://www.techtarget.com/searchsecurity/news/366596532/Microsoft-Faulty-CrowdStrike-update-affected-85M-devices). Bu gibi teknik çözümler kimi zaman kısmen yararlı olabilir. Ama geldiğimiz aşamada hack tarzı çözümler yazılımların karmaşıklığı karşısında artık yetersiz kalıyor. İkincisi, kullandığımız bilgisayarların (yazıda bilgisayar kelimesi masaüstü ve dizüstü bilgisayarların yanında tabletler, akıllı telefonlar vb teknolojileri de kapsıyor) disk, işlemci ve bellek kapasiteleri ne kadar yüksek olursa olsun gerçekte bilgisayarlarımız dünyadaki birkaç dev bilgisayara (platforma) bağımlı.

Yazılımların Artan Karmaşıklığı

Henry Ford’un başarısının temelinde standartlaştırma vardı. Ama bu aynı zamanda Ford’un zaafıydı. Standartlaştırma, bir yandan ölçek ekonomisi için elverişli bir ortam sağlarken diğer yandan çeşitliliği azaltıyordu. Örneğin Ford’un arabaları sadece siyahtı. Çünkü Ford, otomobillerin fiyatının olabildiğince uygun olmasını ve bunun için de maliyetleri düşürmeyi hedefliyordu. Birden fazla renk seçimi, yeni ekipman ve işçilik maliyetlerini artıracak ve üretim sürecine bir karmaşıklık katacaktı. GM (General Motors), Ford’daki bu açığı fark etti ve 1923’ten itibaren her model yılında değişen birden fazla renge ve şık gövdeye sahip otomobiller piyasaya sürmeye başladı. Bu strateji, GM’nin Ford’u otomotiv pazarı lideri olarak yerinden etmesine yardımcı oldu.

Fikri ürünler ve özellikle de yazılım ekonomisi tartışılırken aynı ürünün bir kopyasını oluşturmanın maliyetinin sıfıra yakın olduğu üzerinde durulur. Bir yazılım paylaşıldığında, paylaşan da paylaşılan da yazılımı kullanabilir. Bunun yanında, yazılıma yeni özellik (feature) ekleme süreci de fiziksel ürünlere yeni özellik eklemeden farklıdır. Malzemenin fiziksel dönüşümünü içeren yeni özelliklerin geliştirilmesi çoğunlukla çok daha uzun sürer ve daha büyük masraflara neden olur. Yukarıdaki örnekte Ford, standartlaşmış üretim süreçlerini değiştirmeyi göze alamamış ve GM’nin gerisine düşmüştür. Yazılım kodunun doğası gereği birçok yeni özellik hızlı bir şekilde eklenebilir ve genellikle büyük maliyetler olmadan geliştirilebilir. Bu nedenle, modülerliğin sağlanması yazılım mühendisliğinin temel hedeflerinden biridir. Bilişim sistemleri, temel etkileşim kurallarına uyulduğu sürece her bir özelliğin diğerlerinden bağımsız olarak geliştirilebileceği şekilde tasarlanabilir.

Böylece yazılım firmaları ürünlerinin özelliklerini hızla artırabilirler. Yeni özellikler, farklı talepleri olan müşterilerin ihtiyaçlarının daha çok karşılanması anlamına gelir. Ancak yazılıma eklenen her yeni özellik yazılımın karmaşıklığını da artırır. Bir firma, piyasada tutulan ve çok sayıda özelliği olan bir yazılımla rekabet etmek istediğinde karşısında büyük başlangıç maliyetleri ve çok sayıda özellik içeren karmaşık bir yazılım bulacaktır.

Yazılım soyutlamadır ve gerçek dünyadaki ilişkiler yazılımda yeniden kurulur. Kuruluşlar, gerçek dünyadaki karmaşıklığı yazılımla yönetilebilir hale getirebilirler. Örneğin, talep değiştikçe ürünlerini, hizmetlerini, dağıtımlarını ve pazarlamalarını hızla değiştirmek için yazılım yeteneklerinden yararlanabilirler. Böylece sundukları ürün ve hizmetlerin kalitesini artırabilirler.

Yazılımın otomobil sektörünü nasıl etkilediğine bakalım.

1920’lerde otomobil sektöründe rekabet otomobillerin renkler ve gövde stilleri üzerinde gerçekleşirken şimdi rekabetin temelinde yazılım sistemleri var. Bugünün otomobilleri, hepsi birbirine bağlı elli, yüz ya da daha fazla bilgisayardan oluşuyor. Ortalama bir model yüz milyon satırdan fazla yazılım kodu içerebiliyor (örneğin Google Chrome’daki kod miktarı altı milyondan biraz fazla). Ama otomobil sistemlerindeki karmaşıklığın asıl nedeni kod miktarından çok modüller arasındaki etkileşimin fazlalığı.

Yazılım, yeni özellik eklemeyi kolaylaştırarak otomobil üreticilerinin rekabet gücünü artırıyor. Çünkü performans, güvenlik ve güvenilirlikte önemli iyileştirmeler sağlıyor. Ancak yukarıda belirttiğim gibi modüller arasındaki etkileşimin artması ve bir modülün performansının diğerlerini etkileyebiliyor olması araçlardaki hata ayıklama sürecini zorlaştırıyor. Yanlış gidebilecek ve ön görülemeyen sonuçlara yol açabilecek çok şey var. Volkswagen, Passat ve Tiguan’ları geri çağırmak zorunda kaldı. Çünkü bir yazılım hatası nedeniyle, klima açıldığında motor beklenmedik şekilde devir yapıyordu. Mercedes-Benz kullanıcıları ise navigasyon düğmesine basıldığında koltukların hareket etmesine neden olan bir sorunla karşılaştılar. Araç geri çağırmaları giderek artan oranda yazılımla ilgili hatalardan kaynaklanıyor. IBM, otomobillerin garanti maliyetlerinin yüzde 50’sinin yazılım ve elektronikten kaynaklandığını tahmin ediyor.

Otomobil sistemlerindeki yazılım yoğunluğunun ve karmaşıklığının artması yeni veya daha zayıf oyuncuların rekabet gücünü azaltıyor. Karmaşıklık nedeniyle, mevcut ana bileşenleri (motor, platform vb.) kullanarak yeni bir model tasarlamanın maliyeti yaklaşık bir milyar dolardan başlıyor ve beş yıl sürebiliyor. Sıfırdan yeni bir otomobil tasarlamanın maliyeti ise beş ya da altı milyar doları bulabiliyor. Sadece yazılım kodunun maliyeti bir milyar dolara ulaşabiliyor.

Hizmet sektöründeki rekabet de karmaşık yazılımlar üzerine kurulu. Google ve Facebook, büyük miktarda veri ve en ileri yazılım sistemlerini kullanarak reklam verenlere daha önce görülmemiş düzeyde hedefleme olanağı sunuyorlar. Gerek Google’ın gerekse de Facebook’un kullandığı sistemler son derece karmaşık. Örneğin Google, daha başarılı sonuçlar için sürekli arama algoritmalarını değiştiriyor ve son yıllarda arama etkinliğini iyileştirmek için yılda on binden fazla deney yapıyor. Finansal kurumlar, hem ürünlerini hem de pazarlamalarını yazılımsal düzeyde ekledikleri özelliklerle zenginleştirirken kullandıkları yazılımlar karmaşıklaşıyor. ABD kredi kartı sektörü, dört büyük bankanın elinde. Bu bankalar, hakim ve yüksek düzeyde hedeflenmiş müşteri gruplarına özel kredi teklifleri sunuyorlar. Böylece hem pazar erişimini en üst düzeye çıkarıyor hem de riski yönetiyor.

Özetle, 2000’li yıllardan beri bir dizi sektörde (özellikle büyük) firmalar ve kurumlar, özel yazılım sistemlerine büyük yatırımlar yapıyorlar. Yazılım, firmaların fiziksel dünyadaki karmaşıklığı daha iyi yönetmelerine yardımcı oluyor. Yazılımlar sayesinde ürün ve hizmetlerinin kalitesini iyileştiren firmalar rekabet avantajı elde ediyorlar. Fakat gerçek dünyadaki ilişkilerin soyutlanarak yazılımda yeniden kurulması eklenen her yeni özellikle beraber yazılımların kendi karmaşıklıklarını artırıyor. Dolayısıyla yazılımlar performans, güvenlik, güvenilirlik gibi konularda kayda değer iyileştirmeler sağlarken hata ayıklama zorlaşıyor ve yazılım modülleri arasındaki ön görülemeyen etkileşimler beklenmedik sonuçlara neden olabiliyor. Microsoft’un DDOS savunmasında yaptığı bir hatanın saldırının etkisini artırması üzerinde durulması gereken bir konu. Ya da Crowdstrike’ın kendini affettirmek için müşterilerine 10 dolarlık bir hediye kartı göndermesi, yoğun kart kullanımı nedeniyle Uber Eats’in bunu bir dolandırıcılık girişimi sanması, kartları kabul etmemesi karmaşık yazılımların çalıştığı bir dünyada işlerin her zaman kolay olmadığını gösteriyor.

Üç Büyükler: Amazon, Microsoft ve Google

İşlemci hızı ve bellek kapasitesi oldukça yüksek bilgisayarlarımız var. Apollo 11’in bilgisayarını, Apollo 11’in uçuşundan tam 50 sene sonra, 2019 yılında piyasaya sürülen iPhone 11 ile kıyasladığımızda elimizdeki bilgisayarların yüksek kapasitesi daha rahat görülüyor (https://evrimagaci.org/telefonunuz-sizi-aya-goturebilecek-kadar-guclu-mu-13243):

” Apple’ın bu ürünü [iPhone 11], 4 GB’lık RAM’e sahiptir. Bu da 34,359,738,368 bite eşittir. Günümüzdeki telefonların RAM’ı, Apollo bilgisayarının RAM hafızasından yaklaşık 1 milyon kat (tam olarak 1,048,576 kez) daha güçlüdür. iPhone 11’lerin 512 GB’a kadar ROM hafızası vardır. Bu da 4,398,046,511,104 bite eşittir ve Apollo Kılavuz Bilgisayarı’ndan 7 milyon kat daha güçlüdür.”

Ayrıca, Apollo 11 bilgisayarının 0.043 MHz’lik bir işlemcisi varken iPhone 11’inki bunun 100000 katı, 2490 Mhz’dir.

Buna karşın, her geçen gün daha güçlü bilgisayarlara, bulut bilişim platformlarına, bağımlılığımız artıyor. Telefonlarımızı tam anlamıyla ağa bağlandıklarında kullanabiliyoruz. Ağ bağlantısıyla sosyal medya platformlarına giriyor, anlık mesajlaşma uygulamalarını kullanıyor, müzik dinliyor, film izliyor, yol tarifi alıyor, bankacılık işlemlerini yapıyor, alışveriş yapıyoruz ve fotoğraflarımızı yedekliyoruz. Televizyonlarımız, medya platformlarına bağlı. Bilgisayarlarımıza kurduğumuz yazılımların sayısı azaldı. Şirketlerin yazılımlarına abone oluyoruz. Daha da önemlisi bireylerden çok kuruluşların platformlara bağımlılığı artıyor. Hizmet olarak yazılım iş modelinin yanı sıra hizmet olarak YZ’ye dayanan iş modelleri yaygınlaşıyor. Gerçekte akıllı olan yüksek işlemci hızlarına ve bellek kapasitelerine rağmen telefonlarımız değil, YZ modellerini oluşturan, eğiten ve YZ hizmeti olarak sunan dev bilgisayarlar. Bilgisayarlarımızın artık başka bilgisayarlara bağımlı olması bir sorun. Ama bu başka bilgisayarların aslında sadece birkaç büyük şirketin elinde toplanmış olması daha büyük bir sorun.

Son yıllarda YZ altyapılarının ve hizmetlerinin geliştirilmesinde üç büyük teknoloji şirketi öne çıkıyor: Amazon, Microsoft ve Google. Bu şirketlerin gücü üç etkene dayanıyor. İlk olarak, YZ gelişiminin anahtarı olan büyük miktarda değerli veriye sahipler ve veri birikiminin sürekliliğini sağlayabiliyorlar. İkincisi, bu şirketler, yüksek vasıflı YZ araştırmacılarını istihdam etmek ve onları elde tutmak için çok daha fazla finansal kaynağa sahipler. Üçüncüsü, GPU’lar (Grafik İşlem Birimleri) gibi ileri teknoloji hesaplama kaynaklarına sahip olmaları, YZ’nin geliştirilmesini kolaylaştırıyor. Kısaca veri, bilgi işlem altyapıları ve YZ uzmanlığı üzerindeki artan ekonomik ve siyasi güçleri ile YZ teknolojilerinin geliştirilmesinde, YZ hakkındaki anlatının şekillendirilmesinde ve YZ’nin yönelimlerinde merkezi bir role sahipler.

Son yıllarda bu üç şirket, bulut bilişim platformlarını altyapısal olarak genişletmek için büyük yatırımlar yaptılar. Amazon Web Services (AWS), Microsoft Azure ve Google Cloud Platform (GCP) küresel bulut bilişim pazarının %68’ini oluşturuyor. Bu platformlar kendi bulut altyapılarında yapay öğrenme sistemleri ve uygulamalarının üretimi, eğitimi ve dağıtımı için tam kapsamlı entegre araçlar ve hizmetler sağlıyorlar (Luitse, 2024).

Böylece YZ soyut bir fikir olmaktan çıkarak platformlar üzerinden ete kemiğe bürünüyor. Platformlar; altyapı, model ve uygulamaların yanı sıra yine bunlara dayanan uygulamalar ve şirketlerden oluşan bir ekosistemi kapsayan gerçek bir teknoloji yığını olarak karşımıza çıkıyorlar. van der Vlist, Helmond ve Ferrari’nin (2024) YZ’nin endüstrileşmesi adını verdiği bu geçiş sürecinde YZ sistemleri, araştırma ve geliştirme aşamasından çeşitli sektörlerde pratik ve gerçek dünyayla ilgili ticari ürün ve hizmetler olma yolunda ilerliyor.

Kamuoyunda Microsoft’u bir işletim sistemi, Amazon’u bir alışveriş sitesi, Google’ı da bir arama motoru olarak görme eğilimi yaygın. Oysa bu üç şirket, çok çeşitli hizmetler sunuyorlar ve aslında internetteyken çoğu zaman doğrudan veya dolaylı olarak (AWS’nin bazı müşterileri için bkz. https://spacelift.io/blog/who-is-using-aws ) bu şirketlerin bulut platformlarına bağlanıyoruz. AWS, Azure ve GCP, YZ’nin endüstrileşmesi sürecinin temel omurgasını oluşturuyor. Günümüzde internetin kalbinin attığı bu üç platform, farklı sektörlerdeki işletmeler üzerinde derin bir etkiye sahipler. Pazar araştırması tahminlerine göre AWS’yi internetin birincil işletim sistemi olarak değerlendirebiliriz. Dünyadaki tüm bulut hizmetlerinin üçte biri AWS (%32) üzerinde çalışıyor. Onu Microsoft Azure (%22) ve Google Cloud (%11) takip ediyor (age).

AWS; iş uygulamaları, YZ ve yapay öğrenme hizmetleri, hesaplama ve altyapı, veri ve analitik, nesnelerin interneti, BT operasyonları, güvenlik ve uyumluluk, sektöre özel çözümler gibi kategorilerde kapsamlı hizmetler sunuyor. Azure da benzer hizmetler sunuyor: YZ ve yapay öğrenme hizmetleri, hesaplama ve altyapı, veri ve analitik, nesnelerin interneti, BT operasyonları, ve sektöre özel çözümler. GCP ise veri ve analitik, nesnelerin interneti, BT operasyonları ve sektöre özel çözümlere odaklanıyor. Benzer çalışma alanlarına karşın şirketlerin yoğunlaştıkları alanlar farklılaşabiliyor. Örneğin, Azure ve GCP, hesaplama ve altyapı alanında öne çıkıyorlar. Uygulama geliştirme ve entegrasyon kategorisinde AWS, güvenlik ve uyumluluk kategorisinde ise GCP başı çekiyor.

Bu iş modellerinin büyük bir kısmı bulut bilişimin ilk günlerinden beri var. Fakat YZ’deki gelişmelerle beraber büyük teknoloji şirketleri son yıllarda daha iddialı adımlar atıyorlar. Üçüncü taraf geliştiricileri ve işletmeleri çekmeyi amaçlayan, sektör odaklı çözümler ve pazar yerleri geliştirerek daha geniş bir YZ ekosisteminin büyümesini teşvik ediyorlar. Örneğin sağlık sektörü her üç platformun da yer aldığı bir sektör. GCP, tıbbi teşhis ve veri analizine yönelik YZ çözümlerini kolaylaştırmak için ‘Cloud Healthcare API’, ‘Medical Imaging Suite’ ve ‘Healthcare Natural Language AI’ gibi sağlık hizmeti odaklı ürünler sunuyor. Azure’un sağlı hizmetleri ‘Health Data Services’ ve ‘Azure Data Lake Storage’. Bunların yanında YZ destekli bir sağlık botu hizmeti de var. AWS, yapay öğrenme modellerini kullanarak tıbbi ve sigorta verilerini dönüştürmek için ‘AWS Health’, ‘HealthLake’ hizmetlerini sağlıyor.

Perakende sektörü, Amazon’un uzmanlık alanı olmasına karşın diğer bulut platformlarının da çeşitli hizmetleri var. Örneğin, Google perakende sektöründe, ‘Discovery AI for Retail’ ve ‘Recommendations AI’ gibi çözümlerle dönüşüm oranlarını iyileştirmeyi ve kişiselleştirilmiş ürün önerileri sunmayı amaçlıyor. Müşteri etkileşimi ve iletişim merkezleri için AWS’nin ‘Amazon Connect’ ve GCP’nin ‘Contact Center AI’ hizmetleri var. Veri yönetimi ve analizi için ‘BigQuery’, ‘Amazon DocumentDB’ ve ‘Azure Synapse Analytics’ kullanılabiliyor.

van der Vlist vd.’nin (2024) YZ’nin endüstrileşmesi olarak adlandırdığı bu süreç, büyük teknoloji şirketlerinin daha gelişmiş ve kapsamlı YZ hizmetleri sağlamasıyla şekilleniyor. Büyük teknoloji şirketleri söz konusu hizmetleri sağlarken YZ için kritik bir altyapı hizmet sağlayıcısı haline geliyorlar. Bulut platformları, hizmet olarak altyapı (örneğin hesaplama kapasitesi) sunarak ve dijital ürünleri (örneğin önceden eğitilmiş modeller veya yazılım paketleri) metalaştırarak YZ geliştirme ve entegrasyonunda merkezi bir rol oynuyorlar. Platform şirketleri, üçüncü taraf geliştiricileri ve işletmeleri kendi ekosistemlerine dahil ederek erişimlerini, etkilerini ve kullanıcı tabanlarını genişletmeye çalışıyorlar. Tamamlayıcı uygulamalar ve hizmetler oluşturmak için geliştiricileri, sundukları özel mülkiyetli araçları ve altyapıyı kullanmaya teşvik ediyorlar.

(Büyük Teknoloji şirketleri sık sık YZ araçlarını geniş bir kitle için erişilebilir hale getirerek YZ’yi demokratikleştirdiklerini iddia ediyorlar. Bu demokratikleştirme söyleminin büyüsüne kapılan geliştiriciler çoğu zaman (belki de farkında olmadan!) Büyük Teknoloji şirketlerinin altyapısal hedeflerine katkıda bulunuyorlar. Teknoloji devleri tarafından sağlanan altyapıyı kullanarak uygulamalar ve entegrasyonlar oluşturuyorlar. Fakat geliştirilen uygulama ve özellikler, temelde platformun özel mülkiyeti olan hesaplama kaynaklarına dayanıyor. Daha da kötüsü çoğu zaman bu iyi niyetli uygulama ve entegrasyonlar bir bağımlılık ilişkisine neden oluyor.)

Son yıllarda bu üç büyük şirket, YZ yatırım faaliyetleri oldukça artırdılar. Crunchbase ve Tracxn’den alınan veriler Microsoft’un yaklaşık 211 yatırım ve 214 satın alma işlemine dahil olduğunu ve 188 milyar doların üzerinde satın alma harcaması yaptığını gösteriyor. Google, 238 yatırım ve 260 satın alma işlemini yapmış ve toplamda 41,8 milyar dolar harcamış. Amazon’un ise 132 yatırım ve 99 satın alma işlemi var ve 36,9 milyar dolar harcamış. Birçok YZ firması, YZ modellerini ve uygulamalarını ölçeklendirmek için gereken finansal ve altyapısal gereksinimleri ancak büyük teknoloji şirketleriyle yaptıkları ortaklıklarla sağlayabiliyor. Finansal yatırımları, satın almaları, ortaklık programları ve başlangıç fonları, büyük teknoloji şirketlerinin farklı sektörlerdeki YZ uygulamalarındaki merkezi rolünü pekiştiriyor.

Örneğin, Microsoft’un OpenAI ile uzun vadeli bir ortaklığı var. Azure, OpenAI’nin özel bulut sağlayıcısı. OpenAI ürünleri ve API hizmetleri, YZ için optimize edilmiş altyapı ve araçlarla sunuluyor. OpenAI modellerine Azure’un OpenAI Hizmeti aracılığıyla erişilebiliyor ve kurumsal geliştiriciler Azure’da YZ uygulamaları oluşturabiliyorlar. Microsoft ayrıca OpenAI’nin modellerini Microsoft 365, Edge tarayıcı, Bing arama motoru, GitHub Copilot, Power Platform ve Microsoft Designer gibi kendi ürün ve hizmetlerine entegre etmek için özel bir lisansa sahip. Microsoft, Bulut İş Ortağı Programı ve Yapay Zeka İş Ortakları aracılığıyla kendi iş ortaklarına da entegrasyon olanağı sağlıyor. Bu iş ortağı programları, Microsoft’un firmalar ve kuruluşlarla stratejik ittifaklar kurmasına yardımcı oluyor; müşteriler böylece gelişmiş araçları ve hizmetleri özel yazılımlarına ve ürünlerine dahil edebiliyorlar.

Microsoft’ın OpenAI dışında Wayve (otonom mobilite için derin öğrenme), PrimerAI (istihbarat ve operasyonel iş akışları), Novo Nordisk ve Paige (YZ tabanlı teşhis ve ilaç geliştirme) gibi şirketlerle ortaklıkları da var. D-Matrix (veri merkezleri için verimli bilgi işlem), Noble.AI (Ar-Ge teknolojileri) ve KudoAI (Microsoft Teams’de bulunan canlı konuşma çevirileri) gibi YZ girişimlerine yatırımlar yapıyor. Ayrıca AI Grant ve Startups Founders Hub gibi programlar aracılığıyla Azure bulut kredileri, teknik danışmanlık, geliştirme araçları vb kaynaklar sağlıyor ve geliştiricileri kendi platformunu kullanmaya teşvik ediyor. Tüm bu ortaklıklar ve yatırımlar, Microsoft’un çeşitli endüstri sektörlerinde YZ hizmetlerinden yararlanma ve kendisini kurumlar için birincil altyapı sağlayıcısı olarak sunma stratejisini gösteriyor.

Google ve Amazon da YZ geliştirme ve dağıtımındaki konumlarını sağlamlaştırmak için benzer stratejiler uyguluyorlar. Google, 2014 yılında derin öğrenme algoritmaları ve sinir ağları alanında uzmanlaşmış DeepMind’ı satın aldı. Bu satın alma Google’ın YZ yeteneklerini geliştirdi ve YZ dünyasındaki konumunu güçlendirdi. Anthropic, AI21Labs, Midjourney, Osmo ve Cohere gibi YZ odaklı şirketlerle ortaklıklar kurdu. Ayrıca Google’ın yapay öğrenme için opitmize edilmiş çipleri Google’ı tercih edilen bir bulut sağlayıcısı yaptı. Google, Adobe ile ortak çalışmalar yürütüyor.

Google’ın YZ programları ve ortaklık girişimleri, bulut YZ yığınının her düzeyindeki iş ortaklarının Google altyapısına ve YZ zeka yeteneklerine erişilebilirliğini artırmak için tasarlanmış. Bir diğer deyişle, çip üreticileri, geliştiriciler ve danışmanlık firmaları, Google’ın altyapısına, YZ ürünlerine ve temel modellere erişebiliyorlar. Bu erişilebilirlik sayesinde kurumsal müşteriler yapay öğrenme modeli geliştirme ve dağıtma konusunda yetkin teknoloji ortaklarının desteğini alabiliyorlar. Google ayrıca temel modeller oluşturan şirketlerle ve üretken YZ uygulama geliştiricileri ile işbirliği yapıyor. Bu işbirlikleri, çeşitli müşteri kullanım senaryolarının oluşturulmasını teşvik ediyor ve çeşitli sektörlerde inovasyonu destekliyor. Ayrıca Google, YZ öncelikli girişimleri destekliyor ve bu şirketlerin YZ projelerini ilerletmek için şirketlere, bulut kredileri, teknik eğitim vb kaynaklar sağlıyor.

Amazon’un ise Stability AI ve Hugging Face ile ortaklıkları var. Bu şirketler, modellerini geliştirmek ve eğitmek için Amazon’un bulut yapay öğrenme platformu ‘SageMaker’ı kullanıyorlar. AWS İş Ortakları, işletmelere YZ ve altyapı ihtiyaçları konusunda yardımcı oluyorlar. Amazon, birçok YZ girişimine doğrudan yatırım yapmasa da Microsoft ve Google gibi geliştiricileri platformuna çekmeye çalışıyor. Amazon birçok YZ girişimine doğrudan yatırım yapmasa da, yeni girişimler için AWS Generative AI Accelerator programını yürütüyor, yatırımcılara ve kurumsal müşterilere krediler, teknik mentorlar ve ağ oluşturma fırsatları sunuyor.

Özetle, Amazon, Microsoft ve Google, kendilerinin merkezde yer aldığı stratejik girişimler yoluyla YZ’nin gelişimini ve farklı sektörlere entegrasyonunu hızlandırıyorlar. Fakat YZ şirketleri ve kurumlar bu ekosistemlere bağımlı olma riskiyle karşı karşıyalar. Çünkü bir platformdan başka bir platforma geçmenin riski bir hayli yüksek.

***

Bulut platformları çeşitli endüstrilerin altyapısını oluşturmaya başladı. Bunun sonucunda, platformlarda çıkan sorunların (güç kesintisi, siber saldırı, teknik hatalar vb) etki alanı genişledi ve sıkıntılar daha hissedilir olmaya başladı. Örneğin 13 Haziran 2023’te AWS’deki bir kesinti Associated Press (AP), McDonald’s, Reddit gibi farklı sektörlerden bir çok şirketi etkiledi.

Özgür/Açık Kaynak yazılımların karşı karşıya kaldığımız soruna etkisi son derece sınırlı olacak. Çünkü kurumlar ve firmalar gerçek hayattaki karmaşıklığı kendi bünyelerinde (doğrudan ya da dış kaynak kullanarak) geliştirdikleri karmaşık yazılımlarla yönetiyorlar. Bulut platformlarına bağımlılıkları ve oralardaki yazılımlarla etkileşimler yazılımları özellik yönünde zenginleştirse de yazılımın kendi karmaşıklığının yönetimi zorlaşacak.

Ayrıca yazılımların artan karmaşıklığı bilişim teknolojilerinin kamusal denetimini de zorlaştırıyor. Bessen (2022) üç örnek üzerinde duruyor. Birincisi, Volkswagen’in 2015 yılında ortaya çıkan emisyon skandalı. Volkswagen’in aldatıcı bir yazılımla dizel motorlardaki emisyon değerlerini manipüle ettiği ortaya çıktı. Volkswagen’in bu yazılımını dünya çapında yaklaşık 11 milyon otomobilde kullanmış ve yıllarca denetçileri atlatabilmişti. İkincisi, Boeing 737 Max’taki bir arızanın yazılımla örtbas edilmesiydi. Uçaktaki fiziksel bir sorun bir yazılımla saklanmış ve uçak FAA’nın (Federal Havacılık İdaresi ) testlerinden başarıyla geçmişti. Bunun sonucunda 2018 ve 2019’da beş ay arayla gerçekleşen iki uçak kazasında 346 kişi öldü. Düzenleyicilerin yazılımın karmaşıklığı karşısında yenik düştüğü üçüncü olay ise 2008 krizinde, düşük faizli ipoteklerde ortaya çıktı. Yazılım modelleri ve yazılım destekli finansal araçlar, büyük bankaların mali durumunu ve sistemik riskin büyüklüğünü gizlediler.

Kurumsal yazılımların bulut platformlarıyla kurduğu ilişkiler yazılımdaki karmaşıklığın yönetimini zorlaştıracak. Bunun sonucunda da riskler artacak ve kamusal denetim daha da zorlaştıracak.

Özgür/Açık Kaynak yazılımlar bir çözüm değil. Ama 41 yıllık Özgür Yazılım Hareketi 2000’li yıllarda bulut bilişime karşı çıkarken tam da bugün yaşadıklarımıza işaret ediyordu. Bireylerin, kurumların ve ülkelerin üretim özgürlüğünü sınırlayan veya ortadan kaldıran her teknolojiye kuşkuyla yaklaşmak gerekiyor.

Kaynaklar

Bessen, J. (2022). The new goliaths: How corporations use software to dominate industries, kill innovation, and undermine regulation. Yale University Press.

Luitse, D. (2024). Platform power in AI: The evolution of cloud infrastructures in the political economy of artificial intelligence. Internet Policy Review, 13(2), 1-44.

van der Vlist, F., Helmond, A., & Ferrari, F. (2024). Big AI: Cloud infrastructure dependence and the industrialisation of artificial intelligence. Big Data & Society, 11(1), 20539517241232630.



15 February 2020

Python ile ufak bir resim boyutlandırma betiği


Pampalar şimdi malumunuz ben linux kullanıcısıyım bu blogumdan da belli oluyordur. :P Ama tamamen alışkanlık ve kod yazmayı sevmekten dolayı konsol kullanmasını seviyorum. Geçenlerde okulda bi resim boyutlandırma ve video çevirme işlemi lazım oldu windowstaki gibi iki saat programlarla cebelleşmek yerine hemen konsoldan birer satırlık (ffmpeg ve imagamagick şahaneleri ile) kodla işimi gördüm. Burda amaç havalı görünmek değildi işi hızla bitirmekti.

Müdür yardımcımız hemen yapıştırdı siz linux kullanıyonuz ya dedi :) yani konsol falan :) Bunun konsol haricinde de yapılabildiğini anlattım ama seviyorum böyle dedim ama yine de tuttum bir de python betiği yazdım.
Adını da feriha koymadım pyresim koydum ( isim bulamadım salladım) github a da koydum ha :) alın bakın kullanın falan diye :)
https://github.com/birtanyildiz/pyresim





29 October 2018

Linux için F5 Ssl Vpn Client i Kurulumu ve Kullanımı


Windows için Windows Store da, android için Google Play de client i bulunan F5 Ssl VPN linux için herhangi bir repo ya katılmış gözükmüyor. Eğer siz de benim gibi linux kullanıcısı iseniz, kuruluşunuz tarafından size verilen vpn geçidi adresine firefox ile eriştiğinizde karşınıza çıkan sayfaya kullanıcı adı ve şifreniz ile giriş yapabilirsiniz.

Giriş yaptığınızda karşınıza şöyle bir sayfa çıkacak
Bu sayfada işaretli olan yerden manual olarak yüklemeyi seçip indirdiğiniz tgz uzantılı dosyayı açtığınzda
karşınıza şu dizin gelecek. Burada sağ tıklayıp terminalde açtıktan sonra;

sudo ./Install.sh 
komutu ile kurulumu başlatabilirsiniz. sadece bir kere kurayım mı diye soracak size "yes" yazıp entera basıp geçtikten sonra vpn clientiniz hazır. Kullanmak için sadece komut satırında (terminalde)

sudo f5fpc -s -t "https://sslvpnadresiniz.com"

yazarak başlatmanız

sudo f5fpc --stop 

yazarak durdurmanız mümkün olacaktır.

Detaylı bilgi için f5fpc --info yazmanız yeterli....

Kolaylıklar dilerim.



Zemberek 0.16.0 Text Normalizasyonu ve gRPC sunucusu


Zemberek NLP 0.16.0 yayınlandı.  Bu sürümdeki yeni özelliklerden bazıları:

Metin Normalizasyonu
Bu özellik ile sosyal medya, forum ve mesajlaşma yazlımlarında kullanılan cümlelerdeki hatalar düzeltilmeye çalışılır. Bu işlem, metne daha sonra uygulanacak işlemlerin başarımını arttırabilir. Örnek:

Yrn okua gidicem
yarın okula gideceğim

Tmm, yarin havuza giricem ve aksama kadar yaticam :)
tamam , yarın havuza gireceğim ve akşama kadar yatacağım :)

ah aynen ya annemde fark ettı siz evinizden cıkmayın diyo
ah aynen ya annemde fark etti siz evinizden çıkmayın diyor
Bu ilk denememiz olduğu için sıklıkla hata yaptığı durumlar olacaktır. Detaylar için dokümantasyona bakınız.

gRPC sunucusu
gRPC, açık kodlu, yüksek hızlı bir uzaktan fonksiyon çağrı mekanizmasıdır. Zemberek fonksiyonlarının bir kısmına başka programlama dillerinden hızlı erişim sağlamak için kullanılabilir. Bu ilk sürümde grpc sunucusu ve kısıtlı fonksiyonlara python ile erişim kütüphanesi yayınlandı. Dokümantasyon.

Yeni morfolojik analiz modları:
Normalizasyon türü işlemler için faydalı olabilecek iki yeni analiz modu eklendi. Bunlardan ilki "informal" analiz. Bu şekilde özellikle konuşma dilinde kullanılan "yapıcam, edicem, geliyo, gidek" türü kelimelerin analiz edilip formal şekillerine dönüştürülebilmesi için mekanizmalar hazırlandı. Bu mekanizmanın kapsamını ilerki sürümlerde arttırmayı düşünüyoruz.

Diğer mod ise türkçeye özgü harfleri ihmal eden analiz mekanizması. Bu şekilde "kisi" kelimesi "kişi, kışı" çözümleri bulunabiliyor.

Yeni analiz modları için dokümantasyonu inceleyebilirsiniz.

Bu sürümde önceki sürümlerdeki API'yi bozan değişiklikler de oldu ve bazı hatalar giderildi. Eğer projeyi kullanıyorsanız güncelleme yapmadan değişiklik listesini incelemenizi öneririz. Bu sürümde yardımı olan herkese, özellikle morfoloji hatalarını bildiren Müge ve lm modelindeki problemi gideren bojie'ye teşekkürler.



31 May 2016

Bilgisayar Mühendisliği


Ekşisözlük'teki bilgisayar mühendisliği tanımlarına bakınca, "bilgisayar mühendisi mimar, programcı ameledir", "utp kablo takmayı bilmezler", "temeli hardware'dir", "programlamayla alakası yoktur", "bilgisayar bilimlerinden farklı bir şeydir", "asıl işi işlemci tasarlamak" gibi saçmalıklar arasında kayboluyorsunuz.

Bu da şaşırtıcı değil çünkü bazı hocalar ve mezunlar bile bu yanlış fikirleri yaymaya devam ediyor.

Bilgisayar Mühendisleri Odası'nın şu kuruluş raporuna bakın:

Meslek Alanında Yaşanan Tahribat (sayfa 9): ...sektör kamu ile akademiden ziyade serbest piyasa koşulları içinde büyümüş... kamusal düzenleme olmaması (yüzünden) ülkemiz salt tüketici konumda kalmış... bilgisayar mühendisleri teknoloji ve bilim dünyasında çığır açan çalışmalara imza atmak yerine kod yazan kişiler olarak kalmışlardır.

Bu metni yazan ve okuyan hiç kimsenin aklına, "silikon vadisinde çığırları açanların kamu düzenlemesi mi vardı?", "serbest piyasa hakimiyetindeki Amerika, bilişim tüketicisi konumunda mı?" ya da "Knuth, Tarjan, Sedgewick gibi teorik araştırmacılar bile her gün kod yazıyorken bizim bilgisayar mühendislerinin ayağına bu niye bağ oluyor" gibi çok basit sorular gelmemiş anlaşılan!

Bu bilgi kirliliğine engel olmak için bazı kavramları temelden açıklamak gerekiyor.

Bilgisayar Mühendisliği

Bir çok ülkede Computer Science (Bilgisayar Bilimi) olarak geçen bölümdür. Bir uygulamalı matematik alanıdır. Temel problemleri: neleri hesaplayabiliriz (karmaşıklık, quantum), nasıl hesaplayabiliriz (algoritmalar, veri yapıları, yapay zeka, diller ve derleyiciler) ve neyle hesaplayabiliriz (bilgisayar mimarisi, ağlar, sistemler) olan bir bilim dalıdır.

Türkiye'de bir mühendislik bölümü olarak açılmasının nedeninin devlet kadrolarında mühendis olmayanların teknik kadro sayılmasının zorluğu ve yüksek maaş alamamaları olduğunu düşünüyorum.

Mühendislik iki anlamda kullanılabiliyor: Bilimsel bilginin bir şeyler geliştirmek için kullanılması ile bir profesyonel meslek dalı. Birinci anlamın bir sakıncası yok. Örneğin bir problemin çözülmesi için bir program geliştirmek bir mühendislik çalışması olarak görülebilir.

İkinci anlamda ise sıkıntı büyük. Profesyonel mühendislik, tıpkı doktorluk ya da tesisatçılık gibi bir meslektir. Denetime bağlıdır, mesleği yapanlar bir oda ya da kuruma kayıtlı olmak ve belli yeterlik şartlarını yerine getirmek zorundadır. Bunun amacı da, örneğin evinize patlama riski olan bir doğalgaz borusu bağlanmasını ya da iki inşaat mühendisinin aynı bina için farklı statik hesapları vermesini önlemektir.

Böyle bir durum bilgisayar mühendisliği için iki nedenden anlamsız. Birincisi bu bir profesyonel meslek değil, bir bilim dalı ve bu bilgiye herhangi biri sahip olabileceği gibi kendi başına her türlü amaçla da kullanabilir. İkincisi ise yaratıcılığa ve çeşitliliğe açık bu alanda, şu iş bu şekilde yapılır gibi meslek kurallarını üretecek bilgiye sahip değiliz. Evet, bazı tasarım kalıpları (design patterns), ve yazılım geliştirme teknikleri (test tabanlı geliştirme, sürüm kontrolü, vb) icat ettik ama hâlâ genel problemi çözebilmiş değiliz. Bu iş bir bilim olduğu kadar aynı zamanda bir sanat da. Şirketlerin diplomaya sertifikaya değil kendi mühendisleriyle yapılacak mülakata bakmasının altında da bu yatıyor.

Bilgisayar Bilimcisi Program Yazmaz mı?

Bu saçma fikrin savunulmasının ardında diplomayı aldıktan sonra yan gelip yatarak para kazanma beklentisi var herhalde.

Araştırmacılar için hipotezlerini test etmenin, modellerini incelemenin önemli bir yolu program yazmak. Bazen teorileri ispatlamanın bir yolu bile olabiliyor.

Endüstride ise program yazmayacağım diyen adamı görüşmeye bile çağırmazlar. Google, Microsoft, Apple gibi şirketlerin herhangi bir pozisyonuna girmek için iş görüşmesinde bile program yazmanız gerekiyor.

Bir kişi analiz yapacak, diğeri tasarım yapacak, kalanlar da tasarımdaki fonksiyonları yazacak modeli 60'larda kaldı. Yazılım geliştirme, yazılımların artan karmaşıklığı ile birlikte çok daha dinamikleşti. Tasarım, gerçekleme, test ve hata ayıklama ayrı süreçler değil artık. Takımlar, hiyerarşi yerine birlikte çalışan uzmanlardan oluşuyor.

Elini kirletmeyen biriyle hiç kimse çalışmaz. Okulda ödev olarak yazdığı programlar dışında bir deneyimi olmayan adamın zaten tasarım bilgisi de olamaz. Dahası, bu işlerden bir kaç yıl kopmuş birinin bile tasarım becerisi hızla düşmeye başlar.

Okullu mu Alaylı mı?

Bir başka saçma tartışma. Genelde bu tartışma teorik bilgi mi yoksa pratik bilgi mi gibi yanlış bir düzleme de çekiliyor. O yüzden ikisine de bakalım.

Örneğin elindeki dosyalardan bazı bilgileri tarayıp istatistiksel bir sonuç çıkarmak isteyen bir kişiye Python ile basit betikler yazmaya yetecek kadar bilgisayar bilimleri bilgisi yeterli olabilir. Benzer şekilde bir felsefeci hiç programlama öğrenmeden yalnızca karmaşıklık teorisini çalışarak kendi alanında ihtiyaç duyacağı bilgilere kavuşabilir.

Karşılaşılan herhangi bir problemi çözebilecek genel bir program yazma yeteneği ya da bilgisayar bilimleri alanında yeni bilgiler keşfedebilecek bir araştırma yeteneği için ise üniversite eğitimi programında yer alan hemen her konuyu öğrenmek şart.

Bilgisayarlar bir çok katmandan ibaret. Algoritmalar, kitaplıklar, diller, işletim sistemi, işlemci, transistörler, elektronlar. Bu katmanların hangi seviyesinde çalışırsanız çalışın altınızda kalan kısımlara bağımlısınız. Dolayısıyla işinizi daha iyi yapabilmeniz altta neler döndüğünü bilmenize bağlı.

Teorik ve pratik bilgiden biri daha üstün diyemezsiniz. Daha iyi bir algoritmayla kazandığınız teorik hızı, o algoritmanın işlemci önbelleği kullanımı daha kötü olduğu ve veri setiniz yeterince büyük olmadığı için geri kaybedebilirsiniz örneğin.

Bu bilgileri nereden ve nasıl öğrendiğiniz değil, öğrenmiş olmanız önemli. Dahası dünyanın en iyi üniversitelerinde bile okusanız, işlenen konular ve yaptığınız ödevler sizi bu alanda uzman yapmaya yetmeyecek.

Orko der ki...

Eskiden İstanbul'da her kahvede, satrançta o kahvedeki herkesi yenmiş ama başka birileriyle oynamadığı için Kasparov'u yenerim ben diye böbürlenen tipler vardı.

Ne iş yapıyorsanız yapın, o alanda dünyanın en iyileri kimse onları bulun ve onları tanımaya ve geçmeye çalışın. Bilgisayar alanında bir şeyler keşfetmiş her araştırmacının, günlük yaşamda kullandığımız ürünleri yapan her geliştirici ve girişimcinin, Internet üzerinde blog'ları, sunumları, ders videoları, makale ve kitapları var.

Hayatında büyük ölçekli bir ar-ge projesinde yer almamış, eski ders kitaplarından okuduğu arkaik tanımları öğreten hocaları, yaptığı e-ticaret sitesi ya da muhasebe programıyla kendini girişimci sananları, yabancı dilden yarım yamalak çevirilerle kitap yazanları, forumlarda iki üç soru cevapladığı için büyük üstat havalarına giren tipleri ciddiye almayın.

Yoksa yukarda alıntıladığım kişiler gibi kendi küçük mağaramızda dışardaki dünyanın gölgeleriyle oyalanır dururuz.



04 February 2016

One of The Largest Events in Europe: FOSDEM



This year, I've been attended Fosdem for the first time. Fosdem is one of the largest events of free software and open source world that happens every january, gathering thousands of the developers (+5000) in Brussels. It is great opportunity to get in touch with the developers of world's leading organisations.

Fosdem has really strong infrastructure to satisfy needs of the attenders.
I've attended the event through Episkey Limited Company's travel fund which is part of Cottange Labs. I've seen the converisation on the mailing list and said if there is any other company that supplies travel fund please let me know because Google have not published scholarship for Fosdem and I could not find another company. Emanuil Tolev has volunteered since 2011 for Fosdem. He replied me and said me and my coworkers would like to sponsor for a person. Then we started a private thread and solved sponsorship requirements. I am thankful for travel grant to Emanuil and Episkey Limited developers.

First day of the event, I've met with Michel, he works as Linux Kernel developer at Intel. We took coffe and talk little. Talking with the kernel developers makes me happy and I really feel very excited. After the meeting, I've discovered the event place, it was at Brussels University, ULB Campus, Solbosh. Fosdem is biggest event that I've attended untill now.

In general, I've joined Main Track sessions. Rspamd is one of my favorites. Vsevolod Stakhov is developer of Rspamd, he told project stages quite clear.

Libreboot and Frosted Embedded Posix OS are my favorites as well. I love to learn about low level software that's why I contribute Linux Kernel. I am former Linux Kernel at Outreachy and would like to keep contribution.

There was an Embedded Systems DevRoom, it was in Building U. I should say, location of the building is hard to find little because there was no sign about Fosdem front of the building. We could not see at least.

In the evening, I've met with my Turkish friends. We have a community photo:


Second day, I've met with Emanuil to talk face to face. He said, I really am glad to sponsor you. That's great to hear.

I've bought tshirts to donate the organisations. It is really great, I am happy to be part of free software and to move it forward.


There was a talk for in memory of Ian Murdock. I would have loved to attend it but I had to leave early because had a flight in the evening. Talks are stored here so far. This is great opportunity to watch the presentation later.

I am very happy about my first Fosdem experience because I improved my network recognizing great folks.

I've seen on the event brochure, it says 8000 developers attended! and you can see diversity at the event. Hope to improve diversity and see underrepresented groups in computer science.

Fosdem is a free event, you can attend without registration. We should donate individualistically or institutionally, if we woud like to see the event in future years.

Avrupa'nın En Büyük Etkinliklerinden: FOSDEM



Bu yıl ilk kez Fosdem'e katıldım. Fosdem; Ocak ayında, Brüksel'de düzenlenen, 5000'den fazla katılımcısı olan (etkinlikte dağıtılan kağıtta 8000 yazıyordu), Özgür Yazılım ve Açık Kaynak dünyasının en büyük etkinliklerinden biri.

Fosdem gidip görmeyi çok istediğim etkinliklerden biriydi. Hazır vizem varken Fosdem'e katılmak harika olurdu ve öyle de oldu. Aslında Fosdem'de kısa konuşmaya başvurup, burs alarak katılmak gibi bir planım vardı. Google ve Fosdem'in sayfalarında burs verdiklerine dair bir şey göremedim. O süreçte bu konuşma üzerinden burslardan bahsedildiğini gördüm. Bir süre bekledikten sonra, listeye burs vermek isteyen bildiğiniz başka şirketler var mı? Ben bulamadım. diye yazdım. Fosdem'de gönüllü olarak çalışan Emanuil Tolev yardımcı oldu. Episkey Limited şirketi olarak bu yıl bir kişiye burs vermek istiyoruz dedi. Sonra özelden bir konuşma başlatarak bursu hallettik. Üstelik burs oldukça dolgundu (725€) ve geri ödeme şeklinde değil, etkinlikten önce aldım. Brüksel'de Cuma-P.tesi kalmayı istemiştim ama cuma gecesi ve pazar akşamı şeklinde oldu. Olsundu, etkinlik harikaydı :).

Kısa konuşma başvurum kabul edildi ama ben iptal ettim. Çünkü Outreachy sayesinde tanıdığım birkaç çekirdek geliştiricisiyle görüşme planı vardı ve aynı gün iki heyecanı kaldıramazdım :). Zaten Brüksel'de nefes almaya vaktim kalmadan geçeceği için bu konuşmayı başka zamana erteledim.

İlk gün ben olay mahallini kavrayıp, planladığım kişilerle görüşünceye kadar öğlen oldu. Etkinlik Brüksel Üniversitesi, ULB Kampüs'ünde birkaç binaya yayılmıştı. Binalar arasındaki mesafe çok fazla değil ama peş peşe sunumlara farklı binalarda girmeye yetecek kadar da değil.
İlk gün sunumlara yetişemiyorum yha diye bir miktar homurdandım ancak akşama kadar aynı binada olmaktansa arada başka binalara giderken temiz havayı solumak çok mantıklı :).

Yemek için H binasının ara geçişinden gidilebilen bir kafe var. Sandviçler 3€ ve büyük, ton balıklı olan çok güzeldi. Bir de kampüsün içerisinde karavanlarda satılan sandviç, kızartma, waffle ile yeme ihtiyacını karşılamak da mümkün. Aynı zamanda veganlar için açılan ayrı bir karavan var.

K binası ana bina, Main Track'ler orada yapılıyor ve büyük organizasyonların çoğu orada stand açıyor. Standlardan bardak, atkı, stres topu, polar hırka, havlu, şemsiye, çanta .. ne koymuşlarsa satın alarak organizasyonlara bağışta bulunabilirsiniz. Ben bursum bol olduğundan dilediğimce aldım diye düşünürken, Arda tüm standları topladı :). Arda, Open Media odasında sunum yaptı. Ben yine mükemmel zamanlamamla kaçırdım. Aslında kaçırmadım, ben gittiğimde kapının üzerinde kocaman FULL yazıyordu. Bir de Tuna arguman.org hakkında konuşma yaptı.

Fosdem'e yakın zamanlarda yapılan Fosdem Fringe adında bir oluşum var, farklı organizasyonlar kendilerine özel etkinlik düzenliyorlar. Gülçin Yıldırım Fosdem PGDay'de sunum yaptı, biz öncesinden Fosdem'de görüşmeyi planlamıştık. İlk günün akşamı etkinliğe katılan birçok Türkle görüşme fırsatım oldu. Bu da fotoğrafımız:

Sadece bu kadar değildik, ikinci gün üniversiteden arkadaşlarımla buluştum. Şu an Kartaca'da çalışan ekip, toplanıp Fosdem'e gelmişler. Onlarla görüşme fırsatı bulmak harikaydı. İkinci gün aynı zamanda Emanuil ile görüştüm. Bana burs vermiş olmaktan çok mutlu olduklarını söyledi.

Bunlar da etkinlikten aldığım tişörtler. Suse'li olanın üzerine sanırım PostgreSQL çantasının rengi geçti :(. Etkinlik günleri oldukça yağışlıydı, benim bile rengim geçmiş olabilir :p.


Bu da gördüğünüz gibi Perl'ün devesi :).


Katıldığım sunumlar ise pek az ama çevremi genişlettiğim bir etkinlik olduğu için hiç sorun değil. Benim hazırladığım program kayınca, katılmak istediğim sunumlarda da kocaman FULL yazınca Main Track'tekileri dinlemeye karar verdim. Ian Murdock'un anısına bir konuşma vardı, uçağa yetişmek için pazar öğleden sonra olmadığımdan katılamadım. Konuşmaların kayıtları aynı zamanda burada tutuluyor. Eski arşivlere bakmak isterseniz de burası.

Girdiğim sunumlardan en beğendiklerim, Libreboot ve Embedded POSIX OS oldu. Gnu Guile'ı çok merak ediyordum, baştaki sunumlara girmeyince sonradan katılmak biraz balıklama oldu. Gnu Guile bir programlama dili ve Fosdem'de organizasyonlar kendilerine Dev Room'lar ayırabiliyorlar. Gnu Guile'ın da bir odası vardı :).

Rspamd'yi tanıtan arkadaş projenin adımlarını çok güzel açıklamıştı. Fark ettim de, en çok alt seviye yazılımlarla ilgili şeyler dinlediğimde mutlu oluyorum.

Bir de aklınızda bulunsun, Brüksel'de taksiler çok pahalı. Gece on birde binip, 20 dk ancak yol gittik ve 50€ verdim. Gündüz de çok fark etmedi, 42€ verdim. Sonra sordum, lüks taksiye mi bindim acaba neden bu kadar pahalı? Tüm taksiler aşağı yukarı aynıymış. Dublin'de hava alanına gitmek için Air Coach'lar var ve 7-10€ arası. Taksiyle giderseniz hava alanı o kadar uzak olmasına rağmen merkezden tutan miktar 20€. Söyleyeceklerim bu kadar :p.

Fosdem, ücretsiz katılınabilen bir etkinlik. Eğer anahtar imzalamaya katılmayacaksanız etkinlik öncesi kayıt tarzı bir şey yapmanız gerekmiyor.

K ve H binasında Fosdem tişörtlerinden alarak ya da almadan Fosdem'e 25€dan başlayarak bağışta bulunabilirsiniz. Bu güzel etkinliğin bu şekilde devam etmesini istiyorsak, şirketler ya da bireyler olarak destekleyelim.

28 November 2015

CV Hazırlama Üzerine Tavsiyeler


Geçtiğimiz günlerde WomENcourage Konferansı'na katılmıştım. Etkinlikteki kariyer fuarında İntel'in standına uğradım. Standdaki çalışanlarla tanışıp, hangi alanlarda çalıştığım hakkında konuşma fırsatı buldum. Standa şu anki açık pozisyonlarından bir kısmının çıktısını alıp, gruplara ayırarak koyduklarını gördüm.

Standda Bev ile iletişime geçtim. Etkinlik akşamı güncel cv'mi ona gönderdim. Bunun üzerine bir Skype görüşmesi ayarladık. Bana sıkı çalışmışsın ama proje detaylarını (amacı, önemi, yararı vs.) yazmamışsın dedi. Bu yüzden cv'min insan kaynaklarında çalışan birine açık olmadığı belirtti.

Bunun üzerine Google Doc belgesi açarak orada cv'mi baştan yazmaya başladık. Açıkçası kendimi tanıtırken etkili cümleler yazmak konusunda pek yetenekli değilim ve bu zamana kadar bunun çok da önemli olmadığını düşünüyordum (hala bir miktar öyle düşünüyorum :p). Bev de bunu fark ettiği için bana çok yardımcı oldu.

Bev'e ilk gönderdiğim cv'yi buradan inceleyebilirsiniz. Birlikte hazırladığımız cv ise burada. Özellikle yurtdışında bir yere başvuruyorsak şu anki konumumuzu belirtmeliyiz. Eski cv'me ek olarak: Profile, Key Skills and Experiences, Project History alanlarını ekledik ve Professional Experiences kısmına açıklamalar yazdık.

Profile kısmında; kendimi kısaca tanıtıp, ilgi alanlarımı belirttim. Key Skills and Experinences kısmında çalıştığım alanları alt başlıklara ayırıp, hangi görevleri üstlendiğimi yazdım. Project History kısmında ise sahip olduğum deneyimleri nasıl kazandığımı yazdım. Şimdi şurada çalışıyorum, daha önce şuralarda çalıştım şeklinde. Bev'in Red Hat'te çalışan bir arkadaşı var. Söylediğine göre o arkadaşı cv hazırlama konusunda çok iyiymiş. Bana yardım etmek için arkadaşıyla iletişime geçeceğini söyledi. Bir süredir arkadaşından gelecek cevabı bekledim (hala bekliyorum) :). Bir aya yakın bir zaman geçince bu yazıyı artık yayınlamam gerektiğini düşündüm. Zaten Bev de cv'min bu halinin eskisine göre çok daha iyi olduğunu söyledi.

Cv'de sen bu cümleleri nasıl hazırladın diye soracak olursak, Bev bir şey yazamadığımı görünce İntel'in iş ilanlarına (ya da başka bir firma) bakarak, kendinde oradaki gibi ilgi çeken cümleler kurabilirsin dedi, zaten yazmama Bev de yardım etti. Yani başvuracağımız şirketin tanımlarına bakıp oraya çok uygunmuşuz gibi cümleler kuruyoruz :p

Cv'de olması gereken diğer şeyler; telefon numarası, kullanmıyorsak bile bir github hesabı linki (mülakata almak için github hesabı olmasına bakan firmalar var), yaptığımız sunumlar varsa onları da eklemeliyiz.

Günlük tutuyor olmak iyi bir cv için gerçekten önemli. Günlükte teknik konularda yazmak, kişinin nasıl öğrendiği, nasıl çalıştığı, hangi yolu izlediği, sonuca nasıl vardığı hakkında karşı tarafa bilgi veriyor.

Bev bana WomENcourage gibi katıldığın başka önemli etkinlik var mı diye sordu, varsa onları da eklememi söyledi.

Eğer hakkında bir miktar bilgimiz olan ama çok uzun süre çalışmadığımız konular varsa "I am familiar with .." şeklinde yazmak gerçekten çok mantıklı :). Geçtiğimiz yıl bir yerde denk gelip görmüştüm.

Yukarıda linkini verdiğim eski cv'yi Rik'le birlikte, Red Hat başvurusu zamanında hazırlamıştım. Bu zamana kadar ne zaman cv hazırlamam gerekse hep gel cv'ni birlikte hazırlayalım diyen birileri oldu. Bu konuda çok şanslı olduğumu düşünüyorum. Bev'le birlikte ilk kez bir İK çalışanıyla cv hazırlamış oldum.

Bev'in arkadaşından da tavsiyeler alırsak bu yazıyı güncelleyeceğim. diff'ini alıp paylaşırım :)

19 October 2015

WomENcourage Konferansı - 2015


Geçtiğimiz günlerde İsveç'in Uppsala kentinde düzenlenen WomENcourage etkinliğine katıldım. Neden WomENcourage, anlatsana biraz diye sorarsak açalım. Bir süredir Google'ın seyahat bursu verdiği etkinlikleri bu sayfadan takip ediyorum. Beğendiğim etkinlikleri not edip, uygun zamanlarda bursa başvurarak katılmak gibi bir planım var (aslında beğenmediğim etkinlik yok ama naparsın :b). WomENcourage isminden de anlaşılacağı gibi gitmeyi çok istediğim bir etkinlikti. Ancak bu sene LinuxCon'a katılacağım için WomENcourage'a başvurmaktan vazgeçmiştim. LinuxCon 5-7 Ekim'de İrlanda'da, WomENcourage 24-26 Eylül'de İsveç'te oldu. İkisine farklı vizeler gerekiyor ve vize almaya zaman yetmez diye düşündüm.

Bu düşüncelerden birkaç hafta sonra  Google'ın Dablin'deki ofisinden bir eposta aldım. Epostanın içeriği şu şekilde: Daha önce iş arkadaşlarımla görüştüğün için senden haberdar oldum, biz bu sene WomENcourage konferansı için burs vermeye başladık. Başvurmak ister misin? Buradan anladığım kadarıyla geçen sene Dablin ofisine iş görüşmesine gitmemden dolayı tanıdığı söylüyor. İlgili yazı için bknz.: Google Mülakatları

Şansımı denemek için teklifi kabul edip, başvurdum. Başvuru formunda cv dosyası, linkedin hesabı istiyorlar. Herhangi bir soru çözme, kod yazma gibi bir şey yok. Birde hayatta en çok gurur duyduğunuz, heyecanlandığınız proje nedir ve neden en çok onunla gurur duyuyorsunuz gibi bir soru vardı. Ben Outreachy aracılığıyla yaptığım Linux çekirdeği stajımı yazdım.

Başvuru sonuçları açıklandığında bursa kabul edildiğimi öğrendim \0/. Peş peşe iki vize başvurusu gerektiğinden süre yeter mi diye kaygılandım ama her şey beklediğimden daha iyi gitti :). Google seyahat bursunun içeriği şu şekilde, etkinlik için bilet + 1000€'ya kadar masraf bedeli. Herhangi bir fiş sunma zorunluluğu olmadan bu bedeli veriyorlar (ama yinede fişleri ödemeyi alana kadar saklamamı istediler). İsveç için verdikleri burs: konferans bileti + 800€ oldu.



Etkinliğin ilk günü hackathon ve kariyer fuarına katıldım. Ben vardığımda Hackathon'da gruplar ve projeler belli olmuştu. Ben de sayıca az olan bir gruba eklendim :). Projemizin konusu gaz sızmasını en erken şekilde tespit edip, insan hayatını korumaktı. Bunun üzerine proje tasarımı, sunumu ve basit bir simülasyonunu yaptık. Simulasyonu Edison Board kullanarak gerçekleştirdik. Hackathon'da çok yaratıcı olan başka projeler vardı. Düştüğümüzde kimseden yardım alamayacağımız durumlar için uygulama ve şehirde bisiklet sürümünü daha güvenli hale getirmeyi amaçlayan uygulama aklımda kalanlardan.















Kariyer fuarında Googlçalışanlarıyla tanışarak burs kazananlara hediye edilen çantayı aldım. Charlie beni Mine'yle tanıştırdı. Mine, Google'ın Londra ofisinde çalışıyor. Orada bizden birilerini görmek gerçekten çok sevindirciydi. Sadece bu kadar değil, Bilkent Üniversitesi'nden Reyyan hoca etkinliğin organizatörlerinden! Birde Uppsala'da yüksek lisans yapan Tuğçe ile tanıştım. Tuğçe, bilgisayar bilimlerinde yüksek lisans yapıyor. Etkinlik akşamı, orada yüksek lisansın nasıl gittiği hakkında konuşma fırsatımız oldu.


Fuarda Intel'de çalışan bir kadınla tanıştım. Bana eposta adresini verip kendisiyle iletişime geçmemi istedi. Bugünlerde onunla görüşüp cv hazırlıyorum, bana bu konuda danışmanlık ediyor. CV hazırlamayla ilgili kısa bir yazı yazmayı düşünüyorum.

Google'da çekirdek seviyesinde çalışmak istersem genelde android tarafında iş bulabileceğimi öğrendim. Birde eğer yurtdışında yüksek lisans / doktora yaparsam, muhtemelen burslu yapacağım, bu konuları konuşabileceğim birkaç kişinin eposta adresini aldım.

Etkinliğin asıl amacı insanların tanışıp, çevre edinmesi olduğundan çok yoğun sunumlar yoktu. En çok beğendiğim sunumlardan biri Facebook'ta çalışan kadının yaptığı sunumdu. Benim de hala aklıma şanslı olduğum için işe alındım, benden başka başvuran kimse yoktu o yüzden aldılar gibi düşünceler geliyor ama aslında öyle değil. Kendime bir şeyleri yaptım, başardım ve alındım diyorum dedi.

Bir diğer sunum ise Anita Borg bursuyla doktora yapan arkadaş oldu. O da alınmayacağını düşündüğü için ilk senesinde bursa başvuru yapmadığını, daha sonra başvurup alındığını söyledi. Bu seneki burs miktarı 7000€ imiş. Üstelik burs sadece doktora için değil, lisans ve yüksek lisansta da başvurulabilen bir bursmuş (sadece doktora için sanıyordum ^_^).

İsveç'te güzel anılar gibi güzel diyebileceğim günler geçirdim. Gezmeye vakit bırakmak için birkaç gün fazla kaldım. Boş olan günümde trenle Stokholm'e geçtim. Tam bir harikaydı. Şehre aşık oldum. Gamla Stan'ı beni buraya gömün diyerek gezdim. City Hall de kesinlikle görülmesi gereken yerlerden. Viking Kuleleri'ne asansörsüz çıkarken yaşanacak durum gerçekten harika. İnsanı sayamadığım kadar yıl öncesine götürüyor :).

Uppsala ve Stockholm'de çektiğim fotoğraflara buralardan bakabilirsiniz.

Stokholm'den sonra LinuxCon için Dablin'e gittim ve sunum yaptım ^_^. Onu da bir yazımda paylaşacağım.






13 September 2015

XFS Filesystem has duplicate UUID – can’t mount


Gerek müşterilerimiz gerekse kendimizin AWS üzerinde barındırdığımız sanal sunucularımızda klasik olarak RHEL 7 kullanıyoruz. Red Hat ve türevlerinin 7 sürümü ile birlikte default olarak gelmeye başlayan XFS dosya sistemi ile formatlanmış diskleri farklı sunuculara mount etmek istediğiniz zaman – ki böyle bir durum özellikle AWS için problematic sistemlerin ebs disklerini recovery amacı ile bir başka ec2 instance’ına bağlamak sureti ile cereyan eden bir durumdur – aşağıdaki mount hatası ile işlem başarısız olabilir:

mount: wrong fs type, bad option, bad superblock on /dev/xvdf2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Bu durumda detay almak için aşağıdaki komut ile

 journalctl -k

komutu ile kernel tarafından üretilen loglara baktığınızda sistem üzerindeki iki disk bölümünün aynı uuid’ye sahip olduğu gerekçesi ile mount işleminin yapılamadığını belirtir aşağıdaki hata mesajını görürsünüz:

[  789.411840] XFS (xvdf2): Filesystem has duplicate UUID 6785eb86-c596-4229-85fb-4d30c848c6e8 - can't mount

Bu durumda önünüzde iki seçenek bulunuyor.

Birincisi diski aşağıdaki örnekte olduğu gibi nouuid parametresi ile mount etmektir:

# mount -t xfs -o nouuid /dev/xvdf2 /disk2

Bu yöntem disk üzerinde herhangi bir değişiklik yapmadığı için özellikle ilgili diski ilgili sisteme geçici olarak mount edecekseniz ilk tercih edilebilecek yoldur.

İkinci opsiyon ise, ilgili disk için aşağıdaki komut ile yeni bir uuid üretip diski bu şekilde mount etmektir:

# xfs_admin -U generate /dev/xvdf2
# sudo mount /dev/xvdf2 /disk2/ -t xfs

Bu şekilde disk sorunsuz olarak mount edilecek ve erişilir duruma gelecektir.



10 September 2015

Git'te Yama Uygularken Oluşan Çakışmaları Çözmek



Yazma iznimizin olmadığı depodaki projeye katkı verme işlemini yama dosyası oluşturarak yaparız. Yama dosyaları karşı tarafa yaptığımız değişiklikleri insan okuyabilir şekilde özetler. Bu konu hakkında kısa bir yazı yazmışım, buradan bakabilirsiniz.

Github üzerinden geliştirdiğim kendi projelerime olan katkıları kabul ederken terminal kullanmadan, web sayfası üzerinden hallediyorum.

Linux çekirdeğinde her takım farklı alt dizinlere baktığından ve çoğu github kullanmadığından işlemleri konsol üzerinden yapmak gerekiyor.

Linux çekirdeğinde uzunca bir süredir büyük bir yama  setini kabul ettirmeye çalışıyorum. İnsanlık için küçük olabilir ama benim için büyük demeden geçmeyelim. Yamanın konusu özetle bellek üzerinde büyük bir baskı olduktan sonra swapten dönerken, ihtiyaç duyulmayan sayfaları da swapten belleğe getirip büyük sayfa oluşturarak, performans sağlamak.

Bu yama uzun bir sürece girdiğinden, linux çekirdeği sürekli güncelleniyor ve benim değişikliklerim deponun eski halindeki gibi kalıyor. Bu durumda karşı taraf uygulamaya çalışırken çakışma oluşacak, yama bu nedenle reddedilecek.

Eskiden hep küçük değişiklikler yaptığımdan ve daha kısa süreçte bittiğinden, kendi yamamı güncel depoya uygulama ihtiyacı duymadım. Her satırı tekrar kontrol ederek yeniden oluşturuyordum. Yama büyük olduğunda işler böyle olmadı. Her satırı tekrar oluşturmak çok zor ve derlemede hata almıyorsam bile mantıksal hata yapma ihtimalim çok yüksek.

Değişiklikleri uygulamadan önce git apply --check yama_dosyası şeklinde yamanın uygulanabilir olup olmadığını kontrol edebiliriz. Eğer git apply yama_dosyası komutunu verirsek, yamayı commit yapmadan depoya ekler. Bu durumda değişiklikler commitlenmediği için de git diff ile farkları görebiliriz. Bu bize yama dosyasını ekleyip, commit yapmayarak elle başka değişiklikler yapmaya olanak verir. Tüm değiştirmek istediğimiz dosyalar bittikten sonra kendimiz git commit -a komutuyla değişiklikleri loglayabiliriz.

Yamanın commit yapılarak depoya eklenmesini istiyorsak git am < yama_dosyası şeklinde uygulamalıyız.

Eğer daha önceden yaptığımız commitlerde düzenlemeler istiyorsak git rebase harika bir araç. Onunla ilgili daha önceden bir yazı yazmıştım, buradan bakabilirsiniz.

Yama uygularken geçenlerde karşılaştığım durum, yamanın (muhtemelen) güncel depoyla uyumlu olmamasından kaynaklıyordu. Hata aldığım makine çok sık kullandığım bir makine değildi, belki daha önceki başka bir şeyden kaynaklanıyor da olabilir. Hata mesajı şu şekilde:

Applying: mm: add tracepoint for scanning pages
error: include/trace/events/huge_memory.h: already exists in working directory
error: patch failed: mm/huge_memory.c:2673
error: mm/huge_memory.c: patch does not apply
Patch failed at 0001 mm: add tracepoint for scanning pages
The copy of the patch that failed is found in:
   /home/ebru/linux-stable/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Bunu görünce daha önceden aynı commitler depoda vardı, bu yüzden bir yerde indeksleri tutuluyor düşündüm. mv linux-stable/.git/rebase-apply ..path/ ile rebase-apply dizinini başka bir yere taşıdım. Tekrar yamayı uygulamaya çalıştım yine aynı hatayı aldım (kaldırdığım dizin tekrar oluştu).

Bunun çözümü şu şekilde hatayı aldıktan sonra, git apply linux-stable/.git/rebase-apply/patch --reject komutunu veriyoruz. Bu sayede yamanın çakışma oluşturmayan kısımları depoda oluşturuluyor.

Checking patch include/linux/mm.h...
Checking patch include/trace/events/huge_memory.h...
error: include/trace/events/huge_memory.h: already exists in working directory
Checking patch mm/huge_memory.c...
Hunk #1 succeeded at 30 (offset 1 line).
Hunk #2 succeeded at 2270 (offset 53 lines).
Hunk #3 succeeded at 2307 (offset 53 lines).
Hunk #4 succeeded at 2319 (offset 53 lines).
Hunk #5 succeeded at 2327 (offset 53 lines).
....
       ........
Hunk #13 applied cleanly.
Hunk #14 applied cleanly.
Hunk #15 applied cleanly.
Hunk #16 applied cleanly.
Rejected hunk #17.
Hunk #18 applied cleanly

Bu şekilde uygulanan/uygulanamayan kısımları özetliyor. Uygulamada sorun oluşturan her dosya için uygulanamayan kısımları dosya_adı.rej uzantılı diff dosyası oluşturarak bize gösteriyor. Bu dosyaları git status ile bakarsak görebiliriz. Bu süreçte depo aslında rebase etme gibi git apply sürecinde oluyor. Yamanın uygulanmayan kısımlarına .rej uzantılı dosyalardan bakıp, kendimiz dosyaları açıp değişiklikleri yapıyoruz. git status ile tekrar bakıp eklememiz gereken dosyaları git add ile ekledikten git am --resolved ile işlemi sonlandırıyoruz. Bu şekilde çakışma oluşan yama dosyalarını depoya uygulamış olduk.

Çakışma çözme işlemini bu yazıdan okuyarak öğrendim. Umarım benim yazım da faydalı olmuştur.



11 August 2015

Red Hat'te Linux Çekirdeği Geliştiriciliği


Geçtiğimiz kış Outreachy'de Linux çekirdeği üzerinde, Red Hat'te çalışan Rik van Riel'in danışmanlığında staj yaptım.

Staj bitiminde Rik istersen Red Hat'te birkaç pozisyona başvur, ileride seninle birlikte çalışmak isterim dedi. Aslında birkaç sene daha Türkiye'de kalma kararımı Google görüşmesinden sonra vermiştim ama Red Hat'te çalışma düşüncesi de geri çevirilemez bir şeydi, o yüzden kabul ettim.

İlk önce jobs.redhat.com adresinde ilgimi çekebilecek olan işlere baktım. Rik deneyimli çalışan aradıklarını söyleseler bile, yeni başlayan pozisyonunda da iş bulabiliriz dedi. Open Stack, Sanallaştırma ve Arm işlemciler için çekirdek geliştirimi olarak 3 farklı pozisyona başvurdum. Bu üç pozisyon üzerinde de hiç deneyimim yok ancak daha uygun pozisyonlar bulamadım. Zaten onlar da deneyimi olmayan eleman alacaklarını biliyorlardı.

Open Stack ekibi İstanbul'dan taşınman gerekir, bu gibi durumlarda deneyimsiz geliştriciler yerine kıdemli olanları tercih ediyoruz ama sen şansını deneyip mülakatlara gir dedi. Sonrasında kıdemli elemana daha çok ihtiyaçları olduğunu belirttiler, diğer görüşmeleri yapmadık.

Sanallaştırma ekibi aynı zamanda Rik'in çalıştığı ekip. KVM ve Qemu'yu geliştiriyorlar. Sanallaştırma pozisyonu için öncelikle başlangıç görüşmesi yaptık. 2 hafta sonrasına gün belirleyip ilk mülakata girdim. En fazla teknik soruyu ilk mülakatta aldım, sorular zor değildi. Glassador'dan okuduğum kadarıyla Red Hat için soruları zor olmuyor yazıyordu. İlk görüşmede spinlock, zamanlama gibi temel çekirdek kavramlarından sordu. Yeni bir konu olsa da gerçek zamanlı algoritmalar üzerinde yorum yapmamı istedi. Üniversitede en sevdiğim dersler, staj projemde neler yaptığım, bir yamayı kabul ettirene kadar en fazla kaç sürüm gönderdiğim, stajda kabul edilen yamaların çekirdeğin kaçıncı sürümünde olduğu, Rik'le nasıl çalıştığım, kodlamaya nasıl başladığım .. şeklinde devam eden staj sürecimin her evresinden sorular aldım. Görüşme sonunda bir sonraki adıma geçtiğimi öğrendim \0/.

Sonraki adım 5 farklı mühendisle görüşmeyi içeren bir paket gibi. Bu görüşmelerin hepsi aynı günde olmak zorunda değil ve her biri yaklaşık 50 dk sürüyor.

Red Hat görüşmeleri Google'ınki kadar zor değil ve görüşme zamanlarını istediğimiz kadar geniş bir süreye yayamıyoruz. İki görüşme arasındaki süreyi Google pek önemsemezken, Red Hat'teki arkadaş senin yerine başka birini işe alabilirler, bu yüzden görüşmelere ne kadar erken girsen o kadar iyi demişti.

Diğer görüşmeler çok az teknik soru içeriyordu. Genelde stajda neler yaptığım üzerine konuştuk. Bir gün iki görüşmeye birden girdim. O akşam pek yorucuydu diyebilirim. Birde Google görüşmelerinde bu kadar heyecanlanmadım. Sanırım 3. görüşmeden sonra normal heyecanda konuşabildim.

Son görüşmeyi Rik'in içinde bulunduğu takımın yöneticisi olan bir kadınla yaptık. Tüm görüşmeler içindeki tek kadındı. Görüşebileceğim en yüksek mercideki kişiydi.

Son görüşme çok eğlenceli geçti. Bir iş görüşmesinden ziyade bir arkadaşımla konuşuyormuşum gibiydi. Teknik sorular yok denecek kadar azdı. Çanakkale'den, şimdiki işimden, neden çekirdek üzerinde çalıştığımdan, Türkiye'den taşınma durumumdan konuştuk.

Bu görüşmeden bir iki hafta sonra Red Hat'te işe alındığımı öğrendim, Brno'da çekirdek geliştiricisi olarak çalışacaktım.

Birkaç aydır pek iyi değildim, rahatsızlığım zirveye ulaştığında doktora gittim. Şimdilik çok ciddi bir rahatsızlığım yok ancak İstanbul'dan taşınmaya yetecek kadar da iyi değilim, ülkeyi değiştirmek zaten zor bir durum .. Ben bu kararsızlıklar içerisindeyken Red Hat'e de bunu söyledim, taşınmam 4 ay sürer, ben birkaç ay daha geciktirsem gitmeyi derken Red Hat'ten gelen maaş teklifi çok az oldu. Birde taşınma masraflarını zaten karşılamıyorlar. Bir iki firmadan duyduğum kadarıyla taşınma konusunda çok yardımcı olan yerler de var ..

Brno netten gördüğüm kadarıyla pahalı bir yer değil, ancak Red Hat'in €1k'nın biraz altında maaş teklif etmesine şaşırdım. Mezuniyetten sonra bir seneye yakın bir zaman evden çalıştım ve bu zamanı çok da fazla karşılık almayarak geçirdim. Başarılı projelere bu şekilde katkı vermek bir süreliğine benim için kabul edilebilir bir şey. Ancak bunu yurtdışındayken ve sağlığım da şuan için çok iyi değilken kabul etmedim.

Aslında Red Hat kabul etmediğimde evden çalışmayı teklif etti, kabul ettim ancak sonrasında yeni başlayanların bir sene boyunca ofiste çalışması gerektiğini ve ilk yıldan sonra evden çalışma izinlerinin olduğunu söyledi. Neticede maaş ve rahatsızlığım nedeniyle kabul etmemiş oldum. İk'daki arkadaşa Brno'da çalışmayı İstanbul'da birkaç sene çalıştıktan sonra olsaydı kabul ederdim, dedim. Daha sonraki bir zamanda eğer çalışmak istersem kendisiyle iletişime geçmemi istedi.

Bugünlerde kendime iyi bakıp, daha sağlıklı yaşayarak hayatımı düzene oturtmaya çalışıyorum. Zaten öğrenciyken de yaşama şeklimi değiştireceğim diyerek kendime bu sözü vermiştim. Ben bu sözü tutmaya başlamadan önce, vücudum bana uyarıyı verdi :p. Aslında çok önemli şeyler değil ama çok geç saatlere kadar uyanık kalmamak, az tuzlu yemek, sağlıklı beslenmeye çalışmak gibi okul temposundan sonra daha normal koşullarda çalışmayı düşünüyorum :).

Yurtdışına yine giderim, sonraki zamanlarda karşıma daha iyi koşullarda başka fırsatlar çıkar diye ümit ediyorum.

25 May 2015

Google Mülakatlarına Hazırlanma Süreci


Geçen yaz Google ik'dan (insan kaynakları) profilinizi linkedin, github ve birkaç listeden inceledik kabul ederseniz başlangıç bir görüşme yapmak isteriz içerikli bir e-posta aldım. 2 gün sonra başlangıç telefon görüşmesini ik ekibinden bir arkadaşla yaptık. Görüşmenin 45-55 dk arası sürmesi bekleniyor, benim bir saati biraz geçmişti. İlk görüşmede kod yazmamı gerektirecek bir şey sormadılar. Veri yapıları, ağ bilgisi, bit düzeyinde işlemler, algoritmalar ve karmaşıklıkları, bash komutları, sistem çağrıları, süreçler hakkında sorular geldi. İlk görüşmede tanışma, ilgi alanlarını öğrenme, hangi işler üzerinde uğraştığın hakkında bilgi edinme gibi kısımlardan da konuşulduğu için teknik değil olarak adlandırıyor ancak bence gayet teknikti :). Görüşme sonunda, ilk adımı geçtiğimi öğrendim.

Daha önce bir iş tecrübem olmadığı için bir alan seçmem gerekiyordu, telefondaki arkadaş Site Reliability System Engineering (SRE) ve Software Engineering olmak üzere 2 pozisyon sundu. Bilgilerin sistem tarafı için daha uygun istersen SRE seç şeklinde öneride bulundu. SRE görüşmelerinde daha başarılı olacağımı düşündüğümden onu seçtim.

Başlangıç görüşmesinden önce çok gerildim, zaten nasıl konuşacağım kısmı ayrı bir olay :). Soruları bitirdikten sonra, görüşmeyi yapan arkadaş diğer adımlar için tavsiyelerde bulundu, sorular üzerinde sesli düşün, eğer ne sorulduğunu anlayamadıysan bilmiyorum deme, anlayana kadar sorman sorun değil, dedi. Çünkü söylediği bir kelimeyi anlayamadığımdan bilmiyorum demiştim, anlamadığımı fark etti ve gtalk'a sorunun bir kısmını yazdı ve cevapladım :).

İkinci görüşmeyi bir mühendisle yine telefon üzerinden yaptık. Kodlama soruları için google doc kullandık. Görüşme yine 45-55 dk arasıydı. Soruların neredeyse hepsi çalıştığım sorulardı ancak düzenli ifadelere çok fazla çalışmaya vaktimi yetiremedim. Görüşmede son soru basit split, join işlemleriyle çözülebilecekken suçluluk psikoljisi ile düzenli ifadelerden çözülmesi gerekiyor sandım :). Çözüme yaklaştım ancak çoğu şeyi göz ardı ettik, ben ifadeleri karıştırdım gibi şeyler oldu. Görüşme sonunda mülakatı yapan arkadaş, bu görüşmenin büyük kısmını harika yaptın dedi. Bir an şok olmamla birlikte havaya uçup geri oturdum :).

Google'ın mülakatlarına hazırlanırken aşağıdaki linklerden yararlandım. Bunlar dışında deneyimler üzerine yazılmış çok fazla blog yazısı bulabilirsiniz. Hepsini okumak belki mümkün olmaz ama çoğunu okuyun gerçekten çok faydalı oluyor. Mühendislerle yaptığım görüşmeler ik'daki arkadaşla yaptığım görüşme kadar eğlenceli geçmedi. İk'da olan arkadaş görüşme sırasında harikasın, çok iyi gibi sürekli destek olarak ve çok sevecen bir şekilde konuşuyordu. Ancak mühendisler süreci soğuk, sadece soru soran ve cevap bekleyen bir şekilde geçiriyorlar. Okuduğum bir blog yazısında telefonda problem olduğu için Skype'a geçmek zorunda kalan bir arkadaş mühendis soğuk ve sıkılmış görünüyordu yazmıştı. Bu yüzden telefondaki soğuk tavırları hiç üzerime alınmadım :), sadece en sonda tebrik eden bir ifade duydum.

Siteler: Geeks For GeeksGlassadorCareerupCracking Code InterviewsSystem DesignDevops Interview Questions.

3. mülakat için yeniden tarih belirledik. Genelde 3 er hafta arayla yaptık görüşmeleri. İlk iki görüşmem iyi geçtiğinden sonuçlarını hemen öğrenmiştim, normalde bir haftayı bulabiliyor. Görüşmelerin arasını çok uzatmak bence iyi değil, sonuna kadar gidebileceğimizi düşünürsek insan bunalabilir. 3 hafta gayet iyi bir süreç. Zaten görüşme 45 dk sürüyor, en fazla kaç soru sorabilir diye görüşmeden önce kendimizi rahatlatmak da bir yöntem :). Birde hazırlanırken süremi bir hafta kadar tanım sorularına çalışarak, bir hafta kodlama sorularına çalışarak sonraki hafta bunları karmaşık tekrar ederek geçirdim.

3. görüşme görüntülü olacaktı ancak ne olduysa yine telefon üzerinden yaptık. Bu görüşmede sorular beklediğim gibi değildi. Temelde bir soru sorup, diğer soruları aynı soru üzerinden türetti. Görüşmenin nasıl geçtiğini anlamadım, soyut şeyler üzerinden benim daha önce deneyememiş olacağım şeyler üzerinden konuştuk. O zamanlar her görüşmenin bitiminde sonucu söylüyorlar sandığımdan bu adımı geçebildim mi? diye sordum, henüz bilmiyorum cevabını aldım :). Bir hafta sonra geçtiğimi öğrendim.

Buradan sonraki adım Google ofisinde yapılması gereken görüşme. Yine ik'daki arkadaş önce aradı sonra aynı bilgileri e-posta ile gönderdi. Birkaç Google pozisyonu önerdi, Dublin'de olanı seçtim, Dublin aynı zamanda Google'ın Avrupa'daki ofislerinin merkezi. Vize işlemleri nedeniyle ve benim gideceğim haftada Dublin'de etkinlikler olduğundan, son görüşmeyi 1,5 ay kadar ertelemek zorunda kaldık :(.

Son mülakat 45'er dakika şeklinde ve 5 oturumdan oluşuyor. Her oturuma 1 ya da 2 mühendis girebiliyor. Son oturumu SRE takımının yöneticisiyle yaptık ^_^.

Son aşama gerçekten çok heyecanlıydı. Uzaktan yapılan görüşmeler sırasında sesin kesilmesi problemi çok oluyor. En sonunda duyamıyorum, sesin kesiliyor dediğimde google doc'a soruyu yazdıkları olmuştu. Yüzyüze görüşmede çok hızlı konuşurlarsa diye sıkıntım vardı ancak öyle olmadı. Google çalışanları konuşma konusunda diğer şirketlere göre çok daha anlayışlı. Oldukça anlaşılır konuşuyorlar.

Konuşma pratiği yapmak için dil kurslarına gitmek faydalı, birde Google SRE ekibinin düzenlediği etkinlikleri youtube'dan çok rahat bulabilirsiniz. Ben onları izlemiştim, hem birkaç anahtar kelime öğrenmemi sağladı hem anlamamı geliştirdi.

Mülakatın yapılmasından bir gece önce Dublin'deydim. Sabah ik'daki arkadaş istersen otelden seni alayım, yürüyerek gayet yakın dedi. Kabul ettim, çok yağmurlu bir sabahta ofise birlikte gittik. Her oturumdan sonra 3-5 dk beklemek gerekebilir, bu sürelerde eğer odada yalnız kalırsam dışarı çıkmamamı ve henüz çalışan olmadığım için ofiste tek gezmememi söyledi.

Son görüşmede soruların çoğunluğu çalıştığım yerlerden çıkmadı. Bu kadar sorulmaz ya dediğim ve ayrıntısına inmediğim şeylerden çıktı. Açıkçası hiç beklememiştim. Daha önce bir yerde de öyle soruları görmedim :(. Basit sorulan sorular da vardı elbette ama geneli değildi. Çok iyi veri yapıları soruları bekliyordum, hiç sormadılar :|.

Ancak sürecin tamamı çok heyecanlı ve cesaretlendiriciydi. Yüzyüze yaptığımız görüşmelerdeki arkadaşlar da çok sevecendi, bir soğukluk yoktu :). Birde yurtdışına ilk seyahatimi Google sayesinde yapıyor olmam da çok mutluluk vericiydi.

Google'ın sizle görüşmek isteriz şeklinde e-posta atması için sadece bir github hesabımız olması bile yeterli. Çünkü onlar da yeni insanlar tanıyıp, onları görüşmelerine hazırlamak istiyorlar.

Üniversiteden "olmadı sanırım .. olduğu kadar :(" şeklinde hissederek mezun olmuştum, bunun üzerine Google görüşmesinin bu kadar ilerlemesi çok iyi oldu, çok da güzel oldu :). Mezuniyetimden sonra 7-8 ay boyunca kadar her şey böyle karmaşık ve heyecanlı bir şekilde ilerlerdi. Bir hafta önce bundan sonrası şöyle olur muhtemelen dediğim şeylerin hiçbiri tutmadı :), şimdi tekrardan her şey düzene girdi. Bundan sonrasında yine Linux çekirdeği üzerinde devam edeceğim. Belki bir gün yine Google ile görüşebiliriz :).

Dublin'de 2 gece kaldım ve çok gezemedim. Bir dahaki sefere daha fazla kalabilirim diye düşünüyorum. Dublin'de çektiğim fotoğraflar için buraya bakabilirsiniz.

26 April 2015

Linux Stajı Sonucunda



12 Mart sonunda Outreachy (OPW) kış dönemi stajları sona erdi. Ben bu süreçte bellek yönetiminde, THP (transparent huge page) kodları üzerinde çalıştım. Birlikte çalıştığım danışmanımın istersen bir süre daha birlikte çalışmaya devam edebiliriz demesiyle şimdi hala devam ediyorum :).

Staj sürecinde sadece okunur sayfalar, sıfır içerikli sayfalar (zero page, bellekte henüz eşleme yapılmamış sadece okuma isteği almış ve veri içermeyen sayfa) ve swap cache üzerinde çalıştım. Swapteki veriler için birini stajdayken diğeri stajdan sonra olmak üzere iki yama hazırladım. İkisininde ortak yanı do_swap_page kısmında takılıyor olmaları ^_^. Sistem bazen askıda kalıyor, bazen boot aşamasında bile bir panik oluyor gibi problemleri var hala. Koddaki sayaçların değerini daha iyi görebilmek için tracepoint yazdım. Tracepointi de ayrı bir yama olarak göndereceğiz. Askıda kalma problemleri için en iyi yöntemler ise serial console ya da netconsole kullanmak. Geçen gün Sarah Sharp'ın günlüğüne bakarken burada bir netconsole yazısı gördüm :). Askıda kalma olayı genelde spinlocklarda bir hata yaptıysak oluşuyor.

Outreachy'de, Linux Vakfı kendi stajerlerini 5 dakikalık kısa konuşma yapmak için Linuxcon'a davet ediyor. Ben Dublin'de olana katılacağım, Seattle'da olan biraz fazla uzak. Zaten bu ara hangi etkinliğe gitmek istesem hep Dublin'e denk geliyor, aslında ben mümkün olduğunca başka şehirler seçmeye çalışıyorum :).

Nisan başında lwn.net'te stajımla ilgili bir yazı yayınlayacaktık, yazının taslağı hazır, sanırım swaplerle olan işler bittikten sonra onları da ekleyip yayınlayacağız.

Bu staja alınmam benim için biraz sürpriz gibi oldu. Necdet hocanın hadi Ebru başvursana demesiyle başvurdum ve çok iyi oldu, çok da güzel oldu :).

Mezuniyetimden beri evden çalışıyorum, bu biraz değişik oldu. Muhtemelen bir ay daha evdeyim, sonra bir süre çekirdeğe ara verip başka işlere bakıp, sonrasında tekrar döneceğim :). Çekirdek üzerinde çalışmanın diğer alanlara göre daha fazla dikkat gerektirdiğini düşünüyorum. Çünkü bir yerde hata yaparsam o değişikliği geri almak daha uzun sürüyor, daha fazla şeyi kontrol etmem gerekiyor.

Staj sürecimde işini çok iyi yapan insanlarla birlikte çalıştım. Rik, 12 senedir Linux üzerinde çalışıyor. Bunun ilk duyduğumda bir yutkunma .. :).

Aslında üniversiteye başladığımdan beri hep işini çok iyi yapan, hayran olduğum insanlarla bir aradayım. "Harika insanlarla birlikte çalıştım" diyebilmek, bu hayattaki en güzel şeyler arasında ilk sıralarda yer alır. Çomü'de bilgi işleme gitmeye başladığımdan beri ben de bu sözü söyleyebiliyorum ve iş hayatında da böyle devam eder diye ümit ediyorum :).

17 April 2015

Linux Çekirdeğine Tracepoint Eklemek


Linux kaynak kodunda değişiklik yaptıktan sonra, bunları izlemek için farklı yollar var. Ben henüz çok değişik bir şey kullanmadım. Bu zamana kadar hep printk ile kern.log'a aktarıp, sonra grep, wc, tailsplit gibi komutlarla inceleme yapıyordum. Aslında çok farklı şeyler kullanırım sanmıştım :) ama danışmanım ilk olarak bu yöntemi önerdi.

kern.log'u incelemek sandığım kadar rahat olmuyor, her adımda kodun patlamadığından emin olmalıyım. Bu yüzden bir sürü şey yazdırıyorum, gerçi panik olduğunda otomatik olarak loglara düşüyor ama bazı askıda kalma durumlarında düşmeyedebilir. Birde her testten sonra log dosyasını boşaltıyorum sonra içinden bir şeyler parse etmek zorlaşıyor, sadece 1 test için dosya boyutunun 15M olduğunu hatırlıyorum. kern.log'u boşaltmak için bir yöntem olarak "sudo tee /var/log/kern.log < /dev/null", bunu kullanabiliriz. Hiç boşaltmadan test yapmaya devam ettiğimde dosya boyutu .. ^_^. Elbette inceleme yapılamayacak kadar büyük oluyor diye bir düşüncem yok ama zorlaştırmasak iyi olur.

Uzunca bir süredir yaptığım değişikliklerde beklenmedik sonuçlar görüyorum, aslında beklenmedik sonuçlar görmek elbette en beklendik şey :P, ilk zamanlar test yaparken her testte farklı bir sonuç görürdüm. Danışmanımın emin misin bunu gördüğüne, o zaman şunu da ekle demesine neden olmuşumdur, sonra başka bir testte ben yanlış bakmışım problem o değilmiş şeklinde döndüğüm çok olmuştur :). Ancak bu sefer öyle olmadı, ben uzunca bir süre hep aynı beklenmedik sonucu aldım. Bu durumda oluşabilecek ihtimaller, 1- ben yanlış bakıyorum, 2- pteleri swapten çektiğim halde hala bir şeyler onların swapte gibi loglanmasına neden oluyor, bunun nedeni belleği mantıklı kullanmak ya da tekrar swape gitmesi gerekirse daha az işlem yapmak istemeleri olabilir.

Test yaparken 800M'lık verinin üzerindeki değişimlere bakıyorum, büyük sayfalar 2M olarak tutuluyor. Tek bir büyük sayfa için 512 kere (normal sayfalar 4kB) döngü yapılıyor, benim de her döngüde 15 satıra yakın yazdırdığımı düşünürsek, bu durumda loglarda gözümden bir şey kaçmamıştır demek pek mümkün değil :). İşte tam bu gibi problemler için tracepoint'ler var.  Tracepoint eklediğimiz her fonksiyon için bir kez çalışıyor, aslında değişkenlerin son değerini, kodun sonuna printk ekleyerek de yazdırabiliriz. Ancak bu yöntem boş yere kern.log'u dolduruyor ve kendi testlerimiz için eklediğimiz printk'lar ile birlikte upstream'e yama gönderemeyiz zaten, yani göndermesek iyi olur :). Tracepointler; printk ekledim, eklemeyi unuttum (bir daha derle), upstreame göndermeden önce printk'ları kaldır bir daha derle - test et gibi şeyleri önlüyor. Tracepoint kodu yazıyoruz ve bir kere derliyoruz, sonra eğer o değişkenlerin değerine bakmak istersek perf aracı ile testleri çalıştırıyoruz ve değerleri görüyoruz :).

Tracepoint Nasıl Tanımlanır?

Daha önceden tanımlanmış tracepoint kodlarını inceleyebiliriz. Birde lwn.net'te çok açık anlatan yazılar var. Örneğin vmscan.c'deki birkaç fonksiyon için tracepoint ekleyeceğiz. Bunun için  include/trace/events/'de vmscan.h dosyası oluşturmalıyız. Tracepoint yazmak için yapmamız gerekenler: 1) temel tanımlamaları yapmak, 2) TRACE_EVENT() tanımlamak, 3) TRACE_EVENT içerisinde belirttiğimiz fonksiyonu kaynak kodda çağırmak.

#undef TRACE_SYSTEM
#define TRACE_SYSTEM vmscan

#if !defined(_TRACE_VMSCAN_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_VMSCAN_H

TRACE_EVENT(....
                             .....
);

#endif /* _TRACE_VMSCAN_H */
#include <trace/define_trace.h>

Şimdi TRACE_EVENT() içeriğini tanımlayalım:
TRACE_EVENT(name, proto, args, struct, assign, print)
name: Kaynak kod içerisinde çağırılacak fonksiyonun adı.
proto: Fonksiyon için prototip.
arg: Fonksiyonun alacağı değişkenler.
struct: Tracepoint içine geçen verilerin depolanması için yapı.
assign: Değişken ataması yapmak için kullanılıyor.
print: Değişkenleri yazdırmak için kullanılıyor.

Yazdırmak istediğimiz değişkenler sadece struct shrinker *shr ve unsigned long lru_pgs değişkenleri olsun:

TRACE_EVENT(mm_shrink_slab_start,
    /* proto */
    TP_PROTO(struct shrinker *shr, unsigned long lru_pgs),
    
    /* arg */
    TP_ARGS(shr, lru_pgs),

   /* struct */
    TP_STRUCT__entry(
        __field(struct shrinker *, shr)
        __field(unsigned long, lru_pgs)
    ),

    /* assign */
    TP_fast_assign(
        __entry->shr = shr;
        __entry->lru_pgs = lru_pgs;
     ),

     /* print */
     TP_printk("shr = %p,  lru_pgs = %ld",
                       __entry->shrink,
                       __entry->lru_pgs)
);

TRACE_EVENT içerisinde mm_shrink_slab_start şeklinde belirttiğimiz fonksiyonu, vmscan.c dosyasından, önüne trace_ ekleyerek bu şekilde çağırıyoruz: trace_mm_shrink_slab_start(shr, lru_pgs); Bu değişkenler için sırasıyla proto, arg, struct ve assing'ı tanımladık. Daha sonrasında print ile yazdırma kısmını ekledik.

vmscan.h dosyasının tüm içeriğine buradan bakabilirsiniz. Dosya içerisinde event_class, define_event gibi tracepoint'leri gruplayarak tekrara düşmeyi önleyen makrolar kullanılmış. Ben henüz bunlara gerek duymadım. Tracepoint kullanmak için yukarıda belirttiğim 3 temel maddeyi yapmak yeterli.

                   http://lwn.net/Articles/379903/


06 April 2015

Sparse Nasıl Kullanılır?


Sparse, Linux çekirdeğine katkı verirken kullanılabilen araçlardan biri. Linus Torvalds tarafından yazılmış statik kod denetleyicisi ve bir süredir de bakımını Josh Tripplett yapıyordu.

Normalde çekirdek derlemesi yaparken almadığımız hataları/uyarıları Sparse'ı etkinleştirerek alabiliriz. Peki Sparse bize ne tür hatalar döndürüyor? Makro kullanımlarındaki yanlışlıklar, tip dönüşüm hataları, static & extern gibi anahtar kelimelerin kullanımlarında yanlışlık varsa ya da bir fonksiyon üretildiği ve hiç kullanılmadığı durumlarda uyarı veriyor.

Kurulum için sparse paketini kurmak yeterli ya da depodan çekerek de kurabiliriz. Temel kullanımı ise şu şekilde: make C=2 drivers/staging/wlan-ng/ 

Sparse'ı kullanabilmek için çekirdek hakkındaki en temel veri tiplerini, makrolarını bilmek gerekiyor. Eğer static, extern ifadelerindeki kullanımları düzeltmek gerekiyorsa o fonksiyonların nerelerde çağrıldığına, hangi başlık dosyasında tanımlandığına bakıp düzeltme yapmak gerekiyor. Ben sparse'ı ilk kullanmaya başladığımda bu yazıyı okumuştum, zaten okumamla birlikte oldu o zaman, beni evden beklerler demem bir olmuştu :). Sparse ile katkı vermeye başladığımda da artık beni evden beklemiyorlar demeyi unutmadım tabi ^_^.

Sparse kullanırken veri gösterimlerindeki hataları da alabiliriz. Eğer driver Makefile dosyasında endian kontrolleri etkinleştirilmediyse, sparse kullanırken  make C=2 CF="-D__CHECK_ENDIAN__"  drivers/staging/wlan-ng/  şeklinde bayrağı aktif etmeliyiz.

Verileri big endian ya da little endian şeklinde göstermek tasarımcıya göre değişen bir şey. Veri biçminde anlaşabilmek için işlemcinin kullandığı yerel biçimden driverın kullandığı biçime dönüş yapmak gerekebiliyor. Bunun için cpu_to_le16(), ya da le16_to_cpu() fonksiyonları var. Bu fonksiyonlar little endian 16 bit olan veriler için. Veri gösterimiyle ilgili fonksiyonlara buradan ulaşabilirsiniz. Birde burada örnek var, gayet yararlı olduğunu düşünüyorum :). Burada temel problem fonksiyonların aldığı değişkenler ya da atama işlemlerinde meydana gelen tip uyumsuzlukları. Bu gibi durumlarda değişkenin tipini değiştirmek ya da dönüştürme işlemini kaldırmak gerekiyor. Ya da driverın özelliklerinden ve kodu inceleyerek, veri aktarımı olurken hangi biçime dönüştürülmesi gerektiğini anlayabiliriz. Ağlarla ilgili olan driverlarda big endian gösteriminin kullanılması gibi.

Couchbase 2.x İçin nagios-plugin-couchbase Güncellemesi


nagios-plugin-couchbase, iki yıl önce Necdet Yücel'in düzenlediği Yakından Eğitim ile ortaya çıktı. Bu projeyi Kaan'ın danışmanlığında geliştirdim. Daha önce kullanmadığım Nagios, Couchbase'i kullanmam ve NoSQL kavramlarını öğrenmem bakımından oldukça faideli bir proje olmuştu :).

Projeye ilk başladığımız zamanlar geliştirimi Couchbase 2.0 üzerinde yapıyordum. Şimdi Couchbase 2.x serisi kararlı halde ve 3.0'ın beta aşamasındalar. Ben de eklentiyi güncelledim ve artık Couchbase 2.x ile uyumlu diyebiliyorum :).

Eklentiye birkaç yama gönderilmişti onları aldım, bir de her güncellemede yeniden .cfg oluşturması uzun sürmesin diye örnek bir dosya ekledim. Bu arada proje aynı zamanda nagios-exchange'de de yer alıyor ^_^.

Bu projeyi geliştirmemi sağlayan Yakından Eğitim ekibine teşekkürler.

04 March 2015

Sending First Patch To Upstream


Last week, I sent first patch to upstream and it was accepted in mm tree :). I am very happy about that. You can see it here.

Subsystem maintainers are very careful and a lot of people review the codes. Out side of staging directory, and before the internship, my first patch is about y2038 project. When I sent patch for y2038, a lot of developers reviewed and suggested something. I have recently seen the patch here: http://lwn.net/Articles/620870/, it was my first experience :).

Todays, I work with linux kernel mm community, this makes me very excited and happy :).  I gained some experiences in this process and learnt how can I be sure with my changes. This is most important case for coding. When I talked with my mentor, every time I reported different thing :) and said "oh this prevents collapsing pages into a thp!". Because I was testing wrong. Finally I could find what was the problem.

For test results, I look /var/log/kern.log, it is very large file so I split it like that: "split -n 5" and look newly created small files and log time stamps is important. To be sure with my changes print out virtual memory address area for my test programs.

/proc/pid/smaps shows whole vmas for the process. pr_info("vm_start = %04lx\n", vma->vm_start); is enough to see begining address of the vma. Sometimes I need to see which process run this function, I print out current->pid. If I know what happened in every step, I find my faults very easy. I have to do something like that, because other processes will log about their huge pages in kern.log and I shouldn't confuse which process logged the results. To examining kern.log was big scale thing for me.

Before sending patch I need to be careful and check something for my patch. Also keeping focus on the issues is important. Working on kernel needs to pay attention more accorrding to other projects which I got experiences with them when I was student.

After this patch, I will work on zero pages and discover new things :).


Linux Kernel Ekibiyle Staj


Geçtiğimiz yaz haziran sonunda mezun oldum. Mezuniyetten sonra bir işe girip çalışmak, her gün işe gidip gelmek, birkaç ay işim dışında bir şeye bakmamak, sonrasında iş temposuyla birlikte neler yapabileceğime karar vermek gibi bir düşüncem vardı. Ancak tabi ki böyle olmadı :).

Ağustos başında Google İrlanda ofisinden iş görüşmesi için e-posta aldım, benim ile başlangıç bir telefon görüşmesi yapmak istediklerini söylediler. Hemen kabul ettim. İlk üç aşamayı geçtim, son görüşme için Irlanda'ya gittim ancak son görüşmede başarılı olamadım. Sorular beklediğim gibi değildi, internetten çalıştığım gibi de değildi.

Ben evde son görüşmeye hazırlanırken Gnome OPW için başvurular da başlamıştı. Ben daha önce ilk Gnome'un araçlarına sonra da Linux Kernel'a başvurmuştum. Gnome'a katkı verirken katkı vermek için masaüstü bilgisayarınızda ortam oluşturmak zor. En son Fedora 19'un alfa sürümünü kullanmak zorunda kalmam ve alfanın hiç kullanışlı olmaması üzerine katkı vermeyi sonlandırdım :). Aslında jhubild'de kullanabiliriz ama onda ortamı hazırlaması .. bana bir tane geliştiricisi o zamanlar Fedora beta sürümü varken, beta kullanmamı önermişti, beta yine kullanılabilirdi ancak bir sonraki sürüme geçtiklerinde alfa kullanmak zorunda kalmam pek iyi olmadı. Bir de Gnome Continuous var, onu yeni gördüm ama henüz denemedim.

Linux Kernel'a katkı verdiğim sene aslında alınmayı beklemiştim gerçekten ama olmadı. Bu dönem başvuru süresi 2 ay gibi uzundu :), geçen sene 3 hafta gibi bir süreydi. Necdet hoca "Aslında sen başvursan çok şey yaparsın" dedi, ben de başvurdum ve alındım :). Alınmayı gerçekten beklemiyordum ve çok güzel bir sürpriz oldu.

Şimdi Rik van Riel ile birlikte bellek yönetimi üzerinde çalışıyorum. Bellek yönetimi katkı vermeye başlamanın en zor olduğu kısımlardan biri, çünkü çekirdeğin temel fonksiyonlarını içeriyor ve daha karmaşık. Başvurduğunuz projeye göre staj sürecinde ne kadar yama gönderebileceğinizin sayısı da değişiyor. Ben projem zor olduğundan, 4 ayda otuz satır yazabilir miyim derken şimdiden bir yamayı kabul ettiler bile :).

Linux kaynak kodunda bellek yönetimi ile ilgili dizin mm/. Eğer güncel mm dizinini takip etmek istiyorsak da Linus Torvalds'ın kullandığı dalı değil de linux-next'i takip etmek gerekiyor. Yamaları Andrew Morton kabul ediyor ve günlük olarak etiketliyor. Güncel linux-next'i nasıl takip edeceğinizi görmek için buraya bakabilirsiniz.

Anladığım kadarıyla, Linux'ta bellek yönetimi üzerine çoğunlukla Redhat ekibi bakıyor, çünkü birçok sunumu ve belgeyi o ekip hazırlamış. Ben yamaları gönderirken mm dizini bakıcılarına baktığımda genelde @redhat.com alan adlı hesaplar var. Yamaları vger.kernel.org ve  [email protected] listelerine gönderdiğim için de çok mutluyum. O kadar büyük listelerdeki insanların kodlara bakıyor olması oldukça heyecanlı :).

Üzerinde çalıştığım proje ise, bellek üzerinde 2kB/4kB kadar boyutlarda olabilen sayfaların dışında bir de büyük sayfalar (huge page) var. Onların boyutları ise 2MB/4MB. Peki neden büyük sayfalara ihtiyaç duyuyoruz? Çünkü sayfalar büyük olduğunda sayfa tabloları da büyük oluyor ve bir süreç için verileri bellekten atma/belleğe getirme miktarı azalıyor. Eğer sayfalar 4MB'tan büyük olursa verimsiz oluyor.

Sistemin swap kullanması gerektiğinde büyük sayfalar normal boyutlu sayfalara parçalanıyor (2kB/4kB) ve o şekilde swap alanına yerleştiriliyor. Sorun şu ki; swap alanından belleğe tekrar geri getirilmek istendiğinde büyük sayfa olarak değil, normal boyutlu sayfalar olarak getiriliyorlar bu durumda eski verim sağlanamıyor, aynı zamanda burada izlenmesi gereken bir algoritmaya da karar verilmeli. Çünkü bir süreç swap kullanıyor diyelim, ve swapte olan bir veriye ihtiyaç duyuldu, sadece tek bir verinin bulunduğu sayfa 2kB, ancak bunun yerine 2MB büyük sayfa getirmek her zaman yararlı olmaz. Burada karar verilmesi gereken noktalar var.

Geçtiğimiz dönem kod ve belge okumak üzerine geçti. Bir tane de yama gönderdim. Sadece okunabilir sayfaları büyük sayfalar şeklinde birleştirmek için. Yamayı burada görebilirsiniz.

Bundan sonraki bir süre ise; "daha önce hiç okuma/yazma isteği almamış, henüz fiziksel belleğe eşlenmemiş, sadece sanalda bulunan, bir süre sonra ilk kez okuma izni aldığında fiziksel belleğe eşlenen sayfalar" var, bunlara zero page deniliyor, bunlar üzerinde çalışacağım. Eğer sayfa içerisinde veri yoksa, ilk okuma isteği aldığında çekirdek bunu sıfırlarla dolu bir sayfa olarak üretiyor. Bunları da büyük sayfalara dahil etmek üzere çalışacağım. Aynı zamanda (emin değilim), Documentation dizininde de belgelendirme yapmam gerekecek. Muhtemelen birkaç işim daha var ancak henüz ben bilmiyorum, danışmanımla işleri bitirdikçe yenisini alma şeklinde ilerliyoruz. Henüz başlamadığımız işlerden de şuna bir ara bakarız şeklinde konuşuyoruz.

Staj sürecinde birkaç Türkçe yazı daha yazacağım (yazmadı) :).


01 March 2015

Richard Stallman - Telif Hakları Sunumu


Bu sene Stallman Türkiye'ye geldi. İstanbul'da iki sunum yaptı ve Bilmök'te bir sunum daha yapacak. Etkinlik hakkında bilgi için buraya bakabilirsiniz.

Ben Sabancı Üniversitesi'nde yapılan Telif Hakları konuşmasına katıldım. İlk defa bu kadar büyük bir insanın yaptığı konuşmaya katıldım, çok mutluyum. İstanbul Avrupa tarafında oturmam ve etkinliğin Tuzla'da olması nedeniyle 09:30da yola çıktım ama olsun :). Sabah Kadıköy'de Gülçin ile buluşup servisle etkinliğe gittim. Bu kadar zaman sadece sosyal ağlardan konuşma fırsatı bulduğum insanlarla yüz yüze görüşmek de heyecanlı oluyor.

Etkinliğe muhtemelen kapılar kırılır, ortalık yıkılır düşüncesi ve Necdet hocayla (ve ekibiyle) daha fazla vakit geçirmek için bir saat erken gittim. Necdet hocayı ve arkadaşlarımı görme kısmı tamamdı ancak böyle bir etkinlikte dolup taşıp oturmaya yer olmaması gibi bir durum beklerdim, olmadı. Salon doluydu ancak yine de beklediğim hararet yoktu.

Stallman konuşurken "bu konuda en mantıklı böyle düşünebilirdi" düşüncesi aklımda oluştu. Aslında Necdet hoca da bize okulda yıllardan beri Stallman'ın felsefesinden, görüşlerinden bahsediyor. Stallman konuşurken "Necdet hoca da bize bunlardan bahsetmişti" şeklinde hatırladım. Stallman'ın bize bahsettiği noktalar:

- Özgürlük nedir? Özgürlük yazılım açısından nedir?
- Özgürlük kod içeriği şöyle olmalıdır, böyle güvenli olmalıdır, gibi şeyleri göz önüne almaz, kullanıcının onu değiştirebilmesi, dağıtabilmesi anlamına gelir
- Özgür olmayan yazılımlar oluşturulmamalıdır
- İnsanların sahip olduğu yazılımları paylaşma hakları ellerinden alınmamalıdır
- Eğer bir sistem içerisinde özgür olmayan başka yazılımlar da varsa o sistem özgürlüğünü kaybeder

Bunun dışında tersine mühendislik hakkında da güzel şeyler söyledi. Üniversitelerde ders olarak verilmesi gerektiğinden bahsetti. Bir de Torvalds hakkında da .. :(. Bu ara Linux Vakfı'nda staj yaptığımdan yine de öyle demesek mi şirinliğinde dinledim :). Torvalds'ın Gnu projesini de kullanarak bir çekirdek oluşturduğunu ve Gnu içerisinde bir boşluk oluşup Linux'un geliştirildiğinden bahsetti.

Etkinlik başlarında Gnu is not unix şakası oldukça döndü. Bu cümleyi ilk okuduğum zamanı dün gibi hatırlıyorum. 2. sınıftayken Gnu ne acaba diyip What is gnu yazdığımda gördüğüm ilk cevap Gnu is not unix olmuştu. O zamanlar çok yeni olduğumdan "hmmm .. Pek anlamadım, bir daha okuyalım, Gnu is not unix .. hmm ..". O halim de pek şirindi ;).

Etkinliğin sonlarına doğru Gnu peluş oyuncak açık artırmaya sunuldu ve sahibi elbette ki Necdet hoca oldu. Aslında yedi kişi bir Gnu'ya girsek de olabilirdi ama .. :).

Açık artırmadan sonra dinleyicilerin sorularına yer verildi ve soranların bir kısmı Stallman'ın aslında iddia etmediği şeyleri sanki Stallman öyle düşünüyormuş gibi sordu. Düşünceler hakkında böyle düşünmek de yanlış olmaz mı, ya da şöyle düşünebilir mi şeklinde sorulmasını anlarım ama salonda ben haklıyım şeklinde yapılan konuşmalar vardı. Stallman'ın buna verdiği cevap beni dinlemeye gelenler bana katılmayabilir ne yapabilirim oldu :).

Etkinlik çıkışında Necdet hoca ve öğrenci/mezun grup birlikte vakit geçirdik. Dün Kaan'ın da söylediği gibi ben biraz neşe saçmış olsam da çok güzel bir gündü. Aşağıda etkinlikten fotoğraflar, Stallman ile topluca fotoğraf çektirdik :)







04 February 2015

Uyap Döküman Editörünün linux sistemlerde çalıştırılması. (UDF Editör)


Bilindiği üzere Adalet Bakanlığı ve Milli Eğitim Bakanlığı (ve belkide benim bilmediğim bazı diğer kurumlar) döküman editörü olarak "udf editör" adı altında bir yazılım kullanmakta. Bu editörle elektronik imzalama işlemlerini de gerçekleştirmekteler. Yazılım java da yazılmış olduğundan platform bağımsız çalışır hissi verse de, son kullanıcılar için hazırlanmış bir linux kurulum yönergesi veya paketi bulunmuyor.(En azından ben bulamadım).

Bir ubuntu kullanıcısı olarak sistemim de uyap döküman editörünü çalıştırmak için önce uyap.gov.tr den windows kurulum dosyasını indirip wine ile çalıştırdım. /home/username/.wine/drive_c/ altına uyap adında bi dizin oluşturup dosyaları buraya atmıştı. Baktığımda ise bir bat dosyası da bu java dosyalarını tetikliyordu. Bunun için ben de bi sh dosyası oluşturup bu jar dosyalarını çalıştırması için gerekli değişiklikleri yapmam yeterli oldu. Zaten deb dosyasının içini bir arşiv yöneticisi ile açarsanız yaptığım değişiklikleri görebilirsiniz.

Buraya kadar olan kısım kendi isteklerine göre dağıtımlarına uyap editörü kurmak isteyenler içindi. Bundan sonrası için ise; ubuntu kullanıcıları için hazırladığım deb dosyasını direk indirip kurabilirler. Bu deb i komut satırından indirdiğiniz dizinde sudo dpkg -i uyapeditor.deb komutu ile kurabilirsiniz. Dash da ise Uyap Editor yazdığınızda başlangıç simgesini göreceksiniz. Komut satırında ise uyap komutu ile açılıyor.


Ubuntu 14.04.1 LTS olan sistemimde denedim sorunsuz çalıştı. Olur da çalışmazsa haberleşelim :)

Deb Kurulum Dosyası


Not: Bu arada github dan baktığımda editörün paketi PisiLinux depolarında görünüyor. PisiLinux Geliştiricilerini de buradan selamlıyorum :) Harikasınız.

16 January 2015

Happy Coding & Testing Process


After third week, we started coding and made basic things. Our first aim to enable read-only ptes for collapsing. I still look for this issue. Something goes wrong and I can't see what is that.

To test my changes I've prepared test programs. They create pressure on memory and supply to swapped out system. Actually, they are very basic, just make malloc(), read/write operations on memory. memtest and stress are very strong workload programs, but to swapped out something they mix operations which are not correct for me. I should test specific conditions so use my test programs and they will be sophisticated later on.

To get informations about what happened with my changes, I use smem which shows swap usage percentage, pid, ppid with -t -p options and that's enough for me :). For specific process I look /proc/pid/smaps it gives anonhugepages/anonymouspages numbers and swap usage.

To look kernel messages we can use dmesg, but its size is not enough for me :) because I've been testing almost every line of the functions. To increase size of dmesg log, you should should set CONFIG_LOG_BUF_SHIFT in kernel config file. However When I setted it by 27 which means 2^27 bytes, make seems that doesn't accept this number! Probably, the number can be 16 or 17 as suggestion of config, but I'm not sure about that. Then I've looked /var/log/kern.log, and its size enough for me :) I'm sure about test results with it.

do_swap_page() makes swapped in operations afterward khugepaged scans the pages tables that come from do_swap_page(). There is no function call for khugepaged_scan_mm_slot(), it is called per 10000 miliseconds. Its call chain is like that:
khugepaged_scan_mm_slot() -> khugepaged_scan_pmd() -> collapse_huge_page() ->
__collapse_huge_page_isolate()

Today I've realized in khugepaged_scan_pmd(), ptes seem unpresent! but they are swapped in. Then I need to look do_swap_page() again :).

04 January 2015

Collapsing Huge Pages & Swap In/Out


Last week, I focused on collapsing huge pages and swap in/out. Rik  have asked me some questions and I countinue to reply them. When we study, he puts some hints to questions and sometimes, I back to old questions and try to understand them better. I've started to follow linux-mm list and understand what they mention about at least :). Before I've tried to follow some staging lists but see emails a lot* everyday.

My project includes very small coding according to other kernel internship projects but the topic is too complex and its about core functionality of Linux Kernel. That's really good :). Before the internship, I was thinking "I should pick a small staging driver and study for todo issues". Because with small driver, learning and to be part of Linux Kernel can be easier and I was going to do just self study, also work at another company so have not enough time. Todays, I study on almost hardest topic with a Linux Kernel developer!


I can start coding for my project but need to discuss which policy we will follow to get swapped out pages to memory. We should discuss about trade off to collapsing pages in a 2 mb page when getting them from swap to memory. Keeping in mind the functions is a bit hard for me, I re-look a lot of time to which function what does. My memory is not good :(.


I've replied following questions which are asked me by my mentor. When I reply the questions, don't need to search just from books, look to codes and understand a bit of them :).


Following call chains for Linux Kernel - 3.18


1) How is a page swapped out?


add_to_swap()

        get_swap_page()
                scan_swap_map()
        if(PageTransHuge(page))
                if (split_huge_page_to_list(page, list))
                        swapcache_free()
        add_to_swap_cache()

Swapped out is implemented by add_swap_page(). The function allocates swap space for a page. Swap areas includes slots, and their size are equals to page frames.


It checks whether page up to date and locked then gets swap page, get_swap_page() firstly checks is there a swap page with atomic_long_read(&nr_swap_pages) if so, decrements nr_swap_pages by one. In there used highhest_bit to decrease searching time of free slot. get_swap_page() returns type swap_entry_t. add_swap_page(), cheks whether the page is huge, if so; it splits the huge page to list with

split_huge_page_to_list(page, list).  The function calls __split_huge_page() -> __split_huge_page_map().

If split_huge_page_to_list() returns 0, that means splitted pages succesfully. After that it adds the page entry to swap cache. If huge page can not splitted then called swapcache_free(entry), to release retrieved swap page.

Note: I did not understand why we set page as dirty? at line:202. The page is not changed. Rik's answer: After the page is added to the swap, it is removed from the process page tables.


Then we have a page that is only in the page cache, and not mapped in any process. The dirty bit indicates the data has to be saved to swap before the page can be freed.


scan_swap_map() is used to find free swap slot.


2) Where is the information of where a page is in swap, stored in the data structures used to track the memory of a process?  In other words, how does swap in find where in swap memory is?


Using swap_info_struct swap_info[] array, it includes indexes of ptes and also offsets are stored in swap_map.


3) How is a page swapped in?

do_swap_page()
        pte_to_swp_entry()
        lookup_swap_cache()
        if (!page)
                swapin_readahead()

        else if (PageHWPoison(page)) {...}

It calls pte_to_swp_entry(), pte is converted to swap entry. the function converts pte to architecture independent entry format. Then checks validation of entry with non_swap_entry(). Sets DELAYACCT_PF_SWAPIN flag to spcefiy that does in swap operation. It checks whether the page in swap cache. If so, checks HWPoison flag which is for recovering memory errors; if not runs swapin_readahead() to get probably needs to swap in pages. If HWPoison is setted, it goes to label out_release and release the page and swap cache page from page cache. I've a question here: if the page was huge, but right now it is not because splitted to locate on swap. The page have no compound flag anymore? Is that correct?


Rik's answer: Swap only ever stores single pages, indeed. That means swapped
in pages will not have the compound flag set page_cache_release() calls put_page(), and the function checks using PageCompound().

Note: do_swap_page() gets two pte argument. orig_pte is created by handle_mm_fault() using ACCESS_ONCE(). The macro is for volatile issues maybe but I didn't understand why second pte is created.

Answer: do_swap_page gets both the location of the pte (a pointer) and the value of the pte at handle_mm_fault time. This way it can verify whether the pte changed from its original value, while it is doing things (like retrieving data from swap)

4) How can you discover whether a page is present in the swap cache?

_PAGE_FILE detects whether the page in swap cache, it is into page table entry.

5) Under what conditions are 4kB pages collapsed into a 2MB THP?

In handle_pte_fault(), at line: 3219 do_swap_page() is called because system want to swapped in pages, so it wants to collapse the pages but it can't. This happens, if the cases occur: pte shouldn't be on memory and swap cache. Also pte should be belong to anonymous page, not to file.

Rik's question: Can you write down the call traces that contain the collapse functions in mm/huge_memory.c?
My answer, there are two cases for it:
do_huge_pmd_anonymous_page() -> alloc_hugepage_vma() -> .. __alloc_pages_nodemask()

khugepaged_scan_pmd() -> collapse_huge_page() -> khugepaged_alloc_page() -> alloc_pages_exact_node() -> .. -> __alloc_pages_nodemask()

Rik's answer: Firt call chain, you can leave alone during your project, and is important to understand what the data structures look like.

Second call chain: This is the one you will want to work with.

6) how many pages would be good to bring into swap when trying to collapse a huge page? how many is too much?

x86 systems use 4kB page size. It can be enlarged maximum 4mb. With 2mb page, it is enlarged 512 times, thats good. 4mb page means 1024 times enlarged, it is not so good, if size is more than 4mb huge page, it will be useless.

Rik's answer: Sure, but if all of them are swapped out, it is obviously a bad
idea to bring them all into memory just to collapse them into a 2MB THP.

Out of the 512 pages, what would be a reasonable number to not be in memory already, and bring in from swap? 1? 5? 10? 20? What would the number depend on?

My answer: do_swap_page() ->  swapin_readahead() -> swapin_nr_pages()

In swapin_nr_pages(), using page_cluster it detects how many pages getting swap in.

page_cluster defined in swap.c. swap_setup() function assigns its default value.

7) what about pages that are already in the swap cache? how should we count those?

For this question, I'm a bit confused, thought swap cache is a swap slot .. and replied different thing :). Firstly, I've tried to count how many pages in swap, afterwards go ahead to correct intent.

If a page in the swap cache, that means the page up to date on memory. Also the page is on the one swap slot. Swap cache size is equal to a swap slot. struct swap_info_struct, it has array swap_map.

I've read from book, swap_duplicate() increases slot usagecounter, probably it mentions about the line:

count = p->swap_map[offset];

I've seen on comment line of the function "increment its swap map count." So I guess, swap_map count can be slot usage counter. But I know swap_info struct per swap area not per swap slot. A swap area can include set of slots, so I think, swap_map count doesn't mean swap cache usage counter. Did I misunderstand? Can you inform me about swap_map?

Rik's answer: The swap_map counter means the number of users of that swap slot, which may be different from the number of users of the swap cache page.

However, this line of research is tangential to your project, and your interpretation of question 2 differs from my intent.

My answer: I've thought, when a page will be added to swap cache, it increases count of swap cache page.

add_to_swap_cache() -> __add_to_swap_cache()

In __add_to_swap_cache(), after adding radix tree, it increases the counter at line 104:
address_space->nrpages++;

nrpages specify total number of pages in address_space which stores swap cache address that means how many pages are in swap cache.

8) what about the !pte_write test in __collapse_huge_page_isolate? how can that break collapsing of a THP? is there a simple way to improve that?

pte_present() checks whether the entry have write access. It needs to create a page using page table entry with vm_normal_page(). If write access is disallowed, can't create page.

My mentor said __collapse_huge_page_isolate() is important point your project, and I've reviewed it:

__collapse_huge_page_isolate()
        for (_pte = pte; _pte < pte+HPAGE_PMD_NR; _pte++, address += PAGE_SIZE) {
                pte_none()
                !pte_present() || !pte_write()
                isolate_lru_page(page)

For loop:
Firstly, it checks pte_none(), this function returns true if pte is not in Ram. There is a counter none, checks with none for allowed khugepaged_max_ptes_none. If exceeds the limit then goes to label out. pte_none() returns true if none of the bits in the pte are set, that is the pte is all zeroes. pte_present() also is used for page swapped out. pte_write() checks whether the kernel write to page. Then checks is the page compound, if so does system halt. If page is not anon nor swap backed then does system halt. The page should have only one reference, this property checked by _count variable. Then it locks the page.

I'm looking isolate_lru_page(), Lru list includes inactive file/page, active file/page. But I didn't understand why there is PG_lru flag and we check it with PageLRU(page) at line 1344, vmscan.c

Rik's answer: If the page is not currently on an LRU, a different task may have that page on a pagevec, and do something with it later. That could race with trying to collapse the hugepage, and cause all sorts of problems.

In isolate_lru_page(), it checks again VM_BUG_ONE(!page_count(page), page), but already it checked for page_count() before calling isolate_lru_page() line at: 2171. Why it does this again?

Rik's answer: The page_count check is debugging code, in case somebody changes the kernel and calls isolate_lru_page on a page that got freed. It checks PageLRU once outside the lock (it can be changed by another CPU), and once inside the lock (taking a lock is expensive, and only done conditionally).

And also it checks PageLRU two times, in isolate_lru_page(). It gets lruvec then runs page_lru(), which checks page unevictable, if so sets lru as unevictable; if not, calls page_lru_base_type(), this decides base type for page - file or anon after adds active property and returns lru. Then isolate function runs get_page(), if page head or normal, increments _count. Then clear page lru and calls del_page_from_lru_list(), this function deletes lru from page using list_del()

It checks for page young conditions, then set referenced as 1. If it goes to label out, it runs release_pte_pages().

Note: That function gets a pointer to the start of a page table page, and iterates over all the ptes inside that page table page. A 2MB THP contains 512 4kB pages, which is 1<<HPAGE_PMD_ORDER pages.

28 December 2014

Begining to Read Memory Management Codes


My Linux Kernel internship started two weeks ago and will take 3 months. My mentor is Rik Van Riel. My project aim to fix transparent huge page swapping issues, if system needs to swap huge pages, it has to split the pages to small sized ones but then the system can not reconstitute the huge pages.

Rik asked me some questions about huge page and swapping and I've replied them. Before the reply the questions I've looked for following data structures and definitions.

Firstly I've started to examine struct page and mm_struct in mm_types.h. The kernel holds all information in mm_struct, it includes vm_area_struct *mmap which involves list of memory areas.  vm_areas_struct is an object to show memory areas. Also, the kernel threads don't use mm_struct so if you see if (!mm) {...} it means this is  kernel thread.

Likely & Unlikely Functions: Theese are for branch prediction so used for compiler optimization. They supply to guess which instruction will run and do read ahead.
http://kernelnewbies.org/FAQ/LikelyUnlikely
http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel

Numa & Uma Systems: I've understood the two keywords looking the picture :).










Hot &  Cold Page: If a page in cpu cache, it is hot page however cold page is vice versa.

struct scan_control: It is used for page scaning, holds following variables:
unsigned long nr_scanned: How many inactive pages were scanned.
int may_writepage: It determines whether the kernel can write backing store.
swap_cluster_max: It is restriction for a lru list.

struct zone: The kernel divides memory to nodes, and the nodes include zone lists. Every zone area include pages. You can look for struct zone.

struct list_head: Doubly linked list, to build & manage lists.

Page Flags: http://lxr.free-electrons.com/source/include/linux/page-flags.h

High Memory: Linux Kernel seperate high rate of memory for user space so high memory means user space.
http://unix.stackexchange.com/questions/4929/what-are-high-memory-and-low-memory-on-linux

Page Vector: Provides operations on page list instead of individual pages.

Slot: Swap area is divided to slots. Size of each slot equals to page frame.

up_read/write, down_read/write functions: They are for spinlock issues and includes assembly instructions.

BUG_ON* functions: Checks given condition and returns system halt or nothing.
http://lxr.free-electrons.com/source/include/linux/mmdebug.h#L18

Swap Cache: Some pages after swapped out, if the page is not changed, it has an entry on swap cache and system can read data on memory withouth get the page to back memory.
http://www.linux-tutorial.info/modules.php?name=MContent&pageid=314

Transparent Huge Page vs. Huge Page: Transparent huge page supplies a layer for huge page. http://goo.gl/qGksYX

Note-1: Swap space used by user space tools (mkswap)

Note-2: x86 systems don't use pte level for THP (transparent huge page), it can direct access data on pmd.

Following questions which are asked to me by my mentor. I've explained just important points for my project and their function traces because there are a lot of functions, sometimes they can be very complex :).

Below call chains for Linux Kernel - 3.18

1) from do_page_fault(), sometimes the VM uses transparent huge pages
   (2MB size on x86) for anonymous memory. What functions does the
   code go through between do_page_fault() and the function that
   installs 2MB pages in the process page tables?
When I examined functions, I saw a lot of spinlock functions and Rik said, they for ensure that multiple concurrent instances of the page fault code do not manipulate the page table simultaneously.

do_page_fault()
  __do_page_fault() /* checks the fault is belong to bad area or good area */
    handle_mm_fault()
      __handle_mm_fault()
        __do_huge_pmd_anonymous_page()
       
         
pgtable_trans_huge_withdraw takes a page table page from the process's
reserve of page table pages, so the 2MB page (mapped at pmd level) can
be mapped as 4kB page entries (at the pte level).


2) When are 2MB pages used?

If PAE is enabled, then use 2mb pages. I've looked for it following links:
http://en.wikipedia.org/wiki/Physical_Address_Extension https://www.cs.rutgers.edu/~pxk/416/notes/09a-paging.html
http://en.wikipedia.org/wiki/Page_Size_Extension
http://en.wikipedia.org/wiki/Page_%28computer_memory%29#Huge_pages

3) What does the VM do when a 2MB page cannot be allocated?
   (still in memory.c and huge_memory.c)
In  do_huge_pmd_anonymous_page(), if it can not allocate 2MB page;
it returns, out of memory or fall back. It also calls count_vm_event()
with THP_FAULT_FALLBACK argument. At line: 824, it tries to set
huge zero page, if it can't do that, calls put_huge_zero_page(),
which calls atomic_dec_and_test(). 

At line: 839: If it couldn't install huge page, it calls
put_page(). I've thought;in put_page, it checks whether
the page compound or not, but the page will be compound
always, because the page comes from alloc_hugepage_vma().


4) When the system runs low on memory and wants to swap something
   out, it will split up a huge page before assigning it space in
   a swap area. Find the code in vmscan.c, swapfile.c and huge_memory.c
   that does that. What does the function trace look like from
   try_to_free_pages to the function that splits the huge pages?
try_to_free_pages()
  throttle_direct_reclaim(gfp_mask, zonelist, nodemask)
    do_try_to_free_pages(zonelist, &sc)
      delayacct_freepages_start()
      global_reclaim()
      do while { vmpressure_prio()
      shrink_zones() /* if a zone reclaimable it returns true */}


I've seperated shrink_zones() to below:

shrink_zones()
  nodes_clear(shrink.nodes_to_scan)
  loop:
  populated_zone() {return (!!zone->present_pages);}
  zone_reclaimable_pages(zone) -> get_nr_swap_pages()
  node_set()
  zone_reclaimable()
  shrink_zone()
     shrink_lruvec()
       shrink_list()
          shrink_active_list()
          shrink_inactive_list()
             shrink_page_list()
               add_to_swap()
                 split_huge_page_to_list()
                    __split_huge_page()
                       __split_huge_page_map()


try_to_free_pages(): If memory is not sufficent, it checks pages and removes least used one.
shrink_zones(): It is runned by kswapd with specified time interval and used for remove rarely used
pages. It also balances inactive and active lists using shrink_active_list().
shrink_active_list(): Provides to transfer pages between active_list and inactive_list and detect least used active lists and also implements page selection.
shrink_inactive_list(): Removes lists from inactive_list and send the lists to shrink_page_list().

In general, shrink_* functions run per zone.

5) in huge_memory.c look at collapse_huge_page and the functions
   that call it - under what conditions does the kernel gather up
   512 4kB pages and collapse them into one 2MB page?
collapse_huge_page()
                khugepaged_alloc_page() /* allocate new page */
                __collapse_huge_page_isolate(vma, address, pte); /* this one is new function for me */
                if (isolate_lru_page(page)) { ... }
                if (pte_young(pteval) || PageReferenced(page) ||
                        mmu_notifier_test_young(vma->vm_mm, address)) { ... }
                __collapse_huge_page_copy()

collapse_huge_page_isolate() removes pages from lru with isolate_lru_page().
I've thought: when collapsing pages, their lru's will change. So it isolates
pages.


Note-1: __collapse_huge_page_copy(): 
The 4kB pages could be anywhere in memory.
The 2MB page needs to be one contiguous page.
That means the contents of the 4kB pages need
to be copied over into the one 2MB page.
khugepaged_scan_pmd(), if page is young, it will call collapse_huge_page().
If the collapse function can correct vma, pmd and isolate pages, it collapses
pages.


6) under what conditions does the kernel decide not to collapse
   the 4kB pages in a 2MB area into a 2MB page?
There some conditions for it:
1) If can't alloc khuge page, it won't collapse.
2) I've looked to this condition in collapse_huge_page():
        if (unlikely(khugepaged_test_exit(mm))) {goto out;}
   if mm has no user, it goes to label out and doesn't collapse pages.
3) If it can't find vma and pmd
4) If it can't isolate pages


7)  look at what happens when shrink_page_list()
passes a 2MB transparent huge page to add_to_swap()
When it sent 2 MB page to add_to_swap function, it firstly checks whether page locked and up to date then calls get_swap_page(). If there is no swap page returns 0, If not it checks transHugePAge() then implements split_huge_page_to_list(). In split_huge_page_to_list it gets anonymous vma and does write-lock for it and checks PageCompound. With PageCompound it controls the is huge or not.  Then it checks PageSwapBacked. Then calls __split_huge_page() and the function wants the page shouldn't be tail and splits the page in __split_huge_page_splitting(). The function backs to add_to_swap and does swapcache_free() issues.

8) Can you explains what the page looks like after it has been split?
What happened to the 2MB page?  What do we have instead?
What happened with the PageCompound flag?
__split_huge_page(), it calls __split_huge_page_splitting() in the iteration. It counts number of mapped pmds before splitted it and increase mapcount.

In split_huge_page_map(), it takes page offset with address argument. Firstly, it checks pmd address validity. It
creates small entries in for loop with mk_pte(), set_pte_at(), pte_unmap (this one is just nop instruction for x86 systems). The for loop does one entry for page one, then page two, then page three etc. It changes address of entry adding pagesize (haddr += PAGE_SIZE) up to number of pmd.

I've asked, why pmd_populate()  is performed two times at lines: 1790, 1843?
Rik's answer: The first pmd_populate puts in place a special transparent huge page
PMD that says "this transparent hugepage is being split, do not mess
with it".


The second pmd_populate puts in place the page table page containing
the 4kB pages that map the 2MB area.


Note-1: In __split_huge_page() iterates vma from root of red black tree at line: 1864 but the function gets only one page and a page can match just one vma. So why it needs to iterate vma?

Rik replied my question: "The same page may be shared by multiple processes, if the
process that created the 2MB page originally called fork() afterwards."

Note-2: In  __split_huge_page_splitting(), it calls  pmdp_splitting_flush() what does it do also pmd_update and flush_tlb_range function? I think it should save pmd's content before splitting, it shouldn't lose it. Why it flushes pmd?
Rik's answer: if a small page is touched or dirtied afterwards, we want the MMU to set the accessed and/or dirty bit on the 4kB page entry.

Note-3: We can ignore PVOP_VCALL stuff - that is for Xen, which uses an alternate function for filling in page table info. 

9) Under what conditions can a region with 4kB pages be
turned into a 2MB transparent huge page?
I've traced following call chain:
do_page_fault()
        __do_page_fault()
                handle_mm_fault()
                        __handle_mm_fault() /* check conditions */
                                do_huge_pmd_anonymous_page() /* check conditions */
                                __do_huge_pmd_anonymous_page() /* check conditions */

In __handle_mm_fault(), "if (pmd_none(*pmd) && transparent_hugepage_enabled(vma)) { ... }" if the expression is correct, it can realize do_huge_pmd_anonymous_page(). I've seen this quote for pmd_none() "if page is not in RAM, returns true." But I think, if page is not used for any process, it includes zeros and should be in RAM.

In do_huge_pmd_anonymous_page(), "if (!(flags & FAULT_FLAG_WRITE) && transparent_hugepage_use_zero_page()) { ... }"
if it can correct the condition, it can start to create transparet huge page. I've looked for condition values.
flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; allow retry and killable flag values are defined with special values (0x08, 0x02)?
I think their values only for to check something. And transparent_hugepage_flags is 0UL, is it always have this value? I've looked for its value,
probably always have same value. The last condition creates huge zero page using  set_huge_zero_page() which calls pmd_mkhuge().


One more condition: __do_huge_pmd_anonymous_page(mm, vma, haddr, pmd, page), if it returns false, that means created transparent huge page at line: huge_memory.c#L808
If pmd_none() returns true, creates thp.


10) What code turns 4kB pages into a 2MB page?
pmd_mkhuge() installs 2 MB page. Actually, it does pmd_set_flags(pmd, _PAGE_PSE).
_PAGE_PSE uses _PAGE_BIT_PSE which means huge page.

11) Under what conditions can a region with 4kB pages not
be turned into a 2MB transparent huge page?
There are a lot conditions for this.
1) If the entire 2MB page inside vma, return fall back.
2) If it can't create anonymous vma, return out of memory.
3) If it can't create huge page vma, return fall back.
4) If it get true from __do_huge_pmd_anonymous_page(), return fall back.
5) in __do_huge_pmd_anonymous_page(), if page is not support huge page, the code create kernel panic, and halt.
   VM_BUG_ON_PAGE(!PageCompound(page), page);

6)  If it cannot allocate a huge page


07 December 2014

Page Fault Handler


I've started to read something about memory issue. Firstly, I've looked for basic concepts for it. This link is pretty good for basic concepts.

MMU (Memory Management Unit) translates physical memory addresses to virtual addresses. It creates an interrupt when a page fault occured. When a process try to access an address and if the address is unknown for MMU then it creates page fault exception. In this case page fault exception handler examines current state of MMU and process.  do_page_fault(...) function is page fault handler for Linux. It is processor specific function, I've studied for x86 based systems.

do_page_fault() function gets two arguments which are error code and registers of the process. The error code specifies the page fault whether because of read operation or write operation.

Firstly the function saves address of line which is cause of the exception (control register two), then saves prev state of process.

Page fault handler needs to detect whether the page fault is good or bad. Good page fault means the process needs more memory. Bad page fault can occur for different cases, in general it causes of terminate the process by the handler.

Actually do_page_fault calls __do_page_fault(...) function and it is main area to handle the page fault.

In Linux based systems every process has a page directory and page table. We can understand which pages used by which process with the data structures. If process needs more memory, the handler gets a page from pglist_data which is a global list and adds the page to page table of process.

The function using mm_struct can detect whether the process has permission access for the address. It uses find_vma function for this operation. If process has to access then the address assigned to the process else the process is terminated and segmentation fault occured.

Processes are created as instance of task_struct which includes mm_structs and keeps info about processes.

You can see process resources under /proc/pid/*. If you want to see process vma, then type "cat /proc/pid/maps" on bash. To understand memory issues better, I've read the chapter, this book is very good for kernel newbies.

Also this two links are very helpful for me, they are for kernel 2.6x series but very good to understand big picture of the topic.

Other sources:
http://www.stillhq.com/pdfdb/000446/data.pdf
http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/