🔶 توی هر شغلی اگر ۱ درصد ریاضی بلد نباشید, واقعا لنگ می زنید.

نمونه شغل انبارداری یا حسابداری

من خودم ۲۳ روز کارآموز انباردار شرکت تولید لامپ LED بودم اونم چند سال پیش. وقتی جنسی که وارد انبار میشه که باید با دقت شمرده بشه و اینجوری نیست که یک جعبه جنس محتوای آن به خیال راحت بشمارید که بگی ۱۰۰ تا جنس درون جعبه هست در حالی که این جعبه کسی دیگه می شماره که میگه ۹۹ تاست در حالی که خودت ۱۰۰ تا شمردی که اینجاست که یکیش کم داره و عدد قبلی ۱۰۰ وارد سیستم حسابداری شده و کم بودن یکی از آن دچار مشکل محاسباتی آن می شود.

همین کم بودن یکیش می تونه کلی خسارت به شرکت وارد کنه و اینجاست که روی بودجه شرکت و فروش آن ثاتیر می زاره. برای همین باید ریاضیات بلد باشید و چون با اعدادهای بزرگ سروکار دارید.

اصلا ریاضیات دست کم نگیرید.

@TheRaymondDev

👨‍💻مقدمه ای بر نکسوس ریپازیتوری
توی این ویدیو روی سرور ایران نکسوس نصب میکنیم با npm بهش وصل میشیم. به چالش docker registry در ایران در زمان داخلی شدن اینترنت می پردازیم و براش راهکار پیدا میکنیم.
اگه از این ویدیو خوشت اومد، حتما لایک کن و سابسکرایب یادت نره!
🔗 https://youtu.be/jOzbzyHqQAA
🆔 @Hiradsajde

✍️Behnam Mohammadzadeh

اگر تو زبان Go عمیق شده باشین و سعی کرده باشین با نحوه عملکرد Scheduler آشنا بشین احتمالا Asynchronous Preemption به گوشتون خورده. تو این پست میخوام توضیح بدم که این اتفاق چطور میافته و نحوه عملکردش به چه شکله.

برای شروع شاید بد نباشه که بدونیم asynchronous preemption برای چی به وجود اومد و اصلا چه مشکلی رو حل میکنه؛ به همین منظور با یه مثال پیش میرم.

زمانی که GC میخواد اجرا بشه نیاز به (STW)Stop the World داره که تو این وضعیت باید همه گوروتین ها تو یه safe point متوقف بشن؛ کال شدن فانکشن یک safe point هست که گوروتین در این نقطه میتونه متوقف بشه تا GC کارش رو بدرستی انجام بده. ولی بعضی از گوروتین ها ممکنه موقع اجرا اصلا فانکشن کال نداشته باشن که به این حالت میگن tight loop.

تو این حالت گوروتین وقتی ۱۰ میلی ثانیه اجرا شد یه ترد به اسم sysmon که همیشه بصورت مستقل اجرا میشه میاد تشخیص میده که فلان گوروتین زیادی داره اجرا میشه و باید متوقف بشه تا نوبت به بقیه هم برسه و برای اینکه اون گوروتین رو متوقف کنه یه سیگنال SIGURG میفرسته.
از اونطرف یه گوروتین به اسم gSignal که هر ترد(M) یکی مخصوص خودش رو داره و میاد این سیگنال‌ها رو دریافت و هندل می‌کنه .

وقتی gSignal میبینه سیگنال دریافتی از نوع SIGURG هست متوجه میشه که باید preemption اتفاق بیافته و میاد چک میکنه که آیا این اتفاق باید بیافته یا نه؟ (از لینک پایین هم میتونید این فانکشن رو ببینید)
https://lnkd.in/d-cad4-C

بعدش میاد چک کنه ببینه که اگه preempt کنیم مشکلی پیش میاد یا نه؟ پس این فانکشن رو کال میکنه
https://lnkd.in/d5HV8Sh9

دلیلش هم اینه که ممکنه این گوروتین در حال کال کردن بعضی از فانکشن های runtime باشه که نباید وسط اجرای اون فانکشن ها preemption اتفاق بیافته؛ و همچنین چک میکنه ببینه stack فضای کافی داره یا نه(چون مرحله بعد بهش نیاز داره).
حالا که به یه safe point رسیدیم میاد و کار خفن اصلی رو انجام میده.


