چرا دیگر عضو تهلاگ نیستم؟

۱۱ آذر ۱۴۰۴

برای من، فعالیت در تهلاگ از اول یک ماجرای فنی نبود. اصلاً از دید من مسايل فنی به هیچ وجه ارزش این که آدم براشون وقت و انرژی بذاره رو ندارن. اگه فقط قرار بود یک «گروه کاربران گنو/لینوکس» باشه که هر از گاهی دور هم جمع می‌شن؛ یه گنو/لینوکسی نصب می‌کنن، بسته‌هاشون رو عوض می‌کنن و می‌رن من این‌همه سال براش وقت و اعصاب نمی‌گذاشتم.

اون‌چه که من رو به تهلاگ وصل می‌کرد ایده‌های مدرن و مترقی چپ بود که اشکان قاسمیِ فقید لاگ تهران رو بر اساس اون‌ها بنا گذاشت؛ اندیشه‌هایی که توشون فلسفهٔ آزادی و آزاداندیشی و رهایی انسان اولویت مطلق رو دارن؛ بالاتر از هر امر فنی و غیرفنی دیگه‌ای. لینوکس، گنو، بی‌اس‌دی و بقیه ابزارهایی بودن برای هدف آزادی: آزادی نرم‌افزار، آزادی دانش و آزادی بیان.

متن فعلی معرفی تهران‌لاگ روی پایگاه وبش تصویری نسبتاً خنثا و فنی می‌ده:

گروه کاربران گنو/لینوکس تهران یا «تهران‌لاگ» گروهی مستقل از کاربران کامپیوتر علاقه‌مند به گنو/لینوکس ساکن تهران است… تم محوری جلسات تهران‌لاگ نرم‌افزار آزاد است… محیطی برای تبادل نظر، یادگیری، نتورکینگ و…

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


از «اشکال اجرا» تا «برنامهٔ آگاهانه»

در این سال‌ها وقتی مشکلی می‌دیدم سعی می‌کردم با حسن‌نیت نگاه کنم. با خودم می‌گفتم:

  • «این اختلاف سلیقه‌ است. من یه مدل کار می‌کنم؛ یکی یه مدل دیگه.»
  • «این‌ها ایراد تاکتیک و اجراست؛ نه مسئله بنیادی.»
  • «اگه بیش‌تر حرف بزنیم جا می‌افته و به نقطهٔ مشترک مي‌رسیم.»

به همین خاطر با این که نشونه‌ها رو می‌دیدم باز هم تلاش می‌کردم از درون اصلاح کنم؛ بحث کنم؛ هشدار بدم و استدلال بیارم.

اما کم‌کم چیزی عوض شد. نه لزوماً در واقعیت بیرون؛ بلکه در درک خودم از ماجرا.

چند چیز به‌مرور برای من روشن‌تر شد:

۱. تکرار شدن الگوها و تصادفی نبودنشون

  • تصمیم‌های مهم خارج از جمع فعال گرفته می‌شن.
  • کسایی که کار می‌کنن آخرین نفری‌ن که خبردار می‌شن.
  • هر بار که نقد جدی می‌شه، واکنش‌ها تدافعی، شخصی و با برچسب زدنه. اگه چیزی یکی دوبار اشتباه اجرا باشه، می‌شه اسمش رو «سوتی» گذاشت؛ ولی وقتی سال‌ها تکرار می‌شه دیگه «سوتی» نیست؛ روال است.

۲. جابه‌جایی «خط قرمز»ها و «موفقیت»ها وقتی پای حامی‌هایی مثل ابر آروان وسط اومد من این رو یک سقوط اخلاقی دیدم: جمعی که برپایهٔ آزادی بنا شده می‌ره زیر نشان شرکتی که نقش جدی در زیرساخت سرکوب و سانسور داره و دستش به خون مردم آلوده است. ولی در عمل دیدم که برای بخشی از گردانندگان این نه‌تنها مشکل نبود که اتفاقاً یه گام رو به جلو بود:

  • «اسپانسر پولدار داریم»
  • «می‌تونیم رویداد پرزرق‌وبرق‌تر برگزار کنیم»
  • «برامون جاهای مختلف تبلیغ می کنن»
  • «اسم لاگ مطرح‌تر می‌شه» یعنی چیزی که برای من «خیانت به فلسفهٔ اولیه» بود برای اون‌ها یه جور موفقیت در اجرای نقشه بود.

