نه قاطع دسکتاپ کازمیک به کدهای هوش مصنوعی؛ گنوم سر دوراهی پذیرش باگ‌های ماشینی!

شرکت سیستم۷۶ (System76) رسماً ارسال محتوای تولیدشده توسط هوش مصنوعی را برای دسکتاپ کازمیک (COSMIC) ممنوع کرده است. در این میان، هرچند برخی زیرپروژه‌های گنوم (GNOME) هم محدودیت‌های مشابهی وضع کرده‌اند، اما یکی از توسعه‌دهندگان برجسته این پروژه اصرار دارد که باید برای گزارش آسیب‌پذیری‌های امنیتی یک استثنا قائل شد.

دست‌اندرکاران پروژه دسکتاپ کازمیک دستورالعمل‌های همکاری خود را تغییر داده‌اند. در جدید‌ترین نسخه این راهنما، یک قانون صریح علیه هوش مصنوعی اضافه شده که مشارکت‌کنندگان را ملزم می‌کند این جمله را تأیید کنند: «من در این پول‌ریکوئست هیچ محتوایی که توسط مدل‌های زبانی بزرگ (یا همان هوش مصنوعی) تولید شده باشد، اعم از کد، کامنت و توضیحات، قرار نداده‌ام.»

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

این رویکرد با سیاست‌های برخی دیگر از پروژه‌های دسکتاپ هم‌خوانی دارد. برای نمونه، در راهنمای مشارکت تقویم گنوم آمده است: «این پروژه اجازه ارسال مشارکت‌هایی که توسط مدل‌های زبانی بزرگ (LLM) و چت‌بات‌ها تولید شده باشند را نمی‌دهد.»

بخش افزونه‌های گنوم (GNOME Extensions) نیز ارسال‌های مبتنی بر هوش مصنوعی را محدود کرده، هرچند استفاده از ابزار‌های هوش مصنوعی برای یادگیری و تکمیل خودکار کد (Code Completion) مجاز دانسته شده است. با این حال، در دستورالعمل‌های بازبینی آن به وضوح قید شده: «افزونه‌ها نباید توسط هوش مصنوعی تولید شده باشند.»

کازمیک یکی از جدید‌ترین محیط‌های دسکتاپ کامل در دنیای لینوکس به حساب می‌آید، اما توسعه آن سال‌هاست در جریان است؛ ماجرای توسعه این پروژه حدود پنج سال پیش کلید خورد، یعنی حتی قدیمی‌تر از عرضه چت‌جی‌پی‌تی (ChatGPT) در اواخر سال ۲۰۲۲ است (هرچند شاید حس کنید زمان خیلی بیشتری گذشته است!).

کازمیک همچنان از برخی بخش‌های گنوم استفاده می‌کند و پیکربندی پیش‌فرض آن هم با پنل بالایی و لانچر پایینی شباهت زیادی به گنوم دارد. دلیل موجهی هم برای این شباهت وجود دارد: اولین نسخه دسکتاپ سیستم۷۶ که کازمیک نامیده می‌شد، بر پایه گنوم شکل گرفت و با انبوهی از افزونه‌های سفارشی گنوم شخصی‌سازی شده بود.

با این حال، این کازمیک جدید ساختار کاملاً متفاوتی دارد. اولین نسخه پایدار آن در اواخر سال ۲۰۲۵ همراه با توزیع Pop!_OS 24.04 عرضه شد. با وجود ظاهر مشابه، این یک پروژه کاملاً نوپا و از پایه بازنویسی‌شده است که به زبان راست (Rust) و با استفاده از جعبه‌ابزار Iced توسعه یافته و منحصراً روی سرور نمایش وی‌لند (Wayland) اجرا می‌شود.

در نقطه مقابل، پروژه گنوم بسیار قدیمی‌تر، وسیع‌تر و پیچیده‌تر است. شروع این پروژه در سال ۱۹۹۷ معرفی شد، یعنی درست یک سال پس از معرفی پروژه KDE. نسخه ۱.۰ پروژه KDE در سال ۱۹۹۸ منتشر شد و سرانجام گنوم ۱.۰ در سال ۱۹۹۹ به میدان آمد.