❓همونطور که قبلا دیدیم tight loop هیچ فانکشن کالی نداره! پس چجوری باید گوروتین رو مجبور به اینکار کرد؟
✅ جواب، پوش کردن یک function call instruction به stack frame و تغییر PC هست!


این فانکشن این کار رو انجام میده:
https://lnkd.in/dcReVmHt

این فانکشن اول میاد برای یک instruction جدید داخل stack frame جا باز میکنه و بعد رجیسترهای RSP و RIP رو دستکاری میکنه تا PC به asyncPreempt تغییر کنه و بعد از اینکه اون اجرا شد کد قبلی بطور نرمال مثل گذشته به کارش ادامه بده.

لینک پست در ویرگول:
https://vrgl.ir/CLOKC

اصطلاح STW یا Stop The World یکی از مفاهیم مهم در پیاده‌سازی Garbage Collector (GC) در زبان‌هایی مثل Go، Java و… هست. در ادامه با جزییات کامل بهش می‌پردازیم:

---

✅ تعریف STW (Stop The World)

STW به وضعیتی در اجرای برنامه گفته می‌شه که اجرای تمام گوروتین‌ها (یا تردها) متوقف می‌شن تا Garbage Collector بتونه کار خودش رو انجام بده.

> به زبان ساده: GC می‌گه «همه وایسید! من باید حافظه رو مرتب کنم».

---

📦 چرا GC نیاز به STW داره؟

Garbage Collector برای اینکه بتونه حافظه‌ی بدون استفاده رو شناسایی و آزاد کنه، باید بدونه که:

* چه آبجکت‌هایی در حال حاضر در دسترس هستن (reachable)
* چه آبجکت‌هایی دیگه استفاده نمی‌شن (unreachable)

برای اینکه بتونه این بررسی رو دقیق انجام بده، باید:

* بررسی کنه که stack و heap در هر گوروتین در چه حالتی هستن
* مطمئن باشه که گوروتین‌ها در نقطه‌ای امن (safe point) قرار دارن، یعنی وسط نوشتن یا تغییر داده‌ای نیستن که باعث اشتباه در تحلیل بشه.

---

🧩 Safe Point یعنی چی؟

Safe point به جایی از اجرای کد گفته می‌شه که:

* وضعیت حافظه کاملاً قابل پیش‌بینیه
* گوروتین در حال اجرای عملیات بحرانی نیست
* GC می‌تونه بدون نگرانی از race condition، وضعیت حافظه رو بررسی و اصلاح کنه

مثلاً:

* موقع فراخوانی تابع
* موقع خروج از تابع
* قبل یا بعد از تخصیص حافظه

---

⚙️ فرآیند STW چطوری کار می‌کنه در Go؟

1. GC تصمیم می‌گیره که وقت پاک‌سازی حافظه‌ست.
2. سیگنالی به تمام گوروتین‌ها می‌ده که باید به safe point برن.
3. وقتی همه گوروتین‌ها به safe point رسیدن، برنامه وارد حالت STW می‌شه:

* هیچ کدی (حتی گوروتین‌ها) اجرا نمی‌شن
4. GC با خیال راحت تحلیل حافظه (mark and sweep یا mark and compact) انجام می‌ده.
5. بعد از اتمام کار GC، گوروتین‌ها ادامه‌ی اجرای خودشون رو از سر می‌گیرن.

---

🕐 STW در Go چقدر طول می‌کشه؟

در نسخه‌های جدید Go (مثلاً Go 1.18 به بعد):

* STW بسیار کوتاهه (در حد microsecond)
* Go از تکنیک‌های پیشرفته مثل concurrent GC استفاده می‌کنه تا اکثر مراحل GC هم‌زمان با اجرای برنامه انجام بشن
* فقط بخش‌هایی مثل شروع و پایان GC نیاز به STW دارن

---

🎯 چرا STW ممکنه مشکل‌ساز بشه؟

اگر STW طولانی بشه:

* زمان پاسخ‌دهی (latency) سیستم زیاد می‌شه
* در اپلیکیشن‌های real-time یا interactive مثل گیم یا APIهای حساس، این تاخیر ممکنه قابل‌تحمل نباشه
* در برنامه‌های بزرگ با حافظه زیاد، ممکنه pauseها محسوس بشن

