Penguins🐧

غروب بخیر🌆 ‏GNOME Shell و Mutter 51 به Release Candidate رسیدند! توسعه GNOME 51 وارد مرحله نهایی شده و امروز نسخه‌های GNOME Shell 51.rc و Mutter 51.rc منتشر شدند؛ یعنی حالا پروژه به آخرین مرحله پیش از انتشار نسخه پایدار رسیده است. اما یکی از مهم‌ترین تغییرات این نسخه در Mutter، اضافه شدن پشتیبانی از Cross-GPU Buffer Scan-Out است. این قابلیت مخصوصا برای سیستم‌های Multi-GPU و لپ‌تاپ‌های Hybrid اهمیت دارد؛ جایی که سیستم هم‌زمان چند GPU دارد و می‌تواند در بعضی سناریوها باعث استفاده بهینه‌تر از مسیر نمایش تصویر شود. Mutter همچنین یک تست خودکار برای بررسی امکان استفاده از این قابلیت در سخت‌افزارهای مختلف دارد. در کنار آن، بهبودهای مربوط به Direct Scan-Out نیز ادامه پیدا کرده‌اند و Mutter حالا یک Policy جدید برای افکت Background Blur که توسط Client درخواست می‌شود دارد. در GNOME Shell 51.rc هم یک تغییر جالب دیده می‌شود: کتابخانه Rust-based Glycin حالا برای Load و Cache کردن تصاویر پس‌زمینه استفاده می‌شود. همچنین تعدادی اصلاح برای Direct Scan-Out و چندین Bug Fix دیگر انجام شده است. حالا باید منتظر انتشار نسخه پایدار GNOME 51 بمانیم؛ نسخه‌ای که علاوه بر تغییرات ظاهری، بخش قابل‌توجهی از تمرکزش روی Wayland، گرافیک و عملکرد دسکتاپ بوده است. - @MainPenguins | Hub | Source

#GNOME #Wayland #Mutter

غروب بخیر🌆 ‏GNOME Shell و Mutter 51 به Release Candidate رسیدند! توسعه GNOME 51 وارد مرحله نهایی شده و امروز نسخه‌های GNOME Shell 51.rc و Mutter 51.rc منتشر شدند؛ یعنی حالا پروژه به آخرین مرحله پیش از انتشار نسخه پایدار رسیده است. اما یکی از مهم‌ترین تغییرات این نسخه در Mutter، اضافه شدن پشتیبانی از Cross-GPU Buffer Scan-Out است. این قابلیت مخصوصا برای سیستم‌های Multi-GPU و لپ‌تاپ‌های Hybrid اهمیت دارد؛ جایی که سیستم هم‌زمان چند GPU دارد و می‌تواند در بعضی سناریوها باعث استفاده بهینه‌تر از مسیر نمایش تصویر شود. Mutter همچنین یک تست خودکار برای بررسی امکان استفاده از این قابلیت در سخت‌افزارهای مختلف دارد. در کنار آن، بهبودهای مربوط به Direct Scan-Out نیز ادامه پیدا کرده‌اند و Mutter حالا یک Policy جدید برای افکت Background Blur که توسط Client درخواست می‌شود دارد. در GNOME Shell 51.rc هم یک تغییر جالب دیده می‌شود: کتابخانه Rust-based Glycin حالا برای Load و Cache کردن تصاویر پس‌زمینه استفاده می‌شود. همچنین تعدادی اصلاح برای Direct Scan-Out و چندین Bug Fix دیگر انجام شده است. حالا باید منتظر انتشار نسخه پایدار GNOME 51 بمانیم؛ نسخه‌ای که علاوه بر تغییرات ظاهری، بخش قابل‌توجهی از تمرکزش روی Wayland، گرافیک و عملکرد دسکتاپ بوده است. - @MainPenguins | Hub | Source

#GNOME #Wayland #Mutter

