بنیان‌گذار لینوکس: سیل باگ‌یابی با هوش مصنوعی، مدیریت امنیت سیستم‌عامل را دشوار کرده است!

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

ماجرا از این قرار است که برخی پژوهشگران و شکارچیان باگ، با استفاده از ابزارهای هوش مصنوعی، روزانه صدها گزارش از آسیب‌پذیری‌های احتمالی برای تیم برنامه‌نویسان لینوکس ارسال می‌کنند. مشکل اینجاست که این ابزارها مدام خطاهای تکراری، پیش‌پاافتاده و غیرمحرمانه را پیدا می‌کنند. در نتیجه، صندوق پیام‌های امنیتی لینوکس پر از هرزنامه‌هایی شده که ارزش فنی ندارند و مدیریت‌شان هم «تقریباً غیرممکن» است!

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

توروالدز از افرادی که با هوش مصنوعی گزارش‌های انبوه تولید می‌کنند انتقاد کرده و از آن‌ها خواسته رویه خود را تغییر دهند:

«اگر واقعاً می‌خواهید کمک کنید، مستندات نرم‌افزار را بخوانید، یک راه‌حل یا وصله امنیتی بسازید و ارزشی واقعی به آنچه هوش مصنوعی پیدا کرده اضافه کنید. از آن دسته افرادی نباشید که بدون درک واقعی مشکل، صرفاً یک گزارش تصادفی می‌فرستند.»

جالب است بدانید پدیده گزارش‌های بی‌فایده و تکراری فقط به لینوکس محدود نمی‌شود. اوایل سال میلادی جاری، توسعه‌دهندگان ابزار شبکه کرل (Curl) هم اعلام کردند که به دلیل دریافت سیل عظیمی از گزارش‌های بی‌ارزش و تولیدشده با هوش مصنوعی، برنامه جایزه‌دهی برای کشف باگ خود را متوقف می‌کنند!

https://x.com/NooshDaroo_web/status/2056706551700672836?s=20

@codehalics | کدهالیک

نسخه Gemini 3.5 Flash منتشر شد

این نسخه به‌طور قابل توجهی قوی‌تر از Gemini 3.1 Pro است.

مهم‌ترین نکته این است که گوگل به مشکلات مربوط به عامل‌پذیری (agentness) به طور جدی پرداخته و به ویژه مدل را در این زمینه بهبود داده است. به عنوان مثال، نشان دادند که چگونه Gemini 3.5 Flash در ۱۲ ساعت یک سیستم عامل کوچک نوشت که می‌تواند Doom را اجرا کند. مدل Pro نیز وجود دارد و وعده داده شده که ماه آینده عرضه شود، قیمت‌های آن احتمالاً بسیار بالا خواهد بود.

@codehalics | کدهالیک

برای تیم‌های توسعه که روی چند پروژه همزمان کار می‌کنن یا حتی مدیریت پروژه های شخصی، Linear انتخاب خیلی خوبی هست.
مدیریت Issue, Roadmap و... با قابلیت اتصال به AI و Claude Cowork
جایگزین مناسب Jira برای رهایی از سردرد :)

https://linear.app/

Ali Saleh

@codehalics | کدهالیک

کرسر داره بشدت روی مدل composer 2.5 کار میکنه اگر کرسر باز باشید تا حالا شده که مدلای پرمیوم تموم بشن و ازتون بخواد سوییچ کنه روی auto پشت زمینه روی مود auto داره از composer استفاده میکنه
توی نسخه جدیدش تونسته امتیاز بسیار بالایی نسبت به رقبای بشدت سر سختش مثل opus داشته باشه
با قیمت بسیار بسیار بسیار کمتر که این میتونه مزیت رقابتی auto مود کرسر رو بشدت زیاد کنه !

این مورد رو حتی ایلان ماسک ریتوییت کرده و ازشون تقدیر کرده البته که قرار بود با 160 میلیارد دلار کرسر رو بخره رقمی حدود نزدیک به 3.5 برابر قیمتی که توییتر خرید باهاش !

https://x.com/leerob/status/2057077492670767259?s=20

@codehalics | کدهالیک

با این اکستنشن ساده کروم میتونید قیمتارو بصورت دلاری در دیجیکالا ببینید.

https://github.com/hexamya/digikala-currency-converter

Hesam Jr;

@codehalics | کدهالیک

