Penguins🐧

ظهر نکو «لینوکس امن» قسمت ۴ چطور یک فایل معمولی می‌تونه با دسترسی 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 جدا کند.

دل شب خوش🌙 ‏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 ساخته است.

یکی از پنگوئن‌های نابغه یه پروژه واقعاً خفن برامون فرستاده🐧🤍

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

یکی از پنگوئن‌های نابغه پروژه‌ش رو برامون ارسال کرد🐧🤍

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

یکی از پنگوئن‌ها یه پروژه متفاوت برامون فرستاده🐧🤍

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

یکی از پنگوئن‌های نابغه یه پروژه واقعاً خفن برامون فرستاده🐧🤍

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

ظهر به‌خیر🌻 ‏Linux 7.3؛ AppArmor سریع‌تر و کم‌حجم‌تر می‌شود در Linux 7.3، AppArmor یک قابلیت مهم برای مدیریت Policyها دریافت کرده که می‌تونه زمان بارگذاری قوانین امنیتی رو کاهش بده.

از این نسخه، Policyهای فشرده‌شده در فضای کاربر (Userspace) مستقیماً قابل بارگذاری در کرنل هستن؛ در نتیجه دیگه لازم نیست کرنل ابتدا Policy خام رو دریافت و بعد خودش فشرده‌اش کنه

این تغییر مخصوصاً برای سیستم‌های Embedded و دستگاه‌هایی با RAM محدود مفیده، چون می‌شه Policyها رو از ابتدا به‌صورت فشرده نگه داشت و فضای کمتری مصرف کرد. علاوه بر این، AppArmor یک حالت جدید برای Audit، بازطراحی بخش Network Mediation و چندین اصلاح و پاک‌سازی کد هم دریافت کرده. - @MainPenguins | Hub | Source

#Update, #News

🐘 تایپ‌پی‌اچ‌پی (TypePHP)؛ وقتی PHP مستقیم به کد Native تبدیل می‌شود احتمالا اگر با زبان PHP کار کرده باشید اسم Swoole را شنیدید؛ پروژه‌ای که سال‌هاست روی سریع‌تر و قدرتمندتر کردن PHP کار می‌کند. حالا تیم Swoole یک پروژه جالب به اسم TypePHP را زودتر از چیزی که قرار بود منتشر کرده. طبق گفته‌ی توسعه‌دهنده‌ی اصلی این پروژه یعنی آلبرت چِن (Albert Chen) در ایکس پروژه‌ی TypePHP قرار بود در ماه اکتبر منتشر شود؛ اما انتشارش جلو افتاده و الان کد پروژه روی GitHub در دسترسه.

https://github.com/swoole/typephp

🔸 اما TypePHP دقیقا چیه؟ تایپ‌پی‌اچ‌پی یک کامپایلر AOT برای PHP هست. یعنی به جای تفسیر کد PHP توسط Runtime، کد PHP در زمان کامپایل به C++ (17) و سپس به کد ماشین Native تبدیل می‌کنه. در نتیجه می‌تونید کد PHP بنویسید ولی در نهایت یک باینری Native تحویل بگیرید. در این‌صورت نه خبری از Opcode هست و نه JIT که باید موقع اجرا به‌کار گرفته بشه. جالب‌تر اینکه خود TypePHP هم با PHP نوشته شده و Self-hosting هست؛ یعنی کامپایلر می‌تونه سورس خودش رو کامپایل کنه و نسخه Native خودش رو بسازه. 🔸 تایپ‌پی‌اچ‌پی فقط برای سریع‌تر کردن PHP نیست این پروژه قابلیت‌هایی مثل تایپ‌های نیتیو، آرایه‌ها و ساختارهای داده‌ی نوع‌دار مثل std::vector و std::array و حتی امکان ترکیب PHP و C++ رو فراهم می‌کنه. بنابراین می‌شه قسمت‌هایی از برنامه که سرعت بیشتری لازم دارن رو با C++ نوشت و از داخل PHP اجراشون کرد. از طرف دیگه می‌تونید از TypePHP برای ساخت باینری مستقل، اکستنشن‌های پی‌اچ‌پی، Shared Library و حتی خروجی‌های WASI استفاده کنید. توی بنچمارک‌های خود پروژه هم نتایج جالبی دیده می‌شه. برای مثال در بعضی تست‌های زبان پی‌اچ‌پی، تایپ‌پی‌اچ‌پی با "-O3" حدود ۶.۵ تا ۸ برابر سریع‌تر از PHP تفسیرشده بوده. در یک تست مربوط به کانتینرها هم "std::array" حدود ۱۰ برابر سریع‌تر از PHP array عمل کرده و تقریبا به عملکرد "std::vector" در C++ رسیده. البته TypePHP هنوز در حال توسعه‌ست و قرار نیست تمام قابلیت‌های Dynamic PHP رو بدون محدودیت پشتیبانی کنه. خود پروژه هم یک لیست مشخص از قابلیت‌های ناسازگار داره و عملا باید قبل از استفاده در پروژه‌های موجود این محدودیت‌ها رو بررسی کرد. در حال حاضر TypePHP از PHP 8.4 و 8.5 پشتیبانی می‌کنه و برای Linux، Windows و macOS روی معماری‌های x64 و ARM64 در دسترسه. به نظرم بخش جالب ماجرا اینه که TypePHP نمی‌خواد PHP رو کنار بذاره؛ ایده‌اش اینه که همون PHP آشنایی که می‌نویسید رو برداره و تا جای ممکن تبدیلش کنه به کد Native. اینکه این ایده در نهایت چقدر بتونه موفق بشه احتمالا با ادامه توسعه پروژه مشخص می‌شه. - @MainPenguins | Hub | Source

