بعضی لایبری هام هستن که کلی مشکل (issue) دارن ولی هیچ مشکلی ندارن.


@Linuxor

این کانال به مدیر جدید، واگذار شد. ممنونم که در این مدّت، همراه ما بودید.
کانال من: @Bullshits_of_Amiria
کانال زینب: https://t.iss.one/+KuJOCdcXkx01YmZk

#موقت

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

این آتش عشق می پزاند ما را
هر شب به خرابات کشاند ما را
با اهل خرابات نشاند ما را
تا غیر خرابات نداند ما را

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

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




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



@SohrabContents

Anubis
Weigh the soul of incoming HTTP requests to protect your website!

https://anubis.techaro.lol/

#tool

من اطرافم کسی رو ندیدم که کلاس رفته باشه و برنامه نویس خفنی شده باشه، اینکه کلاس تضمین اینو بده خفن می‌شید خودش تبدیل می‌شه به مانع پیشرفت؛ کلاس نباید جوری باشه که مغز به عنوان پناه ازش استفاده کنه برای عدم کار کردن واقعی، کار کردن واقعی کمی سخته... اگه کلاس هم می‌رید سعی کنید اون [چیزی که یاد می‌گیرید] بچربه به اون [تضمینی که کلاس بهتون می‌ده] وگرنه خودش مانع پیشرفتتون می‌شه!


@Linuxor

⚡️نسخه بتا وبسایت دِ گیکس منتشر شد 
🔗 https://thegeeks.ir
دِگیکس؛ پاتوق گیک‌های فارسی‌زبانِ جهان 🌍💻

📚 @TheGeeksCommunity

با یه برق رفتن ساده ببیند چه بلایی سر کیس کامپیوترتون می‌آد!

@Linuxor

دستورات حرفه‌ای لینوکس

🔹 اسکن پورت‌های شبکه بدون نصب ابزار خارجی

for port in {1..1024}; do
  (echo >/dev/tcp/127.0.0.1/$port) &>/dev/null && echo "Port $port is open"
done

🔹 مانیتورینگ real-time پردازش‌های در حال باز کردن فایل

sudo lsof -r 1

هر ثانیه نشون میده چه پروسس‌هایی دارن روی چه فایل‌هایی کار می‌کنن.


🔹 دیدن syscall های یک برنامه

strace -e openat,read,write -p <PID>

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

🔹 پیدا کردن فایل‌های مشکوک (مثل rootkitها)

sudo find / -nouser -o -nogroup

فایل‌هایی که صاحبشون وجود نداره یا گروهشون پاک شده.
معمولاً نشونه‌ی یه فایل مشکوک یا باقیمونده‌ی خرابکاریه.

نویسنده: حسین سیلانی
💬 لطفاً آموزش‌ها را برای بازخورد بیشتر در گروه‌هایی که عضو هستید منتشر کنید.
📢 اخبار و آموزش‌های بیشتر در کانال:
https://t.iss.one/linuxtnt