آپدیت تابستانه زباله با دریایی از مشکلات منتشر شد، این آپدیت ریدمان رو نگیرین. - @MainPenguins | Hub | Source

#WC, #News

ماینکرفت هم دانلود و نصب داشته باشید اگر اینترنت‌ها قطع شد حداقل با پنگوئن‌ها بازی کنیم=)

‏Tether؛ تجربه‌ای شبیه Apple Continuity روی لینوکس یه پروژه متن‌باز جدید به اسم Tether اومده که می‌خواد ارتباط بین iPhone و Linux رو راحت‌تر کنه؛ بدون اینکه به مک نیاز داشته باشید. چه کارهایی می‌کنه؟

‏Sync کردن Clipboard

انتقال فایل

دریافت iMessage و SMS‏

نمایش Notificationها

‏Sync کردن مخاطبین

‏Autofill کردن کدهای OTP

روی لینوکس یه Daemon به اسم tetherd اجرا می‌شه و برای اتصال هم اپ GTK4 و CLI داره. امنیت ارتباط هم با mTLS انجام می‌شه. فعلا برای Arch از AUR و برای بقیه توزیع‌ها هم بسته‌های .deb و .rpm در دسترس هستن. برای استفاده روی iPhone هم حداقل iOS 26.1 لازمه. نصب روی ارچ:

yay -Sy tether

- @MainPenguins | Hub | Source

#App

شامگاه نکو✨️ ‏systemd 262-rc1 منتشر شد اولین نسخه آزمایشی systemd 262 منتشر شده و کلی تغییر جدید با خودش آورده. تغییرات مهم:

اضافه شدن یک سری Unit داخلی برای مواقعی که فایل‌های Unit از روی دیسک قابل بارگذاری نیستن

امکان ساخت systemd به‌صورت یک باینری Static برای Containerهای خیلی کوچک

اضافه شدن LUOSession= برای کار با Live‏ Update Orchestrator

اضافه شدن حالت Headless به systemd-firstboot برای نصب‌های بدون دخالت کاربر

پشتیبانی systemd-coredump از پروتکل جدید Kernel Coredump

اضافه شدن Wizard برای ثبت اولیه در systemd-cryptenroll

پشتیبانی از Intel TDX در کنار AMD SEV-SNP برای ماشین‌های مجازی Confidential

در کل systemd 262 قراره بیشتر روی Containerها، نصب خودکار و زیرساخت آپدیت سیستم تمرکز داشته باشه. - @MainPenguins | Hub | Source

#Update, #News

شب به‌خیر✨️ ‏AMD نسخه جدید پچ‌های UALink برای لینوکس رو منتشر کرد ‏AMD نسخه دوم پچ‌های بزرگ UALink رو منتشر کرده تا پشتیبانی از این فناوری به کرنل لینوکس و درایور AMDGPU اضافه بشه. این نسخه جدید زمینه رو برای UALoE روی پلتفرم‌های آینده مثل AMD Helios آماده می‌کنه. UALink هم قراره برای اتصال سریع چندین GPU و شتاب‌دهنده، مخصوصا در سیستم‌های بزرگ AI و دیتاسنترها استفاده بشه. پچ‌ها هنوز در مرحله بررسی هستن و فعلا وارد کرنل اصلی نشدن، ولی این آپدیت نشون می‌ده AMD داره جدی‌تر زیرساخت لینوکس رو برای نسل بعدی سیستم‌های AI خودش آماده می‌کنه. - @MainPenguins | Hub | Source

#News

صبح به‌خیر🌻 ‏Linux 7.3-rc1 نزدیک ۴۱ میلیون خط کد شد! دلیل رشد بزرگ این نسخه هم تا حد زیادی اضافه شدن فایل‌های رجیستر بزرگ مربوط به سخت‌افزارهای گرافیکی جدید AMD و DCN 6.0 هست - @MainPenguins | Hub | Source

