Penguins🐧
رفتن به کانال در Telegram
We are penguins, don't argue with us. We are genius. GP : @Penguins_Hub Admins : 7 Penguins
نمایش بیشترکشور مشخص نشده استدسته بندی مشخص نشده است
937
مشترکین
+324 ساعت
+137 روز
+4230 روز
تعداد پستها
در حال بارگیری داده...
واکنشها
نظرات
ستارههای تلگرام
بهترین پستها بر اساس
در حال بارگیری داده...
تجزیه و تحلیل انتشار
پست ها | ديناميک بازديد ها | |||||
 شب بهخیر✨️
AMD نسخه جدید پچهای UALink برای لینوکس رو منتشر کرد
AMD نسخه دوم پچهای بزرگ UALink رو منتشر کرده تا پشتیبانی از این فناوری به کرنل لینوکس و درایور AMDGPU اضافه بشه.
این نسخه جدید زمینه رو برای UALoE روی پلتفرمهای آینده مثل AMD Helios آماده میکنه. UALink هم قراره برای اتصال سریع چندین GPU و شتابدهنده، مخصوصا در سیستمهای بزرگ AI و دیتاسنترها استفاده بشه.
پچها هنوز در مرحله بررسی هستن و فعلا وارد کرنل اصلی نشدن، ولی این آپدیت نشون میده AMD داره جدیتر زیرساخت لینوکس رو برای نسل بعدی سیستمهای AI خودش آماده میکنه.
- @MainPenguins | Hub | Source
#News | 154 | 0 | 0 | 2 | Loading... | |
 +1صبح بهخیر🌻
