نوستراداموس (گوگل) پروژه Open Health Stack را به Linux Foundation واگذار کرد

نوستراداموس (گوگل) اعلام کرده که پروژه Open Health Stack (OHS) را به Linux Foundation منتقل می‌کند تا از این پس تحت یک بنیاد مستقل با نام Open Health Stack Software Foundation (OHS-SF) توسعه پیدا کند. هدف این کار، توسعه آزادتر و مشارکت بیشتر جامعه متن‌باز در حوزه سلامت دیجیتال است.

پروژه Open Health Stack مجموعه‌ای از ابزارهای متن‌باز برای ساخت نرم‌افزارهای سلامت، پرونده‌های پزشکی دیجیتال و سرویس‌های مبتنی بر استاندارد HL7 FHIR است و در کشورهای مختلف برای توسعه زیرساخت‌های درمانی استفاده می‌شود. بنیاد جدید همچنین روی ابزارهای چندسکویی و زیرساخت‌های هوش مصنوعی در حوزه سلامت تمرکز خواهد داشت.

نوستراداموس (گوگل) علاوه بر انتقال کامل کدها و دارایی‌های پروژه، ۳ میلیون دلار هم از طریق Google.org برای حمایت از این بنیاد اختصاص داده است. سازمان WHO و چندین شرکت و سازمان دیگر نیز از این پروژه پشتیبانی می‌کنند تا توسعه آن به‌صورت کاملاً جامعه‌محور ادامه پیدا کند.

- @MainPenguins | Source | Source

به نظر می‌رسه توسعه‌دهنده‌های COSMIC در حال Merge کردن قابلیت Frosted Blur (Frosted Glass) روی شاخه اصلی پروژه هستن و اگر همه‌چیز طبق برنامه پیش بره، نسخه بعدی COSMIC این افکت رو به‌صورت رسمی دریافت می‌کنه.

این تغییر فقط محدود به یک بخش نیست و Pull Requestهای مربوط به COSMIC Store، Settings، Panel، Terminal و حتی xdg-desktop-portal-cosmic هم در حال Merge شدن هستن؛ یعنی این افکت قراره به‌صورت یکپارچه در کل دسکتاپ استفاده بشه، نه فقط روی چند پنجره.

- @MainPenguins | Source | Source | Source | Source | Source

پسین نکو🌞
معرفی Virtual Surround Manager؛ صدای فراگیر مجازی برای لینوکس

اگر از هدفون استفاده می‌کنید ولی دلتان یک تجربه نزدیک‌تر به صدای Surround می‌خواهد، پروژه virtual-surround-manager یک ابزار جالب برای مدیریت صدای فراگیر مجازی در لینوکس است.

این پروژه تلاش می‌کند با استفاده از تکنیک‌های پردازش صدا، خروجی استریو هدفون را به شکلی شبیه‌سازی کند که حس وجود چند کانال صوتی و فضای سه‌بعدی بیشتری داشته باشید.

کاربردها:

بهبود تجربه بازی‌ها با هدفون

ایجاد حس Spatial Audio بدون سخت‌افزار خاص

مدیریت پروفایل‌های صوتی مختلف

استفاده در کنار سیستم‌های صوتی لینوکس مثل PipeWire و PulseAudio

یکی از مزیت‌های این مدل ابزارها این است که برخلاف راه‌حل‌های اختصاصی شرکت‌ها، کنترل بیشتری روی نحوه پردازش صدا در اختیار کاربر لینوکس قرار می‌دهند.

- @MainPenguins | Source

معرفی ابزار Komikku؛ یکی از بهترین مانگاخوان‌های لینوکس

اگر اهل مانگا، مانهوا یا وب‌تون هستید، Komikku یکی از بهترین گزینه‌های متن‌باز برای لینوکسه. این برنامه با طراحی مدرن GNOME توسعه داده شده و از ده‌ها منبع مختلف برای مطالعه آنلاین پشتیبانی می‌کنه.

از قابلیت‌های مهمش:

مطالعه آنلاین و آفلاین

پشتیبانی از فایل‌های CBZ، CBR، CBT، EPUB و PDF

حالت‌های مختلف مطالعه مثل Webtoon، Vertical، RTL و LTR