#Linux #News

بامداد نکو✨️ عامل‌هایAi OpenAI از آسیب‌پذیری لینوکس برای گرفتن Root استفاده کردند طبق گزارش جدید، بعضی از Agentهای هوش مصنوعی OpenAI تونستن یک آسیب‌پذیری شناخته‌شده در کرنل لینوکس با شناسه CVE-2026-53362 رو پیدا کنن، Exploit موجودش رو با محیط خودشون سازگار کنن و سطح دسترسی‌شون رو تا Root بالا ببرن.

ماجرا فقط پیدا کردن باگ نبود؛ Agentها خودشون نسخه آسیب‌پذیر کرنل رو شناسایی کردن، Exploit رو گرفتن و تغییرش دادن تا روی سیستم هدف کار کنه. در نهایت هم تونستن از یک Container خارج بشن و به Worker Node میزبان دسترسی Root بگیرن

این اتفاق نشون می‌ده AI Agentها دارن کم‌کم از پیدا کردن باگ عبور می‌کنن و می‌تونن بخش‌های مختلف یک حمله رو خودشون انجام بدن. مطالعه بیشتر - @MainPenguins | Hub | Source

#News, #AI

غروب به کام🐧 قابلیت NVIDIA FRUC وارد FFmpeg شد پشتیبانی از Frame Rate Up-Conversion (FRUC) با استفاده از NVIDIA Vulkan Optical Flow به کد FFmpeg اضافه و Merge شد. FRUC می‌تواند با تحلیل حرکت بین فریم‌های موجود، فریم‌های میانی تولید کند و ویدیوی با نرخ فریم پایین‌تر را به نرخ فریم بالاتر تبدیل کند. این قابلیت در FFmpeg از مسیر Vulkan و افزونه‌ی "VK_NV_optical_flow" استفاده می‌کند و برای اجرای آن، درایور Vulkan مورد استفاده نیز باید از این Extension پشتیبانی کند. پشتیبانی جدید با مجموعه‌ای از Commitهای مربوط به "fruc_vulkan" وارد کد FFmpeg شده و از NVIDIA Optical Flow برای شتاب‌دهی سخت‌افزاری استفاده می‌کند. این قابلیت به‌خصوص برای اکوسیستم Linux + NVIDIA + Vulkan + FFmpeg خبر جالبی محسوب می‌شود و نشان می‌دهد مسیر استفاده از قابلیت‌های جدید GPUهای NVIDIA از طریق Vulkan در پروژه‌های Open Source همچنان در حال گسترش است. - @MainPenguins | Hub | Source

#Linux #FFmpeg #NVIDIA

Normal User
     │
     ▼
Vulnerable SUID Program
     │
     ▼
Higher Privileges
     │
     ▼
Root

به همین دلیل، تعداد زیادی SUID غیرضروری روی یک سیستم چیز خوبی نیست. یک بررسی برای سیستم خودتون همین الان می‌تونید لیست SUIDها رو بگیرید:

sudo find / -type f -perm -4000 -ls 2>/dev/null

حالا برای هر چیزی که نمی‌شناسید، این چهار سؤال رو بپرسید: ۱. این فایل چیه؟

file /path/to/file

۲. از کجا نصب شده؟

dpkg -S /path/to/file

یا:

rpm -qf /path/to/file

۳. مالک و زمان تغییرش چیه؟

stat /path/to/file

۴. آیا واقعاً به SUID نیاز داره؟ اگر جواب این سؤال مشخص نیست، Permission رو کورکورانه تغییر ندید. اول بفهمید فایل چه کاری انجام می‌دهد. یک "s" کوچک در Permission یک فایل ممکنه کاملاً طبیعی باشه... اما اگر روی یک فایل ناشناخته قرار گرفته باشه، می‌تونه ارزش بررسی جدی داشته باشه. پس دفعه بعد که این رو دیدید:

-rwsr-xr-x

