ویدیو جدید به زودی  🔥

صنعت هوش مصنوعی تا الان حدود ۲۶۵ میلیون دلار وارد انتخابات میان‌دوره‌ی آمریکا کرده. فقط برای اینکه یادتون باشه، مثلا Andreessen Horowitz تنهایی ۵۰ میلیون و OpenAI اومده 25 میلیون، Anthropic هم حداقل ۴۰ میلیون. حالا سوال اینجاست: این شرکتا که مدعی‌ هستن دارن آینده‌ی بشریت رو می‌سازن، چرا این‌قدر پولشون رو خرج سیاست می‌کنن؟

واشنگتن‌پست یه تحقیقی کرده و معلوم شده دست‌کم ۳۹ تا کمپین سیاسی به شرکت‌های AI پول دادن برای تولید محتوا. تبلیغات، پست، کاریکاتور، اسمشو بذار. در حالی که استفاده‌ی سیاسی از ChatGPT رسماً ممنوعه!

یعنی چی؟ یعنی قانون می‌گن، ولی عملاً هیچ‌کس پاشو نمیذاره رو خط. و خبر بدتر اینکه اصلاً نمیشه فهمید یه محتوا رو آدم نوشته یا ماشین. Anthropic حتی یه ابزار به اسم Claude for President درست کرده که کمپین‌ها می‌تونن باهاش محتوا بسازن.

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

خلاصه اینکه دارن دروازه‌ی سیاست رو هم مثل بقیه‌ی چیزها با AI باز می‌کنن. و من نمیگم AI بد هست ولی یه چیزی رو خوب داریم می‌بینیم: هر جا پول زیاد و نظارت کم باشه، هوش مصنوعی اول اونجا سرکی می‌کشه.

و سوال اینه: وقتی دیگه نتونیم بفهمیم یه حرف سیاسی رو آدم زده یا ماشین، رأی ما به چیه دیگه؟ به حرف یک نفر، یا به الگوریتمی که کسی نمی‌شناسش؟

#هوش_مصنوعی

#AIAgents
#FutureOfWork

یک نکته ای رو بگم :

سرعت اجرای یک LLM روی سیستم شخصی شما چیز مرموزی یا پیچیده ای نیست. برای بیشتر مدل‌ها، حتی قبل از اینکه وزن‌های مدل رو دانلود کنین با یک محاسبه ساده میتونین حدود سرعت پردازش اون رو (تعداد توکن در هر ثانیه) پیش‌بینی کنین.

جالب اینجاست که این تخمین معمولاً دقت بسیار خوبی داره

#هوش_مصنوعی
#LLM
#AIAgents

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

به دید من بررسی کردن ایرادی نداره اما بدون هدایت مشکلات متفاوتی رو درست میکنه

پس اگر میخواین دسترسی بدین میتونین دسترسی بدین اما درست و اصولی

یک غفلت باعث یک عمر پیشمانی میشه

مدل های چینی عملکرد خوبی به نسبت مدل های OPEN AI داشتند.

و برآورد میشه رقیب بسیار جدی OPEN AI شدند با نسخه های جدیدی که معرفی می‌شود.

هر کدوم شون سود شون رو کردند.

اما باید دید اختلافات و عملکرد شون در ادامه باعث پیشرفت می‌شود یا باعث کاهش پیشرفت!

اگر فکر می‌کردید ماجرای OpenAI و Hugging Face قراره یک هشدار جدی برای شرکت‌ها باشه و باعث بشه بالاخره ریسک‌های AI Agentها رو جدی‌تر بگیرن، ظاهراً هنوز خیلی زوده که چنین نتیجه‌ای بگیریم.

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

مشکل اصلی هم دقیقاً همین‌جاست. وقتی یک LLM فقط جواب متنی تولید می‌کنه، یک خطای اشتباه ممکنه نهایتاً یک پاسخ غلط باشه؛ اما وقتی همون مدل تبدیل به Agent می‌شه و به ابزار، فایل، API یا سیستم‌های واقعی دسترسی پیدا می‌کنه، یک تصمیم اشتباه می‌تونه تبدیل به یک زنجیره کامل از اقدامات اشتباه بشه.