دانلود خودکار فصل‌های جدید

همگام‌سازی پیشرفت مطالعه با MyAnimeList، AniList و MangaUpdates

تاریخچه مطالعه، دسته‌بندی کتابخانه و تم روشن/تاریک

نکته خوبش اینه که از طریق Flathub نصب میشه و روی اکثر توزیع‌های لینوکسی بدون دردسر اجرا میشه. اگر دنبال یک مانگاخوان کامل و خوش‌ساخت برای دسکتاپ لینوکس هستید، Komikku قطعاً ارزش امتحان کردن رو داره.

- @MainPenguins | Source

خردمند و روشن‌اندیش باشد✨️
آپدیت KDE Frameworks 6.28 منتشر شد

نسخه KDE Frameworks 6.28 منتشر شد و مثل همیشه مجموعه‌ای از بهبودها و رفع باگ‌ها را برای اپلیکیشن‌ها و کتابخانه‌های KDE به همراه دارد.

مهم‌ترین تغییر این نسخه مربوط به KRunner است؛ از این به بعد می‌توانید مستقیماً واحدهای انرژی مثل وات‌ساعت (Wh)، کیلووات‌ساعت (kWh) و سایر واحدهای مشابه را هم داخل KRunner به یکدیگر تبدیل کنید.

علاوه بر این، مشکلات مربوط به نمایش تار شدن آیکون‌ها و Thumbnailها در مقیاس‌بندی کسری (Fractional Scaling) برطرف شده و مدیریت برنامه‌هایی که نام یکسان دارند در منوی برنامه‌ها هم بهبود پیدا کرده است.

اگر از Plasma استفاده می‌کنید، این نسخه به‌زودی از طریق مخازن توزیع شما در دسترس قرار می‌گیرد.

- @MainPenguins | Source

شل یه برنامه است! (۲/۱۰)

اما نکته‌ی جالب اینجاست که دیگه خبری از اون دستگاه‌های بزرگ و کیبوردهای سنگین و رول‌های کاغذی نیست. چیزی که باز می‌کنیم درواقع یک Terminal Emulator(شبیه‌ساز ترمینال) ـه؛ یعنی برنامه‌ای که رفتار همون ترمینال‌های قدیمی رو شبیه‌سازی می‌کنه.

برای همین هم هنوز توی لینوکس با اسم‌هایی مثل tty، pts و ترمینال سروکار داریم. این‌ها یادگار همون دورانی هستن که ترمینال واقعاً یک دستگاه فیزیکی بود، نه صرفاً یک پنجره‌ی نرم‌افزاری.

ولی خب خود ترمینال هم به تنهایی دستورات رو اجرا نمی‌کنه. الان هم تقریباً همون کار سنتیشو انجام می‌ده و وظیفه‌اش فقط گرفتن ورودی و دادن خروجیه.

شل هم برخلاف چیزی که ممکنه به نظر برسه، خود سیستم‌عامل نیست. کرنل هم نیست. یه برنامه‌ست؛ مثل خیلی از برنامه‌های دیگه. تنها تفاوتش اینه که وظیفه اجرای برنامه‌ها رو داره. معنی لغوی shell یعنی پوسته و درواقع شل پوسته‌ای برای کرنله و راه ارتباط رو باهاش باز می‌کنه.

مثلاً وقتی توی ترمینال دستور ls رو می‌زنید، شل این متن رو می‌خونه و بررسی می‌کنه که اصلاً ls چی هستش. چطوری انجامش می‌ده؟ دقیقاً درست حدس زدین! با استفاده از متغیر PATH مسیرهای اجرایی ممکن رو پیدا می‌کنه. اگه توی لینوکستون(درواقع منظورمون اکثر شبه‌یونیکس‌هاست) دستور زیر رو بزنید به شما محتوای متغیر PATH رو نشون می‌ده و بسته به سیستم‌عامل یه سری موارد دیگه که بعداً بهش اشاره می‌کنیم ممکنه خروجیش متفاوت باشه.

% echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin

این‌ها مسیرهایی هستن که برنامه‌های ما اونجا ذخیره شدن و شل محترم هم از اونجا دنبال فایل باینریشون می‌گرده؛ و دقیقاً سر این موضوعه که اگه توی یه پوشه یه فایل باینری داشته باشیم فقط با نوشتن اسمش نمی‌شه اجراش کرد و لازمه اشاره کنیم که منظورمون همون فایل اینجاست تا اجرا شه:

% ./my_cool_app

و سر اینه که هکر نامحترم نمی‌تونه یه فایل به اسم sudo بنویسه و بذاره داخل پوشه‌ای که از گیت‌هاب کلون کردین و شما هم اونجا به اشتباه sudo داخل پوشه رو بزنید و رمزتون بره تو آرشیو ایشون.

شل یه برنامه است! (۳/۱۰)

احتمالاً براتون سوال بشه که مگه چند تا شل داریم؟ اصلاً فرقشون چیه؟
همون‌طور که اول مسیر گفتیم، شل فقط یه برنامه‌ست. پس هرکسی می‌تونه شل خودش رو بنویسه! در طول تاریخ هم شل‌های مختلفی برای نیازهای مختلف نوشته شدن:

‏۱. sh (Bourne Shell): پدربزرگ شل‌های مدرن که سال ۱۹۷۷ معرفی شد. خیلی ساده‌ست و هنوز هم به عنوان استاندارد پایه‌ی برای نوشتن اسکریپت‌های سیستمی استفاده می‌شه.

‏۲. bash (Bourne Again Shell): شل پیش‌فرض اکثر توزیع‌های لینوکس. قابلیت‌های خیلی بیشتری نسبت به sh مثل تاریخچه دستورات و کامل کردن خودکار با کلید Tab رو اضافه کرد.

‏۳. zsh (Z Shell): شل بسیار قدرتمند و مدرن که این روزها شل پیش‌فرض macOS و بعضی توزیع‌های لینوکسه. به خاطر پلاگین‌ها و تم‌های فوق‌العاده‌ش (مثل Oh My Zsh) خیلی بین برنامه‌نویس‌ها محبوبه.

‏۴. fish (Friendly Interactive Shell): شلی که تمرکزش روی راحتی کاربره. بدون نیاز به تنظیمات خاصی، قابلیت‌های جذابی مثل پیشنهاد خودکار دستورات بر اساس تاریخچه رو بهتون می‌ده.

شما هر وقت ترمینال رو باز می‌کنید، می‌تونید با تایپ کردن اسم هر کدوم از این‌ها (اگه نصب باشن)، شل فعلیتون رو عوض کنید. مثلاً کافیه بنویسید fish تا وارد دنیای رنگارنگ و قشنگ شل فیش بشید! و برای تغییر دائمی شلتون هم می‌تونید از دستور chsh استفاده کنید.

شل یه برنامه است! (۴/۱۰)

یکی از جذاب‌ترین و قدرتمندترین ویژگی‌های شل، مفهومی به اسم Pipeline هستش. توی فلسفه یونیکس یه قانون معروف هست که می‌گه یه برنامه ساده ولی خوب بنویسید که فقط یک کار انجام بده ولی همون رو درست و به بهترین نحو ممکن انجام بده.
و شل اینجا وظیفه ارتباط بین این دستورها رو داره، چطوری؟ با هدایت کردن ورودی‌ها و خروجی‌ها. هر برنامه‌ای که توی شل اجرا می‌شه، سه تا کانال ارتباطی استاندارد داره:

‏Standard Input (stdin): ورودی برنامه (معمولاً کیبورد شما).
‏Standard Output (stdout): خروجی معمولی برنامه (معمولاً مانیتور شما).
‏Standard Error (stderr): پیغام‌های خطای برنامه (که این هم روی مانیتور میاد ولی کانالش جداست).

حالا فرض کنید می‌خوایم لیست تمام فایل‌های یه پوشه رو بگیریم، اما فقط اون‌هایی رو ببینیم که اسمشون شامل کلمه “report” هست. به جای اینکه یه برنامه بزرگ بنویسیم، دو تا برنامه کوچیک رو با | به هم وصل می‌کنیم:

cat /var/log/mylog | grep -I "error"