#News #PHP #OpenSource

🌼 صبحگاه نکو پنگوئن‌ها؛ پشتیبانی از Apple M3 در Asahi Linux به‌زودی می‌رسد تیم Asahi Linux می‌گوید پشتیبانی از دستگاه‌های مجهز به Apple M3 تقریبا آماده شده و احتمالا در هفته‌های آینده نسخه جدیدی با این پشتیبانی منتشر می‌شود. در نسخه فعلی بخش‌های مهمی مثل وب‌کم، USB 3.0 و Thunderbolt روی دستگاه‌های M3 راه افتاده‌اند و روی پشتیبانی از میکروفون و مدیریت مصرف انرژی پردازنده هم کار شده است. توسعه‌دهندگان در کنار M3 مشغول کار روی M4 و M5 هم هستند؛ البته این دو نسل هنوز به کار بیشتری نیاز دارند. پشتیبانی از GPU direct scan-out هم در حال توسعه است تا عملکرد نمایشگر بهتر شود. فعلا این قابلیت‌ها در کدهای اختصاصی Asahi Linux قرار دارند و وارد کردن همه آن‌ها به کرنل اصلی لینوکس زمان بیشتری می‌برد. - @MainPenguins | Hub | Source

#News #Asahi

شامگاه نکو✨️ مشکل افت عملکرد Fedora 44 روی لپ‌تاپ‌های جدید برطرف می‌شه بعد از اینکه مشخص شد Fedora 44 روی بعضی لپ‌تاپ‌های جدید Intel، مخصوصاً Framework Laptop 13 Pro، عملکرد ضعیف‌تری نسبت به توزیع‌های دیگه داره، علت اصلی پیدا شد. مشکل از تعامل Tuned-PPD با درایور Intel‏ P-State بود. وقتی Tuned حالت Performance رو فعال می‌کرد، درایور P-State به‌درستی وضعیت پردازنده رو مدیریت نمی‌کرد و باعث افت عملکرد می‌شد. این مشکل در کرنل برطرف شده و Patch مربوطه وارد چرخه توسعه Linux 7.3 شده؛ همچنین قرار هست برای کرنل Fedora 44 هم Backport بشه. در تست‌های قبلی، جایگزین کردن tuned-ppd با power-profiles-daemon هم باعث شد عملکرد Fedora روی این سخت‌افزار به شکل محسوسی بهتر بشه. - @MainPenguins | Hub | Source

#News