اگر لندن یا آکسفورد زندگی می‌کردم الان تو راه پاب کلارکسون بودم :(
The Farmer's Dog

مکانیزم Multi-Leader Replication و مصائب Write Conflict - بخش ۱
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ
نمیدونم چقدر راجع‌به مکانیزم Multi-Leader Replications توی دیتابیس‌ها می‌دونید. به‌طور خلاصه اینه که به‌جای این‌که یک نود مستر (Leader، Main یا هرچی) داشته باشیم که درخواست‌های رایت فقط روی اون serve بشند، چندین نود داشته باشیم که این کار رو برای ما انجام بدن. درواقع، Writeهایی که روی هر کدوم از نودها میان، روی باقی نودها Propagate می‌شن.

این کار یک‌سری مزیت داره، اولیش High Availabilityـه. اینطوری اگر یکی از نودهای مستر Fail بشه و به هر دلیلی نتونه به درخواست ما رسیدگی کنه، نودهای دیگه‌ای هستند که این کار رو انجام بدن.

مزیت بعدی Scalability و امکان Load Balancingـه. فرض کنید که تعداد رایت‌هایی که روی نود مستر می‌شه این‌قدر زیاده که I/O نمی‌تونه به همه‌ی درخواست‌ها جواب بده. تو این مکانیزم، ما می‌تونیم لود رو روی نودهای مستر دیگه که به‌طبع روی سرورها و دیتاسنترهای مختلف وجود دارند توزیع کنیم و Response Time رو بیاریم پایین. هر وقت هم که احساس کردیم این تعداد نود کافی نیست، می‌تونیم نودهای مستر جدید به سیستم اضافه کنیم.

با تمام این ویژگی‌های وسوسه‌برانگیز، اما هر آدم عاقلی شما رو تا جای ممکن از این‌که بخواید به این سمت حرکت کنید برحذر می‌داره. علت؟ پیچیدگی بالا و ریسک بالای Write Conflict و در ادامه Data Inconsistencyـه.

چرا این اتفاق می‌افته؟ فکر کنید یک Collaborative Editor درست مثل گوگل داک نوشتید. جایی که آدم‌های مختلف می‌تونن هم‌زمان با هم یک داکیومنت رو ویرایش کنن. یکی از سناریوهای محتمل که به ذهن خیلی‌ها حتما رسیده اینه:

توی خط اول داکیومنت نوشته:

Edited by Alireza

علی و رضا هم‌زمان با هم به داکیومنت دسترسی دارند و دارن این خط رو می‌نویسن. علی که می‌خواد این قسمت رو به‌نام خودش ثبت کنه، این رو این‌طور تغییر می‌ده:

Edited by Ali

درست همون موقع که علی این تصمیم رو گرفته، رضا هم برمی‌داره و اونو این‌طور تغییر می‌ده:

Edited by Reza

و هر دوی این تغییرات به سمت هر کدومشون ارسال می‌شه و اتفاقی که می‌افته اینه که:

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

این دقیقاً همون Write Conflictـه که راجع‌بهش صحبت می‌کردیم. همین مشکل دقیقاً تو سمت دیتابیس هم وجود داره. کلاینت ۱ درخواست رایت رو روی Node A ارسال می‌کنه. در همون زمان، کلاینت ۲ درخواست رایت رو برای Node B ارسال می‌کنه و هرکدوم از این نودها این رایت‌ها رو Propagate می‌کنن و باز هم Write Conflict.

برای رفع این مشکل چه کار می‌شه کرد؟ اولین و بهترین روش: پیش‌گیری! تا جای ممکن نباید سراغ این سناریو رفت. رفع کانفلیکت پیچیده‌ست و شما رو وارد یک Trade-off جدید می‌کنه.
اما واقعاً چه راهکارهایی برای این ماجرا وجود داره؟ چطور میشه حداقل در نهایت، به یک Convergent رسید؟

یک روش که احتمالاً به ذهن شما هم رسیده اینه که جدیدترین (آخرین Writeای که اتفاق افتاده) رو همیشه در نظر بگیریم. این یکی از روش‌های متداولیه که اتفاقاً توی سیستم‌های جدی‌ای مثل Cassandra هم پیاده شده (و تنها روشیه که به‌کار می‌ره). به این الگوریتم می‌گن Last Write Wins یا به اختصار LWW. برای پیاده‌سازیش، در کنار درخواست Write، یک Timestamp هم ارسال می‌شه. این‌طوری هر نود می‌تونه با مقایسه‌ی Timestampها آخرین رایت رو جایگزین مقدار قبلی کنه. مشکل این روش اما فدا کردن Durabilityـه.
این‌طور فرض کنید که توی چند تا کلاینت مختلف، به‌صورت هم‌زمان درخواست رایت ارسال شده و همه‌ی کلاینت‌ها فکر کردن درخواست اون‌ها موفق بوده. این در حالیه که فقط یکی از اون‌ها که دیرتر از بقیه ایجاد شده قبول شده و باقی در نظر گرفته نشدن. در سیستم‌هایی که هیچ‌نوع از دست‌دادن داده‌ای قابل پذیرش نیست، استفاده از LWW چندان مناسب به‌نظر نمی‌رسه.

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

مکانیزم Multi-Leader Replication و مصائب Write Conflict - بخش ۳
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

حالا با در نظر گرفتن Base میشه فهمید که A و ‌B هرکدوم چه تغییری دادند و تغییرات مستقل یا non-coflicting رو به صورت خودکار باهم ترکیب یا مرج کنیم.

درواقع برخلاف مرج دو‌طرفه که ما فقط تغییرات رو باهم بررسی می‌کردیم (مرج دو‌طرف درواقع همون diffـه)، توی این روش علاوه‌ بر مقایسه‌ی دوتایی، این امکان وجود داره که تغییرات هر کدوم رو با نسخه‌ی اورجینال هم مقایسه کنیم. برای درک بهتر ماجرا، این سوال استک‌اوورفلو و جواب‌هاش رو بخونید. این ویدیو‌ هم به‌نظر جالب اومد.

برای مطالعه‌ی بیشتر راجع‌به MPDS: لینک ۱، لینک به جلسه‌ی Presistent Data Structures از کورس MIT Advanced Data Structures

یک تبلیغ از توزیع لینوکس SLS در شماره سپتامبر 1993 مجله BYTE پیدا کردم.

توزیع SLS Linux: دومین توزیع لینوکس بود که نصب و استفاده از سیستم عامل لینوکس را در اوایل دهه ۹۰ میلادی بسیار آسان‌تر کرد. این توزیع بعدها جای خود را به توزیع‌های معروف‌تری مانند Slackware (که از SLS منشعب شد) و Red Hat داد.

مجله BYTE magazine: یک مجله بسیار معتبر و تاثیرگذار در حوزه فناوری و رایانه در دهههای ۷۰ تا ۹۰ میلادی بود. پیدا کردن یک تبلیغ مرتبط با لینوکس در آن دوران، یک یافته تاریخی و کلکسیونی جالب برای علاقه‌مندان به تاریخچه نرم‌افزارهای متن‌باز محسوب می‌شود.

🎨 آموزش ساخت بی‌نهایت وکتور آرت با هوش مصنوعی! 🎨

در این ویدیوی آموزشی یاد می‌گیرید که چطور با استفاده از ابزارهای قدرتمند هوش مصنوعی مثل ChatGPT و Recraft، هر تصویری را به یک اثر هنری وکتور قابل ویرایش تبدیل کنید. 🖌✨

یاد می‌گیرید که چگونه با نوشتن پرامپت‌های ساده و حرفه‌ای، سبک‌های مختلف وکتور را تولید کرده و حتی با ارجاع به یک تصویر، سبک آن را به تصویر دیگری منتقل کنید. همچنین با قابلیت‌های بی‌نظیر Recraft برای وکتورایز کردن، کنترل کامل رنگ‌ها و خروجی SVG برای ویرایش در نرم‌افزارهایی مثل ایلاستریتور آشنا خواهید شد. 🚀

📽 زیرنویس فارسی و انگلیسی
🧠 مناسب برای همه، چه مبتدی چه حرفه‌ای
🌐 ترجمه این دوره با وب‌سایت isega.ro انجام شده — حتماً سر بزن!

☯️ 💳 با حمایت (Donate) از من، محتوای بیشتری در آینده قرار می‌دهم. لینک دونیت (ریالی و کریپتو): donate.isega.ro

📌 برای دیدن قسمت‌های بعدی کانال رو دنبال کن:
📺🌐 @AiSegaro

🚀 هر روز یک قدم نزدیک‌تر به آینده‌ای هوشمند!

📤 بازنشر آزاد با ذکر منبع 🙏❤️

پرامپت هایی که در این اموزش استفاده شده 👆

“Convert this image into a <style> vector art style”
Styles: hyper-detailed, dotwork, tritone, stencil, WPAP, pop, synthwave, lineart, bauhaus, sticker, 3d, flat…etc.

[@01:31] Style Transfer Prompt:
“Apply the style of the first image to the second image, while preserving the characteristics, colors, pose, and facial features of the second image in the final output.”
You should describe your style reference image if it has complex details.

[@02:56] Image Style Prompt:
“Write a descriptive prompt that clearly describes the attached image's style (not its composition). Start the prompt with 'convert this image into'. Ensure the output prompt works on any new image.”

[@03:24] Idea Prompt:
“Write a descriptive prompt that clearly describes a vector art style of <add your idea here>. Start the prompt with 'convert this image into'. Ensure the output prompt works on any new image.”

[@05:47] Basic Unlimited Vector Art Prompts:
“Give me another detailed vector art prompt with a different style/idea.”

⭕️کتاب فارسی مرجع کامل مدرک بین‌المللی LPIC-1(101-500,102-500)

🔸پس از انتشار کتاب مرجع دستورات لینوکسی تحت نام ۱۰۰۱ دستور لینوکس، این بار کتاب جامع و کاربردی با عنوان کتاب مرجع کامل مدرک بین‌المللی LPIC-1 در مرحله نهایی انتشار است.
🔸این مرجع علاوه بر آموزش گام‌به‌گام مباحث اصلی لینوکس، با ارائه محتوای بیشتر از کتاب‌ها و منابع بین‌المللی، مطالعه‌ای منسجم و کامل را برای شما فراهم می‌سازد. با مطالعه این کتاب نیاز به مطالعه کتابهای زیر نمیباشد و تمامی مباحث و سرفصل های کتابهای زیر را پوشش میدهد:


• LPIC-1 Objectives V5.0 – Linux Professional Institute
• LPI Linux Certification in a Nutshell: A Desktop Quick Reference (O'Reilly, 3rd Edition)
• LPIC-1 Linux Professional Institute Certification Study Guide (Sybex)
• CompTIA Linux+ / LPIC-1 Cert Guide: Exams LX0-103 & LX0-104 / 101-400 & 102-400
• Practical LPIC-1 Linux Certification Study Guide
• LPIC-1 Linux Professional Institute Certification Study Guide (Sybex)
• LPIC-1 Linux Professional Institute Certification Bible
• LPIC-1 Linux Certification in a Nutshell

🔹نویسنده: حسین سیلانی
🔹انتشارات یافته
🔹فرمت فایل pdf در 650 صفحه تماما رنگی

اطلاع رسانی به زودی از کانال:
https://t.iss.one/linuxtnt

این ویدیو جز ویدیو هایی بود که خیلی جای خالیشو حس میکنم
بیان صادقانه و بدون سانسور مسیر شغلی و زندگی یک متخصص ایتی
https://youtu.be/tNZnLkRBYA8

🔶 هم زمان با ضبط دوره لاراول, بالاخره من به جمع فول استک MERN پیوستم که قرار است که پروژه مدیریت وظایف با تکنولوژی React, Node.js, MongoDB, Express بنویسم که مبتنی بر SaaS است.

امیدوارم خروجی خوبی از آب در بیاد.

@TheRaymondDev

اگه بگم یه زبان برنامه نویسی داریم که حجم کامپایلرش کوچیک تر از 1kb باور میکنی؟

برین‌فاک (BrainFuck) یه زبان برنامه نویسی رمزی هستش که تو سال 1993 توسط آربن مولبر به هدف کوچکترین کامپایلر دنیا نوشته شد.

هدف مولبر رقابت با کامپایر 1024 بایتی زبان FALSE بود و کامپایلر برین‌فاک فقط 296 بایت فضا اشغال میکرد که البته توی نسخه بعدی این فضا به 240 بایت هم کاهش یافت!!

امروزه توی اینترنت اگر بگردید افرادی هستن که حجم کامپایلر این زبان رو با بهینه سازی الگوریتم هاش به 100 بایت هم برسونن! فکرشو بکن این کامپایلر توی ⅕ یه سکتور دیسک ذخیره میشه (یک دهم کیلوبایت)
حالا از بحث فضا که بگذریم میرسیم به خود زبان که کل دستوراتش از هشت کاراکتر ساخته میشه:   + - , . <> [ ] و همونطور که از اسمش مشخصه به شدت دشواره و مغز شما رو هدف قرار میده.

داکیومنت خیلی وحشتناکی هم داره وقتی وارد سایتش میشی انگار رفتی تو دارک وب:

brainfuck.org

| <Farzad Ebrahimi/>