<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Rekayasa Perangkat Lunak on Nalar</title>
    <link>https://nalar.dev/id/tags/rekayasa-perangkat-lunak/</link>
    <description>Recent content in Rekayasa Perangkat Lunak on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/rekayasa-perangkat-lunak/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Counter eventfd Menggabungkan Notifikasi Sebelum Read</title>
      <link>https://nalar.dev/id/counter-eventfd-menggabungkan-notifikasi-sebelum-read/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/counter-eventfd-menggabungkan-notifikasi-sebelum-read/</guid>
      <description>&lt;p&gt;Sebuah &lt;code&gt;eventfd&lt;/code&gt; Linux dapat menerima beberapa write sebelum consumer berjalan, tetapi descriptor tersebut tidak menyimpan setiap write sebagai pesan terpisah. Setiap write yang diterima menambahkan nilai unsigned 64-bit ke counter yang dikelola kernel. Tanpa &lt;code&gt;EFD_SEMAPHORE&lt;/code&gt;, satu read yang berhasil mengembalikan nilai counter saat itu lalu meresetnya menjadi nol.&lt;/p&gt;&#xA;&lt;p&gt;Perilaku tersebut membuat &lt;code&gt;eventfd&lt;/code&gt; menjadi primitive notifikasi berbasis counter, bukan message queue. Readiness menyatakan bahwa counter tidak nol; readiness tidak mempertahankan jumlah operasi write, urutan, atau boundary setiap write.&lt;/p&gt;</description>
    </item>
    <item>
      <title>EPOLLET Melaporkan Transisi Readiness, Bukan Pengosongan Buffer</title>
      <link>https://nalar.dev/id/epollet-melaporkan-transisi-readiness-bukan-pengosongan-buffer/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/epollet-melaporkan-transisi-readiness-bukan-pengosongan-buffer/</guid>
      <description>&lt;p&gt;Dengan &lt;code&gt;EPOLLET&lt;/code&gt;, sebuah file descriptor dapat tetap memiliki data yang belum dibaca setelah event readiness-nya sudah dikonsumsi. Pemanggilan &lt;code&gt;epoll_wait()&lt;/code&gt; berikutnya tidak wajib melaporkan descriptor itu lagi hanya karena state readable sebelumnya masih bertahan.&lt;/p&gt;&#xA;&lt;p&gt;Perilaku ini merupakan batas utama edge-triggered epoll: notifikasi mengikuti perubahan readiness, sedangkan objek I/O di bawahnya mempertahankan state sendiri secara terpisah.&lt;/p&gt;&#xA;&lt;h2 id=&#34;readiness-dan-pengiriman-event-merupakan-state-terpisah&#34;&gt;Readiness dan pengiriman event merupakan state terpisah&lt;/h2&gt;&#xA;&lt;p&gt;Sebuah epoll instance memiliki interest list dan ready list. Registrasi melalui &lt;code&gt;epoll_ctl()&lt;/code&gt; menentukan open file description yang dipantau dan kelas event yang relevan. &lt;code&gt;epoll_wait()&lt;/code&gt; mengembalikan entry yang sudah mencapai ready list.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Event Linux inotify Merupakan Aliran Perubahan yang Dapat Kehilangan Data</title>
      <link>https://nalar.dev/id/event-linux-inotify-merupakan-aliran-perubahan-yang-dapat-kehilangan-data/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/event-linux-inotify-merupakan-aliran-perubahan-yang-dapat-kehilangan-data/</guid>
      <description>&lt;p&gt;File descriptor inotify memaparkan aktivitas filesystem sebagai antrean terurut berisi record event, tetapi antrean tersebut bukan riwayat otoritatif atas state namespace. Event identik yang belum dibaca dapat digabungkan, kapasitas antrean terbatas, dan overflow secara eksplisit berarti sejumlah event telah hilang. Proses yang memperlakukan aliran ini sebagai transaction log lengkap dapat mempertahankan state yang tidak lagi sesuai dengan filesystem.&lt;/p&gt;&#xA;&lt;p&gt;Model yang lebih tepat adalah notifikasi perubahan dengan kewajiban pemulihan. Event dapat menjaga cache tetap mutakhir secara inkremental selama alirannya utuh; kondisi tertentu memutus riwayat inkremental tersebut dan menuntut rekonsiliasi terhadap state filesystem.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux memfd Seals Mengubah Byte Mutable Menjadi Kontrak yang Ditegakkan Kernel</title>
      <link>https://nalar.dev/id/linux-memfd-seals-mengubah-byte-mutable-menjadi-kontrak-kernel/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-memfd-seals-mengubah-byte-mutable-menjadi-kontrak-kernel/</guid>
      <description>&lt;p&gt;Sebuah memfd dapat dimulai sebagai anonymous file yang writable lalu menolak kelas mutasi tertentu melalui seal yang ditegakkan kernel. Transisi ini melekat pada inode, bukan pada satu descriptor, sehingga proses tidak dapat mempertahankan duplicate descriptor tanpa pembatasan untuk melewati seal yang dipasang melalui referensi lain.&lt;/p&gt;&#xA;&lt;p&gt;Sifat tersebut berbeda dari memberikan descriptor dengan mode akses yang lebih sempit kepada komponen lain. Mode akses descriptor membatasi satu open file description. Seal mengubah operasi yang diizinkan kernel terhadap file itu sendiri, termasuk operasi melalui descriptor lain yang merujuk inode yang sama.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux openat2 Membuat Batas Resolusi Path Menjadi Atomik</title>
      <link>https://nalar.dev/id/linux-openat2-membuat-batas-resolusi-path-menjadi-atomik/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-openat2-membuat-batas-resolusi-path-menjadi-atomik/</guid>
      <description>&lt;p&gt;Sebuah pathname dapat menunjuk ke objek yang berbeda ketika lookup kedua dilakukan. Di Linux, &lt;code&gt;openat2()&lt;/code&gt; menangani batas ini dengan menempelkan aturan resolusi pada operasi kernel yang sama dengan operasi yang menelusuri pathname dan membuka objek hasilnya. Kebijakan dievaluasi selama lookup berlangsung, bukan disimpulkan dari pathname yang diperiksa sebelum atau sesudah file dibuka.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaan ini penting ketika proses menerima komponen path dari sumber yang kurang tepercaya tetapi ingin memastikan resolusi tetap berada di dalam direktori tertentu, menolak symbolic link, mencegah perpindahan mount, atau mewajibkan lookup yang hanya memakai cache. Objek yang penting bukan hanya string input, melainkan hasil resolusi string tersebut terhadap namespace aktif yang isi direktori, link, dan mount-nya dapat berubah secara bersamaan.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux splice Menjadikan Pipe sebagai Batas Transfer Data Kernel</title>
      <link>https://nalar.dev/id/linux-splice-menjadikan-pipe-sebagai-batas-transfer-data-kernel/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-splice-menjadikan-pipe-sebagai-batas-transfer-data-kernel/</guid>
      <description>&lt;p&gt;&lt;code&gt;splice()&lt;/code&gt; dapat memindahkan byte antara dua file descriptor tanpa terlebih dahulu menyalin payload ke buffer userspace, tetapi antarmukanya mengharuskan setidaknya satu endpoint berupa pipe. Syarat ini menjadikan pipe lebih dari sekadar transport perantara. Pipe adalah batas buffer yang terlihat oleh kernel, tempat semantik offset, blocking, kapasitas, dan partial progress operasi tersebut dibentuk.&lt;/p&gt;&#xA;&lt;p&gt;Hal ini berbeda dari &lt;code&gt;read()&lt;/code&gt; yang diikuti &lt;code&gt;write()&lt;/code&gt;. Pada urutan tersebut, userspace memiliki array byte perantara dan dapat memeriksa atau mengubahnya. Dengan &lt;code&gt;splice()&lt;/code&gt;, payload dapat tetap berada di storage yang dikelola kernel sementara proses mengoordinasikan perpindahan antar-endpoint.&lt;/p&gt;</description>
    </item>
    <item>
      <title>pidfd Linux Mengubah Identitas Proses Menjadi Handle yang Dapat Dipantau</title>
      <link>https://nalar.dev/id/pidfd-linux-mengubah-identitas-proses-menjadi-handle-yang-dapat-dipantau/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/pidfd-linux-mengubah-identitas-proses-menjadi-handle-yang-dapat-dipantau/</guid>
      <description>&lt;p&gt;PID Linux adalah angka dari namespace yang dapat digunakan ulang. pidfd berbeda: ia adalah file descriptor yang merujuk ke proses tertentu. Perbedaan itu mengubah pengelolaan proses dari lookup berulang berdasarkan nama numerik menjadi operasi terhadap handle yang dipertahankan kernel dan identitasnya tidak diam-diam berpindah ketika PID didaur ulang.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaannya paling terlihat pada supervisor, launcher, sandbox, dan service manager yang mempertahankan referensi proses melintasi pekerjaan asynchronous. PID numerik dapat tetap valid secara sintaksis setelah proses asli keluar, tetapi kemudian mengidentifikasi proses lain. pidfd menjaga referensi tetap terikat pada objek proses asli dan juga dapat berpartisipasi dalam event loop berbasis descriptor.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Shared Ring io_uring Menjadikan Memory Ordering Bagian dari ABI</title>
      <link>https://nalar.dev/id/shared-ring-io-uring-menjadikan-memory-ordering-bagian-dari-abi/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/shared-ring-io-uring-menjadikan-memory-ordering-bagian-dari-abi/</guid>
      <description>&lt;p&gt;Queue &lt;code&gt;io_uring&lt;/code&gt; adalah shared memory yang diubah oleh dua domain eksekusi independen. User space menyiapkan submission entry dan memajukan metadata queue; kernel mengonsumsi submission tersebut lalu memublikasikan completion entry. Layout ring menghilangkan satu batas copy, tetapi pada saat yang sama membuat visibilitas memori menjadi bagian dari kontrak interface.&lt;/p&gt;&#xA;&lt;p&gt;Assignment biasa pada level source ke tail queue tidak cukup sebagai model publikasi yang portabel. Data entry harus terlihat lebih dulu sebelum nilai tail yang membuat entry tersebut boleh dikonsumsi. Di sisi completion, user space harus mengamati publikasi completion dari kernel sebelum membaca field di completion tersebut. Relasi ordering ini adalah bagian dari correctness, bukan sekadar detail optimasi.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
