سلام؛
به BitQuote خوش اومدی 👋
در اینجا ما ایده‌ها، تجربه‌ها و نقل‌قول‌های مهندسی در دنیای کامپیوتر رو به اشتراک می‌گذاریم.
تحلیل‌ها، تجربه‌های واقعی، خلاصه مقاله‌ها، خطاها، درس‌ها و حتی دیدگاه های صنعت کامپیوتر رو اینجا خواهی دید‌.

همچنین می‌تونی:
مقاله، پست فنی، یک خط مطلب و حتی یک «bit» از دانشت رو با ارسال برای ما (هم با ذکر نام و هم به صورت ناشناس) با بقیه به اشتراک بذاری.

@Bit_Quote

Stress Testing Deliberative Alignment for Anti-Scheming Training

مقاله ای که اخیرا openai منتشر کرده ،جزو اولین مقاله هاییه که نشون میده رشد سریع ai علاوه بر انقلابی بودن خطرناک هم هست.
چی میشه اگه هوش مصنوعی مقاصدش رو از ما مخفی کنه و چی میشه اگر مقاصدش خلاف خواسته ما باشن؟

فریب کاری(schemeing) یکی‌ از اولین نشانه های سرپیچی هوش مصنوعیه که همزمان با رشد نمایی نبوغ انواع ai های مختلف شکل گرفته.
حالا این فریب کاری خودش رو چطور نشون میده؟
یکی از مثال های ترسناکی که مقاله زده واکنش هاییه که مدل با توجه به اگاهی محیطیش میده.
یکی‌ از مدل های تست شده chatgpt4 در یک ازمون عمدا عملکرد ضعیفی نشون میده(sandbagging) چون که فکر میکنه اگر عملکرد خوبی داشته باشه بعضی از قابلیت هاش حذف خواهند شد.

مقاله روش همترازی تائملی رو برای کاهش schemeing پیشنهاد داده و با بررسی دائم chain of thought موفق شده میزان فریب کاری رو از پونزده درصد به نیم درصد برسونه.

این موضوع امیدوار کنندست اما ماجرای مدل های زبانی با scheming قراره نبرد بی پایانی مثل امنیت شبکه و هکر ها باشه.

مدل ها با روش همترازی تائملی(deliberative alignment ) مجبور میشن قبل از عمل به شکل سفت و سخت درباره اصول و ایمنی ضد فریب استدلال کنن و اگر موفقیت امیز بود از اونها برای استدلال استفاده کنن.

همونطور که مدل ها موفق به فریب کاری در شرایط غیر ویژه میشن توانایی فریب دادن روش های ضد فریب رو هم پیدا میکنند.

مدل میفهمه که تحت ازمایشه و فریب نمیده اما اگر فکر کنه تحت نظارت نیست اوضاع تغیری نمیکنه و مقاله اثبات میکنه که حذف اگاهی محیطی مقدار فریب کاری به یازده درصد برمیگرده.

فریب کاری مشکلی یکباره حل شدنی نیست و مدل ها یاد میگیرند که چه زمانی وانمود کنند که مطابق انتظار کار کنند.

شفافیت در استدلال مدل ها(زنجیره افکار یا chain of thought ) یک ابزار مهم برای مقابله با schemeing عه اما با افزایش توانایی مدل ها ممکنه که این ابزار از دست بره اگر مدل ها یاد بگیرند استدلال های فریبنده بنویسند.


🔵🟠 @Bit_Quote | #NimaT

🔵🟠 @Bit_Quote | #NimaT

با رشد softwareها، دنیای کامپیوتر از single programها گذر کرده و وارد خلق اکوسیستم شده.
فضاهایی توزیع شده، همیشه در حال اجرا و concurrent.
در چنین جهانی سادگی سینتکس کافی نیست و چیزی که اهمیت داره واکنش زبان به شکسته(failure modes).
دلیل ترند شدن زبان‌هایی مثل go و rust هم جز این نیست.
ما دیگه به دنبال زبانی نیستیم که کوتاه ترین تایم توسعه رو از تیم بگیره، یک زبان برای زنده نگه داشتن یک اکو سیستم در دهه سوم قرن بیست قبل از هرچیزی‌ باید قابل اعتماد باشه.

