یه شغل عجیبی برای هوش مصنوعی ایجاد شده!

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

نکته تلخ اینه هیچ تولید علمی اینجا صورت نمی‌گیره و این هایپی که توی کامپیوتر و هوش مصنوعی رخ داده باعث توهم تولید علم توی رشته های دیگه شده.


@Linuxor

🚨🤯 حقیقت تکان‌دهنده 11 سپتامبر: آیا CIA از تروریست‌ها محافظت کرد؟! هرگز چیزی که به شما گفتند باور نکنید! 💥✈️

🎥 قسمت اول

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

📽 زیرنویس فارسی
🧠 مناسب برای همه، چه مبتدی چه حرفه‌ای
🌐 ترجمه این ویدیو با وب‌سایت isega.ro انجام شده — حتماً سر بزن!
📌 برای دیدن قسمت‌های بعدی کانال رو دنبال کن:
📺🌐 @AiSegaro
🚀 هر روز یک قدم نزدیک‌تر به آینده‌ای هوشمند!
📤 بازنشر آزاد با ذکر منبع 🙏❤️

برام سوال شده ایرانی بودن فیچره یا باگه

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۵۷۲

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

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

با معرفی Signal در نسخه های جدید Angular، خیلی از توسعه دهندگان این سؤال رو دارن:

آیا باید RxJS رو کنار بذاریم و فقط از Signals استفاده کنیم؟


واقعیت اینه که هر کدوم از این ابزارها جایگاه خاص خودشون رو دارن:

- ابزار Signals: برای مدیریت state ساده، واکنش پذیری سریع و کدنویسی تمیز. وقتی با داده های لوکال و ساده (در سطح کامپوننت) سروکار دارید (مثل state یک فرم یا تغییرات UI) بهترین گزینه هستن.

- ابزار RxJS: وقتی پای جریان های داده پیچیده وسطه (WebSocket، استریم های real-time، درخواست های ترکیبی HTTP و …) همچنان قدرتمندترین ابزار باقی می مونه.


بهترین رویکرد اینه که در پروژه های واقعی ترکیب هوشمندانه ای از این دو داشته باشیم:

از Signals برای مدیریت state در سطح کامپوننت.
از RxJS برای کار با استریم های پیچیده و async.

اینطوری هم از سادگی Signals لذت می بریم و هم از قدرت RxJS.

@DevTwitter | <Farid Shahdad/>

الگوهای مهم Concurrency توی Golang
گاهی وقتا توی Go، کار کردن با concurrency فقط goroutine و channel نیست، یه سری الگو هست که وقتی یاد گرفتم واقعا دیدم کار رو راحت‌تر می‌کنن. مثلا یکی از اینا fan-out/fan-in هست. یعنی فرض کن چند تا goroutine داری که همزمان دارن یه سری داده رو پردازش می‌کنن (این میشه fan-out) و بعد همه‌شون خروجیشون رو میریزن توی یه کانال واحد تا جمع بشه (fan-in). من معمولا اینو وقتی استفاده می‌کنم که یه عالمه فایل یا دیتا دارم که میشه به صورت موازی روشون کار کرد. یه بار برای پردازش لاگ‌ها ازش استفاده کردم، هر worker یه بخش لاگ رو می‌خوند و پردازش می‌کرد و در نهایت همه‌ی نتایج توی یه جا جمع می‌شد.
یه الگوی دیگه که خیلی پرکاربرده worker pool ـه. به جای اینکه برای هر کاری یه goroutine جدا درست کنم، میام یه تعداد ثابت worker درست می‌کنم، مثلا ۵ تا، و همه‌ی کارها رو میریزم توی یه صف. workerها یکی‌یکی برمی‌دارن و انجام میدن. اینجوری هم منابع مصرف نمی‌شن هم قابل مدیریت‌تره. مثلا وقتی می‌خواستم ایمیل انبوه بفرستم، با worker pool خیلی راحت مدیریت کردم که سیستم منفجر نشه.
یه چیزی که همیشه باید حواسم باشه، محدود کردن هم‌زمانی یا همون bounded concurrency هست. مثلا وقتی می‌خوام به یه API خارجی درخواست بزنم، اگه بذارم ۱۰۰ تا goroutine همزمان بزنن، خیلی راحت اون سرویس منو بلاک می‌کنه یا خودم دچار timeout می‌شم. اینجاست که با یه کانال ساده یا semaphore جلوی تعداد درخواست‌ها رو می‌گیرم، مثلا نهایتا ۱۰ تا همزمان.
حالا مشکل بعدی backpressure ـه. این زمانی اتفاق میفته که producer سریع‌تر از consumer کار می‌کنه. مثلا تصور کن داری رویدادها رو از یه سیستم دیگه می‌گیری ولی پردازشت کندتره. اگه هیچ محدودیتی نباشه، حافظه‌ت پر میشه. من معمولا با کانال‌های buffer‌دار اینو مدیریت می‌کنم؛ وقتی بافر پر میشه producer گیر می‌کنه تا consumer کمی جلو بیفته. یه بار اینو توی سیستم لاگینگ پیاده کردم، به جای اینکه همه‌ی لاگ‌ها رو بدون کنترل بخوره، با backpressure سرعت متعادل شد.
یه چیز مهم دیگه cancellation ـه. بارها پیش اومده یه کاری رو استارت زدم ولی دیگه نیاز نبوده ادامه پیدا کنه. مثلا یه درخواست HTTP طولانی بود و کاربر صفحه رو بست. با context خیلی راحت میشه اینو مدیریت کرد، وقتی سیگنال cancel بیاد، همه‌ی goroutineهای مربوطه متوقف می‌شن. این باعث میشه منابع الکی مصرف نشن.
در نهایت هم timeout. خیلی وقتا نمی‌خوای یه عملیات تا ابد ادامه پیدا کنه. مثلا وقتی به یه سرویس بیرونی وصل میشی، میگی اگه بیشتر از ۲ ثانیه طول کشید، دیگه مهم نیست جواب چی بود، تمومش کن. این کار نه تنها سیستم رو responsive نگه می‌داره، بلکه از گیر کردن کل برنامه جلوگیری می‌کنه.