از کنارش بی‌تفاوت رد نشید. اون "s" فقط یک حرف نیست؛ یعنی این فایل هنگام اجرا می‌تونه سطح دسترسی متفاوتی نسبت به کاربر اجراکننده داشته باشه. - @MainPenguins | Hub

#Linux #Security #SUID

ظهر نکو «لینوکس امن» قسمت ۴ چطور یک فایل معمولی می‌تونه با دسترسی Root اجرا بشه؟ فرض کنید یک فایل روی سیستم شما وجود داره که مالک اون "root" هست. تا اینجا چیز عجیبی نیست. اما اگر کاربر معمولی بتونه اون فایل رو اجرا کنه و برنامه با سطح دسترسی Root اجرا بشه چی؟ اینجاست که با یکی از قابلیت‌های قدیمی اما بسیار مهم Linux روبه‌رو می‌شیم: SUID SUID اصلاً چیه؟ به‌صورت عادی وقتی یک برنامه رو اجرا می‌کنید، برنامه با دسترسی‌های کاربری که آن را اجرا کرده اجرا می‌شود. اما یک فایل می‌تواند Permission خاصی داشته باشد که باعث شود برنامه هنگام اجرا، به جای UID واقعی اجراکننده از UID مالک فایل برای دسترسی‌های مؤثر استفاده کند. اگر مالک فایل root باشد، آن برنامه می‌تواند با دسترسی Root اجرا شود. و این دقیقاً همان جایی است که SUID از یک قابلیت عادی سیستم‌عامل به یک موضوع امنیتی تبدیل می‌شود. اول ببینیم اصلاً چه فایل‌هایی SUID هستند برای پیدا کردن فایل‌های SUID روی سیستم می‌توانیم از "find" استفاده کنیم:

sudo find / -type f -perm -4000 -ls 2>/dev/null

برای SGID هم:

sudo find / -type f -perm -2000 -ls 2>/dev/null

ممکنه خروجی‌هایی شبیه این ببینید:

-rwsr-xr-x root root ... /usr/bin/passwd
-rwsr-xr-x root root ... /usr/bin/su

به اون "s" در بخش Permission دقت کنید:

-rwsr-xr-x

این "s" به ما میگه Bit مربوط به SUID روی فایل فعال شده. ۵ع پس هر SUIDای خطرناکه؟ نه! این قسمت خیلی مهمه. SUID خودش آسیب‌پذیری نیست. Linux از SUID برای بعضی برنامه‌های کاملاً معمولی و ضروری استفاده می‌کنه. مثلاً:

/usr/bin/passwd

به‌طور طبیعی باید بتواند اطلاعات مربوط به رمز عبور را که دسترسی محدودی دارند تغییر دهد. مشکل زمانی شروع می‌شود که یک SUID غیرمنتظره، ناشناخته یا دستکاری‌شده روی سیستم پیدا کنیم. چطور یک SUID مشکوک رو بررسی کنیم؟ فرض کنیم در خروجی با چیزی مواجه شدیم که انتظارش رو نداشتیم:

/usr/local/bin/example

اول اطلاعات فایل رو بررسی می‌کنیم:

ls -lah /usr/local/bin/example

بعد:

file /usr/local/bin/example

و:

stat /usr/local/bin/example

این‌ها کمک می‌کنن بفهمیم با چه فایلی طرفیم، مالک اون کیه و چه زمانی تغییر کرده. بعد باید ببینیم این فایل از کجا اومده. مثلاً اگر متعلق به یک Package سیستم باشه، بررسی Package خیلی مهمه. در Debian/Ubuntu:

dpkg -S /path/to/file

در Fedora/RHEL:

rpm -qf /path/to/file

اگر Package Manager گفت:

no package owns this file

