https://virgool.io/GNULand/feed نوشته‌های کاربران نرم‌افزار آزاد fa 2026-06-17 13:30:53 https://files.virgool.io/upload/publication/ad10o0610wv1/jzlgum.png https://virgool.io/GNULand https://virgool.io/GNULand/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%A7%D9%88%D8%A8%D9%88%D9%86%D8%AA%D9%88-%DB%B2%DB%B1%DB%B0%DB%B4-jlcci5yixrew تصویرزمینه‌ی اوبونتو ۲۰.۰۴در آستانه‌ی انتشار نگارش جدید اوبونتو هستیم. توی این مطلب سعی میکنم به برخی از نکات این انتشار بپردازم...یه عادت داشتم و اونم این بود که قبل از هر انتشار رسمی، بشینم و یه مطلب در مورد قابلیت‌ها و نکاتی که نگارش جدید داره مطلبی بنویسم. متاسفانه این روال رو در نسخه ۲۰.۱۰ شکوندم.اما بنظرم ایرادی نداره، خیلی سریع و کوتاه میپردازم به قابلیت‌ها و نکات نسخه ۲۰.۱۰ و سریع برمیگردم به اصل مطلب.اسم رمز انتشار نگارش ۲۰.۱۰ «Groovy Gorilla» بود. تاریخ نگارشش ۲۲ اکتبر ۲۰۲۰ بود.بطور کل تغییرات گسترده‌ای نداشت. اما از گنوم ۳.۳۸ استفاده میکرد و پشتیبانی از fingerprint login که بنظرم یکی از چیز‌های مثبت این قضیه بود.متاسفانه خیلی از درایور‌های سخت‌افزاری این موضوع رو خیلی از سیستم‌ها پشتیبانی نمیشه.البته تغییرات کوچیک توی این نسخه وجود داشت ولی خیلی چیز خاصی نبودن واقعا. بنابراین بریم سراغ اصل مطلبمون...خب اول ببینیم اسم رمز این نگارشمون یعنی چی؟احتمالا از عکس متوجه یه سگ آبی پر مو شدید که باید بگم دقیقا درست متوجه شدید. اسم این نگارش هست «Hirsute Hippo» که Hirsute میشه پر مو و Hippo کوتاه‌شده‌ی hippopotamus. در نتیجه اسم رمز این نگارش به فارسی میشه اسب‌آبی پر مو.اوبونتو داره تقریبا طبق حروف الفبای انگلیسی اسم رمز‌ها رو میره جلو. توی نسخه ۲۰.۰۴ «Focal Fossa» رو داشتیم که با F شروع میشد. بعد توی نگارش ۲۰.۱۰ «Groovy Gorilla» که با G شروع میشد و الان «Hirsute Hippo» که با H شروع میشه. احتمالا نگارش بعدی با I شروع بشه.توی این نگارش به نظر من تغییرات خوبی نسبت به نگارش ۲۰.۱۰ رخ داده.یه توضیحی این وسط بدم، طی تمام این سال‌ها، تغییرات گسترده دارن هعی کمتر و کمتر میشن. بنظر من دلیل این کم شدنه اینه که در نگارش‌های دسکتاپ گنو/لینوکسی داریم به یه ثبات میرسیم. چیزی که واقعا شاید تا الان نداشتیمش و یا کم داشتیمش. ثبات نه به این معنی که سیستم درجا خراب میشه، نه. ثبات به معنی این که از اون دوره هعی بپر روی این بسته بپر روی اون بسته داریم فاصله میگیریم و این میتونه هم خوب باشه و هم بد.تقریبا از نگار ۱۶.۰۴ تا ۲۰.۰۴ تقریبا شاهد تغییرات زیادی بودیم. از خود مدیریت بسته یا همون Package Manager تا مدیریت شبکه(Network Manager)، میزکار(Desktop) و ...اما به مرور این تغییرات کم شدن و شاهد یک ثباتیم.من شخصا این ثبات رو دوست دارم. شاید بخاطر سنمه که از اون دوره‌ی «همه چی رو تست کن و بزن خراب کن» گذشتم و الان صرفا دوست دارم یه سیستمی داشته باشم که همون دستورات قبلی که روش میزدم کار کنه و یهو سوپرایز نشم با یه Network Manager جدید.بگذریم، مدت زمان پشتیبانی این نگارش طبق معمول ۹ ماه هست و تاریخ انتشار این نگارش ۲۲ آوریل ۲۰۲۱ هست که میشه ۲ اردیبهشت ۱۴۰۰.لیست زیر، سایر تاریخ‌هاییه که اوبونتو برای انتشار این نگارش در نظر گرفته که شامل هفته‌ی امتحان، فریز رابطه کاربری، نگارش بتا، فریز کرنل و انتشار تقریبا نهاییه:Feature Freeze: February 25, 2021UI Freeze: March 18, 2021Ubuntu 21.04 Beta: April 1, 2021Kernel Freeze: April 8, 2021Release Candidate: April 15, 2021از تغییرات بگیم:یکی از بزرگ‌ترین تغییرات استفاده از گنوم ۴۰ هستش. حتی شایعه شده شاید توی این نگارش شاهد گنوم ۴۱ هم باشیم. باید ببینیم چی پیش میاد.کلی از برنامه‌هایی که معمولا همراه گنوم هستن هم مثل ترمینال، مدیریت پرونده، تقویم و ... دیگه تغییرات دارند.خود گنوم هم قطعا تغییرات ظاهری زیادی داشته که پیشنهاد میدم خودتون امتحانش کنید و تغییرات رو پیدا کنید.یکی دیگه از تغییرات بزرگ، استفاده از Wayland بصورت پیشفرض به جای X.Org هست که واقعا نمیدونم Wayland چقدر آماده‌ی این جا به جای بزرگ هستش.خیلی ساله که هعی میخوان Wayland رو جایگزین X.Org بکنن ولی بنا به دلایلی هیچ وقت این رخ نمیده. حالا رخ داده، اما باید ببینیم توی ادامه چی پیش میاد. من زیاد به موندن Wayland بصورت پیش‌فرض توی این نسخه امیدوار نیستم.البته Wayland قراره در این نگارش برای امتحانی برای نگارش بلند مدت بعدی باشه.قراره تم تاریک یا Dark Theme بصورت پیش‌فرض فعال باشه که من شخصا کلی باهاش حال کردم. من از طرفدار‌های Dark Theme هستم.یه سری تغییرات رو هم توی شکل آیکون‌ها داریم.ظاهرا توی این نگارش مجددا قابلیت رمزنگاری شاخه خونگی رو با قابلیتی جدید که Recovery Code باشه فراهم کردن.موقعی که من داشتم این نگارش رو نصب میکردم چنین چیزی رو ندیدم ولی در هر صورت بهش واقعا خوشبین نیستم. قبلا هم این گزینه بود و یه سری باگ‌های مسخره‌ای داشت.تغییر دیگه شخصی‌تر کردن شاخه خونگی کاربران مشترک روی یک سیستمه. ظاهرا یه باگی وجود داشته قبلا و الان با تغییر سطح دسترسی شاخه خونگی از ۷۷۵ به ۷۷۰ این مشکل رو حل کردن.انتظار میرفت این نگارش از نسخه‌ی GTK 4 بصورت پیش‌فرض استفاده کنه. اما چون خیلی از برنامه‌ها هنوز از GTK 4 پشتیبانی نمیکنن، قرار شده GTK 3 به پادشاهیش ادامه بده.لیست برخی تغییرات که شاید براتون جالب باشه:استفاده از ویلند(Wayland) بصورت پیشفرض برای Display Managerشخصی‌تر کردن شاخه خونگیکرنل لینوکس ۵.۱۱تم دارک بصورت پیش‌فرضآیکون‌های جدید برای دستکاپلیبره‌آفیس ۷.۱پایتون ۳.۹ بصورت پیش‌فرضدر آخر چنتا عکس از محیط نگارش جدید:منابع:۱. https://www.omgubuntu.co.uk/2021/01/ubuntu-21-04-release-features۲. https://www.omgubuntu.co.uk/2020/10/ubuntu-21-04-codename-revealed گنولند Sosha Tue, 20 Apr 2021 08:54:54 +0430 https://virgool.io/GNULand/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%A7%D9%88%D8%A8%D9%88%D9%86%D8%AA%D9%88-%DB%B2%DB%B0%DB%B0%DB%B4-%D9%88-%D8%AD%D9%84-%D8%A8%D8%B1%D8%AE%DB%8C-%D9%85%D8%B4%DA%A9%D9%84%D8%A7%D8%AA%D8%B4-poikceshttfm تصویرزمینه‌ی اوبونتو ۲۰.۰۴در حالی که خیلیا سرگرم اوبونتو ۱۹.۱۰ هستند و یا قراره سرگرمش بشن، اوبونتو چند مدت بعد از انتشار نگارش ۱۹.۱۰ رفت سراغ آماده شدن برای نگارش پشتیبانی بلند بعدی خودش یعنی "اوبونتو ۲۰.۰۴" با اسم رمزFocal Fossa.تقریبا هر چی قرار بود توی نگارش پشتیبانی بلند اوبونتو تغییر پیدا کنه رو شما توی ۱۹.۱۰ تجربه کردید. ولی باز هم تغییراتی توی این نگارش در حال رخ دادنه که سعی می‌کنم در این مطلب به مرور بنویسمشون، ولی انتظار تغییرات گنده نداشته باشید.اول ببینیم این اسم رمز یعنی چی.اگر از طرفداران انیمیشن مادگاسکار بوده باشید احتمالا این اسم رمز براتون یه طورایی آشنا باشه. "Fossa" نام حیوانی شکارچی و گربه مانند در جزیره مادگاسکار.(شایدم گربه‌ی بومی مادگاسکار؟)معنی "Focal" هم میشه «کانونی»، «مرکزی»... یه چیز توی همین مایه‌ها.من که هیچوقت نتونستم اسم‌ رمز‌های اوبونتو رو درست متوجه بشم. شما شدید؟ اگه شدید برامون بنویسید.این نگارش همانند نگارش‌های پشتیبانی بلند قبلی، ۵سال قراره روی دسکتاپ و سرور پشتیبانی بشه. اما، ظاهرا این نگارش به عنوان "extended maintenance release" قراره یه پشتیبانی ۱۰سال هم بگیره که صد البته وضعیت ESM رایگان نیست و برای مشاغل صنعتی و مشتریان Ubuntu Advantage هست.تاریخ رسمی انتشار این نگارش ۲۳ آوریل ۲۰۲۰ هست که میشه ۴ اردیبهشت ۹۹.لیست زیر، سایر تاریخ‌هاییه که اوبونتو برای انتشار این نگارش در نظر گرفته که شامل هفته‌ی امتحان، فریز رابطه کاربری، نگارش بتا، فریز کرنل و انتشار تقریبا نهاییه:Testing week: January 9, 2020UI Freeze: March 19, 2020Ubuntu 20.04 Beta: April 2, 2020Kernel Freeze: April 9, 2020Release Candidate: April 16, 2020از تغییرات بگیم:اولیش نسخه جدید تم "Yaru".توی این نسخه رنگ‌های اصلی این تم تغییر پیدا کردن به بنفش و نارنجی مانند(یه جورایی همون رنگای اصلی اوبونتو) و خاکستری(شایدم نوک مدادی) که من رو یاد رنگی که توی نوار یونیتی خدا بیامرز استفاده میشد انداخت.تغییر دیگه که خیلی افتضاحه و امیدوارم تحت فشار قرار بگیرن که برش دارن اونه که "Ubuntu Software" یا همون مرکز نرم‌افزاری اوبونتو قراره از این به بعد برنامه‌های "Snap Repository" رو براتون نصب کنه! یعنی اگر از اونجا برنامه‌ای رو نصب کنید، نسخه اسنپ اون براتون نصب میکنه! (پس هموطن، پشتاب برای استفاده از ترمینال)مورد بعد که شدیدا ازش استقبال میکنم تغییر چند برنامه‌ایه که بطور پیش‌فرض از طریق «اسنپ» نصب میشدن و به شدت دیر اجرا میشدن. برنامه‌هایی شامل ماشین حساب، لاگ، کاراکتر و ... . قراره این برنامه‌ها با مخزن "apt" جایگزین بشن.گنوم هم قراره تغییرات جالبی رو ایجاد کنه که اوبونتو هم قراره ازشون استفاده کنه.(پیام بازرگانی!)اضافه شدن برنامه‌ای جدید برای مدیریت اکستنشن‌ها.لیست برخی تغییرات که شاید براتون جالب باشه:گنوم ۳.۳۶ به همراه صفحه جدید lock screenکرنل لینوکس ۵.۴بهبود پشتیبانی از ZFS Installتصویر زمینه جدیدکم شدن حجم پرونده .iso اضافه شدن اکستنشن "Lightning" به تاندربیردپشتیبانی از چند مانیتور در GDMبهتر شدن وضعیت گیمینگعملکرد بهتر GNOME Shellاحتمالا این لیست بروز بشه و بهش چیزای دیگه هم اضافه بشه.بطور کل قراره توی این نگارش ما شاهد شکاف بیشتر بین مخزن‌های apt و اسنپ باشیم. هم یه جورایی قراره سبب خیر باشه و هم شر. این که قراره چی پیش میاد معلوم نیست. اما امیدوارم اسنپ کاملا جدا بشه به شکلی که نبودش سیستم رو خراب نکنه.همچنین توی این نگارش قراره کار خوب قبلی یعنی پشتیبانی از کارت‌گرافیک‌های انویدیا ادامه‌دار باشه. به این معنی که اگه حتی ۱۹.۱۰ مشکل کارت گرافیک شما رو حل نکرده، ۲۰.۰۴ احتمالا حل میکنه.نظر شخصیم اینه که این نگارش میتونه از نظر پایداری بسیار موفق‌تر از همه نگارش‌های قبلی خودش باشه و حتی توی جذب دوباره‌ی کسایی که بعد از یونیتی ازش جدا شدن هم موفق باشه ولی دچار درگیری با افرادی باشه که تمام این سال‌ها بهش تعصب داشتن و حالا بخاطر اجبار کردن مخزن اسنپ به کاربران ازش ناراضین.اما برسیم به حل مشکلات اوبونتو ۲۰.۰۴: خودم فعلا مشکل لود اکستنشن دارم. لود نمیشن که احتمالا بخاطر بروز نبودن اکستنشنام روی گنوم ۳.۳۵.۹۱ه.از مشکلات دیگه اینه که باید هر بار سیستم رو روشن میکنم، صدای میکروفن و هدست رو تنظیم کنم.(البته نسبت به بار قبلش که تنظیمش میکنید تغییر نمیکنه، اما براتون بصورت "Mute" نمایش میده)بازم استیم و مشکل کتابخانه‌های ۳۲بیت...اگه یادتون باشه توی بررسی اوبونتو ۱۹.۱۰ و حل برخی مشکلاتش در مورد استیم و این که کتابخانه‌هاش به زودی منفجر میشن صحبتایی کرده بودم و اینجا این اتفاق رخ میده.اگر با پیغام You are missing the following 32-bit libraries, and Steam may not run:libgcc_s.so.1 خطای رو به رو شدید، باید بسته‌ی lib32gcc1 رو نصب کنید. این مشکلتون رو حل میکنه.مشکل دیگه‌ای فعلا ندارم اما خب احتمالا شرایطم تا روز انتشار تغییر پیدا کنه.این چند عکس رو هم از اوبونتو ۲۰.۰۴ ببینید:منبع: https://www.omgubuntu.co.uk/2019/10/ubuntu-20-04-release-features گنولند Sosha Wed, 04 Mar 2020 06:57:55 +0330 https://virgool.io/GNULand/everything-about-wasm-qciuv9gq72pl توی این مطلب سعی‌ می‌کنم یه نگاه نسبتا عمیق به وضعیت الان WebAssembly و فردای اون داشته باشم. درواقع یک جمع بندی از وضعیت فعلیش و همچنین چیزایی که خودتون در آینده بیشتر دنبالش کنید.چی هست؟وب اسمبلی یک زبان بهینه و سطح پایین به صورت Bytecode برای وب هست که توی یک ماشین مجازی اجرا می‌شه (با اون ویرچوال باکس که خیلی‌ها شنیدیم فرق می‌کنه اون رو از ذهنتون پاک کنید).فرض کنیم 0x6a یک دستور بایت‌کد در این زبان هست که معادل متنی اون می‌شه add (تابع جمع). حالا شما این امکان رو دارید که به زبان‌های مختلف (Rust, Go, C, CPP ...) کد بنویسید و اون رو تبدیل کنید به WASM (بخونید وزم - مخفف وب اسمبلی).مثلا شما می‌نویسید:int sum = 1+2;و مثلا تبدیل می‌شه به:0x6a 0x01 0x02این قالبی هست که WASM داره و کدی که شما نوشتید «کامپایل می‌شه» بهش که مرورگر اون رو می‌فهمه و اجرا می‌کنه. اگه مطلب قبلی من رو خونده باشید و یا با JIT آشنایی دارید (اگه ندارید اینجا رو بخونید) فوری مشخص می‌شه که وقتی یک کد از قبل کامپایل شده باشه دیگه مرورگر نیاز نداره خروجی اون رو «حدس بزنه» و کلی ژانگولر انجام بده در نتیجه سرعت اجرای WASM بسیار بالا تره.آیا وب اسمبلی از جاوا اسکریپت سریع تره؟خب اره، ولی آیا همچین مقایسه‌ای درسته؟ بذارید اینطوری بهتون بگم:یه آزادراه رو در نظر بگیرید که دوتا ماشین دارن توش حرکت می‌کنن؛ یکی شون پول عوارضی رو آنلاین پرداخت کرده و دیگه نیاز نیست همش وایسه و پول بده اما اون یکی باید دم هر عوارضی توقف کامل کنه و پول بده ...ماشین اول، در تمام سفر با نهایت سرعتی که توی آزادراه مجاز هست حرکت می‌کنه ولی ماشین دوم «گاهی وقت‌ها» به نهایت سرعت مجاز می‌رسه و بعد باید توقف کنه و ...مراحل کامپایل و اجرا شدن جاوا اسکریپتدرواقع وب اسمبلی چون کامپایل می‌شه با «نهایت سرعت» و «کارایی» قابل ارائه توسط محیطی که در اون اجرا می‌شه (در اینجا مرورگر) کار می‌کنه اما جاوا اسکریپت چون باید از JIT رد بشه «ممکنه» به سرعت نهایی برسه ولی خیلی وقت‌ها این اتفاق ممکن نیست.مراحل کامپایل و اجرا شدن وب اسمبلیهمونطور که می‌بینید مرحله Parse کردن حذف شده، درواقع جاوا اسکریپت باید یکبار به AST تبدیل بشه و بعد اون رو تبدیل کنن به بایت‌کد که بعد توسط مرورگر کامپایل و بهینه سازی بشه ... ولی این مرحله توی وب اسمبلی نیاز نیست چون خودش یکبار کامپایل شده و به صورت بایت‌کد به مرورگر ارائه می‌شه. مرورگر فقط نیاز داره اون رو decode کنه که خیلی سریعتر و راحت تر از Parse کردن هست.بعلاوه چون این کد فشرده شده دریافت کردنش هم (یعنی دانلود اون توسط مرورگر) خیلی سریعتر از جاوا اسکریپت اتفاق می‌افته. هرچند مثلا gzip کردن جاوا اسکریپت حجم فایل رو کاهش می‌ده ولیکن خب gzip کردن وب اسمبلی هم حجمش رو «بیشتر» کاهش می‌ده ...یه مرحله دیگه توی JIT هست تحت عنوان Reoptimization. یعنی بر اساس کدی که بهینه شده باید درباره «قدم‌های بعدی» اون همزمان با اجرا؛ تصمیم گرفت. فرض کنید 100 تا Object دارین که 99 تاش بهینه شدن ولی موقع اجرا مشخص می‌شه که Object آخر بهینه نیست. اینجا اون «انتظار» که از اجرای کد داشتیم براورده نشده و دوباره باید بهینه سازی انجام بشه ... که این مرحله توی WASM نیاز نیست.پس، بله! وب اسمبلی سریع تره ولی دوتا ماشینه رو یادتونه؟ حالا فرض کنید اونی که سریع ترین سرعت رو داره مسیر رو بلد نیست ولی اونی که سرعتش کمتره بلده از یه راه کوتاه‌تر بره و مجبور نیست کل آزادراه رو طی کنه.یعنی چی؟ خب ببینید یه چیزی مثل DOM Manipulation درحال حاضر توی وب اسمبلی کندتره چون API اون بهینه نشده... (ولی روش کار می‌شه) پس قرار نیست یک شبه جای جاوا اسکریپت رو بگیره. اما توی خیلی از زمینه‌ها مشکلات و محدودیت‌هایی که جاوا اسکریپت داره رو برطرف می‌کنه و ویژگی‌های قابل توجه‌ای به وب اضافه می‌کنه - اینم بگم، خیلی وقتها لازمه از دنیای جاوا اسکریپت بریم توی دنیای WASM و برگردیم، قبلا این عملیات خیلی کند بود ولی الان سریع شده.مثلا وب اسمبلی برای بازی کردن توی مرورگر خیلی خوبه یا حتی شرکت ادوبی محصول Lightroom رو با وب اسمبلی نوشته تا توی مرورگر قابل استفاده باشه. همه اینها باعث می‌شن که بهش به عنوان یک زبان جدید برای وب نگاه کنیم ... (این ویدیو هم ببینید)آیا می‌تونیم جاوا اسکریپت رو به وب اسمبلی تبدیل کنیم؟نه، جاوا اسکریپت خیلی زبان داینامیک و پیچیده‌ای هست. وب اسمبلی بایت کدی تولید می‌کنه که نوع داده‌ها توی اون استاتیک هستن بعلاوه توی وب اسمبلی هنوز Garbage Collection پیاده سازی نشده و باید خودتون مدیریت حافظه رو در دست بگیرید.تایپ اسکریپت «شاید» در آینده به طور رسمی به وب اسمبلی کامپایل بشه چون به نظر می‌رسه تایپ‌هاش رو اضافه کردن. اما خب یه پروژه دیگه هست به اسم AssemblyScript که دقیقا کارش همینه (ولی یه تیم جداست).شکل دستوراتبه این قطعه کد از پروژه اسمبلی اسکریپت نگاه کنید:(module (memory $0 0) (table $0 1 funcref) (export &quotmemory&quot (memory $0)) )این چیه؟ چرا این شکلیه؟ -- این قطعه کد یک «بیان متنی» از بایت کدهای وب اسمبلی هست. که تحت عنوان WAST شناخته می‌شه. اگه فکر می‌کنید شبیه Lua هست کاملا درسته چون به این شکل از نوشتن میگن S-expressions که توسط زبان Lua ابداع شده.این شکل از نوشتن، به اندازه کافی انتزاعی هست که یک انسان بتونه بخونه و بنویسه و در عین حال یک ماشین با کمترین هزینه ترجمه کنه (بیشتر بخونید). شما می‌تونید به جای Rust یا Go مستقیم توی WAST کد بزنید و کامپایل کنید به WASM. این کار رو کسی نمی‌کنه بجز کسانی که می‌خوان به خود وب اسمبلی یه چیزی اضافه کنن. چون، همه چیز سطح پایین و در کنترل شماست و تقریبا چیزی جلودار خرابکاری‌ها نیست.هرچند اگر، تمایل به نوشتن WAST دارین باید حتما درمورد Stack-oriented programming و Stack machine اطلاعات زیادی داشته باشید. چون وب اسمبلی جز زبان‌های پیرو Stack machine هست.حالا که می‌دونید WAST چیه؛ بیاید 1 رو با 2 جمع بزنیم تا بهتون نشون بدم «پیرو استک ماشین» بودن یعنی چی:(i32.add (i32.const 1) (i32.const 2) )این بیان متنی همون بایت کد (0x6a 0x01 0x02) مربوط به عمل جمع هست که توی استک به این شکل هست:اجرای دستور جمع در Stackالبته این یه مثال فرضی هست، کامپایلر هیچوقت برای مقادیر ثابت مثل 1 و 2 استک در نظر نمی‌گیره چون خروجی همون لحظه می‌تونه تشخیص داده بشه که 3 هست ... ولی منظور من اینه که دقیقا مثل یک استک دستورات Push و Pop می‌شه پس شما «باید» بلد باشین با «کمترین» حرکت ممکن دستور یا عملیات خاصی رو پیاده سازی کنید.امیدوارم الان متوجه شده باشید که چرا مقایسه کردنش با جاوا اسکریپت از یک جنبه سطحی (مثل سرعت) معقول نیست.ویژگی‌های اصلی و فرعیچهار رکن اصلی WASMتا اینجا فهمیدیم که یک زبان مثل اسمبلی هست، پس می‌شه باهاش برنامه‌های دسکتاپ رو کامپایل کرد به چیزی مثل x86 و توی «یک محیط» اجرا کرد (1). و اینکه حجمش بسیار کمه برای همین انتقال دادن میزان زیادی از کد توی وب راحت انجام می‌شه‌ (2) و درمورد نحوه اجرای دستورات صحبت شد که نشون دادم چرا سریعه (3) ...اما، ما که نمیتونیم یه برنامه‌ای رو از وب دانلود کنیم و بهش اجازه بدیم از تمام حافظه استفاده کنه. برای همین مدیریت حافظه توی وب اسمبلی به صورت خطی انجام می‌شه. درواقع وب اسمبلی می‌ره یک بخشی از حافظه سیستم رو «اجاره» می‌کنه و بعد اون رو به شکل یک آرایه در اختیار برنامه‌ها قرار می‌ده. اینطوری یک برنامه نمی‌تونه از اون فضا خارج بشه.(4)این فقط «شروع راه» بود! خیلی ویژگی دیگه داره اضافه می‌شه و یا به مرحله‌ای رسیده که علاقه منداش می‌تونن استفاده کنن.مثلا پشتیبانی از multithreading، به مرحله چهار از پیاده سازی رسیده (شیش مرحله داریم از 0 تا 5، مرحله پنجم دیگه تمیز کاری نهایی و پذیرفته شدن کامل اون ویژگی هست). درواقع multithreading این امکان رو داره که فعالیت‌های مختلف یک برنامه رو به بخش‌های کوچیک تقسیم کنیم و بعد به صورت همزمان انجام بشن تا خیلی خیلی سریعتر اون فعالیت به اتمام برسه.یا مثلا پشتیبانی از SIMD که خیلی ساده بگم؛ شما مثلا یه عملیات دارین که «ممکنه» 64 بیتی باشه پس به اندازه یک عملیات 64 بیتی حافظه رزرو می‌کنید. اما اون مجموعه از داده‌ها که عملیات روش انجام می‌شه «ممکنه» همش 64 بیتی نباشه مثلا شاید دوتا 32 بیتی داری. خب اگه یکی یکی انجامش بدی هر بار 32 بیت از حافظه اضافه میاد که الکی رزرو شده. برای همین اگه اون عملیات رو همزمان روی هردوتاشون انجام بدی اینطوری هم از حافظه به خوبی استفاده کردی و هم سرعت پردازش بالا میره. (یه ویدیو جالب).از جهت «بهینه شدن کد و اجرای سریعتر» هم راه‌ حل‌های جالبی ارائه شده مثل Streaming compilation و Tiering compiler که یعنی به محض رسیدن یک قسمت از کد به کامپیوتر؛ همزمان یه مرحله کامپایل می‌شه.بعدش هم وقتی که همه کد رسید یه دور دیگه کامپایل می‌شه تا بهینه‌ترین حالت خودش قرار بگیره. ایده اینه که ما عادت داریم وقتی یه برنامه رو روی کامپیوتر خودمون باز می‌کنیم بتونیم اون رو فوری استفاده کنیم پس، وقتی هم که از اینترنت یه قطعه کد دانلود می‌شه باید بتونیم همونطوری سریع اجرا و استفاد کنیم.قابلیت Implicit HTTP caching هم خیلی جالبه یعنی یک بار که کد کامپایل و بهینه شد دیگه همون نسخه رو می‌تونی اجرا کنی و نیاز به کامپایل و بهینه سازی مجدد نیست. (و کلی ویژگی باحال دیگه مثل Garbage Collection و Exception Handeling و Debuging که اینجا می‌تونید بخونید.)پس؛ با وجود این همه ارکان فرعی که درحال اضافه شدنه یه بحث جذاب شکل گرفته و اونم استفاده از وب اسمبلی در بیرون از وب هست برای IoT یا پردازش ابری و ...وب اسمبلی بیرون از وبچرا بالا تر گفتم «محیط اجرا» و مستقیم نگفتم مرورگر؟ به خاطر اینکه؛ در هیچ کجا ذکر نشده که «باید حتما مرورگر باشه» و بلکه فکرهایی شده برای اینکه خارج از مرورگر هم بشه از وب اسمبلی استفاده کرد.اما به چه درد می‌خوره؟ خب همیشه وقتی به وب فکر می‌کنیم یاد HTML CSS JS میوفتیم اینها «کدهای یه نفر دیگه» هستن که ما «یه راهی پیدا کردیم که با خیال راحت اجراش کنیم». مثلا فرض کنید جاوا اسکریپت به همه سیستم دسترسی داشت و یه کتابخانه معروف مثل React می‌تونست بعدا یه کد مخرب به آپدیت جدیدش اضافه کنه و همه وبسایت‌ها آلوده می‌شدن ...می‌دونم الان با اخم به پاراگراف نگاه می‌کنید. خب React که متن بازه همه می‌تونن سورسش رو ببینن. آره؛ اما آیا همه وب متن بازه؟ همه وب قابل اعتماده؟ یا حتی اون قسمت‌هایی که متن باز هستن اگه یه روزی شیطنت کنن ما «بلافاصله» می‌فهمیم؟ یا بعد چند روز/ماه که گندش در اومد؟خب خوشبختانه مرورگرها خیلی زحمت می‌کشن که یه محیط ایمن و Sandbox ایجاد کنن که این اتفاق‌ها خیلی کم رخ بده و کدها فقط به اون چیزی که اجازه دارن دسترسی پیدا کنن ... پس بحث همینه؛ وقتی وب اسمبلی رو به چشم یک Sandbox نگاه کنیم استفاده ازش خارج از مرورگر می‌تونه خیلی پر کاربرد باشه.یه موضوع دیگه Portability هست. الان وبسایت‌ها فارغ از اینکه بدونن معماری پردازنده شما چیه کد جاوا اسکریپت می‌نویسن و اجرا می‌شه چون مرورگر سکوی اجراست و اون تشخیص می‌ده.دقیقا NodeJS هم هدفش این بود دیگه که جاوا اسکریپت رو بتونی خارج از مرورگر هم اجرا کنی... اما حتی اونجا هم مجبوری یه ماژول CPP بنویسی اگه سرعت بالا می‌خوای.خب، وقتی بتونیم ایمنی رو با Sandbox ارائه کنیم و Portability در کنارش باشه نتیجه اینه که می‌تونیم بدون نیاز به کانتینر؛ فضای اجرای یک قطعه کد رو محدود کنیم و کدهای بیشتری رو در زبون‌های مختلف روی یک ماشین اجرا کنیم. کجا این قضیه به درد می‌خوره؟ خب معلومه توی FaaS.بعلاوه ماهیت وب اسمبلی طوریه که واقعا به زبان ماشین خیلی نزدیکه؛ در نتیجه اگه بشه روی دستگاه‌های IoT ازش استفاده کنیم عملا این امکان رو داریم که با پایتون و تایپ اسکریپت و خیلی زبون‌های دیگه شروع کنیم به برنامه نویسی روی اونها دیگه بازارش محدود نیست به زبان C و پیچیدگی‌های آنچنانی از بین میره.روند اجرا بیرون از مرورگر چطوریه؟روی خیلی از سیستم‌ها یک زبان برنامه نویسی به طور مستقیم به شبکه، حافظه، سیستم‌فایل و غیره دسترسی نداره. چرا؟ چون اگه برنامه‌ها حق داشته باشن آزادانه از تمام منابع استفاده کنن بالاخره چه عمدی یا غیر عمدی سو استفاده رخ می‌ده.حالا سیستم‌عامل یک سری توابع تحت عنوان System Call ارائه می‌کنه و هر قطعه کدی که به منابع سیستم نیاز داشته باشه باید اون توابع رو صدا بزنه و از اونها درخواست کنه.اصطلاحا به این میگن یک برنامه user space که توی حلقه 3 اجرا می‌شه. درواقع سیستم‌عامل یک سری حلقه امنیتی داره و بحث ما مربوط میشه به حلقه سوم.خب، طبیعتا هر سیستم عاملی مجموعه توابع خودش رو داره درسته؟ و این یعنی ما باید کدهای متفاوت بنویسیم برای سیستم‌عامل‌های متفاوت.اما چرا این حرکت لازم نیست؟ به خاطر اینکه اکثر زبون‌های برنامه نویسی خیلی چیزا رو به صورت انتزاعی پیاده می‌کنن (مثلا تابع خواندن از فایل رو توی کتابخانه استاندارد خودشون به برنامه نویس ارائه میدن) بعدش در لحظه کامپایل بر اساس سیستم هدف؛ system call های مورد نیاز رو جایگزین اون لایه انتزاعی می‌کنن و پورتابل شدن از این رویه میاد.اما وب اسمبلی برای یک ماشین فرضی کد تولید می‌کنه یعنی درواقع نمی‌دونه معماری و سیستم‌عامل حاضر روی ماشین چیه. بنابراین همچین اتفاقی میوفته:شما کدتون رو توی یکی از زبانهایی که وب اسمبلی پشتیبانی می‌کنه می‌نویسید. بعد یک «تفسیر» از اون کد تولید می‌شه که کامپایلر وب اسمبلی از اون استفاده می‌کنه تا با دیتا تایپ‌های خودش تطابق بده و بایت‌کد تولید کنه. مثلا چیزی تحت عنوان Struct توی وب اسمبلی نیست این باید تبدیل بشه به چی؟ کار IR تفسیر همچین شرایطی هست.توی فضای وب، مرورگر می‌شه runtime وب اسمبلی و مسئول تبدیل بایت‌کد WASM به کد ماشین (پس اینطوری پورتابل می‌شه).بعدش یک سری system call در اختیار وب اسمبلی قرار می‌ده و اونهم بر اساس نیازهای برنامه درحال اجرا اون توابع رو در اختیار برنامه قرار می‌ده. (اینطوری ایمنی به شکل Sandbox پیاده می‌شه).به همین جهت بیرون از وب هم به یک runtime نیاز داریم که دوتا از معروف ترین هاش WAVM و Wasmtime هستن.اما یه سوال دیگه، بیرون مرورگر کی قراره شرایط Sandbox رو دیکته کنه؟ کی قراره به ما بگه کدوم syscallها رو در اختیار داریم و کدوما رو نداریم؟رابط بین وب اسمبلی و سیستم میزبانوزی (WASI) یا همون رابط بین وب اسمبلی و سیستم میزبان یک سری قرارداد هستن که هر runtime باید اونها رو پیاده کنه و Sandboxing از این طریق به برنامه‌های درحال اجرا دیکته می‌شن.توی حالت عادی برنامه‌ها مسیری که نیاز دارن رو به صورت یک رشته به سیستم عامل می‌دن و بعد سیستم عامل چک می‌کنه که آیا کاربری که این برنامه رو اجرا می‌کنه دسترسی داره به اون مسیر یا نه؟ و چون رشته هست، عملا وقتی دسترسی بهت داد می‌تونی فراتر از اونهم پیش بری.ولی مستندات WASI اینطوری تعریف شده که، سیستم میزبان یک مسیر رو در اختیار runtime قرار می‌ده بعد وقتی برنامه درحال اجرا درخواست می‌کنه که از مسیر x فایل y رو بهم بده، بهش یک file descriptor برگشت می‌ده. یعنی برنامه دیگه فقط حق داره روی فایل y عملیات انجام بده و «اگر» نیاز شد می‌تونه بقیه مسیر x رو طی کنه. اما نمی‌تونه فراتر از x بره.همچنین این سطح دسترسی «از برنامه به برنامه دیگه» فرق می‌کنه و یکسان نیست. همه برنامه‌ها به طور پیشفرض به کل مسیر x دسترسی ندارن.این تعاریف ماژول بندی شدن؛ فعلا بحث‌های سیستم‌فایل و شبکه و غیره توی wasi-core قرار گرفته و این سیستم ماژول بندی باعث می‌شه که بعدا افراد جامعه کاربری ماژول‌های خودشون رو توسعه بدنمثلا خیلی چیزا توی wasi-core داره استاندارد‌های POSIX رو دنبال می‌کنه و چیزایی مثل read,open,close توش پیاده سازی شدن اما بحثی مثل fork واقعا پیچیده هست و نمی‌شه همون مسیر POSIX رو دنبال کرد و در عین حال، به خاطر ماژولار بودن این روال؛ شانس «استاندارد سازی» fork هست و بعدا می‌تونه به عنوان یک ماژول جدا اضافه بشه.برای یک زبونی مثل Rust خودش مستقیم این توابع رو توی اون لایه انتزاعی صدا می‌زنه ولی برای زبون‌های دیگه مثل c و cpp کتابخانه wasi-libc وجود داره.مثلا Rust توی اون لایه انتزاعی یه شرط گذاشته که «اگه قرار بود به WASM کامپایل بشی، باید از wasi syscalls استفاده کنی» زبون‌های دیگه مثل python می‌تونن از اون کتابخانه wasi-libc استفاده کنن و کتابخانه‌های بومی اون زبان رو تولید کنن.حالا پورتابل بودن در کنار امنیت برقرار می‌شه و همزمان «تعریف امنیت» بین هر runtime می‌تونه متفاوت باشه مثلا node یک سری دسترسی بیشتر بده ولی firefox کمتر و همون کد (با سطح دسترسی‌های متفاوت) روی جفتشون اجرا می‌شه ...درست مثل ویژگی‌های فرعی که کم کم اضافه می‌شه؛ یک سری ماژول فرعی هم مثل asynchronous I/O یا file watching و غیره اضافه می‌شن و به مرور دنیای بیرون از مرورگر هم بهتر و بهتر می‌شه.پاسخ به سوالات توییتر+ الان blazor بیاد استقبال میشه ازش؟خب، موسی به دین خود. عیسی به دین خود!. محصولات مایکروسافت همیشه پیروان دو آتیشه خودش رو داره پس در زنده موندن blazor شکی نیست؛ اما وب اسمبلی توی زمینه‌های بزرگتری فعالیت می‌کنه بنابر این اگه بخوایم کلاس بندی کنیم میشه رقیب blazor در زمینه وب. یا میشه رقیب Firecracker در زمینه FaaS. هیچوقت کاملا جایگزینش نمیشه.+ آیا آینده‌ای داره، یا مثل سیلور لایت زود آفتابش غروب میکنه؟بله، اینده خیلی خوبی داره و نه! مثل سیلور لایت سرش نمیاد. بالا تر گفتم باید وب اسمبلی رو کلاس بندی کنیم؛ پس اگه در زمینه وب شکست بخوره در زمینه‌های دیگه آینده داره ...تو Back-End هم استفاده می‌شه؟نه به شکلی که NodeJS حضور داره بلکه در مقیاس بزرگتر. مثلا بازار سرویس‌های PaaS کمرنگ می‌شه و ظهور و فعالیت سرویس‌های FaaS پررنگ تر.بیاید به سرویس فندق (لیارا/اروان) نگاه کنیم؛ چه چیزی باعث می‌شه فندق هزینه‌اش زیاد بشه؟ خب؛ یه سری بحث مثل لود بالانسر یا پشتیبانی و فایروال و غیره هست که توی IaaS هم وجود داره پس این فاکتور‌ها رو نمی‌تونیم دستکاری کنیم.ولی آیا می‌تونیم با یه نرخ معقول «کانتینر بیشتر بسازیم»؟ الان فندق مثل اینه که یه زمین رو اجاره کرده و روش یه هتل ساخته و داره اتاق‌هاش رو کرایه می‌ده .. من نمی‌تونم «نصف یک اتاق» رو اجاره کنم یا «یه اتاق و نیم» رو اجاره کنم درسته؟این باعث می‌شه که اتاق‌هایی با اندازه مشخص اجاره بده و حتی اگه مهمان بین ساعت 7صبح تا 4 ظهر توی اتاقش نیست اون نمیتونه به کس دیگه اجاره بده؛ چمدون‌هاش توی اتاقه (همون registry).پس متوجه می‌شیم که هدف PaaS «سهولت در توزیع/انتشار یک محصول» هست ولی لزوما در «کاهش هزینه» موثر نیست.یه ذره عمقی‌تر صحبت کنم؛ توی شرایط داکر، فهمیدن اینکه «کی چقدر منابع مصرف کرده» سخته و راه آسون تر اینه که بگیم تو 8 گیگ رم داری و 4 هسته پردازنده؛ قیمت اجارش می‌شه اینقدر ...یه ذره منطقی‌تر اینه که اجاره رو روزانه حساب کنیم و مشتری هر لحظه بتونه منابع رو گسترش بده. تا اینطوری از کم شروع کنه و بعد پله پله زیاد کنه؛ یا اگه جمع کرد فقط تا اون روزی که استفاده داشته پول بده.اما وقتی مشتری فندق زیاد می‌شه نمی‌تونه روی همون زمین بازم اتاق هتل بسازه باید بره زمین بیشتر اجاره کنه ...از این طرف FaaS بحث‌های لود بالانسر و فایروال و غیره رو داره و در عین حال می‌تونی به اندازه‌ای که کدت از cycle‌های پردازنده و باقی متریک‌ها استفاده کرده پول بدی. و وقتی کدت اجرا نمیشه‌ همزمان یه نفر دیگه از منابع می‌تونه استفاده کنه.استخراج این متریک‌ها از وب اسمبلی کاملا ممکن هست، بعلاوه سبک بودن runtime اون در کنار قوانین WASI و پورتابل بودنش بهش این امکان رو می‌ده که کدهای «هر زبانی» خیلی «سریع» و «بدون ایجاد تداخل برای کد‌های دیگه» اجرا بشن.شرکتی مثل fastly کاملا از این موقعیت سود می‌بره. چرا؟ خب اونها کلی سرور سراسر دنیا دارن که باید به صورت عادی ترافیک زیادی رو تحمل کنه؛ فایروال و لود بالانسر و بقیه چیز‌ها هم که وجود داره. این‌ها اومدن runtime خودشون رو توسعه دادن که بتونن سرویس FaaS ارائه بدن روی سرورهاشون و انقدر سریعه که بر اساس هر درخواست یک sandbox بالا میارن (فکر کنم در حدود 60 نانو ثانیه طول می‌کشه تا هر sandbox بالا بیاد).البته، قصد من از این مقایسه نادیده گرفتن زحمات فندق یا بقیه نیست. به این اشاره می‌کنم که خیلی از فرایند‌های stateless رو میشه با هزینه کمتر اجرا کرد. و اینم بگم PaaS به کلی از بین نمیره مثلا یه برنامه موبایلی رو در نظر بگیرید که نیاز داره محاسبات خاصی انجام بده و نتیجه رو ذخیره کنه. در اینجا زیرساخت پایگاه داده رو می‌تونم ببرم روی PaaS و اون تابع رو ببرم روی FaaS.کلام پایانیمن سعی کردم جریانی که از 2017 شروع شده تا الان رو توی یک مطلب جمع کنم برای همین خیلی فشرده شد ... مثل تور بازدید از اماکن یه شهر؛ حالا اگه علاقه مند بودید بعد از خوندن این مطلب می‌تونید برید یه جنبه خاص از وب اسمبلی رو یاد بگیرید.اینبار سعی کردم توی توییتر از بقیه سوال کنم و موضوع رو بر پایه اون سوالات بچینم. به خاطر اینکه هرموقع درمورد یه موضوعی می‌نویسم یا توییت می‌کنم بعدش سوالاتی هست که من نمی‌تونم توی اون فضای کاراکتری محدود توییتر جواب بدم... اگه به نوشته‌های من علاقه دارین توی توییتر منو دنبال کنید؛ شاید مطلب بعدی یکی از سوالات شما بود.منابع (بیشترش حول صحبت های Lin Clark هست) :"Isolation without Containers" by Tyler McMullenRust, WebAssembly, and the future of Serverless (DevFest 2019)Bringing WebAssembly outside the web with WASI by Lin ClarkGOTO 2018 • A Cartoon Quest: New Adventures for WebAssembly • Lin ClarkWebAssembly DemystifiedWebAssembly Articles گنولند هادی اعظمی Mon, 24 Feb 2020 06:25:01 +0330 https://virgool.io/GNULand/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%A7%D9%88%D8%A8%D9%88%D9%86%D8%AA%D9%88-%DB%B1%DB%B9%DB%B1%DB%B0-%D9%88-%D8%AD%D9%84-%D8%A8%D8%B1%D8%AE%DB%8C-%D9%85%D8%B4%DA%A9%D9%84%D8%A7%D8%AA%D8%B4-mobq5m8ta5ow دو ماهی هست که از انتشار اوبونتو ۱۹.۱۰ با اسم‌رمز eoan ermine میگذره. احتمالا شمایی که این مطلب رو داری میخونی از موقع انتشار رسمی رفتید سراغش و یا این که قراره برید. اما من نزدیک به چندین ماه طولانی هست که روی اوبونتو ۱۹.۱۰ هستم. یه چیزی حدود ۵ الی ۶ماه. توی تمام این مدت مشکلات و اتفاقات بسیاری رو در روند توسعه‌ی این نگارش دیدم. پیش خودم گفتم شاید بد نباشه که این مسائل رو با بقیه هم به اشتراک بذارم.اول یکی از مزیت‌های اوبونتو ۱۹.۱۰ بگم:توی این نگارش شرکت انویدیا با کنونیکال برای حل مشکل گرافیک کاربران همکاری کرده و این همکاری باعث شده که اوبونتو درایور ۴۳۰ رو بطور پیشفرض توی iso نگارش بذاره تا مشکل درایور کاربرا از همون اول حل بشه.این اتفاق اتفاق خیلی خوبیه، احتمالا شروعیه برای پشتیبانی هر چه بهتر توزیع‌های گنو/لینوکسی توسط انویدیا. انویدیایی که بخاطر عدم همکاری مناسب با توسعه‌دهندگان توزیع‌ها مورد لطف لینوس تروالدز قرار گرفت.در مورد خود من، تقریبا سال پیش توی همین موقع‌ها بود که اوبونتو یک بروزرسانی برای کرنل منتشر کرد. من خیلی ساده زدم که سیستم بروز بشه، سیستم بروز شد اما دیگه اوبونتو اون اوبونتو سابق نشد. اتفاقی که بعد از بروزرسانی افتاد باعث شد که من به مدت تقریبا ۸ماه دیگه نتونم از اوبونتو روی سیستم اصلیم استفاده کنم و به اجبار برم روی ویندوز.مشکل این بود که درایور کارت گرافیکم توسط کرنل امضا نمیشد، متن خطا: pkcs #7 signature not signed with a trusted keyجالب اینجاست که مشکل توی همه کارت‌های گرافیک حل شد بود جز کارت گرافیک سری من که NVIDIA GTX 1050Ti بود. حتی برای برخی با خاموش کردن secure boot هم مشکل رفع میشد اما برای سری من نه. در نتیجه همینطوری منتظر یه فرجی مونده بودم که بعد از هشت ماه رسید. خلاصه بعد از اون موقع بود که تونستم به اوبونتو برگردم و دوباره شروع کنم شیرجه زدن توی عمق اوبونتو و باهاش سر و کله بزنم تا مشکلاتش رو پیدا کنم و گزارش کنم.این اولین مشکلی بود که توی اوبونتو ۱۹.۱۰ حل شده بود.مشکل دوم با قلم سیستم بود. قبلا با ایجاد یه پرونده به اسم .fonts توی شاخه خونگی تنظیمات قلم سیستم رو تغییر میدادیم. اما توی نگارش ۱۹.۱۰ شما باید از مسیر زیر برای تغییر قلم سیستم اقدام کنید:/etc/fonts/conf.d/51-local.confهمون پیکربندی رو که توی .fonts میزدید رو همینجا بذارید کار میده.مشکل سوم استیم بود، استیم اومد اعلام کرد که دیگه از اوبونتو پشتیبانی نمیکنه و این یعنی یه خبر فاجعه‌آمیز برای کاربرای گنو/لینوکس که روی توزیع‌هاشون بازی میکردن. بعدا استیم بنا به دلایلی از تصمیم قبلی خودش صرف‌نظر کرد و دوباره اعلام کرد که از اوبونتو پشتیبانی میکنه. اما مشکل این بود که بعد از اون خبر تا مدتی استیم روی اوبونتو نصب نمیشد و بعد از این که نصب شد بالا نمیومد. متن خطا این بود:اجرا نشدن استیمراه‌حل منطقی براش پیدا نکردم اما اگر روی xorg هستید احتمالا با حذف محتویات پوشه .steam و یا ایجاد یه یوزر جدید مشکلتون حل بشه. برای خود من با انجام هر دوی این‌ها درست شد. درواقع همیشه پوشه رو حذف میکردم درست نمیشد اما اونبار نمیدونم چرا درست شد.برای این که بدونید رو xorg هستید و یا wayland دستور زیر رو بزنید:echo $XDG_SESSION_TYPEمشکل چهارم با افزونه پیشفرض gnome-shell-extension-appindicator بود. این افزونه مدت زیادی هست که بروز نشده و با گنوم‌های جدید ناسازگاری داره.توی مورد من باعث میشد وقتی من از دیسکورد استفاده میکنم و میکروفنم روشن میشه، تصویر برام لگ بشه. فرقی نمیکرد چی میدیدم، کلا همه ویدئو‌ها توی همه برنامه‌ها(از تلگرام گرفته تا توییتر و VLC) همه لگ میشدن.با بررسی لاگ متوجه این پیغام شدم:Dec 2 11:14:57 Sosha-PC gnome-shell[1978]: [AppIndicatorSupport-FATAL] unable to update overlay iconراه حل؟ حذف بسته gnome-shell-extension-appindicator و نصب بسته gnome-shell-extension-top-icons-plus.با این کار مشکل بطور کامل حل شد. تازه این افزونه پیکربندی‌های بهتری هم داره. تعجب نمیکنم چند وقت دیگه این افزونه پیشفرض بشه.مشکل پنچم اینه که هر بار سیستم رو روشن میکنم و یا از اسلیپ در میارم باید برم توی بخش تنظیمات صدا بخش خروجی و خروجی صدا رو از روی «HDMI / DisplayPort 2» بردارم و بذارم روی اسپیکر و یا هر چیز دیگه که میخوام خروجی باشه. در حالی که نباید اینطور باشه و وقتی یه بار من خروجی پیشفرض رو انتخاب میکنم همیشه روی همون بمونه. این یه باگه گزارش شده و در حال حل شدنه ولی اگر خیلی روی مختونه برید توی مسیر زیر:/etc/pulse/default.paو این دو خط رو کامنت کنید:load-module module-switch-on-port-availableload-module module-switch-on-connectسوالی اگر دارید همینجا بپرسید سعی میکنم پاسخ بدم. گنولند Sosha Tue, 03 Dec 2019 14:45:48 +0330 https://virgool.io/GNULand/smart-questions-eal15dceyo2x این نوشته نظر شخصی من هست؛ اگر کسی لینک این مطلب رو برای شما فرستاده، نه من و نه اون شخص از شما متنفر نیستیم و این مطالب به هیچ عنوان قصد توهین به شما رو نداره. صرفا به نظر رسیده که شما شیوه درستی برای سوال پرسیدن ندارین.حرف‌هام خیلی مشابه نوشته Eric S. Raymond و Rick Moen هست (1) اما رو‌خوانی و ترجمه نکردم. اگر دقیقا شبیه به همون شد به خاطر اینه که «واقعا» این مسئله رو قبول دارم.قبل از خوندن این پست موارد زیر رو بپذیرید:1- کمک داوطلبانه در مقابل پشتیبانی پولی بسیار متفاوته؛ شما آدم مهمی نیستین، کسی هم که تصمیم گرفته به شما کمک کنه آدم مهمی نیست. شما دو نفر در فضای مجازی هستین که در رابطه با یک مشکل فنی گفتگو می‌کنید. پس:باید به من کمک کنیدمن آشنای فلانی هستمتو هیچ میدونی من کی ام؟جایگاهی در این فضاها نداره. اگر من یک سکه قورت بدم کسی من رو «بانک» خطاب نمی‌کنه همچنین شماهم اگر در یک محفل بخصوصی آدم مهمی هستین دلیل نمیشه دیگران همه جا به شما احترام بذارن، احترام از اعتماد به دست میاد و اعتماد به غریبه ها به طرز برخوردشون با همدیگه بستگی داره.2- وقت من (کسی که قراره به شما کمک کنه) دقیقا به اندازه وقت شما (کسی که سوال رو مطرح کرده) با ارزشه. پس به وقت همدیگه احترام بگذاریم.3- آدمها نمی‌تونن ذهن همدیگه رو بخونن. باید به طور دقیق تمامی جزئیات موردنیاز برای درک موضوع مطرح بشه.4- در لحظه عصبانیت و بلاتکلیفی هیچوقت از کسی سوال نپرسید، اول به آرامش برسید بعد. (بند یک رو به خودتون یاد آوری کنید.)5- تمرینات رو خودتون حل کنید، دیگران مسئول حل کردن تمرین شما نیستن. اسمش رو گذاشتن تمرین که یاد بگیرین... خیال کردین اون کسی که انتظار دارین جواب بده خودش چطوری یاد گرفته؟ با حل کردن تمرینجمع آوری اطلاعات (قبل از سوال پرسیدن)چهار نوع سوال وجود داره، سوالاتی هستن که با «بله» / «خیر» به نتیجه می‌رسن؛ سوالاتی هستن که باید در موردشون تحقیق بشه [مثل باگ‌های جدید سخت افزاری و یا نرم افزاری]. سوالاتی هستن که در جوابشون یک سوال پرسیده می‌شه و مهمتر از همه سوالاتی هستن که باید کنار گذاشته بشن. [کالی!!!]موارد زیر رو انجام بدین:جستجو توی اینترنت.جستجو توی انجمن مربوط به موضوع شما.خوندن مستندات مربوط به برنامه/زبان/ابزار مورد بحث.اگر مربوط به برنامه نویسی هست، نوشتن یک قطعه کد. (حتی اگه اجرا نمیشه، اصلا لازم نیست اجرا بشه فقط یه نقطه شروعه)تمامی لینک‌ها و مستنداتی که پیدا کردین رو موقع سوال پرسیدن مطرح کنید.+ ای آقا من اگه حوصله این چیزا رو داشتم که از تو نمی پرسیدم - من چرا باید حوصله جواب دادن به تو رو داشته باشم که اینقدر تنبلی؟سوال اگه جذاب نباشه، اگه به اندازه کافی پر محتوا نباشه ازش به خوبی استقبال نمیشه.چون من می‌خوام با جواب دادن به سوال شما، خودم هم یه چیزی یاد بگیرم. پیام هرچقدر پربار تر باشه آدمهای بیشتری به شما و سوال شما علاقه نشون میدن. اعتبار این شکلی به دست میاد؛ با درست سوال پرسیدن و نشون دادن اینکه شما شخص لایقی هستین. تنبل یا فرصت طلب نیستین و صرفا در این لحظه خاص به مشکلی برخوردین که توانایی حل کردنش رو به تنهایی ندارین.موقع سوال پرسیدنجای مناسب سوال بپرسید، اگر انجمن هست توی دسته بندی مربوط به خودش. اگر مطمئن نیستین که موضوع به چه دسته بندی‌ای مربوطه کافیه توی ذهنتون بهش سه تا کلمه کلیدی ربط بدید هر کدوم که بیشتر به دسته بندیها نزدیک بود اونجا سوال رو مطرح کنید.اگر گروه تلگرامی هست حتما قبل از سوال پرسیدن قوانین گروه رو بخونید. تا یکی به پیامتون جواب داد فوری وارد چت خصوصی نشید، اصلا تا حد امکان از این قضیه پرهیز کنید؛ گروه رو ساختن تا بقیه هم یه چیزی یاد بگیرن.بریده بریده پیام نفرستین، همه رو توی یک الی دو پیام متوالی بفرستین (پیام قبلی رو reply کنید تا ادامه اون گم نشه). هر داده ای که می‌تونه به سوال شما ربط پیدا کنه رو توی پیام بنویسید. چیزایی مثل:نوع سیستم عامل و نسخه‌ای که استفاده می‌کنیدآدرس مطلب یا مطالبی که درباره این مشکل پیدا کردین (*)اگر مشکل درباره یک برنامه هست، نحوه نصب اون برنامه رو ذکر کنید (از مخزن گرفتین؟ از فلان سایت گرفتین؟ و ...)* حتما، لینک یا کلمات کلیدی که در رابطه با این مشکل پیدا کردین رو توی پیام ذکر کنید به خاطر اینکه بقیه می‌فهمن اون موارد رو امتحان کردین در نتیجه جواب تکراری نمیدن. بعلاوه ممکنه شما درحین تحقیقات درست متوجه چیزی نشده باشین و الان یکی می‌تونه براتون بر اساس همون منابع بیشتر توضیح بده.سعی کردم این بحث رو زیاد کشش ندم تا کسایی که حوصله ندارن بتونن یه نگاهی بندازن. کسانی که این موارد رو می‌دونن و رعایت می‌کنن نیازی به خوندن این مطلب ندارن.در پایان اینکه همه اداب و رسوم معقول که توی یک جامعه واقعی رعایت می‌شه توی فضای مجازی هم می‌تونه رعایت بشه. چون اون رو نمی‌بینید و اون هم شما رو نمی‌بینه دلیل نمیشه که انسانیت رو فراموش کنید. گنولند هادی اعظمی Tue, 15 Oct 2019 02:16:35 +0330