یک ترد جالب تو ردیت
از اینجور آدما فراری باشید :)
کامنت خیلی خوب بود.. resume driven development 😂

@PyBackendHub

من مستقیما بچه هاش رو نمی شناسم ولی شاید براتون جالب باشه. کد تخفیف jadi رو هم تست کنید شاید به درد خورد (:

🔶 ویدئو لحظه شروع آتش‌سوزی در مرکز داده ملی کره جنوبی (NIRS – دائجون) | فاجعه فناوری ۲۶ سپتامبر ۲۰۲۵

#خبر

@TheRaymondDev

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۱۴۸۴

سرمست شدم در هوس سرمستان
از دست شدم در ظفر آن دستان
بیزار شدم ز عقل و دیوانه شدم
تا درکشدم عشق به بیمارستان

#مولانا | گنجور
📍@iipoem

اگه سایت وردپرسی دارید این مسیرو چک کنید:

/wp-json/wp/v2/users

@TheRaymondDev

ایجاد dark mode فقط با css بدون یک خط js

codepen:
https://codepen.io/ditheringidiot/pen/JjbzNMz

@DevTwitter | <Hesam Valizadeh/>

⚙️ مکانیزم گسترش ظرفیت (cap) در Slice

وقتی یه slice در Go پر می‌شه و شما با append() عنصر جدیدی بهش اضافه می‌کنی،
Go متوجه می‌شه که ظرفیت (capacity) فعلی کافـی نیست و باید حافظه‌ی بیشتری اختصاص بده.
به این فرآیند می‌گن slice growth یا reallocation.


🧠 مرحله‌به‌مرحله چه اتفاقی می‌افته؟

فرض کن داریم:

s := make([]int, 3, 3)

الان:

* len(s) = 3
* cap(s) = 3

حالا اگر بنویسی:

s = append(s, 10)

Go متوجه می‌شه که ظرفیت فعلی (۳) پر شده.
در نتیجه:

1. یه بافر جدید در حافظه ایجاد می‌کنه (یه آرایه‌ی جدید با ظرفیت بزرگ‌تر)
2. تمام عناصر قبلی (10, 20, 30) رو به آرایه‌ی جدید کپی می‌کنه
3. عنصر جدید رو اضافه می‌کنه
4. و یه slice جدید که به آرایه‌ی جدید اشاره می‌کنه، برمی‌گردونه


📈 حالا ظرفیت چقدر زیاد می‌شه؟

Go از یه الگوریتم رشد پویا (dynamic growth algorithm) استفاده می‌کنه.
الگو به‌صورت تقریبی اینطوریه:

✅ تا ظرفیت‌های کوچک:

وقتی cap کوچیکه (مثلاً زیر 1024)،
ظرفیت معمولاً ۲ برابر می‌شه.

مثلاً:

cap: 1 → 2 → 4 → 8 → 16 → 32 → ...

✅ وقتی ظرفیت بزرگ شد (≥ 1024):

Go رشد رو آهسته‌تر می‌کنه تا حافظه هدر نره.
تقریباً ظرفیت جدید ≈ ظرفیت فعلی × 1.25 (یعنی حدود 25٪ افزایش).

مثلاً:

cap: 1024 → 1280 → 1600 → 2000 → ...

🔬 مکانیزم دقیق در سورس‌کد Go

در پیاده‌سازی داخلی زبان Go (در runtime/slice.go)، تابعی وجود داره به نام:

growslice(et *_type, old slice, cap int) slice

این تابع دقیقاً تصمیم می‌گیره:

* ظرفیت جدید چقدر باشه
* حافظه جدید کجا اختصاص پیدا کنه
* چطور داده‌های قبلی کپی بشن

📌 بخشی از منطق اون (به‌صورت ساده‌شده) اینطوریه:

newcap := old.cap
doublecap := newcap + newcap
if cap > doublecap {
    newcap = cap
} else {
    if old.cap < 1024 {
        newcap = doublecap
    } else {
        for newcap < cap {
            newcap += newcap / 4 // رشد 25 درصدی
        }
    }
}

---

🧩 نتیجه:

* append() در واقع یه slice جدید می‌سازه با آرایه‌ی بزرگ‌تر.
* cap به شکل نمایی (expontential) رشد می‌کنه تا کارایی حفظ بشه.
* حافظه‌ی قبلی ممکنه توسط garbage collector آزاد بشه اگه دیگه بهش اشاره‌ای نباشه.

---

📊 مثال برای درک تغییر ظرفیت:

s := []int{}
for i := 0; i < 10; i++ {
    s = append(s, i)
    fmt.Printf("len=%d cap=%d\n", len(s), cap(s))
}

📤 خروجی معمولی:

len=1 cap=1
len=2 cap=2
len=3 cap=4
len=4 cap=4
len=5 cap=8
len=6 cap=8
len=7 cap=8
len=8 cap=8
len=9 cap=16
len=10 cap=16

می‌بینی چطوری ظرفیت به شکل ۲ برابر رشد می‌کنه.


➖➖➖➖➖➖➖➖
👑 @gopher_academy

بریم دقیق‌تر سراغ الگوریتم رشد پویا (dynamic growth algorithm) توی Go — چون این یکی از طراحی‌های خیلی هوشمندانهٔ Go برای مدیریت حافظه و performance هست.


⚙️ تعریف ساده:

وقتی یه slice داری و با append() داده‌ی جدید بهش اضافه می‌کنی،
اگر ظرفیت (`cap`) پر شده باشه**، Go باید تصمیم بگیره **چقدر حافظه‌ی جدید رزرو کنه.

الگوریتم رشد پویا دقیقاً وظیفه‌اش همینه:

> چطور ظرفیت جدید (newCap) محاسبه بشه، تا نه حافظه زیاد هدر بره، نه append‌ها کند بشن.



🧩 هدف الگوریتم رشد پویا:

Go می‌خواد بین دو چیز تعادل ایجاد کنه:

| هدف | توضیح |
| 🏎 سرعت بالا | با رشد نمایی (مثل ×2) تعداد دفعات تخصیص حافظه کم می‌شه.
| 💾 مصرف بهینه حافظه | با رشد تدریجی (مثل ×1.25) در ظرفیت‌های بالا از هدر رفت RAM جلوگیری می‌شه.



🔍 منطق داخلی (بر اساس runtime/slice.go)

الگوریتم در تابع داخلی Go به نام growslice() پیاده‌سازی شده.
خلاصه‌اش به این صورته:

func growslice(et *_type, old slice, cap int) slice {
    newcap := old.cap
    doublecap := newcap + newcap  // ظرفیت دو برابر

    if cap > doublecap {
        newcap = cap
    } else {
        if old.cap < 1024 {
            newcap = doublecap       // برای ظرفیت‌های کوچک: رشد ۲ برابری
        } else {
            // برای ظرفیت‌های بزرگ‌تر: رشد تدریجی (حدود 25٪)
            for newcap < cap {
                newcap += newcap / 4 // افزایش 25%
            }
        }
    }
    // در ادامه حافظه جدید اختصاص داده میشه و داده‌های قبلی کپی می‌شن
}

📈 نتیجه‌ی این منطق

| بازهٔ ظرفیت فعلی | نحوهٔ رشد | مثال
| < 1024 | رشد نمایی (۲ برابر) | 64 → 128 → 256 → 512 → 1024
| ≥ 1024 | رشد خطی-تدریجی (۱.۲۵ برابر) | 1024 → 1280 → 1600 → 2000 → 2500



🧠 چرا این الگوریتم هوشمنده؟

1. در ظرفیت‌های کوچک:
رشد دو برابری باعث می‌شه appendها سریع‌تر باشن (کمتر نیاز به کپی داده داریم).
یعنی append تقریباً در زمان amortized O(1) انجام می‌شه.

2. در ظرفیت‌های بزرگ:
رشد کمتر باعث صرفه‌جویی در حافظه می‌شه چون کپی‌کردن چند مگابایت داده هزینه‌بره.

3. در مجموع:
الگوریتم به شکل پویا بسته به اندازهٔ فعلی slice تصمیم می‌گیره چطور رفتار کنه → بهینه برای performance و memory.



📊 مثال واقعی از رشد پویا:

s := make([]int, 0)
for i := 0; i < 2000; i++ {
    s = append(s, i)
    if i%200 == 0 {
        fmt.Printf("len=%d, cap=%d\n", len(s), cap(s))
    }
}

📤 خروجی تقریبی:

len=0, cap=0
len=200, cap=256
len=400, cap=512
len=600, cap=1024
len=800, cap=1024
len=1000, cap=1280
len=1200, cap=1600
len=1400, cap=2000
len=1600, cap=2000
len=1800, cap=2500
len=2000, cap=2500

می‌بینی که تا 1024 ظرفیت دو برابر می‌شه، بعدش رشدش 25٪ می‌ره بالا. 🔥



📚 جمع‌بندی ساده

| ویژگی | توضیح
| نام الگوریتم | Dynamic Growth Algorithm
| هدف | افزایش ظرفیت slice به‌شکل خودکار و بهینه
| تا 1024 | رشد دو برابری (exponential)
| بیش از 1024 | رشد حدود 25٪ در هر بار (incremental)
| مزیت | سرعت بالا + صرفه‌جویی در حافظه
| محل پیاده‌سازی | runtime/slice.go → growslice()


➖➖➖➖➖➖➖➖
👑 @gopher_academy

به کمک اسکریپت ورکر FoxCloud و اکانت کلودفلر، می‌تونین یک کانفیگ شخصی Vless درست کرده و #فیلترینگ رو دور بزنین.

🎥 youtube.com/watch?v=5awqhmbEdcs
👉 github.com/code3-dev/foxcloud/releases/latest

🔍 ircf.space
@ircfspace

💠پروژه جدید بنیاد نرم‌افزار آزاد Librephone💠

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

مدیر اجرایی FSF، زویی کویمن گفته:
«وقتی چهل سال پیش FSF رو شروع کردیم، هدف‌مون آزادی در کامپیوترهای دسکتاپ و سرور بود. تکنولوژی عوض شده، اما تعهدمون به آزادی نه. الان وقتشه همین مسیر رو برای موبایل هم ادامه بدیم. این پروژه پیچیده‌ست، ولی ما به کارهای بلندمدت عادت داریم.»

هدف Librephone اینه که فاصله بین نسخه‌های آزاد اندروید و آزادی کامل نرم‌افزار رو از بین ببره. برای شروع، FSF توسعه‌دهنده با سابقه‌ای به اسم راب ساووی (از پروژه‌های DejaGNU، Gnash، OpenStreetMap و غیره) رو استخدام کرده تا وضعیت فریمور و باینری‌های غیرآزاد گوشی‌ها رو بررسی کنه. تمرکز اولیه هم روی کارهایی هست که پروژه‌هایی مثل LineageOS انجام دادن، با این تفاوت که Librephone می‌خواد اون بخش‌های بسته و غیرآزاد رو حذف و جایگزین کنه.

سرمایه اولیه این پروژه رو جان گیل‌مور (عضو هیئت‌مدیره FSF) داده. خودش گفته:
«من سال‌ها از LineageOS با MicroG و F-Droid استفاده کردم که گوگل‌افزارها رو حذف می‌کنه. ولی بعد فهمیدم هنوز بخش‌هایی از فریمور گوشی به صورت باینری و بسته داخلش هست. به‌جای تسلیم شدن، تصمیم گرفتم با همکاری دیگران اون بخش‌ها رو مهندسی معکوس کنیم و کاملاً آزادشون کنیم.»

اولین گام پروژه پیدا کردن یه مدل گوشی با کمترین مشکل از نظر نرم‌افزار غیرآزاده. بعد از اون، تیم شروع می‌کنه به جایگزینی کامل کدهای بسته با نرم‌افزار آزاد. Librephone قراره بستری باشه برای توسعه‌دهندگانی که می‌خوان یه سیستم‌عامل کاملاً آزاد و سازگار با اندروید بسازن.

بنیاد نرم‌افزار آزاد سال‌ها از پروژه‌های مشابه مثل Replicant حمایت کرده و حالا با Librephone قدم بعدی رو برمی‌داره. گیل‌مور هم اضافه کرده:
«خوش‌شانس بودیم که راب ساووی رو پیدا کردیم، مهندسی با دهه‌ها تجربه در نرم‌افزار آزاد و سیستم‌های امبدد.»

ساووی هم گفته:
«به‌عنوان کسی که سال‌ها روی سیستم‌های امبدد و موبایل کار کرده، خوشحالم که می‌تونم برای ساخت یه گوشی واقعاً آزاد تلاش کنم. این کار آسون، سریع یا ارزون نیست، ولی ما روی شونه‌ی غول‌هایی وایستادیم که قبلاً بخش زیادی از مسیر رو رفتن. خوشحال می‌شیم شما هم با کار یا کمک مالی‌تون همراه ما بشید.»

اطلاعات بیشتر و نحوه مشارکت:
https://fsf.org/campaigns/librephone

سایت پروژه:

https://librephone.fsf.org

گفت‌وگو در IRC:
#librephone روی irc.libera.chat

#خبر

بنظرم اینکه نتونم یک مدل رو روی سیستم لود کنم خیلی خیلی بهتر از اینه که بتونم لود کنم و ۳-۴ تا توکن در ثانیه خروجی بگیرم.

خب بالاخره DGX Spark هم اومد و این انتشار دیرهنگام و قیمت 4000$ و عملکرد ضعیفش باعث شده هیچکس بهش علاقمند نباشه! برخلاف باقی محصولات nvidia که نسخه founder edition به زور پیدا می‌شه این محصول رو به راحتی می‌تونید پیدا کنید.

تنها نکته مثبت این محصول؛ قابل حمل بودن و البته مصرف برق کم هست!
برای مصرف برق کم گزینه‌های دیگه و سریعتر هم هست؛ AMD و شرکت‌های دیگه کارهای جالبی در این زمینه کردند؛ چند موردی رو توی کانال‌های دیگه معرفی کردم (تست هم کردم)
قابل حمل بودنش اما؛ کمی شک دارم کسی بخواد دستگاه 4000$ دلاری که موقع استفاده هم شدیدا داغ میشه رو توی کیفش بذاره و با خودش جابجا کنه (ی سوال همینجا برام پیش اومد؟ چرا ماژول wifi اش زیر دستگاه هست بخشی که قراره روی میز قرار بگیره؟)
اکثر کسایی که خرید کردند و تست کردند؛ میگن باید توی خونه بذاری با یک خنک کننده خوب و دسترسی remote بهش بگیری!

موارد جایگزین چی می‌تونه باشه ؟
از شرکت اینتل می‌تونید برید سراغ GPUهای سری Arc B50, B60 با توجه به قیمت‌‌ها میشه با کمی حوصله سیستمی با قمیت 5000-6000$ خرید کرد که 256GB رم و 96GB هم حافظه گرافیک داشته باشه با سرعت انتقال داده سریعتر BUS منظورم هست. شخصا با قیمت‌هایی که گفته شد؛ قطعات رو کنار هم گذاشتم حدود 5200$ می‌شد البته هارد ۲ برابر و ماژولار بودن و گیم و کارهای دیگه انجام دادن روی این سیستم مواردی هست که با پرداخت ۱۲۰۰ دلار بیشتر به دست میارید! مهمترین نکته پرفورمنس حداقل ۱۰ برابر برای خیلی از مدل‌ها هست!
بعضی مدل‌هایی که روی DGX Spark طبق گزارشات 3-5 t/s بیشتر نمیده روی این دستگاه بالای 30t/s بهتون میده مثلا مدل‌های خانواده Qwen3

جایگزین‌های دیگه خرید mini-pc های شرکت‌های رغیب که از AI chip های AMD استفاده می‌کنند؛ با اینکه توی Inference عملکرد خوبی دارند مشکل این دستگاها عملکرد ضعیف موقع Finetune کردن هست برای همین گزینه Intel رو بیشتر پیشنهاد میدم!

اما اگر هر دو این موارد برای شما قابل قبول نیست؛ حتی خرید یک سیستم با ۴ تا Nvidia 3090 خوش قیمت‌تر و به مراتب سریعتر از DGX Spark هست.

تنها نکته مصرف برق هست؛ دو مورد اول مصرف برق زیادی ندارند مثلا B50 های اینتل 70W مصرف دارند؛ اما حتی سیستمی با ۴ تا 3090 که مصرف بالایی هم داره خیلی بصرفه تر از DGX Spark خواهد بود؟ چرا ؟ میزان زمانی که دولوپر‌های شما بر اساس کند بودن token/second از دست نمی‌دند میزان زمانی هست که کار شما سریعتر پیشرفت می‌کنه و خب این خودش تاثیر مستقیم روی درآمد داره!


خلاصه که DGX Spark به معنای واقعی یک سخت‌افزار بدرد نخور ولی بسیار خوشگل هست!

شخصا برای آپگیرید سیستم چشم به Arc B60 دارم و البته قیمتی هم که بالاتر گفتم با فرض قیمت‌هایی هست که اینتل گفت + هاردهای اضافه و water cooling, ...

پ.ن:
۱- هزینه سیستم با ۴ تا 3090 حدودا: 3800-5200 دلار هست بستگی به مادربرد و ...
۲- این لینک هم ببینید اگر ۴ تا 3090 خواستید ببندید.
Local Ai Home Server Build at High End $5000 Price

سرعت اینترنت ایران عالیه 🥰


@SohrabContents

امین بشیری که مسیرش از استارتاپ‌هایی در ایران شروع شد و امروز در کمپانی تاکسی اینترنتی لیفت(Lyft) به‌عنوان Software Engineer فعالیت می‌کند.
امین از مسیر واقعی مهاجرت کاری، چالش‌های مصاحبه در شرکت‌های بزرگ، تجربه‌های شکست‌خورده و درس‌هایی گفت که هر برنامه‌نویس باید بشنود!
https://youtu.be/PH1qcACGRXw?si=B50eJ8adFDGL3QBC

@DevTwitter | <Name/>

با من بخند 🦋

🔶 دبیان تصمیم گرفت تغییر systemd را لغو کند تا سازگاری با برنامه‌های قدیمی حفظ شود.

سیستم systemd در نسخهٔ جدید، دسترسی پوشهٔ /var/lock را محدود کرده بود تا فقط root بتواند در آن بنویسد. اما این باعث خرابی برخی برنامه‌های قدیمی شد که هنوز برای قفل‌گذاری از آن پوشه استفاده می‌کنند.

کمیتهٔ دبیان گفت طبق استاندارد FHS، این پوشه باید برای همهٔ کاربران سیستم قابل نوشتن باشد و بنابراین دستور داد پکیج systemd در دبیان اصلاح شود تا دسترسی قبلی برگردد.

#لینوکس

@TheRaymondDev

🔶 طرح شیشه ای ویندوز ویستا

#یادآوری
#ویندوز

@TheRaymondDev