معادل دستور du در لینوکس که با راست نوشته شده: dust

توضیحات کامل در گیت هاب:
http://github.com/bootandy/dust


@DevTwitter | <Mohammad/>

الان ۸ ساله با کمک ۴۰ نفر دیگه لیستی از APIهای ساخت ایران رو نگهداری می‌کنم. دنبال اینم که لیستی بسازم از MCP Server مربوط به سرویس‌های داخلی.
https://github.com/Hameds/APIs-made-in-Iran

@DevTwitter | <Hamed/>

#لاس

کامپیوتر بهانه است؛
خط به خط به دنبال تو می‌گردم.

@DevTwitter | <Masih/>

اون اوایل که زیاد می گفتن ویندوزت لینوکسه؟

توی این سال‌ها هم که لینوکس با میزکار Gnome شناخته شده، با توجه به اینکه از KDE استفاده می کنم بارها بهم گفتن اینکه ویندوز هست!

قیافه KDE قبل از ویندوز همین شکلی بوده!
حتی فراتر از این عکس‌ها Customize میشه کرد.
https://hackernoon.com/18-awesome-linux-themes-for-your-inspiration

@DevTwitter | <VAHID NAMENI/>

آنچه خوبان همه دارند، تو تنها داری: معرفی OpenObserve

بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های اخیر، ابزارهایی چون VictoriaMetrics و Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.

اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
OpenObserve (O2)
openobserve.ai
OpenObserve

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

معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده

پروژه OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده می‌شود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل Parquet.

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

️ آنچه در بررسی اولیه توجه من را جلب کرد

امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد

پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران

معماری Stateless با مقیاس‌پذیری افقی آسان

قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch

پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob

کوئری با SQL، PromQL و VRL

سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه

طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ

عملکرد و مقیاس

در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.

جامعه و مسیر رشد

این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.

دعوت از تیم‌های DevOps و SRE

اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.

@DevTwitter | <Mojtaba Banaie/>

میخوام دو تا از عجیب ترین Http status code هایی که وجود داشته و داره رو بگم