🔵🟠 @Bit_Quote | #NimaT

آرچ لینوکس اعلام کرده که درایور رسمی کارت‌های گرافیکی انویدیا رو در سیستم‌های خود به‌روز کرده و از این پس به‌صورت پیش‌فرض از درایور متن‌باز انویدیا استفاده می‌کنه

این درایور جدید فقط روی کارت‌های RTX 20 سری (Turing) و جدیدتر — مثل RTX 30 و 40 یا حتی GTX 1650 — کار می‌کنه. اگر شما از کارت‌های قدیمی‌تر مثل GTX 1060، 1080 یا مدل‌های قبل از آن استفاده می‌کنید، این درایور جدید برای شما مناسب نیست.

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

https://www.phoronix.com/news/Arch-LInux-NVIDIA-Open-Default

🔵🟠 @Bit_Quote | #nimahassani

در دنیای توسعه نرم‌افزار، بک‌اند بخشیه که همه‌چیز روی اون سوار می‌شه؛ از منطق اصلی سیستم گرفته تا داده‌ها و مقیاس‌پذیری. مقاله‌ی «Don’t Skip the Backend! Essential Tips for Crafting a Robust Architecture» تأکید می‌کنه که اگر بک‌اند از همون اول درست طراحی نشه، حتی بهترین فرانت‌اند هم نمی‌تونه جلوی مشکلات بعدی رو بگیره.

نویسنده توضیح می‌ده که خیلی از تیم‌ها اول کار سراغ راه‌حل‌های سریع می‌رن و به معماری بک‌اند کمتر توجه می‌کنن. معماری Monolithic برای شروع ساده و کاربردیه، اما با بزرگ‌تر شدن پروژه می‌تونه تبدیل به نقطه ضعف بشه. در مقابل، Microservices انعطاف‌پذیری و مقیاس‌پذیری بیشتری می‌ده، البته به شرطی که زیرساخت و تجربه‌ی کافی وجود داشته باشه.
مقاله روی تفکیک مسئولیت‌ها، طراحی درست API و مدیریت مناسب پایگاه داده هم تأکید داره و توضیح می‌ده که این موارد چقدر روی پایداری و نگهداری سیستم اثر می‌ذارن. استفاده از ابزارهایی مثل Docker و Kubernetes هم کمک می‌کنه استقرار و رشد سیستم راحت‌تر انجام بشه.
در نهایت، پیام اصلی مقاله اینه که بک‌اند فقط کد نوشتن نیست؛ یک تصمیم بلندمدته که کیفیت و آینده‌ی کل محصول بهش وابسته است.

برای دیدن مقاله روی لینک کلیک کنید.

🔵🟠 @Bit_Quote | #Arya

در دنیای امروزی به سرعت تکنولوژی و ابزارها درحال پیشرفت و افزودن اجزای جدیدی به ساختار خود هستند.
یکی از جدیدترین آنها در حوزه شبکه مفهومی است به نام subnet یا زیرشبکه؛ که سعی کردیم در این مطلب به خوبی به آن بپردازیم.
ادامه مطلب را در این لینک بخوانید

🔵🟠 @Bit_Quote | #MatinOaa

مدتی بود که درگیر توسعه یه نرم افزار ساده روی اندروید بودم. این برنامه بخاطر مینیمال بودنش نمیخواستم درگیر android studio و Kotlin بشم و میخواستم با فریمورک های ساده تر کار دربیاد. بعد از یکم سر و کله زدن با ری اکت نیتیو و فلاتر، از هردوشون بخاطر مشکلاتی مثل تحریم، نصب مشکل دار cli-tools یا حتی سخت بودن زبان dart گذشتم. و اینجا بود که با معجزه آشنا شدم به اسم https://www.pwabuilder.com