۳. دعوا بر سر هدف و نه ابزار برای مدت‌ها برداشت من این بود که همه قبول داریم تهلاگ باید جمعی آزاد و منتقد قدرت باشه؛ فقط سر این‌که چطور به این برسیم اختلاف داریم. ولی کم‌کم دیدم نه؛ برای بعضی‌ها تهلاگ هیچ‌وقت قرار نبوده جایی برای نقد جدی قدرت و ساختار باشه! تهلاگ برای اون‌ها بیش‌تر یه جمع فنی برای برندسازیه که می‌تونه بستری برای ارتباط با شرکت‌ها برای برگزاری رویداد توسعه‌دهنده‌محوره که «آزادی نرم‌افزار» توش یه شعار تزئینی روی دیواره؛ نه قطب‌نمای اخلاقی!

در این نقطه، فهم من از ماجرا عوض شد. مشکل اصلاً «شیوه‌های متفاوت رسیدن به یه هدف» نبود؛ بلکه هدف ما اصلاً هیچ اشتراکی با هم نداشت.


وقتی «مشکل» برای دیگری «ویژگی» است

اگه دو نفر یه برنامه بنویسن و یکی بگه «این خط مشکل داره. باید درستش کنیم» و اون یکی بگه «نه! این دقیقاً همون کاری رو می‌کنه که من می‌خواستم» دیگه دعوا سر «کی بهتر پیاده می‌کنه» نیست؛ بلکه سر چی درسته و برنامه اصلاً برای چی نوشته شده است.

من در تهلاگ کم‌کم به همین نقطه رسیدم:

من:

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

اون‌ها: این‌ها رو مسیر طبیعی رشد لاگ می‌دیدند:

  • ارتباط با شرکت‌ها،
  • جذب منابع،
  • حرفه‌ای‌تر شدن ظاهر،
  • بی‌حاشیه نگه داشتن رویداد.

جایی که من دکمهٔ «توقّف» رو می‌دیدم، اون‌ها دکمهٔ «ادامه» رو می‌زدند.

این‌جا بود که فهمیدم این روند، از منظر کسانی که دارند جلو می‌برنش، اصلاً «مشکل» نیست؛ بلکه عین پیشرفت موفق طبق نقشه است.

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


چرا در نهایت بیرون ایستادم؟

نقطه‌ای که تهلاگ از شرکت‌های بدنامی مثل ابر آروان حمایت گرفت و ازشون تقدیر کرد برای من تبدیل شد به لحظه‌ای که اتصال بین تهلاگ اشکان قاسمی (یا لااقل تصوّر من از اون) و اون‌چیزی که امروز بهش می‌گن تهلاگِ پاره شد. از اون‌جا به بعد دیگه نمی‌تونستم با خودم رو راست باشم و بگم «این‌ها فقط اشتباه اجراین، و درست می‌شن». نه، این‌ها داشتن مطابق یه نقشهٔ دیگه «درست می‌شدن»؛ نقشه‌ای که من نه قبولش دارم و نه حاضرم اسمم کنارش قرار بگیرد.

از اون‌جا به بعد موندن من در تهلاگ دیگه «وفاداری به یه ایدهٔ مشترک با اجرای ناقص» نبود؛ بلکه عملاً تزریق مشروعیت به روندی بود که با ایدهٔ اولیه و با باورهای خودم در تضاده.

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


اگه قرار باشه تهلاگ واقعاً اصلاح بشه چی؟

برای من مسئله این نیست که تهلاگ حامی داشته باشه یا نه؛ بلکه اینه که چه‌طور تصمیم گرفته می‌شه که کی حامی باشه. اینه که چه‌طور تصمیم گرفته می‌شه که لاگ کجا وایسه؛ چی رو نقد کند و چی رو «موفّقیت» تعریف کنه. تا وقتی شکل تصمیم‌گیری همونی باشه که امروز هست بود و نبود یه حامی تأثیری در ماجرا نداره.

اگه قرار باشد تهلاگ به چیزی شبیه تصوّر من نزدیک بشه چند تا تغییر ریشه‌ای لازمه:

۱. قدرت از پایین به بالا، نه برعکس

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

۲. نقش‌های گردشی، نه صندلی‌های دائمی

نقش‌هایی چون مسئول جلسه، مدیر کارساز، نگه‌دارندهٔ دامنه، مسئول شبکه‌های اجتماعی و… نباید تبدیل به «مالکیت شخصی» بشن؛ بلکه باید دوره‌ای و انتخابی باشن و همیشه به کل جامعه پاسخگو بوده و به دست اون‌ها قابل عزل باشن.

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

۳. شفافیت مالی و معیارهای اخلاقیِ روشن

هر حمایتی که وارد تهلاگ می‌شه باید پیش از پذیرش بهصورت عمومی مطرح بشه:

  • این پول از کجا می‌آد؟
  • این نهاد چه نقشی در ساختار قدرت داره؟
  • پذیرشش چه تصویری از تهلاگ می‌سازه؟
  • این حامی دنبال چی بوده که این حمایت رو کرده؟

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

۴. استقلال از پروژه‌های برندسازی شخصی و شرکتی

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

