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

play.google.com/store/apps/details?id=eu.depau.etchdroid

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


@Linuxor

استیم یه کنسول خفن قراره تا 2026 بسازه!

مزیتش هم اینه بازی های کامپیوتر رو می‌تونید روی TV پلی بدید، درواقع یه کامپیوتر لینوکسیه با سیستم عامل SteamOS که جز بازی کردن کلی کار دیگه هم می‌شه کرد، ایده جذابیه، قبلا سال 2014 هم یه ایده شبیه این اجرایی کرد ولی اون موقع غول های کنسول اصلا اجازه ندادن حتی مطرح بشه، اما الان Valve بازار سنگینی رو دستش گرفته و خیلی راحت میتونه وارد بشه، حتی جایگزین سایر کنسول ها مثل XBox و PlayStation بشه.


@Linuxor

جلوگیری از اثر زنجیره‌ای در سرویس‌ها (Cascading Effect)

هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه.
سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، ... تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن.
به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره.

در حالت ایده‌آل، از کار افتادن یک سرویس با اولویت پایین نباید روی سرویس‌های حیاتی اثر جدی بذاره. اما همیشه این‌طور نیست؛ گاهی ارتباط سرویس‌ها طوری چیده شده که از کار افتادن یک سرویس tier4، عملاً سرویس tier1 رو هم با خودش پایین می‌کشه.

یکی از مهم‌ترین راه‌ها برای جلوگیری از این اثر زنجیره‌ای، طراحی asynchronous بین سرویس‌هاست. یعنی برنامه‌ها به‌جای وابستگی‌های synchronous و اجرای خطی، از صف‌ها، eventها یا callbackهای غیرهمزمان استفاده کنن.
خوبه هنگام طراحی ارتباط بین سرویس‌ها به این موضوع دقت کنیم و در trade-offها گزینهٔ async رو جدی‌تر بررسی کنیم.

مورد مهم دیگه انتخاب timeout مناسب و استفاده از retry + backoff و circuit breakerهاست؛ به‌طوری که اگر یکی از وابستگی‌ها قطع شد، سرویس بتونه خودش رو سرپا نگه داره و کامل از مدار خارج نشه.

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

@aminrbg

این سایته خیلی عجیب و جالب بود، توش کلی داستان از کار‌ آفرین ها هست (بیشتر برنامه نویس ها و حوزه Tech) و توضیح دادن که چطوری به اولین فروش و مشتری هاشون رسیدن، چیزای جالب و سرگرم کننده ای توش هست :

www.fakemayo.com

@Linuxor

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


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


روحش شاد و راهش پر رهرو باد.


با احترام، تیم توسعه و نگهداری از توزیع پارچ

@ParchLinux

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


@Linuxor

🎙️ عنوان پادکست:
Metal! 🤘 Bare metal go, config libs, building response writers
خلاصه پادکست:
** این قسمت با حال‌وهوای «Metal! 🤘» به Go روی سخت‌افزار بدون سیستم‌عامل می‌پردازد: هدف و کاربردهای GOOS=none برای هدف‌های freestanding، محدودیت‌های runtime و کار در نبود syscalls. در خبرها، به انتشار GCC 15.1 با پشتیبانی از COBOL اشاره می‌شود و موضوع «os: Root permits access to parent directory» به‌عنوان هشداری درباره لبه‌های امنیتی در مدیریت مسیرها بررسی می‌شود. سپس معیارهای یک کتابخانه پیکربندی «ارگونومیک» (API قابل‌کشف، ایمنی نوع، لایه‌بندی env/فایل/فلگ، hot reload و پیش‌فرض‌های معقول) و خطاهای رایج مرور می‌شود....

بدهی فنی (Technical Debt)
(هزینه‌ی تصمیم‌های سریع)

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

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

برخی از بدهی فنی رایج:

- کدی که تغییر یا توسعه آن بیش از حد دشوار شده است
- معماری‌ای که دیگر پاسخگوی نیازهای جدید نیست
- میان‌برهای موقت که در ابتدا ساده بودند اما امروز به گره‌هایی پیچیده تبدیل شده‌اند

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