برای دیدن نمودار و لاگ‌های واقعی اجرای GC در برنامه Go (و بررسی دقیق زمان‌های STW)، می‌تونید از ابزارهای داخلی خود Go استفاده کنید..

🔧 مرحله 1: فعال‌سازی لاگ GC در Go

برای گرفتن لاگ دقیق GC، برنامه‌ات رو با تنظیم متغیر GODEBUG اجرا کن:

GODEBUG=gctrace=1 ./your_program

یا اگه داخل کد می‌خوای فعال کنی:

import "runtime/debug"

func main() {
    debug.SetGCPercent(100) // یا مقدار دلخواه
    // بقیه کدها
}

---

📜 نمونه لاگ واقعی GC در Go:

مثال خروجی لاگ با GODEBUG=gctrace=1:

gc 1 @0.004s 8%: 0.48+1.5+0.015 ms clock, 1.4+0.72/1.8/0+0.045 ms cpu, 4->4->2 MB, 5 MB goal, 4 P

🧩 تحلیل این لاگ:

| gc 1 | شمارنده اجرای GC (این بار اولیه) |

| @0.004s | زمان اجرای GC (۴ میلی‌ثانیه بعد از شروع برنامه) |

| 8% | درصد زمانی که GC نسبت به زمان اجرای برنامه گرفته |

| 0.48+1.5+0.015 ms clock | ۳ فاز GC به ترتیب: STW شروع + Marking (concurrent) + STW پایان |

| 1.4+0.72/1.8/0+0.045 ms cpu | مصرف CPU در مراحل مختلف |

| 4->4->2 MB | حجم heap قبل، بعد از marking، بعد از sweep |

| 5 MB goal | هدف بعدی برای heap |

| 4 P | تعداد پردازنده‌های منطقی (GOMAXPROCS) |

---

📊 مرحله 2: گرفتن نمودار GC (با pprof)

1. اضافه کردن HTTP profiling:

import _ "net/http/pprof"
import "net/http"

go func() {
    http.ListenAndServe("localhost:6060", nil)
}()

2. اجرای برنامه و گرفتن پروفایل GC:

در ترمینال جدید:

go tool pprof https://localhost:6060/debug/pprof/heap

یا برای لاگ GC دقیق‌تر:

go tool pprof -http=:8080 https://localhost:6060/debug/pprof/goroutine

سپس داخل مرورگر: https://localhost:8080
می‌تونی نمودارهای flamegraph، timeline و heap را ببینی.

---

✅ خلاصه

| GODEBUG=gctrace=1 | لاگ دقیق از اجرای GC و زمان STW |
| runtime/pprof + net/http/pprof | ساختن پروفایل‌های گرافیکی |
| go tool pprof | بررسی گرافیکی یا CLI لاگ‌ها و ساخت flamegraph |
| debug.SetGCPercent | تنظیم حساسیت GC |

این آخرین پستم برای جمع‌بندی در خصوص پروژه این پروژه هستش.

در ایران دسترسی قطع کردن ارتباط داخل با خارج (اینترنت ملی) و خارج با داخل بطور مجزا وجود داره.
در زمانی که سازمان های بزرگ مورد نفوذ سایبری قرار بگیرن با این سامانه میشه موضوع رو تا حد خوبی مهار کرد.

وجود این بک‌دور در چنین شرایطی زمینه ساز این موارد میشه:
1- از زیرساخت آی‌پی هزاران کاربر در کسری از ثانیه با آیپی مهاجم یکی میشه و شناسایی رو به شدت دشوار می‌سازه.
2- با استفاده از این آسیب پذیری میشه دسترسی کامل سرور میزبان رو گرفت و حملات رو از روی سرور های داخلی هک شده انجام داد.

با این فرض که با تغییر ورژن ردیس بک‌دور بسته بشه، باز هم این پروژه با توجه به اینکه کانفیگ های تانل شده رو جدا می‌کنه و روی سرور ایران اجرا میشه، باعث مشکل اول میشه.
این موضوع دو گزینه بیش باقی نمی‌گذاره:
1- برباد دادن میلیارد ها دلار از سرمایه مردم
2- خاموشی کامل (قطع اینترنت داخلی و خارجی)

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

