ایلان ماسک: حمایت مایکروسافت از OpenAI خودتخریبی جنون‌آمیز است
https://digiato.com/business/elon-musk-microsoft-openai-suicidal-competition

پروژه qemu جز جذاب ترین پروژه های حوزه ویرچوالیزیشن هست که تابه‌حال دیدم
این ویدیو مقدمه خوبی برای آشنایی با پروژه هست
https://youtu.be/mzrQqB4ZReM

🔶 در لینکدین یه مشکلی داره که بخش جستجو و هشتگ واقعا عملکرد ضعیفی دارند.

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

@TheRaymondDev

🔶 جمعیت لاراول کاران ایران بیشتر از اروپا و آمریکاست.

#لاراول

@TheRaymondDev

دیگه نمیتونم برای کدهام کامنت بزارم
یه‌جوری شده هر چی مینویسم بوی ai میده 😩💻

@TheRaymondDev

🔶 با انتخاب ترکیبی دو سرور ایرانی تونستم با اینترنت مخابرات به لینوکس مینت ۲۲ ارتقا بدم.

#لینوکس

@TheRaymondDev

فقط با یک پرامپت هر لندینگ پیج یا سایت استاتیکی که دوست داری سریع و رایگان برای خودت بساز!🔥

یکی از کاربردی ترین ابزار هایی که میتونید استفاده کنید DeepSite است ، در ویدئو من یک پرامپت ساده بهش دادم و نتیجه رو میتونید ببینید!🪐

https://huggingface.co/deepsite

@TheRaymondDev

🔶 قسمت جدید طراحی سایت شرکتی با لاراول ۱۲ منتشر شد.

۱۲- ایجاد مدل و دیتابیس و کنترلر برای نمونه کار و گالری
۱۳- مدیریت و ثبت نمونه کار – پارت ۱
۱۴- ایجاد صفحه ویرایش نمونه کار – پارت ۲
۱۵- نمایش گالری با جاوا اسکریپت در نمونه کار – پارت ۳

قیمت دوره با تخفیف ۴۰ درصد : ۸۹۹,۰۰۰ تومان

https://rayium.ir/course/?p=1613

#لاراول

@TheRaymondDev

حافظه تو سیستم عامل صفحه ای page based مدیریت میشه.
به صورت معمول 4KB تقسیم میکنه یعنی مثلا اگه برنامه مون 40MB حافظه بخواد 40MB تقسیم بر 4KB حدودا میشه 10,240 صفحه کوچیک هر صفحه باس تو page table ثبت بشه و cpu هر بار برای دسترسی به حافظه اون رو چک میکنه این overhead زیاد میاره.

واسه بهبود این قضیه huge page ها کمک میکنن معمولا به اندازه های 2MB یا 1GB هستن همون حافظه 40MB فقط با 20 صفحه 2MB میشه مدیریتش کرد این خودش cpu رو کمتر درگیر میکنه و دسترسی سریع میده اینطوری overhead رو میتونیم کاهش بدیم.

یه کش کوچیک داریم تو cpu که آدرس های مجازی رو به فیزیکی ترجمه میکنه اسمش TLB وقتی صفحه ها کوچیک زیاد میشن این زود پر میشه به خاطر این miss زیاد میزنه cpu باید دوباره ترجمه کنه و کندی به بار میاره وقتی سایز page بزرگ میشه هر entry حافظه بیشتری پوشش میده حافظه سریع تر و predictable کار میکنه.

تو کدی که نوشتم با mmap میاد حافظه بزرگی که میخوایم رو از os رزرو میکنه و با MAP_HUGETLB مشخص میکنه که میخوایم hugepages استفاده کنیم بعد این حافظه به شکل آرایه ای از عدد ها در میاد تا راحت بشه روش حلقه و اوپریشن read/write زد با clock_gettime زمان قبل و بعد از حلقه رو در میاره تا latency و throughput حافظه مشخص بشه... چون صفحه ها بزرگ اند cpu کمتر درگیر میشه page table رو چک کنه و TLB miss میاد پایین.