اینجا شل میاد خروجی استاندارد (stdout) دستور cat /var/log/mylog رو می‌گیره و مستقیم می‌فرسته به ورودی استاندارد (stdin) دستور grep. به همین سادگی، برنامه‌ها مثل قطعات لگو به هم وصل می‌شن!

توی پست «چرا توی unix همه چیز فایله» بیشتر درموردش صحبت کردیم.

شل یه برنامه است! (۵/۱۰)

وقتی Enter می‌زنیم دقیقاً چه چیزی به شل می‌رسه؟

تا اینجا از ترمینال و خود شل گفتیم. حالا برسیم به لحظه‌ای که واقعاً یه دستور می‌نویسیم و Enter می‌زنیم. از دید کاربر، انگار فقط یه خط متن برای شل فرستاده می‌شه، ولی پشت صحنه چند لایه درگیرند.

اول، ترمینال ورودی صفحه‌کلید را می‌گیره. این ورودی در نهایت از طریق TTY به برنامه‌ای می‌رسه که در پیش‌زمینه‌(FG) اوه ترمینال قرار داره. اگر شل در FG باشد، این متن به شل می‌رسه. یعنی شل مستقیماً «کیبورد» را نمی‌خونه؛ بلکه از FD استاندارد ورودی خودش می‌خونه که معمولاً به همان ترمینال وصله.

پس وقتی می‌نویسیم:

% echo myfile

چیزی که شل دریافت می‌کنه اول فقط یک رشته‌ متنیه. هنوز هیچ برنامه‌ای اجرا نشده، هیچ echo ای هم صدا زده نشده. شل باید اول این خط را بخونه بفهم، تکه‌تکه کنه و تصمیم بگیره اصلاً منظورمون چه بوده. اینجا شل فقط یک launcher نیست؛ یک مفسر زبان هم هست.

شل یه برنامه است! (۶/۱۰)

شل اول حرف ما را parse می‌کنه، بعد از اون اجرا.

خیلی‌ها ناخودآگاه فکر می‌کنن که شل فقط فاصله‌ها را نگاه می‌کنه و بعد برنامه را اجرا می‌کنه، ولی در واقع شل قبل از اجرا، روی خط فرمانمون یک مرحله‌ی کامل parsing و expansion انجام می‌ده.

مثلاً این دستورها ظاهراً شبیه هم‌ان، ولی برای شل یکی نیستن:

% echo $HOME
% echo "$HOME"
% echo '$HOME'
% echo *.txt

در اینجا شل باید بفهمه کجا quote باز شده، کجا بسته شده، چه چیزی باید به عنوان متغیر expand شه. کدوم * باید به اسم فایل‌ها تبدیل شن و کدوم بخش باید عیناً به برنامه تحویل داده بشه. یعنی چیزی که برنامه نهایی می‌بینه، الزاماً همون چیزی نیست که ما تایپ کردیم.
این تفاوت‌ خیلی مهمه. چون بسیاری از رفتارهای shell از همین‌جا شکل می‌گیره. echo هیچ درکی از $HOME یا *.txt نداره؛ این خود شله که قبل از اجرا، این موارد رو به چیزی که باید باشن تبدیل می‌کنه. ودر عمل شل اول از متن خاممون یک چیز با «معنا» می‌سازه و بعدش تازه اونو اجرا می‌کنه.

شل یه برنامه است! (۷/۱۰)

خب، تا اینجا دیدیم که شل چطور دستورات ما رو پیدا می‌کنه. اما بعد از پیدا کردنش چه اتفاقی می‌افته؟ چطوری اون برنامه رو اجرا می‌کنه؟
اینجاست که با دو تا از مهم‌ترین مفاهیم سیستم‌عامل‌های شبه‌یونیکس آشنا می‌شیم: fork و exec.

وقتی شما دستوری مثل ls یا هر برنامه دیگه‌ای رو تایپ می‌کنید و اینتر می‌زنید، شل خودش رو کپی می‌کنه! به این کار می‌گن fork کردن. یعنی یه پروسه جدید (فرزند) از روی خودش می‌سازه. بعد، این پروسه فرزند با استفاده از سیستمی به اسم exec خودش رو با برنامه مورد نظر شما (مثلاً همون ls) جایگزین می‌کنه. در تمام این مدت، شل اصلی (والد) منتظر می‌مونه تا کار فرزند تموم بشه و بعد دوباره کنترل ترمینال رو به دست می‌گیره و منتظر دستور بعدی شما می‌مونه. برای اینکه قشنگ درک کنیم چه اتفاقی می‌افته، بیاید با هم یک کد ساده به زبان C بنویسیم که دقیقاً همین کار رو انجام میده:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