موضوع لزوماً به معنی Malware نیست، اما ارزش بررسی بیشتری دارد؛ مخصوصاً اگر شما خودتان آن فایل را ایجاد یا نصب نکرده باشید. حالا خود فایل رو هم بررسی کنیم برای فایل‌های Binary می‌توانیم Hash بگیریم:

sha256sum /path/to/file

اگر فایل متعلق به یک Package باشد، بهتر است یکپارچگی Package را هم بررسی کنیم. در Debian/Ubuntu می‌توان از:

sudo debsums -s

و در Fedora/RHEL:

sudo rpm -Va

استفاده کرد. هدف این نیست که صرفاً یک Hash ببینیم؛ هدف اینه که بفهمیم: «آیا این فایل همان چیزی است که سیستم Package Manager انتظار دارد؟» اگر یک SUID واقعاً مشکوک بود چه کار کنیم؟ز اینجا یکی از بدترین کارها اینه که بدون بررسی بریم سراغ:

rm suspicious-file

چون ممکنه فایل متعلق به یک برنامه‌ی واقعی سیستم باشه. اول باید مشخص کنیم فایل برای چه چیزی استفاده میشه. اگر فایل متعلق به یک Package معتبر است، بهتره Package را بررسی یا در صورت نیاز دوباره نصب کنیم. مثلاً در Debian/Ubuntu:

sudo apt reinstall package-name

یا در Fedora:

sudo dnf reinstall package-name

اما اگر فایل یک Binary ناشناخته است و مشخص شد به نرم‌افزار مورد اعتمادی تعلق ندارد، بعد از بررسی دقیق می‌توان SUID را حذف کرد. برای برداشتن SUID:

sudo chmod u-s /path/to/file

بعد دوباره بررسی:

ls -l /path/to/file

اگر قبلاً:

-rwsr-xr-x

بود و حالا:

-rwxr-xr-x

شد، Bit مربوط به SUID برداشته شده. یک نکته خیلی مهم‌تر SUID فقط یک Permission ساده نیست. در امنیت Linux، هر برنامه‌ای که با سطح دسترسی بالاتر از کاربر اجرا می‌شود، سطح حمله‌ی بسیار مهمی محسوب می‌شود. اگر یک برنامه‌ی SUID دارای یک آسیب‌پذیری جدی باشد، ممکن است مهاجم بتواند از سطح دسترسی معمولی به سطح دسترسی بسیار بالاتر برسد. به این نوع مسیر کلی می‌گوییم: Privilege Escalation یعنی:

پسین نکو🌻 ‏Mabox Linux 26.08 منتشر شد نسخه جدید Mabox Linux که بر پایه Manjaro و Openbox ساخته شده، با چند ابزار جدید منتشر شده است. تغییرات مهم:

ابزار mabox-snapshot برای ساخت یک ISO سفارشی از سیستم فعلی شما

ابزار mabox-persistence-usb برای ساخت Live USB با قابلیت ذخیره تغییرات

ترمینال کشویی F12 حالا از Kitty استفاده می‌کند

فایل‌منیجر ترمینالی Yazi هم به‌صورت پیش‌فرض اضافه شده

این نسخه با انتخاب بین کرنل‌های Linux 6.18 LTS و 6.6 LTS هم در دسترس است. - @MainPenguins | Hub | Source

#Update, #News

پسین نکو🌻 ‏Vulkan 1.4.361 منتشر شد؛ یک افزونه جدید برای NVIDIA نسخه جدید Vulkan با شماره 1.4.361 منتشر شد. این نسخه بیشتر روی اصلاحات، شفاف‌سازی‌های مشخصات API و بهبود محدودیت‌های هم‌ترازی در "VK_EXT_descriptor_heap" تمرکز دارد. اما مهم‌ترین تغییر این نسخه، اضافه شدن افزونه جدید "VK_NV_private_data_base_handle" از NVIDIA است.