در نهایت، بدهی فنی دشمن توسعه نیست؛ ابزاری است که اگر آگاهانه به‌کار گرفته شود می‌تواند سرعت ایجاد کند. اما اگر رها شود، همان سرعت را از شما خواهد گرفت.

موفق باشید! 🌹

@srfirouzi_channel

گاهی اوقات بیشتر از یک پروسه بکند داریم که ممکنه روی سرور های مختلفی باشن و میخوایم درخواست ها به همه اینا برسه. تو اینطور شرایط از چیزی به اسم LoadBalancer استفاده میکنیم.
کارش اینه که روی یک پورت لیسن میکنه و هرچی درخواست میاد رو میفرسته به آدرس یا آدرس هایی که بهش میگیم.
نمونه: Haproxy و Nginx (چند ده محصول معروف دیگه هستن که اسمشون رو نمیگم)
سوالی که پیش میاد اینه که چطور میفهمه به کدوم بکند بفرسته؟

الگوریتم های LoadBalancing:
1️⃣ ‏Round Robin: الگوریتم خیلی معروف در Scheduling هست که بصورت ترتیبی درخواست هارو به ترتیب به بکند های مختلف ارسال میکنه.

2️⃣ ‏Least Connections: بررسی میکنه که درحال حاضر چند کانکشن به هر سرور بازه، و درخواستو میفرسته به اونی که درحال حاضر کمترین تعداد کانکشن رو داره.

3️⃣ ‏Source IP Hash: هر درخواستی که میاد رو بررسی میکنه، آدرس IP و Port مبدا و مقصد رو تو یه جدول نگهداری میکنه و همیشه درخواست های یک Source IP خاص رو به یک بکند خاص میفرسته.

اینا پرکاربردترین الگوریتم ها هستن و هرکدوم تو شرایط خاص خودشون کاربرد دارن. اگر علاقه مند هستین میتونید از ChatGPT الگوریتمای بیشتری رو پیدا کنید.

وارد جزئیات نمیشم ولی مثلا وقتی Websocket استفاده میکنیم بطور معمول نیاز میشه که از Source IP Hash استفاده کنیم (اگر میخواید تو ChatGPT سرچ کنید، به این برمیگرده که وبسوکت از نوع Stateful Connection هست).

#LoadBalancing

روی موبایل یا لپ تاپ ، مدل های Ai سازگار با گوشی یا لپتاپت رو بصورت شخصی ، آفلاین و رایگان اجرا کن!

با ابزار فوق‌العاده Anythingllm این کارو میتونید خیلی ساده انجام بدید.

https://anythingllm.com

برای موبایل فعلا نسخه اندروید داره
ولی این تنها قابلیت این نرم افزار نیست ، میتونید به Api های Ai های دیگه هم وصلش کنید و ازش استفاده کنید مثل یک چت بات سریع و سبک

@DevTwitter | <POURYA/>

بعد این رو می‌ذارم تست بشه، مشکلاتشو بگیرم و پارتیشن منیجمنت و ... رو اضافه می‌کنم.

مثل دورانی که اوبونتو مستقیم از روی ویندوز نصب می‌شد.


@SohrabContents

این بخشش نیاز داره که یکمی دقتش بیشتر بشه بخصوص توی بخش aur و به‌هرحال.

تا الان راضی کننده بوده نتایج :)

@SohrabContents

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

کوبِرنِتیز چیه؟
کوبِرنِتیز یه سیستم متن‌باز (Open Source) برای مدیریت و هماهنگ‌سازی کانتینرهاست.
بهش می‌گن Container Orchestrator چون مثل یه مغز مرکزی عمل می‌کنه و تصمیم می‌گیره
کِی، کجا و چطور کانتینرها اجرا بشن.

️ ساختار کلی کوبرنتیز
کوبرنتیز روی یه ساختار به اسم کلاستر (Cluster) کار می‌کنه.
کلاستر از چند سرور تشکیل شده:

(Control Plane): مغز سیستم که شاملAPI Server، Scheduler، Controller Manager و etcd می‌شه.