خروجی واسه write حدودا 0.005 ثانیه است برای read/verify شده 0.0035 ثانیه اگه صفحه ها کوچیک 4KB بود حدود 0.04-0.02 ثانیه در می اومد یعنی 2 - 5 برابر کندتر این چیزا سر دیتابیس و کانتینر کاربرد دارند بدیش اینه دستی باس تنظیم کنی انعطاف میاد پایین خود os یه گزینه دیگه داره transparent خودکار اگه نیاز بود صفحه بزرگ ایجاد میکنه بدیش اینه ممکنه latency ناپایدار داشته باشه بعضی وقتا باعث fragmentation و overhead سیستم میشه.

چی شد به این چیزا رسیدم؟
داشتم کانسپت های سیستم عامل سیلبرشاتس رو میخوندم کرمم گرفت :)

اَحپِف‌اِیْسم 🍋

توی صف و معماری event-driven، همیشه یه تعادل بین تولیدکننده و مصرف‌کننده هست. اگر تولیدکننده بیشتر از چیزی که مصرف‌کننده می‌تونه پردازش کنه، داده بفرسته، صف‌ها پر می‌شن و سیستم می‌تونه ناپایدار بشه.

دقیقا Back pressure همون مکانیسمیه که این جریان رو کنترل می‌کنه. وقتی مصرف‌کننده یا صف ظرفیتش پر می‌شه، به تولیدکننده یه سیگنال برمی‌گردونه که آهسته‌تر بده یا منتظر بمونه. عملا فشار رو برمیگردونه سمت تولید کننده پیام که داداش آرومتر😅

حذف فایل و فهرست بدون بازگشت و بازیابی
از روش های حریم خصوصی در لینوکس
دستور srm مخفف secure remove هست و برای حذف امن فایل‌ها استفاده میشه.برخلاف دستور معمولی rm که فقط لینک فایل رو از فایل‌سیستم حذف می‌کنه (و داده‌ها هنوز روی دیسک باقی می‌مونن و قابل بازیابی هستن)،
دستور srm داده‌ها رو به‌صورت غیرقابل‌بازیابی پاک می‌کنه 🔐
قبل از حذف فایل، چندین بار (به‌صورت پیش‌فرض ۳۵ بار) داده‌های تصادفی یا الگوهای خاص روی فایل نوشته میشه،
تا هیچ اثری از اطلاعات قبلی باقی نمونه.

🧾 حذف امن یک فایل:

srm secret.txt

⚡️ حذف سریع‌تر با بازنویسی کمتر (مثلاً ۱ بار):

srm -s secret.txt

📁 حذف امن چند فایل:

srm file1.txt file2.txt file3.txt

📂 حذف پوشه به‌صورت بازگشتی:

srm -r myfolder/

🔻پست و آموزش بیشتر در وبلاگ آکادمی:
https://learninghive.ir/linux-blogs/

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

آن دل که به یاد خود صبورش کردی
نزدیک تر تو شد چو دورش کردی
در ساغر ما زهر تغافل تا چند
تلخیش نماند بس که شورش کردی

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

🔵 عنوان مقاله
A look into how JavaScript source maps work

🟢 خلاصه مقاله:
خلاصه‌ای از ساخت‌وکار source map در JavaScript: کدی که در مرورگر اجرا می‌شود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخش‌های دلتایی موقعیت‌های کد تولید‌شده را به سطر/ستون‌های فایل‌های اصلی (و در صورت وجود، نام‌ها) نگاشت می‌کند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل می‌سازند، Webpack/Rollup/esbuild آن‌ها را ترکیب می‌کنند و Terser در مرحله minify این زنجیره را حفظ می‌کند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را می‌خواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن می‌سازد؛ همچنین پلتفرم‌هایی مثل Sentry با دریافت map می‌توانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشرده‌سازی/کش استفاده کنید. محدودیت‌ها شامل دقت ستونی ناقص در برخی تبدیل‌ها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیری‌های نگاشت است. بهترین رویه‌ها: فعال‌سازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.

#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance

🟣لینک مقاله:
https://golangweekly.com/link/176649/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

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

اون موقع دیگه گند زدید، کاریش هم نمی‌شه کرد ولی برای اینکه خودتون آروم بشید بگید این که MVP بود😂


@Linuxor

یک رپو دیگه برای علاقه مندان به تجربه امنیت و باگبانتی و Ai ابزار جذاب HackGPT Enterprise یه ابزار حرفه‌ای و پیشرفته برای تست نفوذه که با هوش مصنوعی و یادگیری ماشین کار می‌کنه
با HackGPT می‌تونید آسیب‌پذیری‌های سیستم‌ها رو پیدا کنید، گزارش‌های کامل و دقیق بگیرید و حتی از چارچوب‌های امنیتی مثل OWASP، NIST و ISO27001 پیروی کنید.