کوچیک‌ موندن، کم‌خرج بودن و کند رشد کردن اگه بهای حفظ این استقلال باشه از نظر من فضیلته، نه ضعف!

۵. برنامه‌ریزی جمعی بر پایهٔ یاری متقابل و نه رقابت

تهلاگ در رویای شخصی من یه جمع خودگردانه؛ نه یه رویدادِ پرزرق‌وبرق. یعنی توش آدم‌ها برای هم وقت و انرژی می‌ذارن بدون این‌که به «بازگشت سرمایه» فکر کنن؛ دانش و تجربه‌شون رو مثل آزادانه در اختیار هم می‌ذارن و همزمان در برابر هر نوع سازوکاری که انسان‌ها را به «منابع» و «سرمایهٔ انسانی» تقلیل می‌ده می‌ایستن.

این یعنی مخالفت جدی با تبدیل تهلاگ به «بازار کار» یا «اکوسیستم استارتاپی» که توش آزادی نرم‌افزار فقط یک شعار تزئینی گوشهٔ پرده است.


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


راهنمای برگزاری همایش برخط نامتمرکز

۱۹ مرداد ۱۳۹۹

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

روند برگزاری همایش به دو بخش پیش از همایش و روز نمایش تقسیم می‌شود.

پیش از همایش

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

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

با آغاز از زمان مشخّص‌شده برای شروع همایش، هر ویدیوی بارگذاری شده، با یک گام زمانیِ از پیش تعیین‌شده، مدّت زمانی برای پرسش و پاسخ مربوط به آن ارائه برایش مشخّص می‌شود. برای مثال، نخستین ویدیوی بارگذاری شده، ساعت ۱۰، دومی ساعت ۱۰:۳۰، سومی ساعت ۱۱ و همین‌طور تا پایان ارائه‌ها، زمان‌ها به صورت خودکار برایشان تخصیص داده می‌شود.

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

روز همایش

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

مزیت‌ها

  • نداشتنن تمرکز و جلوگیری از کند شدن روند برگزاری.
  • نبودن فرایند داوری و گزینش ارائه‌ها و عدم دخالت سلیقه.
  • مشخّص بودن برنامهٔ زمان‌بندی به صورت خودکار از پیش.
  • وجود امکان ویرایش و رفع مشکلات برای ارائه‌دهنده.
  • وجود زمان برای دیدن ارائه‌ها، فکر کردن روی آن‌ها و رسیدن به پرسش.
  • امکان گزینش و حضور فقط در پرسش و پاسخ مورد نظر فرد.
  • نبودن محدودیت زمانی برای پرسش و پاسخ هر تعداد ارائه.

معایب

هنوز معایبی برای این مدل برگزاری پیدا نشده است. خوشحال می‌شوم با نظرات خود، این نوشته را کامل‌تر کنید.


گنو یا لینوکس

۰۹ مرداد ۱۳۹۶

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

سیستم‌عامل

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

سیستم‌عامل عبارت است از یک مجموعهٔ نرم‌افزاری متشکّل از کرنل و هر آن‌چه مستقیماً با کرنل کار می‌کند، مانند کتاب‌خانه‌ها، میان‌افزارها، کامپایلرها و ابزارهای توسعه. کرنل در این میان بخشی است که مستقیماً با سخت‌افزار صحبت کرده و وظیفهٔ اختصاص منابع را برعهده دارد.

درک جایگاه‌ها

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

متأسّفانه یک کرنل به تنهایی راه به جایی نمی‌برد، برای داشتن یک سامانهٔ قابل استفاده، نیاز به یک پوسته، کامپایلرها، یک کتاب‌خانه و… دارید. این‌ها قسمت‌هایی مجزّا هستند که ممکن است تحت حق رونوشتی محکم‌تر (یا حتا نرم‌تر) باشند. اکثر ابزارهای مورد استفاده برای لینوکس، نرم‌افزارهای گنو هستند و تحت کپی‌لفت گنو قرار دارند.

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

لینوکس و glib

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

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

Linux SCI and Glibc

از این روست که می‌بینیم بخش عمدهٔ مخازن توزیع بزرگی مانند دبیان، بدون تلاش‌های بسیار بزرگ از جانب توسعه‌دهندگان این توزیع، برای کرنل‌های مختلفی چون لینوکس، هرد، مینیکس، kFreeBSD و… پورت شده‌اند، زیرا که اکثر برنامه‌های کاربردی، برای اجرا روی سیستم‌عامل گنو نوشته شده‌اند و نه کرنل لینوکس.

