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

دیروز فهمیدم که میشه با یه لینک همه ی فونت های google fonts رو دانلود کرد. یه لینکی که توی گیتهاب خود گوگل فونتز هست. 1.3 گیگ فایل حدودا. ولی مشکلی داره اینه که کللللی فولدر تو در تو هست و نمیشه دستی این همه رو نصب کرد. پس یه برنامه با پایتون نوشتم تا اینو اتوماتیکش کنه.

استفاده ازش توی ویندوز خیلی راحته، ولی اگه توی لینوکس یا مک میخوایید استفاده کنید هم راهش رو نوشتم (کسایی که برنامه نویسید و مک/لینوکس دارید یه دستی برسونید بیلدهای اونا رو هم بگیرید)

میتونید توی گیتهاب دانلود کنید و طبق دستور عمل استفاده کنید:
https://github.com/zmn-hamid/install-google-fonts

@DevTwitter | <Kyrovert/>

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

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

این قاعده در مورد مسائل فنی و کاری هم به همین صورت است؛ سعی کنیم روی تکنولوژی‌ها و ابزارها سفت‌وسخت نباشیم، چون ابزارها نسبت به شرایط موجود استفاده می‌شوند و عمری دارند و روزی ناچار خواهیم بود آن‌ها را کنار بگذاریم و دیگر استفاده نکنیم.
اگر بخواهیم روی ابزارها هم تعصب داشته باشیم، مثل متعصبان مذهبی و دینی می‌شویم که به هر زور و طریقی سعی دارند مفاهیم تاریخ‌مصرف‌گذشته را در هر موضوعی بسط بدهند و استفاده کنند.

🔵 عنوان مقاله
Container-Aware GOMAXPROCS

🟢 خلاصه مقاله:
** بلاگ رسمی Go سری تازه‌ای را درباره ویژگی‌های Go 1.25 آغاز کرده و در نخستین بخش، به رفتار آگاه از کانتینر در GOMAXPROCS می‌پردازد. مقدار پیش‌فرض این تنظیم روی سخت‌افزار واقعی منطقی است، اما در کانتینرها می‌تواند به‌دلیل محدودیت‌های CPU (مانند cgroup و quota) مشکل ایجاد کند. در Go 1.25 تشخیص و تنظیم پیش‌فرض بهبود یافته تا با محدودیت‌های کانتینر سازگارتر شود، عملکرد پیش‌بینی‌پذیرتری بدهد و تنها در برخی موارد نیاز به تنظیم دستی باقی بماند.

🟣لینک مقاله:
https://golangweekly.com/link/173329/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

دیدین توی گیتهاب نوشته چند درصد کد با چه زبانی زده شده؟ اینو می‌تونید نصب کنید و اطلاعات و گزارش پروژتون از جمله تعداد خط های کامنت و فایل ها و نوع زبان و ... بگیرید
github.com/AlDanial/cloc

@Linuxor

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

دوتا ابزار خیلی خوب پیدا کردم که بخاطر این دوتا چند وقتی هست vscode نگهداشتم.

Flowistry

اول با این ابزار شروع شد؛ یک متغییر یا ... رو انتخاب می‌کنید و بعد این extension رو فعال می‌کنید که باعث میشه کل کدهای دیگه fade بشه و فقط بخش‌هایی از کد که این متغییر رو تغییر دادند هایلایت بمونه.

برای خوندن سورس کد پروژه‌های دیگه و دیباگ پروژه‌های خودم خیلی کمکی هست.

اما همین تیم یک ابزار دیگه هم داره که من ۲ روزه دارم باهاش کار می‌کنم ( خیلی کم استفاده کردم ولی قدرتش خیلی زیاده) اونم :
Argus

این ابزار هنوز درحال توسعه هست و کامل نشده ولی کار رو در میاره کارش هم اینه که ارورهای Trait ها که معمولا مارو بیچاره می‌کنه رو آنالیز می‌کنه و خیلی تمیز و حرفه‌ای فقط بخش‌های مهم رو نشون میده.