فیگما ایجنت قابلیت جدید هوش مصنوعی فیگماست که تازه از ۲۰ می ۲۰۲۶ به‌صورت limited beta برای بعضی کاربران فعال شده؛ ایده‌اش این است که AI فقط یک چت‌باکس کنار ابزار طراحی نباشد، بلکه مستقیم داخل canvas فیگما کار کند: از روی context فایل، design system، کامپوننت‌ها و استانداردهای تیم بفهمد چه باید بسازد یا اصلاح کند، bulk edit انجام دهد، ایده بدهد، فیدبک طراحی بدهد و حتی با استفاده از skills طبق الگوهای تیم خروجی نزدیک‌تری به استاندارد محصول تولید کند. خلاصه‌اش این است که فیگما دارد از «ابزار طراحی» به سمت «محیط طراحی با همکار هوشمند داخل خود فایل» حرکت می‌کند؛ البته فعلاً برای همه باز نشده و در مرحله rollout محدود است.

https://www.figma.com/blog/the-figma-agent-is-here/

@codehalics | کدهالیک

فونت زیبای استعداد (Estedad)، کاری از امین عابدی، منتشر شده در Google Fonts.

https://x.com/aminabedi68/status/2057411238829699436?s=20

https://fonts.google.com/specimen/Estedad

@codehalics | کدهالیک

پایتون ۳.۱۵ هنوز رسمی منتشر نشده، ولی بعضی از تغییرات ریزش واقعاً جذاب‌تر از فیچرای اصلین

یکی از بهترین اضافه‌ها اینه که بالاخره میشه TaskGroup توی asyncio رو تمیز و بی‌دردسر کنسل کرد. قبلاً برای متوقف کردن یه گروه تسک باید کلی حقه با Exception و suppress می‌زدیم، الان فقط:

tg.cancel()

و تمام.

یه تغییر خیلی خفن دیگه هم برای context managerهاست. از این به بعد وقتی از context manager به‌عنوان decorator استفاده می‌کنیم، روی async function و generator هم درست کار می‌کنه. قبلاً decorator عملاً همون اول تموم می‌شد و کل lifecycle فانکشن رو پوشش نمی‌داد. این تغییر کوچیکه ولی برای کسایی که ابزارهای profiling/logging می‌نویسن خیلی ارزشیه.

تو بخش threading هم بالاخره iteratorهای thread-safe اضافه شدن. قبلاً اگر چند thread همزمان از یه iterator می‌خوندن احتمال خراب شدن state یا skip شدن داده‌ها وجود داشت. الان با:

threading.serialize_iterator(...)

خیلی راحت میشه امنش کرد.

یه قابلیت بامزه هم اضافه شده برای Counter:
الان عملگر xor (`^`) هم داره 😄
یعنی میشه symmetric difference روی Counterها انجام داد. شاید استفاده روزمره نداشته باشه ولی از لحاظ کامل‌تر شدن API حرکت جالبیه.

و آخرین چیزی که خیلی دوست داشتم:
الان میشه JSON رو مستقیم به ساختارهای immutable تبدیل کرد. یعنی مثلاً لیست‌ها tuple بشن و objectها frozendict. برای caching و hash کردن داده‌ها خیلی کاربردیه.

در کل حس می‌کنم پایتون ۳.۱۵ بیشتر از اینکه فقط flashy feature داشته باشه، داره جاهای اذیت‌کننده و قدیمی زبان رو تمیز و بالغ‌تر می‌کنه؛ همون تغییرایی که شاید تیتر خبر نشن ولی برنامه‌نویس‌ها هر روز قدرشونو می‌فهمن.

https://blog.changs.co.uk/python-315-features-that-didnt-make-the-headlines.html

@codehalics | کدهالیک

پروژه‌ی Freenet یک پلتفرم همتا‌به‌همتا (peer to peer) برای ساخت اپلیکیشن‌های غیرمتمرکز است که هدفش حذف وابستگی به سرورهای مرکزی و شرکت‌های بزرگ فناوری است. در این سیستم، هر کاربر بخشی از شبکه محسوب می‌شود و داده‌ها و درخواست‌ها بین دستگاه‌های مختلف در یک شبکه توزیع‌شده جابه‌جا می‌شوند. توسعه‌دهندگان می‌توانند با ابزارهای آشنا مثل Rust و TypeScript اپلیکیشن‌هایی بسازند که بدون نیاز به سرور مرکزی اجرا شوند و روی یک شبکه جهانی از کاربران میزبانی شوند.

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

https://freenet.org/

@codehalics | کدهالیک

توی آموزش قوانین مهندسی نرم افزار به یه قانون جدید برمیخوریم که امروز هادی جان احمدی بررسیش کردن و من هم میخوام بهش بپردازم :

