برنامه packet ابزاری برای به‌ اشتراک گذاری پرونده‌ها بین دو کامپیوتر و حتی بواسطه Quick Share اندروید به مخزن پارچ اضافه شد.



برای نصب:

sudo pacman -Sy packet

@ParchLinux

🔰دستورات خالی کردن کش DNS در ویندوز و لینوکس :
🔹ویندوز
ipconfig /flushdns

🔹لینوکس
بسته به سرویس DNS مورد استفاده:

1️⃣ اگر از systemd-resolved استفاده می‌کنی:

sudo systemd-resolve --flush-caches

2️⃣ اگر از dnsmasq استفاده می‌کنی:
sudo killall -HUP dnsmasq

3️⃣ اگر از nscd استفاده می‌کنی:

sudo systemctl restart nscd

یا

sudo service nscd restart

توی تیم درگیر فرایند performance optimization یک اپلیکیشن کاملا client side هستم
که با react + vite نوشته شده و در حال توسعه هست (احتمالا به زودی نسخه MVP هم لانچ میشه).

خب تا قبل از اون همچین تجربه ای رو فقط با nextjs داشتم. که nextjs برای یه همچین منظوری ساخته شده. و تا قبل از اینکه شما وارد فضای performance optimization بشید خودش خیلی چیزارو هندل کرده. من جمله عکس ها و رندر کردنشون در بهترین حالت ممکن (که هنوز هم میبینم بعضیا با اینکه سابقه خیلی زیادی دارن عکس هاشون توی نکست یا سایز مناسبی نداره یا fetchpriority مناسبی نداره یا بدتر از همه CLS خیلی زیادی ایجاد میکنه بخاطر اشتباه سایز دادن)

ولی توی ریکت ما داریم از img element دیفالت خود jsx استفاده میکنیم. و نداشتن یک کامپوننت built-in چالش های مختلفی رو ایجاد میکنه. از جمله همین layout shift که بدترین تجربه ی ممکن رو میتونه برای کاربر ایجاد کنه.

و دقیقا وقتایی که دارید یه پروژه ای رو با ریکت میزنید و میبینید با اینکه ui خیلی خوبی داره ولی اونقد حس حرفه ای بودن و سریع بودن نداره. خیلی از مشکلات تجربه کاربری که داره بخاطر برطرف نکردن CLS یا cumulative layout shift هست.
وقتی توی لود اولیه بعد از پارس شدن استایل ها تازه سایز عکسا مشخص میشه و همه چی بالا پایین میپره توی اون لود اولیه. متریکی که برای گوگل به شدت مهمه.

و اما مسائلی که سعی کردم رعایتشون کنم تا به یک پیشرفت پرفورمنس حدودا ۳۰ درصدی برسم (رسوندنش از ۶۰ به ۸۰ و بالاتر)

اول از همه بهبود متریک CLS بود:
برای عکس هام width و height مشخص کردم توی همون jsx. و همین تمام مسئله ی CLS رو برطرف کرد.

و بهبود LCP:
چیزی که اینجا کمکم کرد به نتیجه خیلی خوبی برسم
اول از همه کاهش سایز تصاویری بود که داشتیم
هرچند عکس ها سایز خیلی کوچیکی داشت ولی همچنان میشد قضیه رو با تبدیل فرمتشون به webp یا avif بهتر کرد.
و همینطور عکس هایی که توی لود اولیه کاربر باید میدید مخصوصا عکس های داخل header رو preload کردم تا خیلی سریع کاربر ببینه و مرورگر قبل از هرچیزی اون عکس هارو دانلود کنه و نگه داره.
که سرعت paint مرورگر نیاد پایین.

همینطور code splitting که به عنوان تسک اصلی مشخص شده بود ولی من پامو فراتر از اون گذاشتم.
کامپوننت route هارو همرو lazy load کردم
و از suspense boundary استفاده کردم تا مرورگر بعد از اینکه وارد اون route شدیم کامپوننت مربوط بهش رو دانلود کنه و نمایش بده.
این کار کمک میکنه توی لود اولیه جاوا اسکریپت اضافه ای دانلود نکنیم و کوچیک تر بودن سایز باندل یا همون js مون به لود سریع تر صفحه خیلی کمک میکنه.

همچنین از rollup-plugin-visualizer استفاده میکنم تا موقع بیلد حتما بهم نشون بده چه ماژول هایی داریم و اگر سایز ماژولی به طور نا متعارف و غیر بهینه ای بزرگه یه trade-off براش انجام بدیم.
یعنی چک کنیم که آیا جایگزینی وجود داره؟
آیا ما داریم واقعا از همه ی پتانسیل ها و فیچر های این ماژول (لایبرری بیشتر منظورمه) استفاده میکنیم؟
اگر جایگزینی داره همین پرفورمنس رو به ما میده؟ و ...