در این مقطع این پروژه باعث آزادی اینترنت و رفع فیلترینگ نیست، بلکه چاره ای جز قطع کامل آن نمی‌گذاره.
🆔 @Hiradsajde

رای‌گیری برای برنامه اداری پیشفرض پارچ در رلیز تابستانه


https://forum.parchlinux.com/t/libreoffice-onlyoffice/601?u=rnjbr




@ParchLinux

ایران ایران 🩸
محمد نوری

از قطعه اصلی لذت ببرید

وین راه بی‌نهایت...
@VinRaheBinahayat

🔶 تلگرام ۱۷ میلیون گروه و کانال رو در سال ۲۰۲۵ مسدود کرد!

@TheRaymondDev

بهشت اینطوریه

🔵 عنوان مقاله
Open Source Outbound Webhooks Infrastructure

🟢 خلاصه مقاله:

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

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

ویدیو شماره ۱ - آشنایی با DNS
توی این ویدیو یه توضیحات خیلی کلی از عملکرد و اهمیت DNS دادم.

https://youtu.be/TXvdyPbxeag

حبیب

جستجوگر گیتی به نگارش ۰.۲.۲ که یک نگارش رفع‌مشکل بر روی ۰.۲.۱ بود به‌روزشد.

تغییرات از ۰.۲:
- اضافه شدن صفحه تنظیمات انجین‌ها
- اضافه شدن قابلیت خلاصه‌سازی یا چت برای جبیر
- اضافه شدن صفحه درباره
- بهبود دسته‌بندی تصاویر
- بهبود تجربه‌موبایل
- رفع باگ‌های گزارش شده
- بهبود صفحه آمار
- همگام سازی شده با آخرین تغییرات سرکس


نمونه برخط:

https://search.parchlinux.com

سورس‌کد:

https://github.com/parchlinuxb/gitee


@ParchLinux

🔰انتشار نسخه آزمایشی Linux 6.16-rc5 با بهبودهای مهم در سیستم‌فایل‌ها، درایورها و سخت‌افزار

🔹لینوس توروالدز به‌صورت رسمی انتشار Linux 6.16-rc5 را اعلام کرد. این نسخه نشان‌دهنده نقطه میانی چرخه توسعه برای هسته ۶.۱۶ است که انتظار می‌رود در اواخر ژوئیه یا اوایل آگوست به صورت پایدار منتشر شود.

🔹ویژگی‌های کلیدی این نسخه:
🔸توروالدز این نسخه را با وجود پنجره ادغام بزرگ، «کاملاً آرام» توصیف کرده است. به‌طور کلی، تغییرات به سه بخش تقریباً مساوی تقسیم شده‌اند:

🔹سیستم‌فایل‌ها (حدود ۳۳% تغییرات):
🔸تمرکز ویژه روی Bcachefs (سیستم فایل نسل جدید با قابلیت Copy-on-Write) شامل رفع باگ‌های مربوط به مدیریت حافظه و جلوگیری از خطاهای اشاره‌گر NULL.
🔸بهبودهای قابل توجه برای SMB و Btrfs به منظور افزایش پایداری و عملکرد در محیط‌های ذخیره‌سازی پیچیده.

🔹درایورها (حدود ۳۳% تغییرات):
🔸به‌روزرسانی‌های گسترده برای پشتیبانی از سخت‌افزارهای متنوع، از جمله رول‌بک برخی تغییرات در Device Mapper برای حل مشکلات کاهش عملکرد.
🔸افزودن پشتیبانی از صفحه‌کلید نازک ThinkPad X1 Tablet Gen2 در درایور HID لنوو.

🔹سایر بهبودها (حدود ۳۳% تغییرات):
🔸رفع مشکل use-after-free در کتابخانه libbpf.
🔸بازگرداندن اطلاعات of_node در sysfs هسته سریال.
🔸به‌روزرسانی مستندات و رفع باگ‌های معماری (به‌ویژه برای LoongArch، UM و x86).

🔹پشتیبانی از سخت‌افزارهای جدید:
🔸درایورهای متن‌باز برای کارت‌های گرافیک انویدیا Blackwell و Hopper.
🔸بهبود سازگاری با پردازنده‌های Intel Wildcat Lake.