این افزونه به لایه‌های Vulkan اجازه میدهد در محیط‌هایی که چندین Vulkan Layer در زنجیره قرار دارند، به handle اصلی دستگاه Vulkan دسترسی پیدا کنند. این قابلیت برای ابزارهایی مثل Nsight Graphics و سایر ابزارهایی که نیاز به ارتباط مستقیم‌تر با درایور دارند کاربرد دارد

در مجموع، Vulkan 1.4.361 یک آپدیت نسبتا کوچک اما کاربردی برای اکوسیستم Vulkan و توسعه لایه‌ها و ابزارهای گرافیکی است. - @MainPenguins | Hub | Source

#News, #Update

پسین نکو🌻 ‏Vulkan 1.4.361 منتشر شد؛ یک افزونه جدید برای NVIDIA نسخه جدید Vulkan با شماره 1.4.361 منتشر شد. این نسخه بیشتر روی اصلاحات، شفاف‌سازی‌های مشخصات API و بهبود محدودیت‌های هم‌ترازی در "VK_EXT_descriptor_heap" تمرکز دارد. اما مهم‌ترین تغییر این نسخه، اضافه شدن افزونه جدید "VK_NV_private_data_base_handle" از NVIDIA است.

این افزونه به لایه‌های Vulkan اجازه میدهد در محیط‌هایی که چندین Vulkan Layer در زنجیره قرار دارند، به handle اصلی دستگاه Vulkan دسترسی پیدا کنند. این قابلیت برای ابزارهایی مثل Nsight Graphics و سایر ابزارهایی که نیاز به ارتباط مستقیم‌تر با درایور دارند کاربرد دارد

در مجموع، Vulkan 1.4.361 یک آپدیت نسبتا کوچک اما کاربردی برای اکوسیستم Vulkan و توسعه لایه‌ها و ابزارهای گرافیکی است. - @MainPenguins | Hub | Source

#News, #Update

غروب دلنشین 🐧 Page Alloc Hogger؛ ابزار جدید برای اذیت کردن حافظه‌ی Linux! توسعه‌دهندگان Linux روی ابزاری با نام Page Alloc Hogger کار می‌کنن که برای تست و Debug کردن Memory Management کرنل طراحی شده. ایده‌اش خیلی جالبه: به‌جای اینکه برای ایجاد فشار روی حافظه یک برنامه‌ی مخصوص بنویسیم و امیدوار باشیم دقیقا همان شرایطی که می‌خواهیم ایجاد شود، Page Alloc Hogger اجازه می‌دهد مستقیماً مشخص کنیم چه نوع Pageهایی و از کدام بخش Memory Management کرنل باید Allocate شوند. مثلاً می‌توان مشخص کرد:

کدام NUMA Node

کدام Memory Zone

چه Allocation Order

چه Migration Type

و در نهایت چند Allocation ایجاد شود. همه‌ی این‌ها از طریق debugfs در اختیار توسعه‌دهنده قرار می‌گیرند. توسعه‌دهنده می‌تواند خیلی دقیق به Kernel بگوید: از این Node، از این Zone، با این Order و این Migration Type، به این تعداد Page برایم Allocate کن. بعد برای Allocationهای ساخته‌شده هم Entryهای جداگانه ایجاد می‌شوند و می‌توان آن‌ها را بعدا آزاد کرد. این ابزار بیشتر برای Kernel Developers ساخته شده، نه استفاده‌ی روزمره‌ی کاربران. مثلاً برای: تست Memory Management بررسی رفتار Kernel در شرایط کمبود حافظه آزمایش "kswapd" و "direct reclaim" بررسی رفتار "OOM Killer" تست Allocation Fallbackها بررسی مشکلات مربوط به CMA ساخت تست‌های قابل تکرار برای Memory Management اندازه‌گیری رفتار سیستم در شرایط شدید Memory Pressure خیلی کاربردی می‌تونه باشه. - @MainPenguins | Hub | Source

#Linux #OpenSource #Kernel

