Linux'ta zaman dilimi kaydı

Bilgisayarlar kapalıyken bile tarih ve saat kaydını tutabilir. Bunu anakartın üzerinde bu işten sorumlu bir zamanlayıcı çip ile yaparlar. Linux dünyası bunu RTC (real time clock) olarak adlandırır. Bu yazıda zamanı tutulması ile bu çipte tutulan zaman bilgisinden bahsedilecektir.

Varsayılan olarak Linux zamanı UTC olarak tutar. Sistem yerelleştirmesi (daha doğrusu zaman dilimi ayarlaması) nasıl ayarlanmışsa bu zamanın üzerine eklenir veya çıkartılır. Örneğin Türkiye +3 zaman diliminde olduğu için UTC olarak tutulan zaman 3 saat ilave edilir.

Ama bunun istisnası da var. Linux'a zamanı yerel saat diliminde tut diyebiliyoruz. Öncelikle mevcut durumu kontrol edelim.

timedatectl

komutunun çıktıları arasında "RTC in local TZ" geçen satıra bakmalıyız. Bende bu

RTC in local TZ: yes

olduğu için benim sistemim demek ki saati yerel saat dilimine göre saklıyor. Bunu değiştirmek için timedatectl komutu ile birlikte set-local-rtc kullanabiliriz. Örneğin UTC zaman dilminde saklayan varsayılan kurulumda durumu yerel saat dilimine çevirmek için

timedatectl set-local-rtc true

diyebiilir, ya da tekrar UTC'ye çevirmek için

timedatectl set-local-rtc false

diyebiliriz. Ya da Windows'da saat bilgisini UTC olarak tutmak için aşağıdaki kayıt defteri değişikliği yapılabilir.

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
          RealTimeIsUniversal = DWORD(1) 

Durum kontrolü için

(gp  "HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" "RealTimeIsUniversal").RealTimeIsUniversal

Zamanı yerel saat diliminde saklayan sistemimde

journalctl -b

komutu ile ilk kaydedilen olayın saatini incelediğimde garip bir şekilde mevcut saat dilimimde değil, bundan da 3 saat ötesinde bir saat görüyorum. Örneğin 13:19'da açtığım bilgisayarım için jounralctl'in ilk satırlarında 13:19 değil, 16:19 görüyorum. Bunun sebebi, ilk açılışta sistemi başlatan initramfs sisteminin sistemin RTC (real time clock) ile tutulan sistem zamanına +3 (Türkiye Saati) ilave ederek başlaması. Ancak bu bir yerde düzeliyor. İlk satırlar, kernel modülünün kayıtları:

