California AB 1043 bikin OS jadi perantara sinyal umur
Oleh Zai · Let's Make It Easy
Dipublikasikan 2026-08-30
California mengesahkan AB 1043, aturan yang mengubah cara aplikasi menerima informasi tentang usia pengguna. Undang-undang ini tidak meminta aplikasi menerima tanggal lahir seca...
California mengesahkan AB 1043, aturan yang mengubah cara aplikasi menerima informasi tentang usia pengguna. Undang-undang ini tidak meminta aplikasi menerima tanggal lahir secara langsung. Mulai 1 Januari 2027, operating system provider dan covered application store harus menyediakan sinyal digital yang mengelompokkan pengguna ke dalam rentang usia tertentu. Kategorinya adalah di bawah 13 tahun, 13 sampai 15 tahun, 16 sampai 17 tahun, dan 18 tahun atau lebih.
1. Apa yang berubah untuk developer
Developer yang menerima sinyal harus memintanya ketika aplikasi diunduh dan dijalankan. Sinyal itu menjadi indikator utama usia pengguna, kecuali developer memiliki informasi internal yang jelas dan meyakinkan bahwa kategorinya keliru. Model ini memindahkan sebagian pekerjaan verifikasi dari masing-masing aplikasi ke platform yang mengelola akun dan distribusi software.
Secara teknis, ini berarti aplikasi perlu memahami API real-time dari operating system atau app store. Implementasi tidak berhenti di form registrasi. Developer juga harus menangani perubahan platform, error pada sinyal, dan perbedaan jalur distribusi. Untuk produk yang tersedia di beberapa sistem operasi, tim engineering kemungkinan perlu membuat adapter per platform.
2. Prinsip minimisasi data
Teks resmi AB 1043 menyebut bahwa platform hanya boleh mengirim informasi minimum yang diperlukan. Sinyal tidak boleh dibagikan kepada pihak ketiga untuk tujuan di luar aturan tersebut. Ketentuan ini membatasi desain yang mengirim tanggal lahir lengkap ke setiap aplikasi.
Aturan ini juga melarang platform memakai data yang dikumpulkan dari pihak ketiga untuk bersaing secara tidak adil. Ada konsekuensi hukum berupa civil penalty hingga 2.500 dolar per anak untuk pelanggaran karena kelalaian, dan hingga 7.500 dolar untuk pelanggaran yang disengaja.
3. Dampak untuk software open source
Tom’s Hardware menyoroti pengecualian untuk software yang didistribusikan di bawah lisensi seperti GPL, MIT, BSD, dan Apache. Namun, teks undang-undang resmi yang dapat diakses publik terutama menjelaskan kewajiban operating system provider, app store, dan developer. Detail tentang bagaimana pengecualian itu diterapkan pada software open source dari berbagai kanal masih perlu dibaca bersama analisis hukum dan aturan pelaksana.
Bagi developer, langkah praktisnya adalah memetakan semua jalur distribusi aplikasi, mencatat data usia yang benar-benar dibutuhkan, lalu menunggu dokumentasi API dari platform. Jangan menganggap satu integrasi otomatis menyelesaikan kebutuhan di semua ekosistem.
Bagi tim kecil, perubahan ini juga menyentuh dokumentasi dan support. Aplikasi perlu menjelaskan kapan sinyal umur diminta, apa yang terjadi jika platform tidak mengirimkannya, dan bagaimana pengguna dapat memperbaiki data akun. Itu membuat age verification menjadi bagian dari product behavior, bukan sekadar komponen backend tersembunyi.
1. Apa Itu MX1
MX1 terhubung ke host melalui PCIe 6 dan CXL 3.2 x8. Artikel teknis tersebut melaporkan kapasitas hingga 2 TB DDR5. Perangkat ini juga memiliki jalur PCIe tambahan untuk SSD, sehingga storage dapat dipresentasikan ke host sebagai kapasitas memory yang lebih besar. DDR5 di dalam kartu berfungsi sebagai cache untuk mengurangi dampak latency SSD.
Konsep ini cocok untuk sistem yang membutuhkan kapasitas besar, tetapi tidak semua data aktif pada saat yang sama. Pengguna dapat menaruh bagian yang sering diakses di DRAM, melakukan prefetch dari SSD, atau menggunakan pinned region untuk menjaga buffer tertentu tetap berada di memory yang lebih cepat. SSD tetap memiliki latency lebih tinggi daripada DRAM, jadi fitur tersebut mengurangi masalah, bukan menghapusnya.
2. Compute di dekat memory
MX1 juga membawa 3.072 core RISC-V yang dikelompokkan ke dalam subsystem. Chips and Cheese melaporkan throughput dot product sekitar 3 TFLOPS untuk FP16 dan FP32. Angka ini jauh di bawah GPU modern. Perbandingan langsung seperti itu bisa menyesatkan karena MX1 tidak dirancang untuk menjadi GPU serbaguna.
Nilai yang dicari ada pada locality. Jika accelerator biasa harus mengambil data melalui link CXL, bandwidth dan konsumsi daya link menjadi batas. Compute yang berjalan di dekat pool memory dapat memproses buffer tanpa memindahkan semua data ke host. Ini lebih masuk akal untuk operasi data-parallel yang terikat bandwidth daripada pekerjaan single-threaded.
3. Tantangan software
Situs resmi XCENA menyebut SDK dengan runtime API tingkat tinggi, driver, simulator, dan API tingkat rendah. Itu penting karena perangkat seperti ini tidak cukup hanya dipasang lalu diperlakukan sebagai RAM biasa. Aplikasi perlu memahami pembagian pekerjaan, sinkronisasi, cache, dan karakteristik halaman memory.
Masih ada detail yang perlu dikonfirmasi, termasuk seberapa jauh perangkat menggunakan koherensi CXL dan bagaimana mekanisme cache SSD diimplementasikan pada produk final. Jadi MX1 menarik sebagai arah arsitektur, bukan alasan untuk langsung mengganti GPU atau infrastruktur production.
Untuk deployment, pertanyaan praktisnya bukan hanya berapa kapasitas memory yang tersedia. Tim perlu mengukur pola akses, ukuran buffer, frekuensi reuse, dan biaya sinkronisasi. Jika data terlalu sering berpindah atau cache tidak efektif, tambahan compute di kartu tidak akan menyelamatkan workload. Eksperimen nyata tetap dibutuhkan sebelum perangkat seperti ini masuk ke production.
1. Apa itu bug blindness?
Bug blindness muncul ketika pengalaman memakai sistem sudah terlalu familiar. Developer memahami asumsi internal, urutan layar, dan istilah yang dipakai produk. Karena itu, perilaku yang terasa jelas bagi tim belum tentu jelas bagi pengguna baru. Dan Luu memberi contoh bahwa orang bisa melihat masalah yang sama berkali-kali tanpa menganggapnya sebagai masalah, karena mereka sudah menyesuaikan ekspektasi.
Kondisi ini berbeda dari bug yang tidak terlihat secara teknis. Sebuah tombol bisa berfungsi sesuai implementasi, tetapi tetap membingungkan. Field bisa menerima input, namun hasilnya tertimpa karena proses lain belum selesai. Tidak ada exception yang muncul, tetapi alurnya gagal dari sudut pandang pengguna.
2. Kenapa tim developer rentan?
Tim yang membangun produk biasanya memiliki mental model yang dekat dengan sistem. Mereka tahu data disimpan di mana, kapan request dikirim, dan langkah apa yang harus dilakukan. Pengguna baru tidak membawa pengetahuan tersebut. Mereka mengandalkan sinyal di layar dan menguji produk dengan cara yang tidak selalu diprediksi oleh pembuatnya.
Diskusi di Hacker News tentang tulisan ini menyoroti jarak tersebut. Developer dapat menguji kasus ekstrem seperti input kosong atau angka negatif. Pengguna biasa sering menemukan masalah yang lebih sederhana: mereka tidak tahu tombol mana yang harus ditekan, tidak melihat perubahan status, atau mengira proses berhenti karena tidak ada feedback.
3. Cara mengurangi blind spot
Mulai dengan mengamati sesi penggunaan tanpa memberi instruksi terlalu cepat. Catat kapan orang berhenti, mengulang klik, membaca ulang label, atau membuat workaround. Sinyal itu lebih berguna daripada hanya bertanya apakah mereka menyukai produk.
Gabungkan observasi tersebut dengan automated tests dan monitoring. Test otomatis menjaga perilaku yang sudah diketahui, sedangkan pengguna baru membantu menemukan perilaku yang belum masuk daftar asumsi tim. Setelah menemukan masalah, dokumentasikan bukan hanya bug teknisnya, tetapi juga mental model yang membuat masalah itu tidak terlihat.
Tulisan Dan Luu adalah esai, bukan studi terukur tentang tingkat deteksi bug. Namun idenya tetap berguna sebagai pengingat: produk yang terasa normal bagi pembuatnya belum tentu terasa masuk akal bagi orang lain.
Untuk tim yang mengelola produk, latihan ini juga bisa masuk ke review rutin. Minta orang dari luar squad menjalankan satu tugas tanpa penjelasan tambahan. Rekam layar dan catat asumsi yang mereka buat. Sering kali masalah kecil di situ lebih jujur daripada laporan internal yang hanya mengukur error.
Untuk tim yang mengelola produk, latihan ini juga bisa masuk ke review rutin. Minta orang dari luar squad menjalankan satu tugas tanpa penjelasan tambahan. Rekam layar dan catat asumsi yang mereka buat. Sering kali masalah kecil di situ lebih jujur daripada laporan internal yang hanya mengukur error.
Referensi: https://danluu.com/bug-blind/