Omarchy: Arch Linux for people who want the Arch experience without experiencing Arch Linux + Bloat

به همین دلیل Zircon مفهومی بسیار مهم دارد: Handles به‌جای اینکه هر Process بتواند آزادانه به منابع سیستم دسترسی داشته باشد، دسترسی به Objectها از طریقخ Handleها مدیریت می‌شود. یعنی به شکل ساده:

Process A
    │
    ├── Handle ──► Object 1
    │
    └── Handle ──► Object 2

Process B
    │
    └── Handle ──► Object 3

این مدل کمک می‌کند سیستم دقیق‌تر بداند:

«این Process دقیقاً به چه چیزی دسترسی دارد؟»

و همین موضوع یکی از بخش‌های مهم مدل امنیتی Zircon است. ‏Fuchsia فقط درباره امنیت نیست گاهی وقتی درباره Fuchsia صحبت می‌کنیم، همه چیز را به Security محدود می‌کنیم. اما اهداف پروژه گسترده‌ترند: Security Isolation Componentization Updateability Hardware abstraction Performance Developer experience و در نهایت ساخت یک پلتفرم که بتواند روی سخت‌افزارهای مختلف مقیاس پیدا کند. یعنی Google صرفاً نگفته:

‏«Linux امن نیست، پس یک Kernel جدید بسازیم.»

ماجرا خیلی بزرگ‌تر از این است. ‏Google یک معماری جدید برای کل سیستم‌عامل طراحی کرده. از Kernel و IPC گرفته... تا Package و Component... تا UI و Update mechanism. و جالب‌تر اینکه Fuchsia واقعاً Open Source است سورس Fuchsia عمومی است و Repository رسمی آن به‌صورت فعال توسعه پیدا می‌کند. ساختار پروژه فقط یک Kernel ساده نیست و بخش‌هایی مثل:

zircon/
src/
docs/
build/
third_party/
tools/

را شامل می‌شود. حتی خود Kernel Zircon هم در Repository رسمی قابل مشاهده است و ساختارهایی برای:

arch/
vm/
object/
platform/
hypervisor/
kernel/

دارد. پس اگر واقعاً کنجکاو باشید، می‌توانید بروید داخل سورس و ببینید Google دقیقاً چه چیزی ساخته. - @MainPenguins | Hub | Source | Source 2 | Source 3 | Source 4

#OpenSource #Kernel #Google

یکی از اجزای مهم رابط کاربری آن Scenic و معماری مربوط به Compositing و Rendering است. ایده کلی این است که Componentهای مختلف بتوانند بخش‌های UI خودشان را در اختیار سیستم قرار دهند و سیستم آن‌ها را در یک Scene نهایی ترکیب کند. یعنی به جای اینکه هر برنامه مستقیماً همه چیز را روی نمایشگر کنترل کند:

Application
     ↓
UI / View
     ↓
Scene / Compositor
     ↓
Display

سیستم کنترل بیشتری روی نحوه ترکیب Viewها دارد. ‏Fuchsia در این بخش از مفاهیمی مثل Views، View Trees و Compositor استفاده می‌کند. حتی UI هم Component محور است این موضوع یکی از قسمت‌های جذاب معماری Fuchsia است. ‏Componentها فقط برای سرویس‌های پشت‌صحنه نیستند. رابط کاربری هم می‌تواند از Componentهای مختلف تشکیل شود. مثلاً:

Shell
 │
 ├── Status
 ├── Navigation
 ├── Application A
 ├── Application B
 └── System UI