Linux 7.3-rc1 نزدیک ۴۱ میلیون خط کد شد!
دلیل رشد بزرگ این نسخه هم تا حد زیادی اضافه شدن فایلهای رجیستر بزرگ مربوط به سختافزارهای گرافیکی جدید AMD و DCN 6.0 هست
- @MainPenguins | Hub | Source
#Linux #News | 323 | 3 | 0 | 9 | Loading... | |
بامداد نکو✨️
عاملهایAi OpenAI از آسیبپذیری لینوکس برای گرفتن Root استفاده کردند
طبق گزارش جدید، بعضی از Agentهای هوش مصنوعی OpenAI تونستن یک آسیبپذیری شناختهشده در کرنل لینوکس با شناسه CVE-2026-53362 رو پیدا کنن، Exploit موجودش رو با محیط خودشون سازگار کنن و سطح دسترسیشون رو تا Root بالا ببرن.
ماجرا فقط پیدا کردن باگ نبود؛ Agentها خودشون نسخه آسیبپذیر کرنل رو شناسایی کردن، Exploit رو گرفتن و تغییرش دادن تا روی سیستم هدف کار کنه. در نهایت هم تونستن از یک Container خارج بشن و به Worker Node میزبان دسترسی Root بگیرن
این اتفاق نشون میده AI Agentها دارن کمکم از پیدا کردن باگ عبور میکنن و میتونن بخشهای مختلف یک حمله رو خودشون انجام بدن.
مطالعه بیشتر
- @MainPenguins | Hub | Source
#News, #AI | 269 | 2 | 0 | 2 | Loading... | |
غروب به کام🐧
قابلیت 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 | 287 | 0 | 0 | 4 | Loading... | |
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 | 249 | 4 | 0 | 6 | Loading... | |
ظهر نکو
«لینوکس امن» قسمت ۴
چطور یک فایل معمولی میتونه با دسترسی 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
یعنی: | 233 | 5 | 0 | 3 | Loading... | |
پسین نکو🌻
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 | 271 | 3 | 1 | 0 | Loading... | |
 پسین نکو🌻
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 | 248 | 2 | 0 | 4 | Loading... | |
پسین نکو🌻
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 | 2 | 0 | 0 | 0 | Loading... | |
غروب دلنشین 🐧
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 | 302 | 2 | 0 | 4 | Loading... | |
Omarchy: Arch Linux for people who want the Arch experience without experiencing Arch Linux + Bloat | 302 | 2 | 6 | 17 | Loading... | |
به همین دلیل 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 | 350 | 4 | 0 | 4 | Loading... | |
یکی از اجزای مهم رابط کاربری آن 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 جدا کند. | 323 | 4 | 0 | 0 | Loading... | |
دل شب خوش🌙
Fuchsia؛ سیستمعامل متفاوت گوگل که قرار نیست Android بعدی باشد!
احتمالاً اسم Fuchsia OS رو شنیدید؛ پروژهای که سالهاست در سکوت نسبی توسعه داده میشه و برخلاف Android، هستهی اصلیش بر پایه Linux نیست.
Fuchsia یک پروژهی Open Source از طرف Google هست که هدفش ساخت یک سیستمعامل مدرن، امن، قابلبهروزرسانی و قابل استفاده روی طیف مختلفی از سختافزارهاست.
و جالبترین قسمت ماجرا؟
Google برای این پروژه Kernel خودش رو ساخته.
اسمش:
Zircon
اما قبل از اینکه بریم سراغ Zircon، بهتره اصلاً ببینیم Fuchsia خودش چیه؟
Fuchsia از اول برای «Component»ها ساخته شده
یکی از مهمترین تفاوتهای Fuchsia با سیستمعاملهای سنتی، مفهوم Component است.
در Fuchsia، برنامهها و سرویسها به شکل Componentهای مستقل اجرا میشوند.
هر Component میتواند مشخص کند:
«من به چه منابعی نیاز دارم؟»
مثلاً:
Camera App
│
├── Camera
├── Display
└── Storage
در حالی که یک Component دیگر ممکن است فقط:
Music Player
│
├── Audio
└── Network
را دریافت کند.
این مدل باعث میشود سیستم بتواند دسترسیها را خیلی دقیقتر کنترل کند.
به جای اینکه یک برنامه صرفاً به خاطر اینکه در سیستم نصب شده، به منابع مختلف دسترسی داشته باشد، دسترسیها بر اساس Capabilityها تعریف میشوند.
Capability یعنی چی؟
فرض کنید یک برنامه به اینترنت نیاز دارد.
در مدل Capability-based، سیستم میتواند به آن برنامه یک Capability مربوط به Network بدهد.
Application
│
│ Network Capability
▼
Network Service
اگر برنامه به دوربین نیاز نداشته باشد، لزوماً نباید Capability مربوط به Camera را داشته باشد.
این موضوع یکی از پایههای مدل امنیتی Fuchsia است:
دسترسی باید چیزی باشد که به Component داده میشود، نه چیزی که Component بتواند هر وقت خواست خودش بردارد.
و این دیدگاه در معماری Fuchsia تقریباً همهجا خودش را نشان میدهد.
یک سیستمعامل قابل تغییر برای دستگاههای مختلف
یکی از ایدههای جالب Fuchsia اینه که از ابتدا قرار نبوده فقط برای یک نوع دستگاه ساخته بشه.
یعنی معماری آن طوری طراحی شده که بتواند روی سختافزارهای مختلف قرار بگیرد.
در نتیجه ممکن است یک سیستم Fuchsia را روی یک دستگاه Embedded تصور کنیم و در سطح دیگری، رابط کاربری و Componentهای متفاوتی روی همان پایه داشته باشیم.
به زبان ساده:
Fuchsia
│
┌───────────┼───────────┐
│ │ │
Embedded IoT Device
│ │ │
└───────────┼───────────┘
│
Zircon
│
Hardware
البته این به معنی آن نیست که یک Image واحد را میتوانیم روی هر سختافزاری بوت کنیم؛ Driverها، Board Support و بخشهای سختافزاری همچنان اهمیت زیادی دارند.
یکی از اهداف مهم: Update کردن سیستم
یکی از مشکلات سیستمعاملهای بزرگ اینه که هرچه سیستم پیچیدهتر میشه، بهروزرسانی بخشهای مختلفش هم سختتر میشه.
Fuchsia از ابتدا با تمرکز روی قابلبهروزرسانی بودن طراحی شده.
سیستم Component-based اینجا دوباره خودش را نشان میدهد.
بخشهای مختلف سیستم میتوانند Componentهای جداگانه باشند و سیستم بتواند آنها را مدیریت و بهروزرسانی کند، بدون اینکه همه چیز الزاماً به شکل یک تودهی واحد دیده شود.
Fuchsia حتی مفهوم Package و Repository مخصوص خودش را دارد.
به همین دلیل اکوسیستم آن فقط:
Kernel + Apps
نیست.
بلکه یک زنجیره کامل دارد:
Source Code
↓
Build
↓
Package
↓
Repository
↓
Update
↓
Device
پس این فایلهای .far چی هستن؟
اگر در مورد Fuchsia جستوجو کرده باشید، احتمالاً با پسوند:
.far
مواجه شدید.
FAR مخفف Fuchsia Archive است.
این فایلها برای بستهبندی فایلهای مربوط به Packageهای Fuchsia استفاده میشوند.
رابط کاربری Fuchsia چطور کار میکند؟
Fuchsia صرفاً یک سیستمعامل بدون GUI نیست.
Google برای آن لایههای مختلفی در سمت User Space ساخته است. | 256 | 4 | 2 | 0 | Loading... | |
کدوم؟ | 309 | 4 | 36 | 0 | Loading... | |
یکی از پنگوئنهای نابغه یه پروژه واقعاً خفن برامون فرستاده🐧🤍
Orven
مدیریت Context و Memory برای Agentهای هوش مصنوعی، با الهام از سیستمعاملها.
وقتی Context Window یک مدل پر میشه، راهحل معمول اینه که ظرفیت Context رو بیشتر کنیم؛ اما Orven یه ایده متفاوت داره: چرا مدیریت Context رو شبیه مدیریت RAM در سیستمعاملها نکنیم؟
Orven یک سیستم Context و Memory سازگار با MCP هست که پروژه رو به چند لایه تقسیم میکنه:
L1: اطلاعات فعال و Symbolهایی که Agent در حال استفاده از اونهاست
L2: یک Index از Symbolهای پروژه که اطلاعاتشون رو سریع میشه پیدا کرد
Swap: اطلاعات کماستفاده، Traceها، Diffها و دادههای ذخیرهشده روی دیسک
به این شکل Agent مجبور نیست کل پروژه رو وارد Context خودش کنه؛ اطلاعات موردنیاز رو در صورت نیاز Load میکنه و موارد کماستفاده میتونن از Context خارج بشن.
برای Index کردن کد هم از Tree-sitter استفاده شده، بنابراین ساختار پروژه بر اساس Syntax واقعی کد تحلیل میشه و با تغییر فایلها، Index بهصورت Incremental بهروز میشه.
اما بخش جذابتر Orven، Theory هست.
Agentها هنگام کار روی یک پروژه دائماً درباره کد به نتیجه و فرضیه میرسن؛ مثلاً اینکه یک Function چه Invariantای رو حفظ میکنه یا چرا یک بخش خاص از کد وجود داره.
Orven این دانش رو به شکل Claim ذخیره میکنه و اون رو به Symbolها و Evidenceهای مشخص مثل تستها، Commitها، Traceها و مستندات متصل میکنه.
وقتی کد تغییر کنه، Claimهای مرتبط دوباره بررسی میشن و اگر دیگه اعتبارشون مشخص نباشه، به جای اینکه همچنان بهعنوان حقیقت نگه داشته بشن، به وضعیت Stale میرن.
جالبتر اینکه Orven خودش رو به یک Editor یا AI خاص محدود نمیکنه؛ چون از MCP استفاده میکنه، هر Agent یا ابزاری که MCP رو پشتیبانی کنه میتونه بهش متصل بشه.
کل سیستم هم Local اجرا میشه و برای استفاده ازش نیازی به Daemon، Container یا سرویس خارجی ندارید.
به نظرم ایده Orven یکی از پروژههای جالب این سریه، چون به جای اینکه صرفاً Context Window رو بزرگتر کنیم، سعی میکنه مسئله مدیریت Context و دانش Agent رو از پایه حل کنه.
اگه به LLMها، Agentها، MCP یا سیستمهای مدیریت Context علاقه دارید، حتماً یه نگاهی به پروژه بندازید.
نصب بسیار سادهای داره و اموزش نصب توی ریپو نوشته شده
https://github.com/naseridev/orven
اگه شما هم پروژهای دارید که فکر میکنید ارزش دیده شدن داره، برای ما بفرستید.
پنجشنبهها ۵ پروژه برتر پنگوئنها رو معرفی میکنیم.
- @MainPenguins | Hub | Source & Github
#PenguinsLab, #Projects | 349 | 8 | 0 | 7 | Loading... | |
یکی از پنگوئنهای نابغه پروژهش رو برامون ارسال کرد🐧🤍
EchoNote
تا حالا شده موقع گوش دادن به پادکست، ویس یا کتاب صوتی یه جمله جالب بشنوید و چند ثانیه بعد یادتون بیاد که ای کاش ذخیرهش میکردید؟
EchoNote برای حل دقیقاً همین مشکل ساخته شده.
ایده پروژه اینه که برنامه همیشه یه بافر کوتاه از صدای اخیر رو نگه داره. وقتی دکمه Capture رو میزنید، برنامه میتونه چند ثانیه از قبل و بعد اون لحظه رو ضبط کنه و بعد با Speech-to-Text به متن تبدیلش کنه.
متن هم بهعنوان یک Note قابل جستوجو ذخیره میشه.
نسخه Prototype فعلی با Python، SQLite و Faster-Whisper ساخته شده و در حال حاضر قابلیتهایی مثل:
Audio Buffering
Time-shifted Audio Capture
تبدیل صدا به متن
ذخیره یادداشتها
جستوجوی بین یادداشتها
خروجی گرفتن متن
رو داره.
هدف نهایی پروژه ساخت نسخه Android با Kotlin و Android Studio هست و ایدههایی مثل خلاصهسازی با AI، استخراج Keyword، ساخت عنوان خودکار و حتی پشتیبانی از Wear OS هم برای آینده در نظر گرفته شده.
به نظرم ایده اصلی پروژه خیلی جذابه؛ مخصوصاً برای کسایی که زیاد پادکست، کتاب صوتی یا محتوای آموزشی گوش میدن و نمیخوان برای ذخیره کردن یه جمله، وسط گوش دادن درگیر تایپ کردن بشن.
توسعهدهنده همچنین برای توسعه نسخه اندروید به دنبال همکاری با کساییه که با Kotlin و Android Studio کار میکنن.
https://github.com/MohannaMiri/Echonote
اگه شما هم پروژهای دارید که فکر میکنید ارزش دیده شدن داره، برای ما بفرستید.
پنجشنبهها ۵ پروژه برتر پنگوئنها رو معرفی میکنیم.
- @MainPenguins | Hub | Source & Github
#PenguinsLab, #Projects | 307 | 9 | 5 | 10 | Loading... | |
یکی از پنگوئنها یه پروژه متفاوت برامون فرستاده🐧🤍
Spy
یه پروژه آموزشی برای مطالعه رفتار Malware
این پروژه با Python نوشته شده و با الهام از رفتار Backdoorها و Ransomwareها ساخته شده تا برای مطالعه و تحقیق در حوزه امنیت سایبری استفاده بشه.
پروژه قابلیتهایی مثل اجرای دستورات از راه دور و عملیات Encrypt و Decrypt رو شبیهسازی میکنه و هدفش اینه که دانشجوها و علاقهمندان امنیت بتونن با رفتار و ساختار این نوع بدافزارها از نزدیک آشنا بشن.
خود سازنده هم تاکید کرده که پروژه صرفا برای Malware Analysis، Security Research، Detection Engineering و آموزش دفاعی ساخته شده.
توجه کنید:
این پروژه رو روی سیستم اصلی یا اطلاعات واقعی اجرا نکنید. برای بررسی چنین پروژههایی حتماً از یک محیط آزمایشگاهی ایزوله و دادههای ساختگی استفاده کنید
اگه به Cyber Security و Malware Analysis علاقه دارید، میتونید سورس پروژه رو برای مطالعه بررسی کنید.
https://github.com/sad-8532110/Spy
اگه شما هم پروژهای دارید که فکر میکنید ارزش دیده شدن داره، برای ما بفرستید.
پنجشنبهها ۵ پروژه برتر پنگوئنها رو معرفی میکنیم.
- @MainPenguins | Hub | Source & Github
#PenguinsLab, #Projects | 317 | 8 | 0 | 5 | Loading... | |
یکی از پنگوئنهای نابغه یه پروژه واقعاً خفن برامون فرستاده🐧🤍
GFilex
یک File Manager و File Sharing Server کامل، فقط با C
GFilex یه HTTP Server سبک و چندنخی هست که از صفر با C و کتابخونههای استاندارد POSIX نوشته شده؛ بدون Framework و بدون استفاده از زبانهای دیگه در سمت Server.
اما چیزی که پروژه رو جالب میکنه فقط «با C نوشته شده» نیست.
GFilex عملاً یک File Manager کامل رو از طریق مرورگر در اختیارتون میذاره و میتونید باهاش:
فایلها و پوشهها رو مشاهده و مدیریت کنید
فایل آپلود و دانلود کنید
پوشهها رو به صورت ZIP یا TAR فشرده و دانلود کنید
فایلها و پوشهها رو Rename، Move، Copy و Delete کنید
فایلهای فشرده مختلف رو Extract کنید
داخل فایلها و پوشهها Search کنید
بر اساس نام یا حتی محتوای فایل جستوجو کنید
فایلها رو به صورت Batch مدیریت کنید
حتی برای دانلود فایلهای بزرگ هم HTTP Range Request و قابلیت Resume در نظر گرفته شده تا دانلودهای قطعشده بتونن ادامه پیدا کنن.
از طرف دیگه Server از یک Thread Pool با Queue محدود استفاده میکنه؛ یعنی اگر تعداد درخواستها بیش از ظرفیت تعیینشده بشه، درخواستهای جدید با "503 Service Unavailable" رد میشن تا Server تحت فشار هنگ نکنه.
یکی از بخشهای جالب پروژه هم امنیت مسیرهاست؛ دسترسی فایلها به Root Directory محدود شده و پروژه برای جلوگیری از Path Traversal چند لایه بررسی انجام میده.
رابط کاربری هم بدون Frameworkهای Frontend ساخته شده و Responsive هست و برای عملیات طولانی مثل Upload، Compression، Extraction و Copy کردن فایل، Progress Bar داره.
در واقع با یه پروژه طرفیم که همزمان میتونه برای استفاده شخصی کاربردی باشه و برای کسی که میخواد بفهمه یک HTTP Server، File Manager و سیستم مدیریت فایل چطور از پایه ساخته میشن، سورس بسیار خوبی برای مطالعه باشه.
پروژه تحت مجوز GPLv3 منتشر شده.
https://github.com/mehmetlotfi/gfilex
اگه به C، Network Programming، HTTP یا ساخت ابزارهای Self-hosted علاقه دارید، پیشنهاد میکنیم حتماً یه نگاهی بهش بندازید.
خودم شخصا استفاده کردم و راضی بودم، خسته نباشید میگم به توسعه دهنده
اگه شما هم پروژهای دارید که فکر میکنید ارزش دیده شدن داره، برای ما بفرستید.
پنجشنبهها ۵ پروژه برتر پنگوئنها رو معرفی میکنیم.
- @MainPenguins | Hub | Source & Github
#PenguinsLab, #Project | 315 | 10 | 1 | 7 | Loading... | |
 ظهر بهخیر🌻
Linux 7.3؛ AppArmor سریعتر و کمحجمتر میشود
در Linux 7.3، AppArmor یک قابلیت مهم برای مدیریت Policyها دریافت کرده که میتونه زمان بارگذاری قوانین امنیتی رو کاهش بده.
از این نسخه، Policyهای فشردهشده در فضای کاربر (Userspace) مستقیماً قابل بارگذاری در کرنل هستن؛ در نتیجه دیگه لازم نیست کرنل ابتدا Policy خام رو دریافت و بعد خودش فشردهاش کنه
این تغییر مخصوصاً برای سیستمهای Embedded و دستگاههایی با RAM محدود مفیده، چون میشه Policyها رو از ابتدا بهصورت فشرده نگه داشت و فضای کمتری مصرف کرد.
علاوه بر این، AppArmor یک حالت جدید برای Audit، بازطراحی بخش Network Mediation و چندین اصلاح و پاکسازی کد هم دریافت کرده.
- @MainPenguins | Hub | Source
#Update, #News | 293 | 1 | 0 | 6 | Loading... |