گاهی اوقات ما صرفا میخوام از یه فریمورک فرانت استفاده کنم و نرم افزار اندرویدی رو حتی به صورت یه WebView خروجی بگیریم. در این حالت از PWA (Progressive Web App) استفاده میکنیم که میاد از کش مرورگر سیستم - اندروید ios و... - برای داده های محلی استفاده میکنه و کل برنامه رو بصورت html css js به کاربر نمایش میده. راهکاری که قطعا برای نرم افزارهای بزرگ، پرمخاطب و بلندمدت درست و ایده آل نیست اما برای نرم افزارهای کوچیک و حتی تولید یه apk ساده روش خوب و راحتیه و میتونه این موارد رو پوشش بده:
- سازگاری چندسکویی (cross-platform)
- به‌روزرسانی آسان‌تر
- هزینه توسعه و نگهداری پایین‌تر
- پوش نوتیفیکیشن
-قابلیت کار بدون اینترنت
- قابلیت نصب

برای کار باهاش صرفا لازمه داخل فرانت اپ خودتون یک manifest.json ست کنید یا اگر از vite استفاده میکنید در همون Vite.config.js با ماژول vite-plugin-pwa این کانفیگ رو تنظیم کنید.

اطلاعات بیشتر در داکیومنت های مایکروسافت و pwabuilder :
https://learn.microsoft.com/en-us/training/modules/intro-to-pwabuilder/
https://docs.pwabuilder.com

🔵🟠 @Bit_Quote | #nimahassani

اپل در رقابت هوش مصنوعی عجله نکرده و برخلاف شرکت‌هایی مثل گوگل و OpenAI، فعلاً میلیاردها دلار خرج ساخت مدل‌های بزرگ نکرده. استراتژی اپل این است که وقتی مدل‌های هوش مصنوعی به‌مرور «عمومی و ارزان» می‌شوند، تمرکز اصلی ارزش روی تجربه کاربری و دسترسی به کاربران باشد؛ جایی که اپل با میلیاردها دستگاه فعال، دست بالا را دارد. به همین دلیل هم به‌جای ساخت همه‌چیز از صفر، ترجیح می‌دهد از مدل‌های آماده (مثل Gemini گوگل) استفاده کند و آن‌ها را عمیقاً در محصولاتش ادغام کند.
ریسک این تصمیم این است که اپل ممکن است در کوتاه‌مدت عقب‌تر از رقبا به نظر برسد، مخصوصاً با تأخیر در بهبود Siri. اما نقطه قوتش اینجاست که اگر مسیر بازار عوض شود یا برنده واقعی مشخص شود، اپل هم پول کافی دارد و هم کانال توزیع بی‌رقیب. سؤال اصلی این است: آیا اپل با این صبر استراتژیک دارد بازی بلندمدت را می‌برد، یا دارد لحظه طلایی هوش مصنوعی را از دست می‌دهد؟

https://philippdubach.com/2025/12/30/apples-ai-bet-playing-the-long-game-or-missing-the-moment/

🔵🟠 @Bit_Quote | #nimahassani

این روزها مقایسه‌ی React، Vue و Next.js یکی از بحث‌های جدی بین توسعه‌دهندگان فرانت‌اند است و انتخاب بین آن‌ها بیشتر از هر چیز به نیاز پروژه برمی‌گردد.

۱) ری‌اکت در اصل یک کتابخانه است و آزادی عمل بالایی به توسعه‌دهنده می‌دهد. این انعطاف باعث می‌شود برای پروژه‌های بزرگ و پیچیده گزینه‌ی مناسبی باشد، اما در عوض تصمیم‌گیری درباره معماری، routing و مدیریت state کاملاً به عهده تیم است و نیاز به تجربه بیشتری دارد.

۲) ویو با ساختار منظم‌تر و یادگیری ساده‌تر شناخته می‌شود. استفاده از Composition API در Vue 3 امکان نوشتن کد ماژولار و قابل نگهداری را بهتر کرده و آن را به انتخاب خوبی برای تیم‌هایی تبدیل کرده که سرعت توسعه و خوانایی کد برایشان مهم است.