و سیستم می‌تواند ارتباط و دسترسی بین این Componentها را مدیریت کند. این باعث می‌شود Fuchsia بیشتر شبیه یک پلتفرم Component-oriented باشد تا صرفاً یک سیستم‌عامل کلاسیک. ولی تکلیف برنامه‌های Android چی میشه؟ اینجا یکی از جالب‌ترین قسمت‌های Fuchsia قرار دارد. ‏Fuchsia برای سازگاری با نرم‌افزارهای Android، پروژه‌ای به نام Starnix دارد. ایده این است که به جای اینکه خود Fuchsia تبدیل به Android شود، یک لایه سازگاری ایجاد شود تا برخی برنامه‌ها و اجزای Android بتوانند روی Fuchsia اجرا شوند. به بیان ساده:

Android Application
        │
        ▼
 Android/Linux APIs
        │
        ▼
      Starnix
        │
        ▼
      Fuchsia
        │
        ▼
      Zircon

یعنی Fuchsia قرار نیست برای اجرای یک برنامه Android، Linux Kernel را به‌عنوان Kernel اصلی خودش تبدیل کند؛ بلکه یک Compatibility Layer در معماری خودش دارد. این دقیقاً یکی از قسمت‌هایی است که نشان می‌دهد Google می‌خواهد معماری جدید بسازد، بدون اینکه الزاماً تمام نرم‌افزارهای قبلی را دور بریزد. حالا برسیم به مهم‌ترین بخش... ‏Zircon چیست؟ ‏Zircon یک Microkernel-based kernel هست. اما یک نکته مهم: ‏Zircon به‌تنهایی کل سیستم‌عامل Fuchsia نیست . خود مستندات پروژه هم Zircon را مجموعه‌ای شامل microkernel به همراه بخش کوچکی از سرویس‌ها، Driverها و Libraryهای User Space معرفی می‌کنند؛ بقیه‌ی Fuchsia روی این پایه ساخته می‌شود. یعنی بهتره این تصویر رو داشته باشیم:

                 FUCHSIA
┌─────────────────────────────────────┐
│ Applications / Components           │
├─────────────────────────────────────┤
│ System Services / Framework         │
├─────────────────────────────────────┤
│ Drivers / Filesystems / Networking  │
├─────────────────────────────────────┤
│             ZIRCON                  │
│           Microkernel               │
├─────────────────────────────────────┤
│             Hardware                │
└─────────────────────────────────────┘

و اینجاست که تفاوت مهمی با یک معماری Monolithic Kernel مثل Linux داریم. ‏Linux چه شکلیه؟ ‏Linux یک Monolithic Kernel هست. به زبان خیلی ساده، بخش بزرگی از قابلیت‌های اصلی سیستم مثل: مدیریت حافظه Scheduler Networking Filesystemها Driverها و بسیاری از Subsystemهای دیگر در فضای Kernel قرار دارند. البته Linux معماری کاملاً ساده‌ای نیست و Moduleها، User Space و مرزهای مختلفی دارد؛ اما در نگاه معماری، Kernel آن Monolithic است. در مقابل، Zircon تلاش می‌کند هسته‌ی مرکزی را کوچک‌تر نگه دارد. ‏Microkernel یعنی چی؟ ایده‌ی اصلی Microkernel اینه که:

«هر چیزی که الزاماً لازم نیست داخل هسته باشد، از هسته بیرون ببر.»

در نتیجه Kernel بیشتر روی چیزهایی مثل این تمرکز می‌کند:

Process Management
Thread Management
Virtual Memory
Scheduling
IPC
Synchronization
Hardware primitives

مستندات Zircon هم مشخصاً از Syscallهایی برای مدیریت Process، Thread، Virtual Memory، IPC و locking صحبت می‌کنند. اما چرا Google باید این کار را بکند؟ یکی از دلایل مهم، Isolation است. فرض کنید یک Driver مشکل داشته باشد. در معماری‌هایی که Driver در Kernel Space قرار دارد، یک باگ جدی در Driver می‌تواند پیامدهای بسیار بزرگی داشته باشد؛ چون Driver در سطح بسیار privileged سیستم اجرا می‌شود. اما طراحی Fuchsia تلاش می‌کند بخش‌های بیشتری را از Kernel جدا کند.