ADR (Architecture Decision Record)

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

عمو مارتین فولر راجبش تو بلاگش نوشته

https://martinfowler.com/bliki/ArchitectureDecisionRecord.html


#lawsofsoftwareengineering

سورس توییت از استاد هادی احمدی

@codehalics | کدهالیک

شاید بپرسید خوب چطوری باید بنویسیم
من از کف یکی از پروژه های اوپن سورس
تونستم لیست ADR هایی که نوشته رو دربیارم
به طور مثال
https://github.com/croz-ltd/klokwrk-project/blob/master/support/documentation/adr/content/0001-architectural-decision-records.md
تمام مقالات این فولدر داره راجب انواع تصمیمات معماری راجب این پروژه صحبت میکنه مثلا چه دلیلی داشته رفتن سمت استفاده از یه پکیج یا یه دیزاین پترن خاص یا تست نوشتن یا خیلی چیزای اینطوری و یه تمپلیت باحال داره که میتونین ازش کمک بگیرین یک دست بنویسید ADR هاتونو

لینک ADR ها :

https://github.com/croz-ltd/klokwrk-project/tree/master/support/documentation/adr/content


@codehalics | کدهالیک

یه نمونه خیلی جذاب تر پروژه backstage که اسپاتیفای ساختش
اولش برای خودشون ساخته بودن ولی بعدش اوپن سورسش کرده
خود همین backstage واس همین کار ساخته شده که مستندات یه سرویس یه جا دیده بشه و تیم ها بدونن هر سرویس مال کیه و ساخت سرویس جدید سریع تر بشه !
پس در واقع یه پنل داخلی برای شرکت‌های بزرگ که همه سرویس‌ها، تیم‌ها، و ابزارهای توسعه رو یکجا جمع می‌کنه
حالا خود همین پروژه که تقریبا میتونه یکی از کاراش ADR باشه هم ADR داره واس خودش !

که باز از این قسمت میتونین لیست ADR هاشو ببینید

https://github.com/backstage/backstage/tree/master/docs/architecture-decisions


https://backstage.io/

@codehalics | کدهالیک

سلام سلام

یکی از دوستانم سه پوزیشن باز دارن توی سازمانشون
• Senior Python developer
• Senior Java developer
• Senior React developer

لطفا رزومه هاتون رو به آیدی زیر بفرستین:
@AhmadSharifian

#backend #frontend

➖➖➖➖➖➖➖➖➖➖
💬 @job_bashe | گروه کار باشه با دسته بندی شغلی
📢 @karbashe_ir | کانال کار باشه

مایکروسافت در مقاله‌ی جدید .NET توضیح داده که C# قرار است مدل دقیق‌تری برای Memory Safety داشته باشد. در نسخه‌های فعلی، کلمه‌ی unsafe بیشتر یک هشدار کلی است؛ یعنی می‌گوید بخشی از کد ممکن است با حافظه به‌صورت مستقیم یا کم‌سطح کار کند، اما همیشه مشخص نمی‌کند دقیقاً کدام عملیات خطرناک است و چه قراردادی باید بین نویسنده‌ی API و استفاده‌کننده رعایت شود. مدل جدید تلاش می‌کند این مرز را شفاف‌تر کند: کدهایی که با pointer، حافظه‌ی unmanaged، Marshal یا APIهای حساس سروکار دارند باید صریح‌تر مشخص کنند چه پیش‌فرض‌هایی برای امن بودن لازم است.
اهمیت این تغییر در این است که C# نمی‌خواهد قابلیت‌های low-level خودش را حذف کند؛ بلکه می‌خواهد استفاده از آن‌ها قابل‌تحلیل‌تر، قابل‌بررسی‌تر و کم‌ریسک‌تر شود. وقتی کامپایلر بتواند بخش‌های حساس به حافظه را دقیق‌تر تشخیص دهد، code review بهتر انجام می‌شود، مسئولیت APIها واضح‌تر می‌شود و احتمال مخفی ماندن خطاهایی مثل دسترسی نامعتبر به حافظه، use-after-free یا buffer overrun کاهش پیدا می‌کند. به زبان ساده‌تر، هدف این نیست که C# را محدودتر کنند؛ هدف این است که هرجا برنامه‌نویس به حافظه نزدیک‌تر می‌شود، قواعد ایمنی هم شفاف‌تر و قابل اعتمادتر باشند.

https://devblogs.microsoft.com/dotnet/improving-csharp-memory-safety/

@codehalics | کدهالیک

نگاه فنی‌تر به Memory Safety جدید در C#