(Worker Nodes): جایی که کانتینرها واقعاً اجرا می‌شن (با استفاده از ابزاری مثل kubelet و Container Runtime مثل containerd یا CRI-O).

مفاهیم کلیدی در کوبرنتیز
پاد (Pod):
واحد اجرایی اصلی در کوبرنتیزه.
هر Pod معمولاً یه کانتینر داره، ولی ممکنه چندتا هم داشته باشه که با هم کار می‌کنن.
Kubernetes تضمین می‌کنه همیشه همون تعداد Podی که تعریف کردی در حال اجرا باشه (مثلاً سه نسخه از وب‌سرویس).

خودترمیمی (Self-Healing):
اگه یکی از Podها از کار بیفته، Controller Manager تشخیص می‌ده و خودش اون Pod رو روی یه Node دیگه بالا میاره (بدون اینکه نیاز باشه دستی کاری بکنی).

مقیاس‌پذیری خودکار (Autoscaling):
وقتی ترافیک زیاد میشه، قابلیت Horizontal Pod Autoscaler (HPA) بر اساس معیارهایی مثل CPU یا Memory Usage تصمیم می‌گیره چندتا Pod جدید بسازه.
و وقتی ترافیک کاهش پیدا کنه، اونا رو حذف می‌کنه تا منابع هدر نرن.

سه جزء مهم کوبرنتیز
دیپلویمنت (Deployment): مشخص می‌کنه چند تا Pod باید اجرا بشن و آپدیت‌ها چطور انجام بشن.

سرویس (Service): ترافیک رو بین Podها پخش می‌کنه تا همیشه در دسترس باشن.

اینگرس (Ingress): مسیر دسترسی کاربران بیرونی (مثل درخواست‌های HTTP/HTTPS) رو به سرویس‌های داخلی مدیریت می‌کنه.

چرا کوبرنتیز مهمه؟
چون اجرای برنامه‌ها رو خودکار، پایدار و مقیاس‌پذیر می‌کنه.
به همین دلیل، امروز Kubernetes قلب دنیای DevOps و Cloud Native به حساب میاد.
از سیستم‌های مایکروسرویسی گرفته تا پلتفرم‌های یادگیری ماشین (ML) و اپ‌های بزرگ،
همه دارن روی K8s اجرا می‌شن.

@DevTwitter | <Monireh Savaedi/>

⭐️تا کنون 15 کتاب حوزه لینوکس، متن باز و سیستم عامل منتشر شده است.

🔹این سه کتاب فارسی کامل، از دوره های lpic لینوکسی است. به جای خوانده چندین کتاب، این مجموعه همراه با پوشش سرفصل های استاندارد ازمون های lpi و سایر مرجع های لینوکسی است.

🔸فرمت فایلها به صورت pdf
🔸تمام رنگی

🔹کتاب lpic 1
25فصل و 730 صفحه
🔻نمونه کتاب به همراه فهرست کامل کتاب

🔹کتاب lpic 2
9 فصل 500 صفحه
🔻نمونه کتاب به همراه فهرست کامل کتاب

🔹کتاب lpic 3
14 فصل 400 صفحه
🔻نمونه کتاب به همراه فهرست کامل کتاب

https://learninghive.ir

خیام | رباعیات | رباعی شمارهٔ ۷۲

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

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

عالی شد

اینکه راجب این مدل و دیتاست اون (هردو رایگان منتشر شده) بعد زا ۴ روز هیچ چیزی نشنیدم چیزی هست که آزار دهنده هست.
اینکه ۱۰۰۰ تا پست راجب chatgpt 5.1 دیدم ولی راجب این به سختی ۱ پست تازه همین هم به لطف ابزاری که برای کرال کردن و خلاصه ‌کردن مطالب مفید اجرا دارم دیدم.

داستان چیه ؟
متا یک مدل ASR جدید + دیتاست منتشر کرده که بیش از 1600 زبان رو شناسایی می‌کنه حتی شاید بشه گفت کم استفاده‌ترین زبان‌های موجود رو و مدل‌هاش رو هم توی سایز های مختلف منتشر کرده.
من کدهای دموی خودش رو اجرا کردم نتایجش خوب بود.