از سوی دیگر می‌توان نگاهی به برنامه‌های سیستم‌عامل اندروید داشت. همان‌طور که احتمالاً می‌دانید، اندروید نیز یکی از سیستم‌عامل‌هایی است که از لینوکس به عنوان کرنل استفاده می‌کند. ولی برنامه‌های نوشته موجود برای این سیستم‌عامل، در توزیع‌های گنو مانند اوبونتو و… به صورت بومی قابل اجرا نیستند. عمدهٔ برنامه‌های این سیستم‌عامل به صورت قرنطینه و روی زیرساختی با نام ART اجرا می‌شوند که خود، برای کار با کتاب‌خانه‌ای با نام بایونیک که بخش اصلی سیستم‌عامل اندروید در لایهٔ اجرایی است نوشته شده است. دلیل اجرا نشدن این برنامه‌ها و برنامه‌های دیگری که به کمک جعبهٔ توسعهٔ بومی (NDK) به صورت مستقیم با بایونیک کار می‌کنند، به صورت بومی در توزیع‌های گنو، این است که مانند مورد مشابه در گنو، همهٔ این برنامه‌ها برای اجرا روی سیستم‌عامل اندروید نوشته شده‌اند و نه کرنل لینوکس.

گفتنی است به تازگی پروژه‌ای با نام هیبریس شروع به توسعه کرده است که تلاش دارد همان‌گونه که واین لایهٔ سازگاری دودویی برای تبدیل زیرروال‌های ویندوز به زیرروال‌های پازیکس گنویی را فراهم می‌کند، یک لایهٔ سازگاری برای تبدیل زیرروال‌های بایونیک به glib را ایجاد کند. البته این پروژه هنوز در ابتدای راه است و به دلیل یکسان بودن کرنل گنو و اندروید، تمرکزش روی تبدیل فراخوانی‌های صرفاً وابسته به کرنل، مانند راه‌اندازهای سخت‌افزاری و… است.

نام‌گذاری

اصل کلّی در نام‌گذاری نرم‌افزارها این است که به پدیداورندهٔ آن، حق گذاشتن هرنام دل‌خواهی را روی نرم‌افزارش دارد. ولی حق دخالت درنام‌گذاری دیگر محصولاتی که با نرم‌افزارش در تعامل هستند را ندارد. برای مثال، توسعه‌دهندگان GNOME در سال ۲۰۱۰ نام میزکارشان را به Gnome تغییر دادند و کاملاً‌ هم اختیار این کار را داشتند، ولی نمی‌توانستند و نمی‌توانند در نام‌گذاری Ubuntu که به صورت پیش‌گزیده از میزکار گنوم بهره می‌برد دخالتی داشته باشند.

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

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

شبهات پرتکرار

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

گنو فقط یک مجموعه ابزار است.

گویندگان این جمله، سیستم‌عامل گنو را با پروژهٔ گنو اشتباه گرفته‌اند. پروژهٔ گنو، پروژه‌ای است که یک سال پس از معرّفی سیستم‌عامل گنو، به منظور نوشتن نرم‌افزارهای آزاد کاربردی برای سیستم‌عامل گنو شروع به کار کرد. حاصل این پروژه، بسیاری از نرم‌افزارهای آزاد است که امروزه بر روی سیستم‌عامل گنو استفاده می‌شود، ولی جزو خود سیستم‌عامل نیست؛ مانند ویرایشگرهای متن، بازی‌ها و…

گنو فقط یک کامپایلر است.

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

استالمن گفته بگویید گنو/لینوکس.

ادّعای درستی است. ولی توجّه داشته باشید که استالمن خواهش نکرده لینوکس را گنو/لینوکس بنامید. پس از گزینش لینوکس به عنوان کرنل آیندهٔ سیستم‌عامل گنو و هم‌زمان با کار گروه توسعهٔ گنو روی لینوکس برای سازگار کردن آن با سیستم‌عامل گنو، فهرست پستی گنو با رشته‌های متعدّدی پر شد که پس از تلاش‌های زیاد برای رفع مشکلات عجیبی که به نظر منطقی نمی‌رسیدند، مشخّص می‌شد فرد پرسشگر از لینوکس به جای کرنل مطرح وقت گنو یعنی تریکس استفاده می‌کرده است. بنا بر این استالمن از کابران گنو خواست در صورت استفاده از لینوکس به عنوان کرنل، در انتهای عنوان درخواست خود، برای مشخّص شدن کرنل مورد استفاده، عبارت «+لینوکس» را درج کنند. این سنّت بعدها منجر به نوشتن نام سیستم‌عامل به صورت گنو+لینوکس شد و پس از مدّتی به دلیل نیاز + به تایپ شدن با دو انگشت، به صورت گنو/لینوکس خلاصه شد. بنابراین خواهش استالمن گفتن این عبارت به ‌جای گنو بود و نه به‌جای لینوکس!

پس دیگر برنامه‌ها چه؟

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

نتیجه‌گیری

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

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


ارسال‌های پیشین ←