گنوم تا حدی پاسخی به KDE بود؛ پروژه KDE با فریم‌ورک Qt ساخته شده بود که در آن زمان کاملاً متن‌باز نبود. به همین دلیل در روز‌های ابتدایی، شرکت رد هت (Red Hat) از قرار دادن KDE در توزیع Red Hat Linux خودداری کرد. علاوه بر این، Qt برای برنامه‌نویسان ++C طراحی شده بود و KDE هم با ++C ساخته شد، در حالی که لینوکس (مشابه یونیکس) با زبان سنتی C نوشته شده بود و بسیاری از سنت‌گرایان یونیکس زبان پیچیده‌تر ++C را نمی‌پسندیدند. در نتیجه گنوم با همان زبان خالص C و با تکیه بر GTK (ابزاری که در اصل برای نرم‌افزار GIMP ساخته شده بود) پایه‌گذاری شد. در سال ۱۹۹۸، توزیع Red Hat Linux 5.1 پیش‌نمایشی از گنوم را گنجاند و با از راه رسیدن Red Hat Linux 6.0 در سال ۱۹۹۹، گنوم ۱.۰ به دسکتاپ پیش‌فرض این توزیع بدل شد.

گنوم هنوز هم دسکتاپ پیش‌فرض توزیع سازمانی RHEL است و بسیاری از توسعه‌دهندگان آن کارمندان رسمی شرکت رد هت هستند. مدیران ارشد رد هت اشتیاق چشمگیری به هوش مصنوعی نشان داده‌اند؛ هرچند کمی بعد، سقف هزینه‌کرد توسعه‌دهندگان برای ابزار‌های هوش مصنوعی را محدود کردند.

بخش اعظم گنوم با زبان C نوشته شده که فاقد سازوکارهای خودکار مدیریت ایمن حافظه (Memory Safety) است؛ هرچند زبان‌های دیگری هم در آن به کار رفته‌اند: پوسته GNOME Shell ترکیبی از جاوااسکریپت و C است و برخی کامپوننت‌ها نیز با زبان اختصاصی والا (Vala) پیاده‌سازی شده‌اند.

مایکل کاتانزارو، از توسعه‌دهندگان گنوم، اخیراً پستی در وبلاگ خود با عنوان «عصر کیفیت نرم‌افزار یا دوران شترمرغ‌ها؟» منتشر کرده و استدلال می‌کند که پروژه گنوم باید گزارش‌های باگ حاصل از هوش مصنوعی را بپذیرد. این موضوع برای او تازه نیست؛ او در پست خود به مطلب قبلی‌اش در ماه ژوئن با عنوان «لطفاً گزارش باگ‌های مبتنی بر هوش مصنوعی را ممنوع نکنید» ارجاع می‌دهد. یک ماه بعد از آن نیز، او کاهش مهلت افشای عمومی آسیب‌پذیری‌ها در تیم امنیتی گنوم را از ۹۰ روز به ۳۰ روز اعلام کرد که از اول اوت اجرایی شد.

کشف ۱۳۱۳ شناسه آسیب‌پذیری امنیتی (CVE) در آخرین گزارش امنیتی هسته لینوکس در توزیع دبیان، نشان داد که ابزار‌های هوش مصنوعی به طور چشمگیری در حال شناسایی خیل عظیمی از باگ‌ها در کدهای پهناور نرم‌افزارهای آزاد و متن‌باز (FOSS) هستند. گنوم نیز یکی از بزرگ‌ترین محیط‌های دسکتاپ در اکوسیستم لینوکس و BSD است که بخش عمده کدهای آن با زبان‌های ناامن از نظر حافظه نوشته شده است.

همان‌طور که کاتانزارو می‌گوید: «فرقی نمی‌کند چقدر تلاش کنیم، برنامه‌نویسان گنوم هنگام استفاده از زبان‌های ناامنی مانند C، ++C یا والا در نوشتن کدهای ایمن ناکام خواهند ماند؛ نوشتن کد بدون باگ در این زبان‌ها حتی برای باتجربه‌ترین برنامه‌نویسان هم کاری بسیار طاقت‌فرساست.»

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

ابتدا پروژه اجازه ورود گزارش‌های باگ تولیدشده با هوش مصنوعی را می‌دهد. از آنجا تا اولویت‌بندی باگ‌ها (Triage) با هوش مصنوعی گام بزرگی نیست. سپس نوبت به اصلاح و پچ‌های خودکار کد می‌رسد. وقتی پای کدنویسی با هوش مصنوعی باز شد، افزونه‌های توسعه‌یافته با این فناوری دیگر چندان عجیب نخواهند بود، بعد کامپوننت‌های اصلی پروژه دگرگون می‌شوند و در نهایت کنترل کل دسکتاپ به دست الگوریتم‌ها می‌افتد.

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