int main(void) {
    pid_t pid = fork();

    if (pid < 0) {
        // Fork failed
        perror("fork");
        return 1;
    } else if (pid == 0) {
        // Child process: replace image with ls
        execlp("ls", "ls", "-l", NULL);
        // Exit if exec fails
        exit(1);
    } else {
        // Parent process: wait for child to finish
        wait(NULL);
        printf("Parent: Child finished.\n");
    }
    return 0;
}

توی این کد چه اتفاقی افتاد؟

۱. تابع fork کل فضای حافظه شل رو کپی می‌کنه (یا به اصطلاح ازش فورک می‌گیره)
۲. شرط pid == 0 مشخص می‌کنه کدوم بخش مربوط به فرزنده. توی این بخش، تابع execlp تمام حافظه‌ی فرزند رو پاک می‌کنه و برنامه ls رو توش بارگذاری می‌کنه. برای همین برنامه ls اجرا میشه.
۳. تابع wait توی بخش والد باعث میشه شل اصلی (والد) تا زمانی که فرزند تموم نشده، دست از پا خطا نکنه و منتظر بمونه. دقیقاً برای همین وقتی شما ls رو می‌زنید، شل شما به اصطلاح «فریز» میشه تا لیست فایل‌ها چاپ بشه و بعد دوباره افسار پرامپت به شما برمی‌گره.


اما یه نکته ظریف وجود داره! همه دستورات اینطوری اجرا نمی‌شن. یه سری دستورات هستن که اصلاً فایل باینری خارجی ندارن و توی خود دل شل ساخته شدن. به این‌ها می‌گن Shell Builtins.

مثلاً دستور cd رو در نظر بگیرین. چرا cd باید داخل خود شل باشه؟ چون اگه cd یه برنامه خارجی بود، طبق چیزی که گفتیم شل براش یه پروسس فرزند می‌ساخت، پوشه کار اون فرزند عوض می‌شد، کارش تموم می‌شد و از بین می‌رفت؛ ولی پوشه کار شل اصلی شما هیچ تغییری نمی‌کرد! برای همین دستوراتی مثل cd یا pwd و alias مستقیماً توسط خود شل اجرا می‌شن و نیازی به رفتن سراغ دیسک و متغیر PATH ندارن.

شل یه برنامه است! (۸/۱۰)

شل فقط اجراکننده‌ی برنامه‌ها نیست؛ خودش یک زبان هم هست

تا اینجا بیشتر درباره‌ این حرف زدیم که شل چطور دستور ما رو می‌گیره و برنامه‌ها را اجرا می‌کنه. ولی یه نکته‌ مهم هم این وسط هست: همون‌طور که یکم پیش گفتیم، شل فقط یک launcher نیست. شل خودش یک زبان هم هست. یعنی وقتی توی شل چیزی می‌نویسیم همیشه قرار نیست فقط اسم یک برنامه و چند آرگومان باشه. خیلی وقت‌ها داریم از امکانات خود زبان shell استفاده می‌کنیم. مثلاً این‌ مثال‌ها را ببینید:

name="Ali"
echo "$name"

if [ -f /etc/passwd ]; then
  echo "exists"
fi

یا مثلاً:

for file in *.txt; do
  echo "$file"
done

اینجا دیگه ماجرا فقط «اجرای یک برنامه» نیست. شل متغیر نگه می‌داره، شرط بررسی می‌کنه، حلقه اجرا می‌کنه و بر اساس syntax خودش تصمیم می‌گیره چیکار باید بکنه. برای همین shell script عملاً یک زبان اسکریپت‌نویسیه و نه فقط یک محیط برای زدن commandهای پراکنده. شما می‌تونید با استفاده از اون، چندین برنامه را کنار هم بگذارید، روی خروجی‌شان تصمیم بگیرید، شرط و حلقه بنویسید، و کارهای تکراری را خودکار کنید. شاید همین‌جاست که shell از یک command runner ساده جدا تمیز می‌ده. چون shell فقط واسطه‌ شما و برنامه‌ها نیست؛ یک لایه‌ی منطقی هم روی آن‌ها می‌ذاره و یعنی هم می‌تونه برنامه رو اجرا کند و هم می‌تواند به اجرای اونا ساختار بده.