تغییر اصلی اینه که در C# 16، مفهوم unsafe دقیق‌تر می‌شه. قبلاً وقتی روی یک متد unsafe می‌ذاشتیم، یعنی داخلش اجازه داریم با pointer و عملیات سطح پایین کار کنیم. اما مدل جدید بین دو چیز فرق می‌ذاره: APIای که از caller انتظار رعایت شرط ایمنی دارد و بخشی از کد که واقعاً عملیات خطرناک انجام می‌دهد.
مثلاً اگر متدی از caller می‌خواهد pointer معتبر بدهد، خود signature می‌تواند unsafe باشد. اما داخل بدنه، جایی که pointer واقعاً dereference می‌شود، باید با unsafe { } مشخص شود:

public static unsafe byte Read(byte* ptr)
{
    unsafe
    {
        return *ptr;
    }
}

اینجا unsafe بیرونی یعنی caller مسئول است pointer معتبر بدهد؛ ولی unsafe داخلی دقیقاً محل دسترسی خطرناک به حافظه را نشان می‌دهد.
چرا این مهم است؟
چون خطر اصلی صرفاً وجود pointer نیست؛ خطر اصلی جایی است که از آن pointer برای خواندن یا نوشتن حافظه استفاده می‌کنیم. مدل جدید کمک می‌کند این نقاط پنهان نمانند، مخصوصاً وقتی با IntPtr، Marshal، NativeMemory یا interop کار می‌کنیم.
همچنین unsafe APIها باید بهتر مستند شوند؛ مثلاً با بخش‌هایی مثل:

/// <safety>
/// Caller must ensure ptr points to valid readable memory.
/// </safety>

این باعث می‌شود در code review دقیق‌تر بفهمیم چه چیزی بر عهده‌ی caller است و چه چیزی داخل متد تضمین شده.

@codehalics | کدهالیک

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

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

به نظرم تو نرم‌افزار هم همین اتفاق می‌افته. تیمی که فقط با تعویض فریم‌ورک و ابزار جلو می‌ره، مزیت عمیق نمی‌سازه. مزیت واقعی وقتی ساخته می‌شه که تیم domain رو بفهمه، history تصمیم‌ها رو بدونه، codebase رو مثل یک موجود زنده بشناسه و آدم‌ها زودبه‌زود عوض نشن.

شاید مهم‌ترین دارایی یک تیم نرم‌افزاری خود کد نباشه؛ حافظه‌ی جمعی تیمه.

https://davidoks.blog/p/why-japanese-companies-do-so-many

@codehalics | کدهالیک

یه نفر اومده سراغ یکی از ساده‌ترین چیزهایی که توی نرم‌افزارها مدام اتفاق می‌افته: تبدیل عدد به متن. مثلاً اینکه عدد 123456 بشه «123456». کاری که معمولاً برنامه‌ها انجام می‌دن اینه که عدد رو چند بار تقسیم می‌کنن، رقم‌ها رو یکی‌یکی درمیارن، یا از یه‌سری جدول آماده کمک می‌گیرن. اما ایده‌ی این مقاله این بوده که بیایم این مسیر قدیمی رو دور بزنیم. عدد رو به تکه‌های ۸ رقمی شکسته، بعد با قابلیت‌های جدید پردازنده، چندتا رقم رو هم‌زمان حساب کرده؛ یعنی به‌جای اینکه CPU رقم‌ها رو دونه‌دونه بسازه، همه رو موازی جلو برده. برای این کار هم از AVX-512 و ضرب‌های سریع استفاده کرده تا تقسیم‌های سنگین تا حد زیادی حذف بشن. جالب‌تر اینکه الگوریتم قبل از اجرا یه نمونه‌گیری کوچیک هم می‌کنه تا بفهمه جنس عددها شبیه همه یا نه، بعد خودش مسیر سریع‌تر رو انتخاب می‌کنه. نتیجه‌اش؟ یه کاری که خیلی معمولی به نظر می‌رسه، توی بعضی حالت‌ها زیر دو نانوثانیه انجام می‌شه.


https://onlinelibrary.wiley.com/doi/10.1002/spe.70079

@codehalics | کدهالیک

ازم پرسید به عنوان یک فرانت اند دولوپر useEffectEvent رو بلدی ؟؟

من بلد نبودم شما یاد بگیرین :

وقتی داخل useEffect نیاز به دسترسی به آخرین مقدار props/state داری ولی نمی‌خوای Effect reconnect بشه.
این هوک دقیقاً برای حل همین مشکل ساخته شده.