@DevTwitter | <Mohammad Salehi/>

ممنون میشم اگر شیر کنید :)

بعد میگید ما خلاقیت نداریم

🔶 تم مک برای گنوم ۴۵

[Gnome 45.8] MacOS Tahoe theme

#لینوکس

@TheRaymondDev

Master Thesis in Program Verification @ MPI-SWS
—————————————————

دوستانی که مشغول تحصیل در مقطع کارشناسی ارشد در اروپا هستند و علاقه‌مندند که تز ارشدشون رو تو حوزه‌ی Program Verification انجام بدند این پست رو بخونند :)

ما دنبال دانشجوی مستری هستیم که علاقه‌مند باشه تز کارشناسی ارشدش رو تو حوزه Program Verification در گروه ما انجام بده. پروژه‌ای که مد نظر داریم در راستای توسعه‌ی Java Model Checker (JMC) هستش. JMC یک Program Analyzer هستش که میتونه برنامه‌های مالتی تردی که به زبان Java نوشته میشن رو با استفاده از تکنیک Stateless Model Checking و یا Random Testing وریفای کنه. در مورد JMC توی کانال بسیار مفصل صحبت شده و با سرچ کردن این کلمه کلی مطلب بدست میارید. پروژه‌ای که مد نظر داریم توسعه‌ی الگوریتم TruSt برای وریفای کردن برنامه‌هایی هستش که از مکانیزم Rendezvous در راستای ارتباط thread ها با همدیگه استفاده میکنه. این مکانیزم در زبان Java با استفاده از wait و notify قابل پیاده‌سازی هستش. در قدم اول توی این پروژه، باید این مکانیزم رو با semantics مبتنی بر DPOR مدل کنیم. در ادامه مکانیک الگوریتم رو طوری تغییر بدیم که بتونه مکانیزم مدل شده رو به شکل sound، complete و optimal ساپورت کنه. در انتها این الگوریتم رو در JMC پیاده‌ میکنیم و روی case های real-world ارزیابی می‌کنیم.

دانشجوی عزیز باید تسلط خوبی در برنامه‌نویسی به‌طور خاص زبان Java داشته باشه و برنامه‌نویسی مالتی ترد هم بلد باشه. علاوه‌بر این با مفاهیم ابتدایی test و مهندسی نرم‌افزار و git هم آشنا باشه. اگر دانشجوی عزیز دل‌ ما model checking هم بلد باشه و هر گونه درس مرتبط یا پروژه‌ی مرتبط با verification یا model checking گذرونده باشه هم پوینت مثبت براش خواهد داشت.

دوستان عزیز و علاقه‌مند لطف کنند یک پیام همراه با cv برای بنده ارسال کنند.@joulook

ددلاین : ۱۵ اکتبر