خیلی پروژه‌های شخصی و کارهای قشنگی میشه با این مدل‌ها کرد:
Meta OmniLingual

وکتور دیتابیس‌ها (Vector Databases)
در دنیای امروز، با رشد مدل‌های زبانی بزرگ (LLMها) و اپلیکیشن‌های هوش مصنوعی، یک نیاز جدید در حوزه ذخیره‌سازی داده به‌وجود آمده که چیزی نیست جز درک معنا، نه فقط داده‌های خام.
اینجاست که وکتور دیتابیس‌ها (Vector Databases) وارد صحنه می‌شوند.

برخلاف دیتابیس‌های سنتی که داده‌ها را بر اساس کلید، متن یا ساختار ذخیره‌سازی می‌کنند، وکتور دیتابیس‌ها داده‌ها را به صورت بردارهای عددی چندبُعدی نگهداری می‌کنند. این بردارها در واقع نمایانگر معنا و مفهوم پشت داده‌ها هستند نه صرفاً کلمات یا مقادیر ظاهری.
کاربرد اصلی این نوع دیتابیس‌ها در سیستم‌هایی است که نیاز به جست‌وجوی معنایی (Semantic Search)، تطبیق شباهت (Similarity Matching) و حافظه بلندمدت برای LLMها دارند. به‌عنوان مثال، در یک چت‌بات هوشمند، وکتور دیتابیس کمک می‌کند تا سیستم مکالمات قبلی یا اطلاعات مشابه را بر اساس معنا بازیابی کند، نه فقط تطبیق واژه‌ها.

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

️ نمونه‌های شناخته‌شده وکتور دیتابیس‌ها
ابزار Pinecone : سرویس ابری مخصوص ذخیره و جست‌وجوی برداری (ساده برای اتصال به LLMها)
ابزار Weaviate : متن‌باز و ماژولار، با قابلیت اضافه کردن embedding model داخلی
ابزار Milvus : یکی از قدرتمندترین پلتفرم‌های متن‌باز در مقیاس بالا (ساخته Zilliz)
ابزار Qdrant : دیتابیس برداری سریع و سبک با API دوستانه (مناسب پروژه‌های کوچک تا متوسط)
ابزار pgvector : افزونه PostgreSQL برای ذخیره و جست‌وجوی برداری (راه ساده برای پروژه‌های موجود)

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

وکتور دیتابیس‌ها پلی هستند بین داده‌های ساخت‌یافته و درک انسانی.
فناوری‌ای که به سیستم‌ها کمک می‌کند “بفهمند”، نه فقط “ذخیره کنند”.

@DevTwitter | <Amir Rahimi Nejad/>

دستور resize2fs در لینوکس

دوستان یک دستور لینوکسی خوب هست که یادگیری اون، همیشه مثل یک ابزار نجات توی شرایط خاص هست.
البته آموزش کاملش رو فردا پشت میگذارم با جزییات و مثال روی سایت

اما خلاصه دستور:
یکی از مواردی که خیلی از کاربرهای لینوکسی درگیرش بودن و هستند تغییر اندازه سیستم فایل هست بخصوص پارتیشن ریشه و home

این برای تغییر اندازه سیستم فایل‌های ext2، ext3 و ext4 استفاده می‌شود. این دستور به شما این امکان را می‌دهد که سیستم فایل موجود را گسترش دهید یا کوچک کنید، بدون اینکه داده‌ها از دست بروند.

البته برای کاهش و افزایش پارتیشن swap قبلا پست گذاشتم

ساخت vm با کامند های qemu جز دلایلی بود که باعث شد من با تأخیر خیلی زیاد سمت استفاده روزمره از این هایپروایزر برم و بعد ها متوجه شدم که پروژه ای به اسم libvirt وجود داره که روی API هایپروایزر های مختلف از جمله qemu به صورت wrapper قرار گرفته که حتی virtual box هم ساپورت می‌کنه
این ارایه با اینکه قدیمی هست ولی بهترین ویدیو هست که پیرامون آشنایی با پروژه libvirt میشه پیدا کرد
https://youtu.be/qr3d-4ctZk4