https://react.dev/reference/react/useEffectEvent

Abolfazl

@codehalics | کدهالیک

بازگشایی اینترنت بین الملل مصوب شد

🔹ستاد راهبری و ساماندهی فضای مجازی صبح امروز دوشنبه (چهارم خردادماه) به ریاست دکتر عارف معاون اول رئیس جمهور تشکیل جلسه داد و بازگشت اینترنت به وضعیت قبل از دی ماه 1404 مصوب شد.

🔹این مصوبه برای رییس جمهور ارسال شد و در صورت تایید رئیس جمهور جهت اجرا برای وزارت ارتباطات ارسال خواهد شد.

@codehalics | کدهالیک

چند وقت پیش توی کانال درباره‌ی یه مقاله‌ی خیلی باحال از Quanta نوشتم؛ مقاله‌ای درباره‌ی اینکه گاهی «چیزی که نمی‌تونیم ثابت کنیم» خودش می‌تونه تبدیل بشه به ابزار امنیتی. ایده‌اش از Zero-Knowledge Proof شروع می‌شد؛ اینکه بتونی ثابت کنی چیزی رو می‌دونی، بدون اینکه خود اون چیز رو افشا کنی. خلاصه‌ی ساده‌اش این بود که در امنیت، همیشه مسئله فقط این نیست که «چیزی قابل شکستن هست یا نه»، گاهی مسئله اینه که آیا اساساً می‌شه راه شکستن یا ناامن بودنش رو ثابت کرد یا نه.
این چند روز دوباره یاد همون مقاله افتادم، وقتی دیدم هنوز در سال ۲۰۲۶، با این حجم از کراولرها، بات‌ها و ربات‌های اسکمر، بعضی سایت‌ها توی سناریوی Forgot Password خیلی راحت جواب می‌دن: Email Not Found. یعنی اگر من ایمیل یک نفر رو داشته باشم، می‌تونم برم توی مسیر بازیابی رمز عبور و بفهمم آیا اون آدم قبلاً عضو اون سایت بوده یا نه. این دقیقاً همون جاییه که UX Writing فقط مسئله‌ی شفاف‌نویسی نیست؛ مسئله‌ی مرز بین اطلاع‌رسانی کافی و افشای داده‌ی پشت سیستم هم هست.
وقتی محصول به من می‌گه «ایمیل یافت نشد»، در واقع داره فرض می‌کنه من حق دارم این اطلاعات رو بدونم. در حالی که با تقریب خوبی، نه. پیام‌هایی مثل «اگر این ایمیل در سیستم ثبت شده باشد، لینک بازیابی رمز عبور ارسال خواهد شد» شاید از نظر تجربه کاربری کمی گنگ‌تر باشن، اما از نظر امنیت و حریم خصوصی رفتار بالغ‌تری دارن. چون به کاربر واقعی کمک می‌کنن، بدون اینکه به فرد ناشناس اطلاعات اضافه بدن.
ما خیلی وقت‌ها درباره‌ی امنیت محصول به‌عنوان چیزی جدا از حریم خصوصی حرف می‌زنیم، در حالی که این دو در عمل به‌شدت به هم گره خوردن. اتحادیه اروپا درگیر کوکی‌ها و قوانین پیچیده‌ایه که خیلی وقت‌ها به UX آسیب می‌زنن، اما هم‌زمان هنوز چنین مسئله‌های ساده‌ای توی محصول‌ها دیده می‌شه. به نظرم امنیت نباید بعد از حریم خصوصی بیاد؛ امنیت باید طوری طراحی بشه که از همان ابتدا مراقب حریم خصوصی آدم‌ها هم باشد.
همون مقاله‌ی Quanta از یک زاویه‌ی عمیق‌تر می‌گفت گاهی «ندانستن» یا «نتوانستن برای اثبات» می‌تونه بخشی از مدل امنیت باشه. شاید در طراحی محصول هم باید همین‌قدر جدی به این فکر کنیم که چه چیزهایی را اصلاً نباید به کاربر ناشناس بگوییم، حتی اگر گفتنش از نظر UX ساده‌تر و واضح‌تر به نظر برسد.
مقاله باحالیه، اگه نخوندین یه سر بهش بزنین:

https://www.quantamagazine.org/how-unknowable-math-can-help-hide-secrets-20260511/

علت این پست خوندن این پست لینکدین از این دوست عزیزمون بود که بنظرم با یکی از پست های ما که کوت کردم قرابت خوبی داشت

سورس پست لینکدین

@codehalics | کدهالیک