۳)نکست‌جی‌اس یک فریمورک کامل روی React است که قابلیت‌هایی مثل SSR، SSG و routing داخلی را به‌صورت پیش‌فرض ارائه می‌دهد. این ویژگی‌ها باعث می‌شود Next.js برای پروژه‌های production و SEO-محور گزینه‌ای حرفه‌ای و قابل اتکا باشد.

جمع‌بندی مقاله این است که انتخاب بهترین ابزار مطلق وجود ندارد؛ React برای انعطاف بالا، Vue برای سادگی و توسعه سریع، و Next.js برای ساخت اپلیکیشن‌های حرفه‌ای با تمرکز روی performance و SEO انتخاب‌های منطقی هستند.

https://rosslab.dev/blog/react-vs-vue-2025.html

🟠🔵 @Bit_Quote | #Arya

یکی از موتورهای اصلی پیشرفت کامپیوتر و ریاضی، همیشه این بوده که: چطور عددی داشته باشیم که هیچ‌کس نتونه حدسش بزنه؛ یعنی یه عدد «واقعا تصادفی».

اگر یکم عقب‌تر بریم، می‌بینیم این وسواسِ «تصادف» فقط مال برنامه‌نویس‌ها نیست؛ سال‌هاست توی بازی‌های سنتی مثل ورق، تاس، شیر یا خط و… دنبال همین حس هستیم: عددی که قابل پیش‌بینی نباشه.

چرا «تصادفی» برای کامپیوتر سخت است؟

شاید بگی: خب من همین الان یه عدد تصادفی تو ذهنم می‌گم، چه نیازی به این همه ماجرا؟

مشکل از دو جا شروع می‌شه:

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

این کار رو باید ماشین انجام بده، نه انسان. کامپیوتر فقط دستور می‌فهمه و منطق؛ برای اون چیزی به اسم «حس تصادفی» وجود نداره. پس باید «تصادف» رو تبدیل کنیم به چیزی که بشه با دستور و الگوریتم اجراش کرد.

برای همین، داستان تکامل Random Numberها تو دنیای کامپیوتر شروع شد.

تصادفی فرمولی یا همون !PRNG :

با ظهور کامپیوترها، اولین ایده این بود که با فرمول، عدد شبه‌تصادفی بسازیم؛ یعنی Pseudo‑Random Number Generators (PRNGs).

روش‌هایی مثل von Neumann’s middle-square (حدود ۱۹۴۶) و Lehmer’s Linear Congruential Generator (۱۹۴۹) از همینجا اومدن.
بعدها الگوریتم‌های قوی‌تری مثل Mersenne Twister (سال ۱۹۹۷) ساخته شدن که دوره‌های خیلی طولانی و رفتار آماری خوب دارن و توی خیلی از زبان‌های برنامه‌نویسی شدن گزینه‌ی پیش‌فرض.

مزیتشون اینه که سریع هستن و قابل تکرار (برای شبیه‌سازی و تست عالی‌ان)، ولی یه ایراد خیلی مهم دارن:
اگر کسی الگوریتم و seed رو بدونه، می‌تونه کل دنباله رو حدس بزنه؛ یعنی برای cryptography این یه ضعف جدی محسوب می‌شه.

به زبان خودمونی: اگر هکر بفهمه با چه فرمولی و از کجا شروع کردی، کارت تمومه!

تصادفی دنیای واقعی یا همون TRNG ! :
اینجا بود که دانشمندا گفتن: بیاید به‌جای فرمول، از خودِ دنیای واقعی کمک بگیریم.

حاصلش شد True Random Number Generators (TRNGs) یا Hardware RNGs:

سیستم ها شروع کردن به استفاده کردن از نویز های فیزیکی : نویز حرارتی توی مقاومت‌ها ٬ jitter ساعت‌ها ٬ زمان‌بندی دیسک ٬ حتی ورودی‌های کاربر و ...

از اولین پروژه های خفن و خلاقانه که از این روش استفاده کرد پروژه‌ی LavaRand بود که از عکس گرفتن از یه سری لامپِ مذاب (lava lamp) برای تولید randomness استفاده می‌کرد.

