"Your C Program Starts Before main()"

You think execution begins at main(), but it doesn't.

Try this:

#include <stdio.h>

__attribute__((constructor)) void before_main() {
    printf("I run before main!\n");
}

int main() {
    printf("Now in main.\n");
    return 0;
}

Output:

I run before main!
Now in main.

But WHY?

C runtime (CRT) initializes before main().
Global constructors, TLS setup, and dynamic linker tricks happen first.
These kind of function are registered in .init_array (most of them but not all of them), which runs before main().


You never had control—your program was already running before you got there.

@segfault_t

داستان این روزای vibe coder ها و software engineer ها 😁

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

توی ترمینال به این شکل می‌شه :

docker ai "continerize my application"


@Linuxor

وقتی درباره یه مشکل کامپیوتری توی اینترنت سرچ میکنی:

اولین جواب توی Microsoft:

Hi ScrepY1337. I'm Rashmi, an installation specialist, 10 years awarded Windows MVP, and Volunteer Moderator, here to help you.

have you tried doing sfc/scannow?

پ.ن: اتوماتیک به عنوان پاسخ درست علامت خورده، ولی هیچ مشکلیو حل نمیکنه

چه بگویم، نگفته هم پیداست 🤦‍♂

مهم اینه کد قشنگ باشه بقیش مهم نی 👌

#fun

به نظرتون readability مهم تره یا performance؟

می‌دونم جواب اینطور سوالا همیشه "it depends" هست ولی به صورت کلی اگه بین این ۲ تا در یک لحظه فقط بتونید یک کدومو انتخاب کنید و در اون لحظه کدی که performance خیلی خوبی داره باعث میشه کد اسپاگتی بشه و نمیشه توی اون تایم کم تمیز نوشتش، کدومو انتخاب میکنید؟

نظر من اینه که کدی که readability بالایی داشته باشه رو اگه بعد از یک سال که کد رو نگاه نکردی برگردی بیای بخوای performance رو بالا ببری، تو زمان کوتاهی میتونی

ولی کدی که performance بالایی داشته باشه ولی خوانا نباشه رو ۱ سال دیگه بیای بخوای refactor کنی دهنت سرویس میشه و شاید چند روز وقت ببره تا بفهمی چیکار کردی در نتیجه readability رو انتخاب میکنم(فقط و فقط اگه در اول لحظه performance پایین ضرر حادی به بیزنس نزنه)

توی سیستم های توزیع شده همون‌طور که میدونید ما یه چیزی داریم به اسم load balancer که میاد جلوی سرورا قرار میگیره و  request هایی که میان رو بین سرورا پخش می‌کنه. حالا چجوری و با چه منطقی پخش میکنه؟

اینا مرسوم ترین روش ها هستن حالا بسته به وضعیت میشه هر کدوم یا ترکیبی ازشون رو انتخاب کرد:

1️⃣ Round Robin
درخواست‌ها یکی‌ یکی و به ترتیب بین سرورها تقسیم میشن. ساده و رایج هست، ولی توان سرورها رو در نظر نمی‌گیره.

2️⃣ Weighted Round Robin
همون Round Robin ولی سرورهای قوی‌تر درخواست‌ های بیشتری می‌گیرن. اینطوری فشار متعادل‌ تر پخش میشه.

3️⃣ Least Connections
هر درخواست جدید به سروری میره که کمترین Connection فعال رو داره. برای کارهایی که زمان پردازش متغیر دارن خیلی خوبه.

4️⃣ IP Hash
این روش میاد IP کاربر رو هش می‌کنه و توی رنج تعداد سرور ها میزاره مثلا۱۰ تا سرور داریم میشه ۱ تا ۱۰ و request های یک IP همیشه به یه سرور میرن . این روش برای Session ها یا وب‌ اپلیکیشن‌ هایی که state دارن مفیده.

5️⃣ Least Response Time
درخواست‌ها به سمتی میرن که هم تعداد Connection کمتر باشه و هم response time سریع‌ تر. مناسب برای سرویس‌های حساس به Performance.

وقتی کارفرما ازت میخواد علاوه بر تسک روزانه ات، تسک مازاد رو هم به عهده بگیری:

#fun

والا !

آسیبی که از عبارات « مطالعات نشون داده » ، « یسری تحقیق کردن دیدن » خوردیم واقعا باورکردنی نیست!

ینی فرشته نجاتی شده برای هرکی که می‌خواد مغلطه کنه یا عقاید شخصی یا نظرات جانبدارانش رو به خورد جمعی بده که احساس میکنه توی اون جمع ممکنه آدم باسوادی وجود داشته باشه!


کدوم مطالعه؟ کدوم تحقیق؟ با چه آماری؟ با چه متغیرهایی؟ آیا همین تحقیق بوده صرفا؟ کدوم موسسه بودجه مطالعاتی رو تامین میکرده؟ بین چه گروهی این تحقیق انجام شده؟ چه سالی؟ و هزاران سوال دیگه!


@AluminumDataset

از روزی بترسید که هوش مصنوعی بتونه جوک جدید و خنده دار بگه

وقتی بتونه اینکارو بکنه یعنی واقعا توانایی درک موضوعات رو داره و اون خلاقیتی که ما درحال حاضر نقطه قوت هوش انسانی نسبت به هوش مصنوعی میدونیم رو بدست آورده

به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

@DevTwitter | <Hossein Moradi/>

همیشه از منوی زمخت و مشکی و بی روح Grub بدم میومد،
چند روز پیش که حوصلم سر رفته بود نشستم ببینم چطوری میتونم خوشگلش کنم که نتیجش شد CS Grub
یه تم برای grub2 مثل بخش select side بازی counter strike 2 برای سیستم های Dual Boot, که لینوکس میشه Terrorist و ویندوز میشه Counter Terrorist 😁

با arrow key های بالا و پایین باید سوییچ کنید

https://github.com/ali-hv/csgrub