و همچنین به عنوان یه نکته کنکوری که هرجایی بهتون نمیگن:
‍این کانفیگ توی vite.config

‍      // .1
      sourcemap: false, 

     // .2
      rollupOptions: {
        output: {
          manualChunks(id) {
            if (id.includes('node_modules')) {
              return id.toString().split('node_modules/')[1].split('/')[0].toString();
            }
          },
        },
      },

اولیش که مربوط به sourcemap میشه
که با تولید نکردن فایل های sourcemap
بخش های مختلف باندل رو به سورس اصلی map نمیکنه
که اول از همه نکته امنیتی خیلی مهم داره و مهم تر از اون باعث کاهش حجم خروجی نهایی میشه.

و کانفیگ بعدی که باعث میشه هر پکیجی که از node modules ایمپورت شده به عنوان یک chunk جداگونه تولید بشه
یعنی که باندل جداگونه یا فایل js جداگونه که باعث میشه:
۱. کش بهتر مرورگر
یعنی اگه فقط توی بروز رسانی فقط یکی از این موراد (لایبرری ها یا chunk ها) تغییر کنه. بقیه شون توی کش مرور گر باقی میمونن
۲. لود اولیه سریع
مرورگر فقط باندلی که لازم داره رو واکشی میکنه.
۳. تحلیل بهتر ساختار باندل
مثل همون ابزاری که گفتم ‍‍`rollup-plugin-visualizer`
وقتی از اینجور ابزار ها استفاده کنیم راحت تر میتونیم بفهمیم کد ها از کجا میان و تصمیم گیری و تحلیل برامون راحت تر میشه

نکته کنکوری رو از دست ندید 😉

This cheatsheet is awesome

#linux #cheatsheet

[ On | No ] syntactic support for error handling

این مقاله درباره تصمیم تیم زبان برنامه‌نویسی Go در مورد عدم افزودن سینتکس جدید برای مدیریت خطاها (error handling) در این زبان صحبت می‌کنه. در ادامه خلاصه‌ای از محتوای مقاله رو برات توضیح می‌دم:

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

💐 نکات کلیدی:
1. سابقه بحث مدیریت خطاها:
   - مدیریت خطاها در Go به دلیل استفاده مکرر از الگوی if err != nil گاهی اوقات به‌عنوان یک فرآیند پرزحمت و تکراری (verbose) مورد انتقاد قرار گرفته. این موضوع در نظرسنجی توسعه‌دهندگان Go در سال ۲۰۲۴ (Go Developer Survey 2024 H1) هم مطرح شده بود.
   - در طول سال‌ها، پیشنهادات زیادی از جامعه Go برای بهبود سینتکس مدیریت خطاها ارائه شده، از جمله ایده‌هایی مثل استفاده از عملگر ? برای کاهش کدهای تکراری. اما هیچ‌کدام از این پیشنهادات به اندازه کافی حمایت یا اجماع لازم رو به دست نیاوردن.

2. چالش‌های موجود:
   - مقاله توضیح می‌ده که هنوز درک مشترکی در مورد اینکه آیا مشکل اصلی در سینتکس مدیریت خطاها (syntactic verbosity) هست یا در پیچیدگی‌های مدیریت صحیح خطاها (مثل ساخت خطاهای معنادار برای APIها و کاربران) وجود نداره.
   - افزودن سینتکس جدید ممکنه باعث بشه کدهای Go از حالت استاندارد و یکپارچه (idiomatic) خارج بشن و توسعه‌دهندگان رو به استفاده از روش‌های جدید مجبور کنه، که با فلسفه طراحی Go (سادگی و اجتناب از روش‌های متعدد برای یک کار) سازگار نیست.

3. تصمیم تیم Go:
   - تیم Go به این نتیجه رسیده که به جای تمرکز روی تغییرات سینتکسی، بهتره انرژی جامعه و تیم روی بهبودهای دیگه در زبان متمرکز بشه.

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

4. تأثیرات و آینده:
   - این مقاله تأکید می‌کنه که تلاش‌های جامعه برای بحث در مورد مدیریت خطاها، حتی اگر به تغییر سینتکس منجر نشده، باعث بهبودهای دیگه‌ای در زبان Go و فرآیندهای توسعه اون شده.

   - تیم Go امیدواره که در آینده، با درک بهتر از نیازها، راه‌حل‌های مناسب‌تری برای مدیریت خطاها پیدا بشه، اما فعلاً تمرکز روی این موضوع متوقف شده.