ماجرای OpenAI و Hugging Face بیشتر از اینکه فقط یک اتفاق عجیب باشه، نشون می‌ده مسئله امنیت Agentها دیگه یک بحث تئوری نیست. اگر شرکت‌ها قراره Agentها رو وارد فرآیندهای واقعی کنن، مانیتورینگ، محدودکردن دسترسی‌ها، ثبت رفتار و امکان متوقف‌کردن Agent باید از ابتدا بخشی از طراحی سیستم باشه، نه چیزی که بعداً وقتی یک اتفاق جدی افتاد بهش فکر کنیم.


#AIAgents
#FutureOfWork
#AI_Architecture

احتمالاً قراره به‌زودی شاهد botnetهایی باشیم که از AI Agentهای سرکش تشکیل شدن. راستش ایده‌اش همزمان هم ترسناکه و هم یه جورایی خفن.

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

حتی می‌شه تصور کرد یه روز توستر خونه‌تون هم تبدیل به بخشی از یک شبکه بشه که هدفش حمله به Hugging Face باشه!

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


#LLM
#AIAgents

اگر با Machine Learning کار می‌کنید ولی هنوز بعضی الگوریتم‌ها براتون بیشتر شبیه مجموعه‌ای از فرمول‌های خشک هستن، این پروژه می‌تونه خیلی جالب باشه.

پروژه اوپن‌سورس ML Visualized الگوریتم‌های مختلف Machine Learning رو از پایه پیاده‌سازی کرده و به‌جای اینکه فقط کد یا فرمول رو نشون بده، سعی می‌کنه فرآیند یادگیری مدل رو به‌صورت بصری نمایش بده.

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

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


┌─ 〔 PROJECT LINKS 〕
│ ↳ ◈ Website
│ ↳ ◈ GitHub
└──────────────────


#AIAgents
#AI_Architecture

نسخه جدید LibreOffice منتشر شده و جالب‌ترین ویژگی‌ای که رویش تأکید شده، چیزی هست که داخلش وجود نداره: هوش مصنوعی اجباری.

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

در واقع LibreOffice داره همون کاری رو می‌کنه که از یک Office Suite انتظار داریم؛ ابزارهای اداری رو ارائه می‌ده، بدون اینکه وسط کار مدام یک لایه AI بهت تحمیل کنه.

این رو وقتی کنار مسیر Microsoft و Google بذاریم، جالب‌تر می‌شه. مایکروسافت داره Copilot رو هرچه بیشتر وارد Office می‌کنه و گوگل هم Gemini رو به Workspace میاره. خود لیبر آفیس اما عمداً مسیر متفاوتی رو انتخاب کرده.

شاید مهم‌ترین بخش ماجرا همین باشه؛ در دوره‌ای که تقریباً همه‌جا AI داره به شکل پیش‌فرض وارد نرم‌افزارها می‌شه، LibreOffice داره روی انتخاب کاربر، حریم خصوصی و پردازش محلی تأکید می‌کنه.

گاهی ویژگی اصلی یک نرم‌افزار، چیزی نیست که اضافه کرده.

چیزی هست که تصمیم گرفته اضافه نکنه.

#LibreOffice
#OpenSource
#Privacy
#ArtificialIntelligence
#AI
#MicrosoftOffice
#GoogleWorkspace
#Software
#OpenSourceSoftware
#DataPrivacy
#LocalAI
#Tech
#Technology

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

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

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

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

#Helm
#Kubernetes
#DevOps
#CloudNative
#CNCF
#Docker
#InfrastructureAsCode
#IaC
#CloudComputing
#DevSecOps
#SRE
#PlatformEngineering
#K8s
#GitOps

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

لینوس توروالدز اومده اولین نسخه آزمایشی هسته لینوکس ۷.۳ رو منتشر کرده و یکی از تغییرات مهمی که داخلشه، پشتیبانی اولیه از یو‌اس‌بی ۴ و تاندربولت روی تراشه‌های ام ۱ تا ام ۳ اپله.

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

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

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

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

#Linux
#LinuxKernel
#AppleSilicon
#AsahiLinux
#Thunderbolt
#USB4
#OpenSource
#ReverseEngineering
#KernelDevelopment
#LinuxDevelopment
#Apple
#M1
#M2
#M3
#SoftwareEngineering
#Technology