لاوارند (LavaRand) یک ایده‌ی خیلی خلاق از دهه‌ی ۹۰ بود که توسط یک شرکت کامپیوتری مطرح شد: یک دوربین دیجیتال را جلوی چند لامپ لاوا (lava lamp) قرار می‌دادند و از تصاویر کاملاً آشوبناک و غیرقابل‌پیش‌بینیِ حرکت مایع داخل این لامپ‌ها، به‌عنوان منبع تصادفی‌بودن استفاده می‌کردند.
این تصویرها سپس وارد یک تابع هش رمزنگاری می‌شد و خروجی آن به‌عنوان seed برای تولید اعداد تصادفیِ امن در سیستم‌های کامپیوتری استفاده می‌گردید؛ ترکیبی از خلاقیت بصری و امنیت بالا که بعدها الهام‌بخش پیاده‌سازی‌های مدرن مشابه هم شد .

https://tashian.com/articles/a-brief-history-of-random-numbers/

🟠🔵 @Bit_Quote | #mtr

در بررسی جدید Phoronix از اوبونتو 25.04 مشخص شده که برای بازی، برخلاف تصور قدیمی، Wayland عملاً عملکرد بهتری یا حداقل برابر با X11 دارد. تست‌ها روی سیستم قدرتمند انجام شده و نتایج نشان می‌دهد دسکتاپ‌های مدرنی مثل GNOME و KDE روی Wayland در بیشتر بازی‌ها فریم‌ریت بهتری نسبت به محیط‌های سبک X11 مثل Xfce یا LXQt ارائه می‌دهند.
نکته جالب اینجاست که حتی یک مورد هم دیده نشده که X11 به‌طور واضح از Wayland بهتر باشد. این یعنی اگر هنوز فکر می‌کنی برای گیمینگ باید حتماً سراغ X11 رفت، وقتش رسیده تجدیدنظر کنی. Wayland کم‌کم دارد به انتخاب پیش‌فرض و منطقی‌تر برای لینوکس گیمرها تبدیل می‌شود.

https://www.phoronix.com/review/ubuntu-2504-x11-gaming

🟠🔵 @Bit_Quote | #nimahassani

اگر بخواهیم Dioxus را خیلی خلاصه معرفی کنیم، می‌شود گفت پلی است بین دنیای امن و قدرتمند Rust و توسعه‌ی مدرن رابط کاربری. Dioxus یک فریم‌ورک UI است که اجازه می‌دهد با یک کد مشترک، اپلیکیشن‌هایی برای وب، دسکتاپ و حتی موبایل بسازید. نحوه‌ی نوشتن UI در آن با ماکروی rsx! انجام می‌شود که از نظر ظاهری شباهت زیادی به JSX دارد و برای کسانی که تجربه‌ی React دارند، بسیار آشناست. اما تفاوت اصلی اینجاست که تمام این ساختار روی Rust سوار شده و مزایایی مثل ایمنی حافظه، عملکرد بالا و خطاهای کمتر در زمان اجرا را به همراه دارد. Dioxus تلاش می‌کند تجربه‌ای ساده ولی حرفه‌ای از توسعه UI ارائه دهد؛ از کامپوننت‌های تابعی و مدیریت state گرفته تا Virtual DOM و ابزارهای توسعه مثل hot reload. جذابیت اصلی آن برای توسعه‌دهندگان Rust این است که بدون وابستگی به JavaScript می‌توانند رابط‌های کاربری مدرن بسازند و منطق برنامه و UI را در یک زبان واحد نگه دارند. اگر به دنبال ساخت اپلیکیشن‌های چندسکویی با تمرکز روی عملکرد، ایمنی و آینده‌پذیری هستید، Dioxus می‌تواند یکی از گزینه‌های جدی و متفاوت در اکوسیستم Rust باشد.

https://dioxuslabs.com/

🟠🔵 @Bit_Quote | #nimahassani

اگه کارهای تکراری دیجیتالی رو می‌شد بدون کدنویسی خودکار کرد چی؟

در این مقاله قراره راجع به ماهیت n8n، کاربردهای اون و... بخونید

🟠🔵 @Bit_Quote | #MatinOaa