توی این چند وقت اونقدر چیز میز یادگرفتم که سروقت همشو بهتون یاد میدم

عادی ترین برنامه نویس صبح شنبه

الگوهای مهم Concurrency توی Golang
گاهی وقتا توی Go، کار کردن با concurrency فقط goroutine و channel نیست، یه سری الگو هست که وقتی یاد گرفتم واقعا دیدم کار رو راحت‌تر می‌کنن. مثلا یکی از اینا fan-out/fan-in هست. یعنی فرض کن چند تا goroutine داری که همزمان دارن یه سری داده رو پردازش می‌کنن (این میشه fan-out) و بعد همه‌شون خروجیشون رو میریزن توی یه کانال واحد تا جمع بشه (fan-in). من معمولا اینو وقتی استفاده می‌کنم که یه عالمه فایل یا دیتا دارم که میشه به صورت موازی روشون کار کرد. یه بار برای پردازش لاگ‌ها ازش استفاده کردم، هر worker یه بخش لاگ رو می‌خوند و پردازش می‌کرد و در نهایت همه‌ی نتایج توی یه جا جمع می‌شد.
یه الگوی دیگه که خیلی پرکاربرده worker pool ـه. به جای اینکه برای هر کاری یه goroutine جدا درست کنم، میام یه تعداد ثابت worker درست می‌کنم، مثلا ۵ تا، و همه‌ی کارها رو میریزم توی یه صف. workerها یکی‌یکی برمی‌دارن و انجام میدن. اینجوری هم منابع مصرف نمی‌شن هم قابل مدیریت‌تره. مثلا وقتی می‌خواستم ایمیل انبوه بفرستم، با worker pool خیلی راحت مدیریت کردم که سیستم منفجر نشه.
یه چیزی که همیشه باید حواسم باشه، محدود کردن هم‌زمانی یا همون bounded concurrency هست. مثلا وقتی می‌خوام به یه API خارجی درخواست بزنم، اگه بذارم ۱۰۰ تا goroutine همزمان بزنن، خیلی راحت اون سرویس منو بلاک می‌کنه یا خودم دچار timeout می‌شم. اینجاست که با یه کانال ساده یا semaphore جلوی تعداد درخواست‌ها رو می‌گیرم، مثلا نهایتا ۱۰ تا همزمان.
حالا مشکل بعدی backpressure ـه. این زمانی اتفاق میفته که producer سریع‌تر از consumer کار می‌کنه. مثلا تصور کن داری رویدادها رو از یه سیستم دیگه می‌گیری ولی پردازشت کندتره. اگه هیچ محدودیتی نباشه، حافظه‌ت پر میشه. من معمولا با کانال‌های buffer‌دار اینو مدیریت می‌کنم؛ وقتی بافر پر میشه producer گیر می‌کنه تا consumer کمی جلو بیفته. یه بار اینو توی سیستم لاگینگ پیاده کردم، به جای اینکه همه‌ی لاگ‌ها رو بدون کنترل بخوره، با backpressure سرعت متعادل شد.
یه چیز مهم دیگه cancellation ـه. بارها پیش اومده یه کاری رو استارت زدم ولی دیگه نیاز نبوده ادامه پیدا کنه. مثلا یه درخواست HTTP طولانی بود و کاربر صفحه رو بست. با context خیلی راحت میشه اینو مدیریت کرد، وقتی سیگنال cancel بیاد، همه‌ی goroutineهای مربوطه متوقف می‌شن. این باعث میشه منابع الکی مصرف نشن.
در نهایت هم timeout. خیلی وقتا نمی‌خوای یه عملیات تا ابد ادامه پیدا کنه. مثلا وقتی به یه سرویس بیرونی وصل میشی، میگی اگه بیشتر از ۲ ثانیه طول کشید، دیگه مهم نیست جواب چی بود، تمومش کن. این کار نه تنها سیستم رو responsive نگه می‌داره، بلکه از گیر کردن کل برنامه جلوگیری می‌کنه.

<Mohammad Salehi/>

فوری فوری:

دوستان دوره های که در این صفحه هستند با کدتخفیف OMID میتونی یک دوره رو با تخفیف 100 دریافت کنید.

https://land.fdrs.ir/omid/?utm_content=abdolreza-pourmozhdegani&utm_campaign=me-1404-06-3rdstep


البته با چند سیم کارت مختلف اکانت مختلف وارد کنید و دوره دیگه رو هم دریافت کنید.