💐 نتیجه‌گیری:
این مقاله بیشتر یک بیانیه رسمی از تیم Go درباره پایان دادن به بحث‌های طولانی در مورد تغییر سینتکس مدیریت خطاها در زبان Go هست. اونا معتقدند که در حال حاضر، سیستم فعلی مدیریت خطاها (بر اساس مقادیر error و بررسی صریح) به اندازه کافی کارآمد هست و نیازی به پیچیده‌تر کردن زبان با سینتکس‌های جدید نیست.

https://go.dev/blog/error-syntax


➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔶 پارچ لینوکس بعد از ۴ سال توسعه مداوم در دیسترواچ لیست شد.

#خبر
#لینوکس

@TheRaymondDev

🔰پیدا کردن خطاهای درایورها حین بوت
🔰نمایش درایورهایی که در زمان بوت لینوکس خطا خورده‌اند و اجرا نشده‌اند را با دستورات زیر پیدا کنید. از فرمتی که نوشتم ایده بگیرید برای بررسی حالت های مختلف

🔹 خطاهای کلی در لاگ کرنل (مربوط به درایور)

dmesg | grep -iE "error|fail|unable|could not|driver"

🔹 خطاهای مرتبط با ماژول‌ها

dmesg | grep -i module

🔹 لاگ بوت systemd برای خطاهای درایور

journalctl -b | grep -iE "error|fail|unable|could not|driver"

🔹 مشاهده ماژول‌های بارگذاری شده

lsmod

نویسنده: حسین سیلانی
اخبار و آموزش های بیشتر در کانال:
https://t.iss.one/linuxtnt

🔶 دیپ سیک ممکن است از مدل‌های جمنای گوگل برای آموزش جدیدترین مدل خود استفاده کرده باشد

براساس گزارش تک کرانچ, هفته گذشته، دیپ سیک نسخه به‌روزرسانی‌شده‌ای از مدل هوش مصنوعی R1 خود را منتشر کرد که در چندین معیار ریاضی و کدنویسی عملکرد خوبی دارد. این شرکت منبع داده‌هایی را که برای آموزش این مدل استفاده کرده، فاش نکرده است، اما برخی از پژوهشگران حوزه هوش مصنوعی حدس می‌زنند که دست‌کم بخشی از این داده‌ها از خانواده مدل‌های هوش مصنوعی جمنای گوگل آمده باشد.

#خبر

@TheRaymondDev

اگه اومدین رو لینوکس و جای خالی فتوشاپ رو حس میکنید و با چیز هایی مثل گیمپ حال نمیکنید یا اصلا رو ویندوزید و نمیخواید فتوشاپ نصب کنید photopea.com میتونه بدردتون بخوره
رابط کاربریش خیلی شبیه فتوشاپه و رایگان هم هست و اکثر فیچر های پایه ای فتوشاپو داره

پ.ن فقط حواستون باشه که قدرت فتوشاپ رو قطعا نداره ولی برا کسایی که کارشون در این حده عالیه

#tools
@CleverDevs - @CleverDevsGp

1️⃣ بررسی لاگ‌های مهم سیستم با journalctl
🔹 خطاهای کلی (Error):

journalctl -p err

🔹 هشدارها (Warning):

journalctl -p warning

🔹 بررسی لاگ‌های اخیر (مثلاً آخرین بوت):

journalctl -b -p err

نویسنده: حسین سیلانی
اخبار و آموزش های بیشتر در کانال:
https://t.iss.one/linuxtnt

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

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

@Linuxor ~ dustin

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


@Linuxor

این ریپو یه کورس 12 هفته‌ایه از مایکروسافت برای شروع ماشین لرنینگ

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

github.com/microsoft/ML-For-Beginners

@Linuxor

آپدیت جدید
Gemini2.5 Pro

این ابزار رو برای من غیر قابل استفاده کرده؛ فقط کافیه کمی تاریخچه چت بزرگ بشه (نه اینکه به محدودیت برسه؛ شاید نهایتاً به ۱۶ هزار توکن برسه)

اتفاقی که میوفته اینه که؛ چت‌های آخر رو بطور کامل فراموش می‌کنه و چت‌های قدیمی رو نگه می‌داره (یکی یادش رفته ایندکس منفی بذاره؟)

با چندتا از دوستان هم چک کردم برای اونها هم همین بود (تسک موردنظر برنامه‌نویسی هست.)

یکی لطفاً کامیت‌های آخر رو revert کنه!!!!


فعلاً:
بهترین راهکار اینه که یک سیستم پرامپت آماده کنید؛ و بعد هربار که تغییرات لازم داشتید یک چت جدید ایجاد کنید.
یا اینکه برید روی ابزارهای دیگه.