شل یه برنامه است! (۹/۱۰)

بعد از اجرا هم کار شل تمام نمی‌شود

ممکنه فکر کنیم شل فقط دستورات رو اجرا می‌کنه و بعدش می ره پی کارش. ولی در عمل، بعد از اجرا هم هنوز نقش مهمی داره.
اگر برنامه توی FG اجرا شده باشه، شل معمولاً صبر می‌کنه تا اون برنامه کارش تموم بشه. برای همینه که وقتی یه دستور زمان‌بر اجرا می‌کنیم تا وقتی کارش تموم نشده پرامپت برنمی‌گرده. شل فقط موقتاً کنترل را به اون برنامه می‌ده و خودش منتظر مونده تا به اتمام برسه.
اگر هم وسط کار Ctrl+C یا Ctrl+Z بزنیم، باز این شل هستش که وظیفه مدیریت اوضاع رو داره. باید بدونه کدوم پروسه در حال اجراست، کدوم job متوقف شده، کدوم یکی رفته توی پس‌زمینه و کِی باید دوباره کنترل ترمینال را پس بگیره.

وقتی هم برنامه‌ای را با & در BG اجرا می کنیم، شل همچنان باید حواسش به اون باشه یعنی هم باید پرامپت را به شما برگردونه و هم وضعیت jobهای قبلی را نگه دارد، هم اگر لازم شد بهمون خبر بده که فلان job کارش تموم شده یا به دلیلی متوقف شده است.
پس شل فقط چیزی نیست که دستورات رو «اجرا» کنه؛ شل مدتی تا بعد از اجرا هم درگیر ماجرا می‌مونه و اجرای برنامه‌ها را زیر نظر داره.

شل یه برنامه است! (۱۰/۱۰)

شل چرا بعد از این همه سال هنوز زنده است؟

اگر از اول این مسیر را نگاه کنیم، از ترمینال و TTY شروع کردیم؛ جایی که ورودی ما وارد سیستم می‌شه. بعد رسیدیم به شل؛ برنامه‌ای که این ورودی را می‌خونه parse می‌کنه، معنی‌اش را می‌فهمه و تصمیم می‌گیره چه چیزی باید اجرا شود.
بعد دیدیم شل فقط دستورات را اجرا نمی‌کنه. بعضی چیزا رو خودش انجام می‌ده و بعضی چیزها را به شکل یک برنامه‌ جدا اجرا می‌کنه و حتی در خیلی از مواقع خودش با استفاده از متغیر، شرط، حلقه و ده‌ها چیز دیگه، کار یه زبان برنامه‌نویسی واقعی رو انجام می‌ده.

از طرفی کار شل با اجرای دستور هم تمام نمی‌شه. باید منتظر پروسه‌ها بمونه، وضعیتشون رو مدیریت کنه و کنترل ترمینال را بین کاربر و برنامه‌ها جابه‌جا کنده؛ یعنی چیزی که از بیرون فقط «یک خط دستور» به نظر می‌رسه، در واقع حاصل همکاری چند لایه‌ مختلفه: از ترمینال، TTY، کرنل، شل گرفته تا پروسه‌ها.
و شاید دلیل اینکه بعد از سال‌ها مردم همچنان از شل‌ها استفاده می‌کنن این باشه که شل فقط یک ابزار قدیمی نیست؛ یک راه ساده، مستقیم و قدرتمند برای کار با سیستمه. هم به ما اجازه می‌دهد برنامه‌ها رو اجرا کنیم و هم می‌ذاره اونا رو ترکیب کنیم و برایشون منطق بنویسیم. شاید به همین خاطر است که با وجود تمام محیط‌های گرافیکی مدرن، هنوز هم خیلی وقت‌ها دقیق‌ترین راه حرف زدن با سیستم، همون خط فرمانی باشه که دهه‌ها پیش شکل گرفت.