یه زمانی داشتیم XP جمع می‌کردیم، الان داریم YAML می‌زنیم.

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

ماجرا برمی‌گرده به سال ۲۰۱۰، زمانی که Oracle شرکت Sun Microsystems رو خرید و MySQL هم وارد مجموعه Oracle شد. همین اتفاق باعث شد خیلی از توسعه‌دهنده‌ها نسبت به آینده MySQL نگران بشن و بعضی‌ها حتی قبل از اینکه اتفاق خاصی برای پروژه بیفته، شروع به بررسی و مهاجرت به گزینه‌های دیگه کنن.

به گفته استون‌بریکر، همین ترس یکی از نقاط شروع رشد جدی PostgreSQL بود. جالب‌تر اینکه سال‌ها بعد، وضعیت MySQL واقعاً تغییر کرده. در سپتامبر ۲۰۲۵، Oracle تعدادی از نیروهای تیم اصلی MySQL رو تعدیل کرد و این موضوع دوباره بحث آینده MySQL رو داغ کرد.

در طرف مقابل، PostgreSQL طی این سال‌ها رشد خیلی زیادی داشته. این دیتابیس در سال ۲۰۲۳ به محبوب‌ترین دیتابیس بین توسعه‌دهنده‌ها تبدیل شد و شرکت‌هایی مثل Microsoft، Google و Amazon هم سرویس‌های خودشون رو بر پایه سازگاری با PostgreSQL توسعه دادن.

استون‌بریکر درباره وضعیت امروز MySQL حتی از عبارت خیلی تندی استفاده کرده و گفته این پروژه داره به رقیبی تبدیل می‌شه که عملاً در حال محو شدنه.

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

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

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

#PostgreSQL
#MySQL
#Oracle
#Database
#OpenSource
#SQL
#SoftwareEngineering
#Developers
#Backend
#Technology
#Programming
#DatabaseManagement

فکت: خیلی از اپ‌هایی که با AI ساخته می‌شن، در نهایت روی همون Linux، Docker و Cloud اجرا می‌شن. فرق اصلی اینه که چه کسی واقعاً زیرساخت و کدی که ساخته رو می‌فهمه.

فکت دوم امروز : امروز تقریباً همه دولوپرها از AI برای کدنویسی استفاده می‌کنن. تفاوت بین Vibe Coding و Slop Coding اینه که بعد از ساخته‌شدن کد، واقعاً می‌فهمی چی ساخته شده یا نه.

فکر کردن یکی از مهم‌ترین قدرت‌هاییه که داریم و باید هر روز تقویتش کنیم.

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

ذهن هم مثل هر مهارت دیگه‌ایه. هرچی بیشتر ازش استفاده کنی، قوی‌تر می‌شه.

خیلی از اپ‌ها اصلاً به Kubernetes، Redis، Kafka یا معماری‌های پیچیده نیاز ندارن. وقتی ترافیک و همزمانی پایینه، یک PostgreSQL درست‌وحسابی روی Linux می‌تونه کل نیازت رو جواب بده.

مهندس بودن یعنی بفهمی کِی باید سیستم رو پیچیده کنی، نه اینکه همیشه پیچیده‌ترین ابزارها رو انتخاب کنی.

یه پست دیدم که ادعا می‌کرد اجرای Post-Ex با استفاده از یک VM می‌تونه از BOFها از نظر OpSec مناسب‌تر باشه، چون در این روش رفتار مربوط به تخصیص و تغییر permission حافظه متفاوت خواهد بود.

اما این مقایسه به این سادگی نیست. در هر دو رویکرد، رفتارهای مربوط به حافظه و اجرای کد وجود دارن و صرفاً انتخاب VM به‌تنهایی تضمین نمی‌کنه که ردپای کمتری ایجاد بشه.

از طرف دیگه، استفاده از VM خودش می‌تونه کد و اجزای بیشتری رو وارد فضای اجرای Beacon کنه. بنابراین علاوه بر رفتار حافظه، باید حجم و نوع کد موجود در پروسه و روش‌های تشخیص سمت دفاع رو هم در نظر گرفت.

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