توی دو موردی که من بهش برخوردم به محض سوییچ روی vsode و فعال کردنش متوجه شدم کدوم Trait داره بهم ارور میده و توی ۲ دقیقه حل شد.

تنها مشکلم با این دو مورد :
کاش برای neovim هم پلاگین میدادند؛ چون هی مجبورم جابجا بشم بین این دو مورد.

پیشنهاد می‌کنم حتما استفاده کنید.

این ریپو اومده یه لیستی از چیزایی که اون سورس هست و میتونید سلف هاست کنید رو گزاشته
از وی پی ان تا پسورد منیجر و تایم ترکر و کلی چیزای دیگه
اگه ازونایی هستید که حریم خصوصی براتون خیلی مهمه و میخواید کنترل همه چیز دست خودتون باشه میتونه براتون کاربردی باشه
لینک ریپو
https://github.com/awesome-selfhosted/awesome-selfhosted

@DevTwitter | <ixAbolfazl />

برای یک سناریو، مجبور شدیم که بریم سراغ persistence کردن ردیس و استفاده از مکانیزم AOF(Append Only File). توی این روش، سربار سیستم‌کال fsync پررنگ میشه. حالا این که دقیقا ماجرا چیه رو سر فرصت توضیح میدم. یک نوتی برای این ماجرا نوشتم که نیازه که سر فرصت مرتبش کنم بعد میذارمش تو کانال.
توی این بررسی که توش پر از نکته و جزئیات جالب بود، خود fsync و چالش‌هاش خیلی برام جذاب شد. ماجرا به طور کل اینه که وقتی شما یک فایل رو تغییری میدین (رایت میکنید) کلی لایه بافر و کش وجود داره. و این تنها محدود به خود سیستم‌عامل نیست. توی سطح storage device هم ما یک لایه‌ی write back cache داریم قبل از این که دیتا واقعا روی دیسک ذخیره بشه. حالا سیستم‌عامل نیاز داره که بتونه حتی این رو هم مدیریت کنه. چون به صورت پیش‌فرض این دستگاه (درایور) به سیستم‌عامل اطلاع میده که IO انجام شده ولی واقعا هنوز دیتا روی کش دیسک ذخیره شده. fsync باید بتونه که این رو مدیریت کنه و دیسک رو فورس کنه که داده رو ذخیره کنه. به طوری باید از ذخیره‌ی قطعی داده مطمئن بشه.

توی این دو تا پست، راجع‌به این مسیر و جزئیاتش حرف میزنه و این که چطوری لینوکس (کرنل نسخه‌ی ۶) در فایل سیستم ext4 این کار رو مدیریت می‌کنه.

Explicit volatile write back cache control

The Secret Life of fsync

امروز ساعت ۱۸:۳۰ به وقت ایران یک ارائه رایگان از طرف Addy Osmani و انتشارات O'Reilly با عنوان Coding for the Agentic World برگزار میشه و که قراره موضوعات زیر رو پوشش بدن:

- Agentic interfaces: Moving beyond chat UX to sophisticated agent interactions
- Tool-to-tool workflows: How agents chain across environments to complete complex tasks
- Background coding agents: Asynchronous, autonomous code generation in production
- MCP and agent protocols: The infrastructure enabling the agentic web

توضیحات بیشتر و ثبت‌نام:
https://www.oreilly.com/AgenticWorld/

@aminrbg

از محتواهای خیلی خوبی که اخیراً بهش برخوردم کتاب رایگان Agentic Design Patterns از Antonio Gulli هستش. ایشون در حال حاضر با عنوان شغلی Sr Director, Distinguished Engineer, CTO Office در شرکت Google مشغول به کار هستن.

نویسنده در چپترهایی مجزا و با مثال‌های عملی الگوهای استفاده از Agentها رو ارائه می‌ده. من فکر می‌کنم کتاب مفیدیه چون هم به تازگی منتشر شده و اطلاعات بروزی داره و هم نگاهش به مسئله خیلی کاربردیه. خودم هم شروع به خوندنش کردم.

Agentic Design Patterns
@aminrbg