این ابزار با معماری میکروسرویس‌ها و پشتیبانی از Docker و Kubernetes، مقیاس‌پذیری بالایی داره و می‌تونید روی ابرهای مختلف مثل AWS، Azure و GCP استقرارش بدید.

https://github.com/yashab-cyber/HackGpt/

@DevTwitter | <POURYA/>

کتاب Understanding Distributed Systems
نکاتی که هر developerی در مورد distributed applicationها باید بدونه


چرا همه درباره Distributed Systems حرف می‌زنن؟ 🤔

وقتی اولین بار با سیستم‌های توزیع‌شده آشنا شدم، فکر می‌کردم فقط برای شرکت‌های بزرگ مثل Google و Amazon کاربرد داره. اما حقیقت اینه که امروز تقریباً هر اپلیکیشنی که ازش استفاده می‌کنیم، یه سیستم توزیع‌شده‌س - از Instagram گرفته تا دیجی‌کالا.

سیستم‌های توزیع‌شده چهار مشکل اساسی رو حل می‌کنن:
1️⃣ وقتی ترافیک بیشتر از ظرفیت یه سرور میشه (Scalability)
2️⃣ وقتی نمی‌خوایم با down شدن یه سرور، کل سیستم از کار بیفته (Resiliency)
3️⃣ وقتی کاربرا از سراسر دنیا دارن به سیستم request می‌زنن (Performance)
4️⃣ وقتی می‌خوایم سیستم رو راحت maintain و توسعه بدیم (Maintainability)

اما این قدرت با چالش‌هایی همراهه: نودها باید با هم communicate کنن، باید coordinate بشن، و باید در برابر failure مقاوم باشن. Leslie Lamport یه جمله معروف داره که می‌گه: "سیستم توزیع‌شده جاییه که failure یه کامپیوتری که حتی نمی‌دونستی وجود داره، می‌تونه سیستم تو رو خراب کنه."
اگه دارید روی backend کار می‌کنید یا قراره شروع کنید، درک این مفاهیم دیگه optional نیست - الزامیه. چون دیگه داریم همه چیز رو distributed می‌سازیم.


نکاتی از فصل اول کتاب Understanding Distributed Systems

با تشکر از جناب Roberto Vitillo برای این کتاب درجه یک!


#understanding_distributed_systems
#roberto_vitillo

@gocasts

🔵 عنوان مقاله
Livecore: A Low-Pause Core File Dumper for Linux Processes

🟢 خلاصه مقاله:
این مقاله Livecore را معرفی می‌کند؛ ابزاری برای گرفتن core file از فرایندهای در حال اجرای Linux با وقفه بسیار کم. این ابزار که در یک جلسه «vibe coding» توسط Brad Fitzpatrick (عضو پیشین تیم Go) ساخته شده، امکان ساخت آنی و کم‌اختلال snapshot از حافظه و وضعیت اجرای فرایند را فراهم می‌کند تا بدون متوقف کردن سرویس، داده‌های لازم برای عیب‌یابی به‌دست آید. به‌جای تکیه بر crash یا توقف کامل فرایند، Livecore با بهره‌گیری از goref و قابلیت‌های Linux تلاش می‌کند تصویری دقیق و با سربار اندک تهیه کند و برای بررسی با ابزارهای post-mortem به کار رود. نتیجه، ابزاری عملی برای تیم‌های توسعه و SRE است که به observability کم‌اختلال—به‌ویژه در سرویس‌های Go روی Linux—نیاز دارند.

#Livecore #Linux #CoreDump #Debugging #Go #Observability #BradFitzpatrick #goref

🟣لینک مقاله:
https://golangweekly.com/link/176630/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

اگه دنبال یه آلترنیتیو برای Claude Code می گردید که اکثر Providerهارو ساپورت کنه بهتون Crush رو پیشنهاد می دم!

با go نوشته شده و من خیلی تجربه خوبی داشتم وقتی توی دو سه روز گذشته!

https://github.com/charmbracelet/crush

@DevTwitter | <Von Datawarehausen/>