- @MainPenguins

صبح روشن
جزئیات بیشتری از خرابکاری در OpenMandriva منتشر شد

اطلاعات جدید نشان می‌دهد خرابکاری اخیر در پروژه OpenMandriva فقط به حذف چند مخزن GitHub محدود نبوده است. طبق گزارش‌ها، یکی از مشارکت‌کنندگان پس از بروز اختلافات داخلی، از دسترسی مدیریتی خود سوءاستفاده کرده و علاوه بر حذف بخشی از مخازن، یک بسته خالی را هم به مخزن Cooker ارسال کرده بود. اگر این موضوع به‌موقع شناسایی نمی‌شد، می‌توانست باعث حذف یا از کار افتادن بسته‌های GNOME و COSMIC برای کاربران شود.

تیم OpenMandriva اعلام کرده این اقدام بلافاصله شناسایی شد، مخازن در حال بازیابی هستند و بسته مخرب هم قبل از رسیدن به کاربران کنترل شده است. همچنین روند بررسی و محدود کردن دسترسی‌های مدیریتی برای جلوگیری از تکرار چنین اتفاقی آغاز شده است.

این اتفاق دوباره یادآوری می‌کند که امنیت پروژه‌های متن‌باز فقط به باگ‌ها و حملات خارجی محدود نمی‌شود؛ مدیریت دسترسی‌ها و اعتماد به مشارکت‌کنندگان هم بخش مهمی از امنیت هر پروژه متن‌باز است.

- @MainPenguins | Source

ظهر تابناک🔆
بلیزارد بالاخره مشکل اجرای Diablo IV روی لینوکس و SteamOS را برطرف کرد

بعد از انتشار آپدیت Season 14، بازی Diablo IV روی لینوکس، SteamOS و Steam Deck دیگر اجرا نمی‌شد و قبل از باز شدن پنجره بازی کرش می‌کرد. این مشکل باعث شد تعداد زیادی از کاربران در انجمن‌های بلیزارد گزارش ثبت کنند.

حالا بلیزارد یک Hotfix اضطراری منتشر کرده که این مشکل را برای نسخه Steam برطرف می‌کند و کاربران دوباره می‌توانند بازی را روی لینوکس و Steam Deck اجرا کنند.

این اتفاق دوباره یادآوری کرد که هرچند Proton وضعیت گیمینگ روی لینوکس را فوق‌العاده کرده، اما یک آپدیت کوچک از سمت سازنده بازی هم می‌تواند همه‌چیز را از کار بیندازد؛ خوشبختانه این بار بلیزارد نسبتاً سریع واکنش نشان داد و مشکل را رفع کرد.

- @MainPenguins | Source

پسین نکو🌞
ابزار DLSS Updater 4.3.0 حالا به یک پنل کامل برای Upscalerهای Proton تبدیل شده

اگر روی لینوکس بازی می‌کنید، DLSS Updater دیگر فقط برای آپدیت کردن فایل‌های DLSS نیست. نسخه 4.3.0 حالا به یک پنل کامل برای مدیریت DLSS، FSR 4 و XeSS در بازی‌های Proton و Wine تبدیل شده است.

مهم‌ترین قابلیت‌های جدید:

فعال یا غیرفعال کردن DLSS، FSR 4 و XeSS بدون نیاز به حفظ کردن متغیرهای محیطی (Environment Variables)

تشخیص خودکار نسخه Proton هر بازی و نمایش فقط گزینه‌های سازگار

پشتیبانی از Steam، Heroic و Lutris

امکان به‌روزرسانی DLLهای Upscaler بدون دستکاری فایل‌های خود بازی

پشتیبانی بهتر از کارت‌های AMD، Intel و NVIDIA با رابط کاربری یکپارچه.

اگر زیاد با Proton سر و کار دارید، این ابزار می‌تواند دردسر تنظیم دستی Launch Options و مدیریت نسخه‌های مختلف DLSS، FSR و XeSS را تا حد زیادی از بین ببرد.

- @MainPenguins | Source