🔶 یکی از چیزهایی که بیشتر در مورد Inertia.js به آن افتخار میکنم، نحوه مدیریت به‌ روزرسانی‌های asset است. وقتی شما یک باندل جاوا اسکریپت جدید را منتشر می کنید، سرور در درخواست بعدی این تغییر را تشخیص میدهد و به فرانت اند می‌گوید که به جای یک بازدید SPA، یک بارگذاری کامل صفحه انجام دهد تا assets به صورت خودکار به ‌روزرسانی شوند. ما هش فعلی asset را در هر درخواست پیگیری میکنیم و اگر تغییر کند، سرور یک پاسخ 409 conflict بر می‌گرداند.

چیزی که واقعاً جالب است این است که این هش در state تاریخچه نیز ذخیره میشود و بنابراین اگر به عقب برگردید و assets شما با چیزی که در یک درخواست قبلی استفاده شده مطابقت نداشته باشد، این مکانیزم یک بارگذاری تازه از سرور را اعمال میکند. این یعنی داده‌های سرور و props کلاینت هرگز از هماهنگی خارج نمی شوند.

#توییت

@TheRaymondDev

🔵 عنوان مقاله
How Go Schedules Millions of Goroutines: A Deep Dive into GMP

🟢 خلاصه مقاله:
این مطلب با نگاهی عمیق و قابل‌فهم توضیح می‌دهد که زمان‌بند Go چگونه با مدل GMP (گورو‌تین‌ها، رشته‌های سیستم‌عامل، و پردازنده‌های منطقی) میلیون‌ها گورو‌تین را روی تعداد کمی نخ اجرا می‌کند. سازوکار صف‌های اجرا، «کار‌ربایی» بین پردازنده‌ها، نحوهٔ ایجاد و توقف گورو‌تین‌ها، مدیریت بلاک‌شدن روی I/O یا syscall، پیش‌امپشن برای عدالت و کاهش تأخیر، و تعامل زمان‌بند با جمع‌آوری زباله بررسی می‌شود. همچنین نکات عملی مانند تنظیم GOMAXPROCS، پرهیز از انفجار گورو‌تین‌ها، مدیریت فشار کانال‌ها، و استفاده از ابزارهای ردیابی و pprof برای عیب‌یابی مطرح شده است. در کنار آن، دو راهنمای کاربردی معرفی می‌شود: ساخت تصویر کانتینر از کد Go با Depot API (تأکید بر بیلد سریع، کش و ادغام در CI) و استقرار یک سایت استاتیک Hugo روی Hetzнер (از آماده‌سازی تا TLS و تحویل پایدار). این مجموعه پلی بین تئوری زمان‌بندی و استقرار عملی ایجاد می‌کند.

🟣لینک مقاله:
https://golangweekly.com/link/173629/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

https://github.com/ItsReZNuM/4InARowTelBot

سورس بازی 4InARow
این بازی باید معرف حضور همتون باشه اگه هم نمی‌دونید چیه یه سرچ کنید
قابلیت بازی دو نفره هم به صورت اینلاین هم داره و هم میشه با ربات توی سه سطح مختلف بازی کرد

@DevTwitter | <Agha Reza/>

یه باگ داشتم، متوجه شدم یه اشتباه عجیب کردم. این دو حالت رو ببینید:

var_dump([$someVariable]);
var_dump((array) $someVariable);

وقتی که مقدار someVariable نال باشه، اولی مشکل ایجاد می‌کنه. چون خروجی‌ها این‌طور می‌شه:

array(1) {
  [0]=>
  NULL
}
array(0) {
}

دیگه اولی یه آرایه‌ی خالی نیست.

مثل اینکه خبر ها حاکی از اون عه اقا وصال
@Vesal_J
روی کور یوتولیتی راست ( شامل کامند های اصلی لینوکس مثل cp , ls , pwd , ... )مشارکت کردن
این به معنی اون که در آینده نه چندان دور کدی که ایشون اضافه کردن در تمام دیسترو های اصلی لینوکس دنیا الردی نصب و قابل دسترس خواهد بود
https://github.com/uutils/coreutils/pull/8565