🔹امنیت و ذخیره‌سازی:
🔸افزودن قابلیت کلیدهای پیچیده سخت‌افزاری (hardware-wrapped keys) برای رمزنگاری fscrypt.
🔸بهبودهای عملکردی در سیستم‌فایل EXT4.

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

نویسنده: حسین سیلانی
اخبار و آموزش های بیشتر در کانال:
https://t.iss.one/linuxtnt

میگم چرا انقدر بهشتیه
نگو بخاطر اینه
اولین روییدنی ای که اقرار به ولایت کرد بادمجان بود

پیرو این پست
https://t.iss.one/linuxtnt/4375
که درباره هشدار تروالدز در خصوص حذف سیستم فایلBcachefs بود
توروالدز پشتیبانی از Bcachefs را پس از درگیری متوقف کرد

لینوس توروالدز اعلام کرده است:
"این را ادغام کردم، اما با توجه به آن بحث، فکر می‌کنم در پنجره ادغام ۶.۱۷ از هم جدا می‌شویم. شما به وضوح نشان دادید که من حتی نمی‌توانم در مورد اصلاحات اشکالات سوال کنم و باید هر چیزی را بدون چون و چرا ادغام کنم. صادقانه بگویم، در این مرحله دیگر احساس راحتی نمی‌کنم و تنها چیزی که هر دو در آن بحث به طور اساسی روی آن توافق داشتیم این بود که 'کار ما تمام است'."

🔰حرکتی رادیکال دیگر: فدورا قصد دارد پشتیبانی بوت UEFI روی MBR را حذف کند
پشتیبانی بوت UEFI برای MBR ممکن است در فدورا ۴۳ حذف شود.

🔹 این تغییر به این معنی است که فدورا دیگر اجازه نمی‌دهد سیستم‌های UEFI روی دیسک‌های با پارتیشن‌بندی MBR بوت شوند
🔹فدورا اخیراً در موقعیت دشواری قرار گرفت هنگامی که پیشنهاد حذف پشتیبانی از سیستم‌های ۳۲ بیتی با واکنش شدید جامعه کاربری مواجه شد. این تغییر که با هدف کاهش بار نگهداری برای توسعه‌دهندگان مطرح شده بود، با مخالفت کاربران و توسعه‌دهندگانی روبه‌رو شد که به سازگاری ۳۲ بیتی برای برخی موارد استفاده نیاز داشتند.
https://t.iss.one/linuxtnt/4363

🔹واکنش‌ها آنقدر قوی بود که این پیشنهاد در نهایت لغو شد، اما این تغییر همچنان در آینده‌ای نزدیک باید مورد بررسی قرار گیرد تا از چالش‌های مداوم نگهداری جلوگیری شود.

🔹حالا یک پیشنهاد تغییر جدید مطرح شده است که هدف آن حذف پشتیبانی بوت UEFI روی دیسک‌های پارتیشن‌بندی شده با MBR است.

🔸پایان پشتیبانی بوت UEFI روی MBR؟
🔸این پیشنهاد تغییر توسط کاترینا کوکیو از تیم نصب‌کننده Anaconda ارائه شده است و هدف آن حذف پشتیبانی از نصب فدورا در حالت UEFI روی دیسک‌های MBR، به ویژه برای سیستم‌های x86-64 از نسخه آینده فدورا ۴۳ است.
🔸هدف از این کار، ساده‌سازی کد نصب‌کننده و توقف پشتیبانی از پیکربندی بوت است که به ندرت استفاده می‌شود، در تنظیمات فرمور به صورت ناسازگار پیاده‌سازی شده و توسط فدورا به طور رسمی تست نشده است.
🔸این تغییر به ما کمک می‌کند تا از کرش‌های بوت‌لودر ناشی از خطاهای فرمور هنگام استفاده از MBR جلوگیری کنیم.
🔸اگر شما یک کاربر فعلی هستید، جای نگرانی نیست، زیرا این تغییر روی نصب‌های موجود تأثیری ندارد. این تغییر فقط برای نصب‌های جدید فدورا از طریق Anaconda اعمال می‌شود که در آن‌ها به جای MBR، از GPT برای بوت UEFI استفاده خواهد شد.