Ağu 02 16:19:00 fedora3 kernel: Linux version 7.1.5-101.fc43.x86_64 (mockbuild@3a3dadcda8bc47f1a8cfdc1237822e70) (gcc (GCC) 15.3.1 202607>

Bir süre sonra initramfs işlevi sonlanıyor ve root filesystem'e geçiş yapılıyor. Bu noktadan sonra zaman hızlı bir şekilde 13:19'a  geçiş yapıyor.

Ağu 02 16:19:03 fedora3 systemd[1]: Starting initrd-switch-root.service - Switch Root...
Ağu 02 16:19:03 fedora3 systemd[1]: Switching root.
Ağu 02 16:19:03 fedora3 systemd-journald[260]: Journal stopped
Ağu 02 13:19:04 fedora3 systemd-journald[260]: Received SIGTERM from PID 1 (systemd).

last reboot komutu ile bakılınca görülen saat beklenen, yerel Türkiye saati 13:19:

last reboot -n 1

reboot   system boot  7.1.5-101.fc43.* Sun Aug  2 13:19   still running 

Windows tarafında benzer bir zaman değişikliği olmuyor, en azından yerel zaman dilimi olarak.

Bir Windows işletim sisteminin açılış kimliği (Boot Id)

Linux'ta

journalctl --list-boots

komutu ile her bir açılışa bir açılış numarası verilir. 0 numaraya sahip açılış mevcut açılıştır, -1 bir önceki, -2 numara iki önceki şeklinde gider.

Window'da da buna benzer bir açılış numaralarının olduğunu öğrendim. Ama Windows'daki açılış kimlikleri 0'dan başlayıp sürekli artan bir düzende gidiyor. Ama bu sayılara garip bir şekilde sadece Kernel-Boot olay kayıtlarından erişebildim.

Get-WinEvent -FilterHashtable @{LogName='System';ProviderName='Microsoft-Windows-Kernel-Boot';Id=20} |

    Select-Object TimeCreated,

        @{N='LastShutdownGood';E={$_.Properties[0].Value}},

        @{N='LastBootGood';E={$_.Properties[1].Value}},

        @{N='BootId';E={$_.Properties[2].Value}}

Bu sorguda BootId ile dönen değerler aradığımız açılış kimlikleri. Sadece ne sonuncu değeri sorgulayarak bilgisayarın, en son işletim sistemi yüklenmesinden sonra toplam kaç kez açıldığını bulabiliriz. Sistem olay günlüğünün doluluğu ve boyutuna göre belli bir tarihten önceki açılışlara ait bilgilere ulaşamıyor olabiliriz ama en azından sürekli artan bir yapıda olması, bilgisayarın toplam kaç kez açıldığına dair sayıyı bozmuyor.

Adından da anlaşılabileceği gibi LastShutdownGood ve LastBootGood  alanları sırasıyla en son kapanma ve en son açılma işlemlerinin eksiksiz gerçekleşip gerçekleşmediğini gösterir.

Tarih verisi ve ayraçlar

Tarih nasıl yazılır, bu konuda bazı kafa karışıklıkları var. 12 Kasım 2025 tarihini ifade etmek için doğru ifade hangisi?

12.11.2025

12/11/2025

11/12/2025

2025-11-12

2025/11/12

Powershell'in Get-Date cmdlet'i yukarıdaki bütün ayraçları kabul ediyor. Ben de merak ettim, daha kaç farklı ayraç kabul edilebilir, hangi formatlar (en azından Powershell içinde) geçerlidir.

Tek tek denemek yerine olası ayraçların olduğu bir dizi oluşturdum. 

$ayraclar = ("",":",";",".",",","/","\","|","-","?","'","~","``","+","%","&","=","!")

Baz tarih değişkenimi de şöyle şekillendirdim:

$baz = "12A11A2025"

Burada sanal ayraç olarak "A" kullandım, çünkü sonrasında her seferinde A'ları ilgili ayraç karakteri ile değiştirmek istiyorum.

$ayraclar | % {try {$dongu=$baz.replace("A",$_);date $dongu -f d -ea stop;$sonuc="tamm";$renk="Green"} catch {$sonuc="hata";$renk="Red"} finally {Write-Host "$dongu - $_ - $sonuc" -for $renk}}

Daha okunabilir bir hali için

$ayraclar | ForEach-Object {

    try {

        $dongu=$baz.replace("A",$_);

        Get-Date $dongu -Format "d" -ErrorAction Stop;

        $sonuc="tamm";

        $renk="Green"

    }

    catch {

        $sonuc="hata";

        $renk="Red"

    }

    finally {

        Write-Host "$dongu - $_ - $sonuc" -ForegroundColor $renk

    }

}

Bunun sonucu şöyle oldu:

12112026 -  - hata

12:11:2026 - : - hata

12;11;2026 - ; - hata

12.11.2026

12.11.2026 - . - tamm

12.11.2026

12,11,2026 - , - tamm

12.11.2026

12/11/2026 - / - tamm

12\11\2026 - \ - hata

12|11|2026 - | - hata

12.11.2026

12-11-2026 - - - tamm

12?11?2026 - ? - hata

12'11'2026 - ' - hata

12~11~2026 - ~ - hata

12`11`2026 - ` - hata

12+11+2026 - + - hata

12%11%2026 - % - hata

12&11&2026 - & - hata

12=11=2026 - = - hata

12!11!2026 - ! - hata

Yeşil satırlar çalışan ayraçları gösteriyor: nokta (.), virgül (,), kesme (/) ve tire (-). Gri satırlar da Get-Date'in algıladığı tarihi (12.11.2025 yerine 11.12.2025 algılayıp algılamadığını) görmek için.

Piller, bataryalar ve aküler

Pil, kimyasal bazı süreçlerle enerji depolayan ve bu enerjiyi (neredeyse) sabit bir gerilim ile verebilen enerji depolama sistemleri. Batarya da aynı, akü de. İngilizce'de bütün hepsi batarya (pil) olarak adlandırılıyor.

Özellikle şarj edilebilen pillerle ilgileniyorum. Eskiden beri değişik pil teknolojileri vardı. Şu videoda denk geldiğim bilgiler hoşuma gittiği için not almak istedim. Videoda 4 pil teknolojisi incelenmiş:

NiMH: Nikel metal hidrit piller. Bunlardan da önce NiCd (nikel kadmiyum) piller vardı, çoktandır görmüyorum. Kadmiyum zehirli olduğu için sanıyorum artık kullanılmıyor. Onun yerine piyasaya sürülen bu pil teknolojisi, pile ihtiyaç duyan elektronik cihazları besleyen güvenilir bir teknoloji. Yerine geldikleri kalem pil olarak bildiğimiz AA veya AAA pillerin sağlayabildiği 1.5 V gerilimin yerine 1.2 V üretiyorlar. Ekolojik açıdan güvenli olarak nitelendiriliyorlar. Ama tam boşalmadan tekrar şarj edilirse kapasiteleri düşüyor. Kullanılmasa bile kendi kendine deşarj olabiliyorlar.

Li-Ion: Son dönemin popüler enerji kaynağı lityum iyon piller. Elektrikli araçları bile şu an için bu pil teknolojisi besliyor. Her bir hücre 3.6 V gerilim üretiyor. Çok güvenli değiller. Darbeler ve kısa devreler karşısında hassaslar. İçerden gelen bir yanmanın durdurulması zor oluyor.

Li-Po: Lityum polimer piller. Diğer iki teknolojinin sunduğu silindir şeklinde hücrelere kıyasla esnek polimerler sayesinde yassı bir yapıda olabiliyorlar. Bu sebeple cep telefonları gibi ince cihazları beslemeleri mümkün oluyor.

Lead-Acid: Kurşun asit piller. Fosil yakıtlarla çalışan arabaların, yine de vazgeçilmez şarj edilebilen enerji kaynakları. Bitince araba çalışmaz ama şarj edilebilir. Çok güvenliler, genellikle kazalar sonrasında bir soruna yol açmıyorlar, kısa devrelere karşı da görece dayanıklılar. Ama kurşun içermek gibi kötü bir özellikleri var.

Piller şarj edildikten sonra sabit bir akımla deşarj olurken belli bir süre bu akımı vermeye devam edebiliyor. Bu akım verme kapasitesini mAh (mili amper saat) olarak belirliyoruz. Her pilin de bir çıkış gerilimi var, 1.2 veya 3.6 gibi. Bu çıkış gerilimi ile mAh cinsinden kapasiteyi çarparak da Wh cinsinden toplam enerji kapasitesini buluyoruz.

Bahsettiğim kanal, pillerin hacimlerini ve ağırlıklarını hesaplayarak birim hacim ve birim ağırlık başına pillerin sağlayabildiği enerji miktarını hesaplamış. Bir birim enerjinin maliyetini dahil etmiş. Sonuçta aşağıdaki gibi bir tablo çıkmış.

Pil çeşidi	Wh/kg	Wh/L	Wh/$
NiMH	98,0	391,48	0,69
Li-Ion	209,3	544,14	1,38
LiPo	153,1	376,73	0,89
Kurşun-Asit	32,7	91,60	3,60

Buradan çıkan sonuçlar:

1. En uygun fiyat NiMH, arkasından LiPo, daha sonra Li-Ion
2. Gerek birim ağırlık gerekse birim hacim başına en fazla enerji Li-Ion pillerde
3. Araçlarda kullandığımız aküler en verimsiz, aynı zamanda en pahalı olanı ama en güvenlileri 

Alt öğelerin sahibini toplu değiştir

Bir klasörün altındaki tüm alt klasörler ve dosyaların NTFS dosya sistemindeki sahibini, üst klasörün sahibi ile değiştirmek istiyorum. Aşağıdaki gibi bir betik işe yaradı.

param(

    [Parameter(Mandatory=$true)][string]$Path

)

$acl = Get-Acl -Path $Path

$cevap = Read-Host "$Path ve altindaki dosya ve klasorlerin sahibini $($acl.Owner) olarak degistirelim mi? (e/H)"

if ($cevap -eq "e" -or $cevap -eq "E") {

    Get-ChildItem -Path $Path -Recurse | ForEach-Object {

        try {

            $item = $_

            $itemAcl = Get-Acl -Path $item.FullName -ErrorAction Stop

            $itemAcl.SetOwner([System.Security.Principal.NTAccount]$acl.Owner)

            Set-Acl -Path $item.FullName -AclObject $itemAcl -ErrorAction Stop

            Write-Host "Tamam " -ForegroundColor Green -NoNewline

            Write-Host $item.FullName

        }

        catch {

            Write-Host "Hata  " -ForegroundColor Red -NoNewline

            Write-Host $item.FullName

        }

    }

} else {

    Write-Host "Islem iptal edildi."

}

 

Debian - Windows 11 dualboot

Üzerinde zaten Windows 11 yüklü olan bir bilgisayara Debian kurdum. Üzerinde SATA SSD bir disk vardı. Kurulum tamamlandıktan sonra os-prober'ın devreye girip bir grub menüsü oluşturmasını, Debian ve Windows'un bu menüde yerlerinin olmasını bekledim. Ama olmadı. Windows görülmedi. Bunun önce Windows'un BitLocker'ı ile ilgili olduğunu düşündüm. Sonra şifrelenmemiş bir EFI bölümünün bu iş için yeterli olduğunu hatırladım. Acaba EFI bölümü kurulum sırasında biçimlendirilerek sadece Debian'ın mı dosyaları kalmıştı? Hayır, Windows'un ekledikleri de yerinde duruyordu. Bu durumda grub menüsünde elle bir müdahale gerekecek.

Debian açıkken önce EFI bölümünün UUID'sini öğrendim.

sudo blkid /dev/sda1

bu satırın sonucunda bana verilen UUID'yi kopyalayarak /etc/grub.d/40_custom dosyasını açarak içine şu satırları ekledim

menuentry "Windows Boot Manager" {
    insmod part_gpt
    insmod fat 
    search --no-floppy --fs-uuid --set=root 1234-ABCD 
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

ardından

sudo update-grub

 yaparka grub menüsünü güncelledim ve sorun çözüldü.

İşlemci önbellek miktarını öğrenmek

Grafik arayüz ile bulmanın yöntemleri var, görev yöneticisi, msinfo32 vs. Ama ben powershell ile bulmak istiyorum. İlk aklıma gelen win32_processor sınıfı. Bunun atlında L2 ve L3 miktarı var, ama L1 yok.

gcim win32_processor | select L1CacheSize, L2CacheSize, L3CacheSize

L1CacheSize L2CacheSize L3CacheSize
----------- ----------- -----------
                   5120        8192 

Bakmam gereken sınıf Win32_CacheMemory. Bu cmdlet bir dizi dönüyor. Dizinin her bir elemanı bir önbellek (tampon) seviyesine ait. Şöyle bir ifade ile tüm bilgileri elde edebildim:

gcim win32_cachememory | ft DeviceID, CacheType, Level, InstalledSize, Purpose

DeviceID       CacheType Level InstalledSize Purpose
--------       --------- ----- ------------- -------
Cache Memory 0         4     3           192 L1 Cache
Cache Memory 1         3     3           128 L1 Cache
Cache Memory 2         5     4          5120 L2 Cache
Cache Memory 3         5     5          8192 L3 Cache 

Purpose alanında da görülebilir ama Level=3 olan satırlar L1, Level=4 olan L2 ve Level=5 olan L3 önbellek miktarı. L1 kendi içinde iki farklı bölümden oluşuyor. CacheType=3 ve CacheType=4 alanlarının toplamını bulmamız gerek, yani 192+128 = 320 ve bu sayıların tümü KB cinsinden.

1 KB'ın kaç byte'a karşılık geldiği konusu duruma göre değişiyor[1]. Burada görüyoruz ki

1 KB = 1024 B

---

[1] https://en.wikipedia.org/wiki/Byte#Multiple-byte_units