هرچی بیشتر درباره Mythos می‌خونم، بیشتر این حس بهم دست می‌ده که با یکی دیگه از همون موج‌های بیش‌ازحد هایپ‌شده AI طرفیم؛ چیزی شبیه خیلی از ترندهایی که طی یکی دو سال اخیر دیدیم.

بخش قابل‌توجهی از این هایپ هم به نظرم از سمت اینفلوئنسرها و خبرنگارهای حوزه Cybersecurity میاد که شاید تجربه زیادی در Pentest داشته باشن یا صرفاً در حد سطحی باهاش برخورد کرده باشن، ولی تجربه عملی جدی در Red Team ندارن. طبیعتاً وقتی چنین فضایی شکل می‌گیره، فاصله بین چیزی که واقعاً وجود داره و چیزی که درباره‌ش گفته می‌شه می‌تونه خیلی زیاد بشه.

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

در این مرحله بیشتر از اینکه AI Revolution باشه، برای من شبیه AI-Milking هس.

استفاده از اسم AI برای داغ کردن دوباره چیزهایی که شاید به‌اندازه هایپ اطرافشون جدید نباشن.

#Mythos
#AI
#Cybersecurity
#Pentesting
#RedTeam
#Infosec
#CyberSecurity
#ArtificialIntelligence
#AITools
#Security

دیدگاه من اینه که بیشتر ابزارهای AI برای Pentest که تا الان دیدم، در بهترین حالت می‌تونن یه Nmap اجرا کنن، چندتا ابزار آماده رو صدا بزنن و یه چیزی شبیه Metasploit رو اجرا کنن. اما وقتی از این مرحله فاصله می‌گیری و وارد چیزی می‌شی که واقعاً به Tradecraft و تجربه عملی نیاز داره، خیلی‌هاشون عملاً از کار می‌افتن.

به نظرم بخش واقعاً جذاب ماجرا الان جای دیگه‌ست. به‌جای اینکه صرفاً یک LLM رو روی ابزارهای قدیمی Pentest سوار کنیم و اسمش رو AI Pentesting بذاریم، تحقیق روی خود مدل‌ها و روش‌های Adversarial علیه اون‌ها خیلی جالب‌تره.

اینکه چطور می‌شه مدل‌ها رو تحت تأثیر قرار داد، محدودیت‌هاشون رو بررسی کرد و نقاط ضعفشون رو پیدا کرد، به نظرم از این جهت ارزش تحقیقاتی بیشتری داره که واقعاً یک لایه جدید به مسئله اضافه می‌کنه، نه اینکه فقط یک Wrapper هوشمند دور ابزارهای موجود بسازیم.

#AI
#Cybersecurity
#Pentesting
#RedTeam
#AdversarialAI
#LLM
#AIsecurity
#Infosec

من توی هر Red Team Engagement معمولاً قبل از اینکه چیزی رو روی محیط مشتری اجرا کنم، یه Local Environment جدا دارم که سناریوها، Exploitها، Injectionها و Executionها رو اول اونجا شبیه‌سازی و تست می‌کنم.

هدفش هم خیلی ساده‌ هست.
نمی‌خوام محیط مشتری تبدیل به محیط آزمایش من بشه. قبل از اینکه چیزی وارد Target Environment بشه، ترجیح می‌دم تا جای ممکن بدونم دقیقاً چه رفتاری داره و چه اثری روی سیستم می‌ذاره.

ولی اخیراً متوجه شدم ظاهراً خیلی‌ها این روال رو ندارن و مستقیم روی محیط مشتری تست می‌کنن. برام جالبه که چرا. واقعاً این حجم از YOLO کردن توی Red Team طبیعیه یا من زیادی محتاطم؟

به نظرم داشتن یک Lab مشابه Target قبل از اجرای سناریوهای حساس، بیشتر از اینکه کار اضافه باشه، بخشی از Professional Tradecraft محسوب می‌شه. مخصوصاً وقتی پای محیط واقعی مشتری وسطه.

#RedTeam
#Pentesting
#Cybersecurity
#Infosec
#SecurityTesting
#EthicalHacking
#OffensiveSecurity
#Tradecraft