غروب دلنشین🌆 :) یک تغییر در درایور لینوکس، Latency وای‌فای را تا ۷ برابر کاهش داد! گاهی وقتی اینترنت روی لینوکس کند یا ناپایدار به نظر می‌رسه، اولین چیزی که به ذهنمون می‌رسه سرعت اینترنت یا خود مودمه. اما این بار مشکل جای دیگه‌ای بود: داخل درایور Wi-Fi. توسعه‌دهندگان در حال کار روی یک Patch Series برای درایور ath11k هستند؛ درایوری که برای چیپست‌های Qualcomm Wi-Fi 6 / 802.11ax در لینوکس استفاده می‌شود. مشکل اصلی این بود که ath11k در مسیر ارسال داده، Queue مخصوص خودش را نداشت و همین باعث می‌شد مدیریت صف‌های شبکه بهینه نباشد. نتیجه؟ وقتی شبکه تحت بار سنگین قرار می‌گرفت، بسته‌ها بیشتر در صف منتظر می‌ماندند و Latency بالا می‌رفت. حالا چه چیزی تغییر کرده؟ در این Patch Series، یک Queue و مکانیزم زمان‌بندی مناسب‌تر برای مسیر انتقال داده اضافه شده و در کنار آن از AQL یا Airtime Queue Limits برای کنترل بهتر مقدار داده‌ای که اجازه دارد در صف منتظر بماند استفاده شده است. ایده ساده است: قبلاً ممکن بود داده زیادی وارد صف ارسال شود و بخشی از آن فقط منتظر بماند. حالا سیستم بهتر کنترل می‌کند که چه مقدار داده واقعاً باید در صف باشد. در نتیجه، در تست انجام‌شده:

قبل:
≈ 155 ms

بعد:
≈ 22 ms

یعنی تقریباً ۷ برابر Latency کمتر. و جالب‌تر اینکه در یک حالت دیگر، با نگه داشتن latency در سطح مشابه، throughput حدود ۲.۲ برابر بهتر شده است. البته این اعداد مربوط به یک سناریوی Benchmark مشخص هستند و قرار نیست هر دستگاهی که ath11k دارد دقیقاً همین نتیجه را بگیرد. نکته جالب این ماجرا این تغییر هیچ Wi-Fi جدیدی اختراع نکرده. سرعت اسمی Wi-Fi هم قرار نیست ناگهان بیشتر بشه. سخت‌افزار همان سخت‌افزار قبلی است. تغییر اصلی در نحوه مدیریت صف‌ها و زمان‌بندی انتقال داده در درایور اتفاق افتاده. یعنی گاهی اوقات برای سریع‌تر شدن یک سیستم، لازم نیست سخت‌افزار را عوض کنیم؛ کافی است نرم‌افزاری که سخت‌افزار را کنترل می‌کند بهتر شود. Patchها هنوز در حال توسعه‌اند و نتیجه نهایی بعد از تکمیل و بررسی upstream مشخص خواهد شد. - @MainPenguins | Hub | Source

#News #Linux #Networking

صبح نکو🌻 🐧 LLVM/Clang 23.1 منتشر شد؛ کامپایلرها برای سخت‌افزارهای جدید آماده‌تر شدند نسخه LLVM 23.1 منتشر شد و حالا اولین نسخه پایدار از سری LLVM 23 در دسترسه. این انتشار، مجموعه‌ای از تغییرات مربوط به کامپایلر، لینکِر، معماری‌های جدید و زبان‌های C/C++ رو با خودش آورده. یکی از تغییرات مهم این نسخه، اضافه شدن پشتیبانی از AMD Zen 6 با Target جدید znver6 هست. یعنی قبلاً کامپایلر برای نسل‌های قبلی پردازنده‌های AMD اطلاعات و بهینه‌سازی‌های مخصوص خودش رو داشت؛ حالا LLVM می‌تونه هنگام کامپایل، معماری Zen 6 رو هم به‌صورت مشخص هدف قرار بده و از قابلیت‌های جدیدش، از جمله AVX-512 BMM، استفاده کنه. در سمت NVIDIA هم پشتیبانی اولیه از Rigel اضافه شده؛ همین‌طور در بخش GPUهای AMD، Target مربوط به GFX1310 وارد LLVM شده. فقط CPU و GPU نیست؛ در این نسخه پشتیبانی از معماری‌های دیگری مثل Arm C1-Ultra و SpacemiT X100 RISC-V هم بهبود پیدا کرده. از طرف دیگر، C++26 هم یک قدم جلوتر رفته. LLVM 23.1 بخشی از قابلیت‌های C++26 رو از طریق:

-std=c++2c

در اختیار توسعه‌دهنده‌ها قرار می‌ده؛ البته هنوز نباید انتظار پشتیبانی کامل از کل استاندارد C++26 رو داشته باشیم. در کنار این‌ها، LLD بهبودهایی دریافت کرده، قابلیت‌های بیشتری از C2Y وارد شده و تغییراتی هم در تشخیص خطاهای کامپایلر و بخش‌های مختلف Backend انجام شده. LLVM 23.1 در ۲۵ آگوست ۲۰۲۶ منتشر شده و طبق برنامه، نسخه‌های نگهداری 23.1.x هم در ادامه منتشر خواهند شد. - @MainPenguins | Hub | Source

#News #Linux #OpenSource