اگر پخش زنده آکادمی ۲۰۲۵ و همینطور تصاویری که از کی‌دی‌ای لینوکس منتشر شده رو دیده باشید و درمورد موز 🍌 براتون سوال شده که چی هستش، داستانش از این قراره، طبق ویکی کی‌دی‌ای:

نصف کردن یک 🍌. یا در مورد ما: ایجاد تغییرات عظیم در پیکربندی‌های sysupdate.d به گونه‌ای که نیازمند یک نسخه شکست سخت باشد که باید قبل از انتقال به نسخه جدیدتر اعمال شود.
همچنین می‌تواند برای خلاص شدن از آشغال‌های سازگاری استفاده شود. با مجبور کردن کاربران به عبور از یک نسخه خاص، می‌دانیم همه به‌روزرسانی‌های آن نسخه اعمال شده و در نتیجه می‌توانیم منطق سازگاری را حذف کنیم.

کمی تاریخچه: در ابتدا از https://files.kde.org/kde-linux/ به عنوان محل به‌روزرسانی استفاده می‌کردیم. این به طرز بدی شکاف تغییر نام به kde-linux را پر کرد و در نهایت برای مهاجرت rootfsv2 از هم پاشید. حالا به جای آن این کار را می‌کنیم:
‏* https://files.kde.org/kde-linux/ حاوی تصویر دیسک .raw و همچنین .torrent مربوط به آن است
‏* https://files.kde.org/kde-linux/sysupdate/*/ حاوی همه مصنوعات sysupdate است
‏* https://files.kde.org/kde-linux/sysupdate/v2/ و غیره نسخه‌های مختلف هستند
‏* https://files.kde.org/kde-linux/vacuum.yaml کدگذاری می‌کند که کدام بیلدها را باید برای همیشه نگه داشت (آنها را سنگ قبر می‌نامند). همچنین تصاویر طلایی را کدگذاری می‌کند (یعنی آنهایی که می‌خواهیم نگه داریم چون می‌دانیم خوب هستند)

درست. پس. چگونه سنگ قبر بسازیم؟ ابتدا با دقت زیاد درباره این مسئله فکر کنید چون تا حدودی مهم است که دقیقاً بفهمید چه کاری می‌خواهید انجام دهید...

بیایید مثال از v2 به v3 را در نظر بگیریم: می‌خواهیم نسخه‌ای در v2 ایجاد کنیم که آخرین نسخه باشد تا بتوان گفت. وظیفه این نسخه این است که یک نسخه v2 باشد در حالی که تغییرات sysupdate.d برای v3 را فراهم کند. شاید آن جمله را تا زمانی که جا بیفتد بخوانید. مصنوعات سنگ قبر باید شبیه آنهای v2 باشند، اما دستورالعمل‌های به‌روزرسانی (یعنی فایل‌های sysupdate.d) درون سنگ قبر باید شبیه آنهای v3 باشند.

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

* اطمینان حاصل کنید v2 (یعنی git master) واقعاً کار می‌کند
‏* v3 را آماده کنید (احتمالاً در یک شاخه) و شاید کمی آن را آزمایش کنید تا مطمئن شوید پیکربندی‌های ارتقا کار می‌کنند
* نسبت به دسترسی کلید امضا فوق‌العاده مراقب باشید. شاخه‌های تصادفی به طور پیش‌فرض امضا ندارند!
* upload.sh را در شاخه v3 به‌روزرسانی کنید تا خط به‌روزرسانی v3 را شروع کند
* تعدادی بیلد v3 برای آزمایش بسازید
* یک بیلد v2 با پیکربندی‌های sysupdate.d نسخه v3 بسازید
* یک بیلد v3 بسازید تا نسخه بالاتری داشته باشید
* ارتقا را آزمایش کنید
‏* vacuum.yaml را ویرایش کنید یا از مدیر سیستم بخواهید تا بیلد v2 (و احتمالاً اولین v3 خوب) را به عنوان سنگ قبر (و احتمالاً طلایی) علامت‌گذاری کند.

https://community.kde.org/KDE_Linux/Banana_Split

@kde_fa