اکثر اوقات nginx برای ریورس پروکسی استفاده می‌شه مثلا چند تا سرویس داخلی بالا می‌آرن و nginx رو می‌زارن جلوش که ریکوست هارو کاربرا به nginx بزنن و با توجه به قوانینی که برای nginx تعریف کردید به اون سرویس ها ریکوست ها ارسال می‌شه.

اومدن برای ریورس پروکسی یه رابط کاربری ساختن که مدیریتش رو راحت تر می‌کنه داکری هم هست نصبش خیلی راحته. بعد نصب بهتون یه پنل وب می‌ده و توش می‌تونید مدیریتش کنید:

nginxproxymanager.com


@Linuxor

حاصلضرب مهارت های اجتماعی و قدرت برنامه نویسی یه عدد ثابته. هرچقدر برنامه نویس خفن تری باشید مهارت های اجتماعی ضعیف تری دارید.

دکتر حسابی‌


@Linuxor

چندروز هست دارم به یکی از دوستان نزدیکم روی ایده‌اش کمک می‌کنم؛ بیشتر کدهای بکند و مربوط به AI اش با من هست.

یکی از مواردی که توی MVP دیده شد این بود که علاوه بر سرعت توکن هم برامون خیلی مهمه (چندتا فاز داره و مثلا یک مرحله‌اش اینه که خروجی رو Text to Speech بخونه) خب رفتیم سراغ Groq که سرعت خوبی داشت ولی مدل‌هایی که میخواستیم رو نداشت و برای اضافه کردن هم هزینه بالایی می‌گرفت.
بهترین مدل بعدی که جایگزین می‌شد هم کارمون رو خیلی راه ننداخت.
توی همین گشت و گذارها به سی‌ری‌براس رسیدم که سرعت تولید توکنش توی بدترین شرایط 2.5x برابر باقی هست و قیمت خیلی خیلی پایینی هم داره برای تعداد بالا؛ مثلا مدل
Qwen 3 235B Instruct
قیمتی که داره با GPT-5-nano یکی هست ولی سرعت خروجی توکن این کجا و اون کجا (دقت رو هم نگم دیگه)

داشتم برنامه ریزی میکردم که برای کارهای شخصی خودمم از مدل‌های این شرکت استفاده کنم؛ نه بخاطر دقتش که قطعا کار من رو راه می‌ندازه بلکه بخاطر سرعتش (بعضی وقتا سرعت تایپ‌کردن خودم از سرعت response مدل‌ها بیشتره)

خلاصه رفتم توی سایتش و بعد دریافت API دیدم به به

Qwen3-480B (Coder) 
GPT-OSS-120B

چیزایی که دوس دارم هم موجود هست؛ تعداد توکن تولیدیش برای Qwen3-480B توی چندتا تست‌های من بین 2000-2050 توکن بر ثانیه هست.

داشتم میرفتم توی صفحه پرداخت که دیدم Referrals داره :
1 successful invite equals +200K tokens per day (up to 1M). Your friend also gets +200k tokens when they sign up.

خلاصه که چون به هرکدوم (هم من هم کسی که با لینک من عضو بشه) روزی 200K+ توکن رایگان میده؛ گفتم با لینک خودم دعوتتون کنم!

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

Get 200K+ token daily for free (Qwen3-480B Coder)

واقعا این سرعت توی بازار الان و ابزارهای LLM یک کد تقلب (cheat code) هست برای ایده‌هایی که بتونند ازش استفاده کنند.
رقبا رو به راحتی می‌تونه کنار بزنه بنظرم.

2016 Token/Seconds 
Qwen3-480B (Coder)

دوستان توی بخش limit محدودیت‌هاش رو بخونید حتما
مثلا برای auto complete حتما از مدل‌های ساده‌تر استفاده کنید مثل gpt-oss-120b یا qwen-3-32b که میزان درخواست روزانه / دقیقه یا میزان token های روزانه رو سریع مصرف نکنید (بعضی از ابزارها بصورت خودکار قویترین مدل رو انتخاب می‌کنند که ضرر هست)

Carry my soul into the night
May the stars light my way
I glory in the sight
As darkness takes the day
Ferte in noctem animam meam
Illustrent stellae viam meam
Aspectu illo glorior
Dum capit nox diem
Cantate vitae canticum
Sine dolore actae
Dicite eis quos amabam (sing a song)
Me nunquam obliturum (a song of life)
Lived without regret
Tell the ones, the ones I loved
I never will forget
Never will forget