احتمالا درمورد Http Status Code 418 شنیده باشین.
418 (I'm a teapot)
داره میگه من قوری ام! جالب تر از اینکه چرا وجود داره و میگه من قوری ام اینه که به طور رسمی این http status code تو RFC 2324 ثبت شده!

این یکی رسمی نیست اصلا ولی تو Twitter API v1 ازش استفاده شده بود.
420 (Enhance your calm)
برای اینکه بگن آقا زیاد داری درخواست میفرستی از این استفاده میکردن
بعدا چون تو استاندارد نبود تو v1.1 اومدن تبدیلش کردن به 429 (Too many requests).

@DevTwitter | <Ali Valizadeh/>

این opencode.ai هم یک جایگزین برای CLIهای متصل به هوش مصنوعی است.

گرچه CLI بیشتر توسط برنامه‌نویس‌ها استفاده می‌شه ولی خب چون می‌تونیم چندین agent تعریف کنیم و همزمان باهاشون در یک پروژه بشینیم (multi-session) می‌شه برای انواع کارها ازش استفاده کرد.

@DevTwitter | <Hamed/>

یه exporter ساده با Go نوشتم که متریک‌های سیستم و اپلیکیشن رو به Prometheus می‌فرسته.
همراه با Docker، Prometheus و Grafana برای تست محلی.

اگر به monitoring با Go یا observability علاقه‌مندید، می‌تونید نگاهی بندازید:

https://github.com/irvaniamirali/go-prometheus-exporter

@DevTwitter | <Amiri/>

یکی از ابزار های باحال و بامزه ای که اکثر لینوکس یوزر ها باهاش آشنایی دارن Neofetch هستش!
این ابزار باحال به شما این اجازه رو میده که یه اطلاعات کلی از سیستم به صورت دسته بندی شده و مرتب رو توی ترمینال داشته باشید.
چیزی که Neofetch رو نسبت به سایر پکیج های sysinfo متمایز میکنه اون تصویر لوگوی توزیع لینوکسی شماست که البته قابل کاستومایز هم هست!(مثل تصویر).

این ابزار بامزه برای همه توزیع های لینوکسی در دسترسه و میتونید با هر پکیج منیجری به راحتی نصبش کنید.البته این ابزار روی بعضی از پکیج منیجر ها مثل Pacman موجود نیست و برای توزیع هایی مثل آرچ لینوکس و مانجارو باید پکیج Fastfetch رو نصب کنید دقیقا کار Neofetch رو میکنه.(که البته خیلی هم کامل تره!)

لینک Neofetch روی گیتهاب:
https://github.com/dylanaraps/neofetch
لینک Fastfetch روی گیتهاب:
https://github.com/fastfetch-cli/fastfetch

* البته neofetch آرشیو شده.

@DevTwitter | <Farzad Ebrahimi/>

زیر 10 دقیقه؛
با توجه به اینکه قبلا Gemini Pro رو گرفتیم؛
اینجا Perplexity PRO رو می‌گیریم...
یکساله | رایگان


لینک ویدیو:
https://www.youtube.com/watch?v=0p6dZ1NPecc&list=PLwUWEGKy5kyNrPv05-Asbhm6g6S8_eRPb&index=16

@DevTwitter | <Ryan Heida/>

اگر علاقه‌مند به امنیت دفاعی و Blue Team هستید یا می‌خواهید دانش خود یا سازمان‌تان را مورد سنجش قرار دهید،
مخزن Awesome Cybersecurity Blue Team می‌تواند تا حدود زیادی به شما در پیدا کردن این مسیر، به شما کمک کند!
https://github.com/fabacab/awesome-cybersecurity-blueteam

@DevTwitter | <VAHID NAMENI/>

https://github.com/MSNP1381/openapi_llm_ready
تابحال شده بخواید از api های یه پروژه که openapi هستن تو کدتون استفاده کنید و خیلی اوقات نیازه که کل فایل openapi رو به llm بدید و خیلی اوقات بخاطر ساختار references مدل نمیتوته خوب درک برا همین این یه فایلو ساختم که api هارو به markdown تبدیل میکنه /

@DevTwitter | <Nemat/>

گیت‌هاب Agent HQ را معرفی کرد؛ دسترسی به ایجنت‌های کدنویسی مختلف در یک هاب

گیت‌هاب با معرفی پلتفرم جدیدی به نام Agent HQ امکان مدیریت و کنترل ایجنت‌های هوش مصنوعی کدنویسی از شرکت‌های مختلف مانند OpenAI، گوگل، آنتروپیک، xAI و Cognition را در کنار کوپایلوت فراهم کرده است.

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

@DevTwitter | <Digiato/>

مقایسه PostgreSQL در برابر MySQL — رقابتی میان دقت و سادگی

در تصویر اول، ستونی از نوع JSONB به همراه ایندکس GIN به جدول کاربران در پایگاه‌داده‌ی PostgreSQL اضافه شده است.
در تصویر دوم، اجرای یک کوئری بر روی ۵۰٬۰۰۰ رکورد در PostgreSQL حدود ۷ برابر سریع‌تر از MySQL انجام شد.

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

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

کارایی و الگوی مصرف
معمولاً در بارهای کاری سبک‌تر و اپلیکیشن‌های مبتنی بر خواندن زیاد MySQL عملکرد بهتری نشان می‌دهد.
ساختار ساده‌تر و تنظیمات ابتدایی بهینه‌اش باعث می‌شود برای استارتاپ‌ها، MVPها و پروژه‌های با معماری ساده انتخابی طبیعی باشد.
در سوی دیگر، PostgreSQL در سناریوهای تحلیلی، تراکنش‌های پیچیده و Queryهای چندلایه قدرت واقعی خود را نشان می‌دهد.
پشتیبانی از قابلیت‌هایی مانند CTE، Window Function و نوع داده‌ی JSONB آن را به گزینه‌ای ایده‌آل برای سیستم‌های داده‌محور تبدیل کرده است.

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

در نهایت، انتخاب میان PostgreSQL و MySQL نه بر اساس «بهتر بودن»، بلکه بر اساس اولویت‌های معماری و نیازهای پروژه تعیین می‌شود.
اگر پروژه‌تان حول محور دقت، استاندارد و توسعه‌پذیری بلندمدت می‌چرخد، PostgreSQL انتخابی استراتژیک است.
اما اگر به دنبال سادگی، سرعت پیاده‌سازی و پایداری در نیازهای روزمره‌ی وب هستید، MySQL همچنان گزینه‌ای درخشان و اثبات‌شده است.


@DevTwitter | <Babak Mirhosseini/>

کمپانی HuggingFace اومده و یک بلاگ (که میتونید به صورت یک کتاب هم دانلود کنید و بخونید) از تمام مراحل training تا post training و fine tuning مدلهای کوچک LLM و VLM که خودشون انجام دادند را درست کردند. یعنی تمام نکات و قلق ها را توضیح میدند.
Link: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook

@DevTwitter | <Mehdi Allahyari/>

سیستم سفارش رستوران من روی گیت‌هاب منتشر شد!
ساده، کاربردی و آماده استفاده برای مدیریت سفارشات

https://github.com/nimaohamdi/Restaurant-Order-System

@DevTwitter | <Nimo/>