فهرست مطالب
لوری کرک، پژوهشگر گوگل و مهندس معکوس سابق مایکروسافت با طرح دوباره یکی از قدیمیترین بحثهای دنیای رایانش، از معماری هسته ویندوز NT تمجید کرده و دیدگاهی انتقادی نسبت به برخی جنبههای لینوکس مطرح کرده است.
به گزارش سرویس سیستمعامل کامپیوتر تکناک، کرک که در سال ۲۰۲۴ به گوگل پیوست و کانال یوتیوب LaurieWired را با بیش از ۵۰۰ هزار مشترک مدیریت میکند در X و لینکدین نوشت: «هسته ویندوز NT واقعا یک شاهکار مهندسی است که هنوز از بسیاری جهات لینوکس را پشت سر میگذارد.»
برای مطالعه بیشتر: مشکل عجیب ویندوز ۱۰؛ کوپایلت با باز کردن هر فایل اجرا می شود + تصویر
تمرکز صحبتهای کرک بر معماری زیربنایی ویندوز NT است؛ یعنی نحوه مدلسازی منابع سیستمعامل و مدیریت دسترسی به آنها و ارتباطی با رابط کاربری ویندوز، منوی استارت، کوپایلوت یا تبلیغات ندارد. او این بحث را به عصر عاملهای هوش مصنوعی نیز تعمیم داده و این پرسش را مطرح کرده است که آیا لینوکس برای عاملهایی که بهطور فزایندهای مجوزهای بیشتری دریافت میکنند، همچنان معماری مناسبی محسوب میشود یا خیر. همچنین کرک یک تاریخ جایگزین را تصور کرده است که در آن مایکروسافت، نسخهای متنباز از NT با نام «Open NT» عرضه میکرد و شرکتهایی مانند آمازون امکان فورککردن آن را داشتند. البته این دیدگاه با واکنش شدید برخی مهندسان باسابقه مواجه شد. منتقدان در پاسخهای خود استدلال کردند که معماری ماژولار لینوکس انتخابی آگاهانه و بخشی از طراحی آن است و ایجاد شاخههای متعدد میتواند به پروژهای مانند Open NT آسیب بزند.
هسته NT را با ویندوز ۱۱ اشتباه نگیرید
ویندوز NT در سال ۱۹۹۳ عرضه شد و از زمان انتشار ویندوز XP در سال ۲۰۰۱، زیرساخت اصلی تمام نسخههای مهم ویندوز دسکتاپ بوده است؛ ویندوز ۱۱ نیز بر همین معماری بنا شده است. در مقابل، ویندوز ۹۵، ۹۸ و Me به خانواده جداگانه ویندوز 9x مبتنی بر DOS تعلق داشتند و ویندوز ۲۰۰۰ از ابتدا بر پایه NT ساخته شده بود.
مایکروسافت در اکتبر ۱۹۸۸ دیو کاتلر را به خدمت گرفت؛ مهندسی که پیشتر رهبری توسعه VMS در DEC را بر عهده داشت. طبق توضیحات مایکروسافت، تیم کوچکی از مهندسان سابق DEC حدود شش ماه را صرف تدوین مشخصات پروژه کردند و قابلیت حمل، پشتیبانی از سیستمهای چندپردازندهای و دستیابی به گواهی امنیتی C2 از اهداف اصلی آنها بود.
دیو پلامر، مهندس بازنشسته مایکروسافت و خالق Task Manager نیز در واکنش به صحبتهای کرک تاکید کرد که NT حاصل نخستین تجربه کاتلر در طراحی هسته سیستمعامل نبود. به گفته او، کاتلر پیش از NT روی RSX-11M و VMS کار کرده بود و NT سومین هستهای بود که او از صفر طراحی میکرد.
با وجود این، NT را نمیتوان نسخهای از VMS با ظاهر ویندوز دانست. این پروژه در ابتدا با نام NT OS/2 شکل گرفت و به عنوان یک سیستمعامل قابل حمل، ابتدا برای تراشه Intel i860 توسعه داده شد و سپس به معماری MIPS منتقل شد. مایکروسافت پس از موفقیت ویندوز ۳.۰، مسیر اصلی پروژه را از OS/2 به Win32 تغییر داد. در همین حال، فرانکو مینوتچی، مهندس سیستمهای روی تراشه در نوکیا درباره ویندوز ۱۱ تفکیک مهمی ارائه کرده و گفته است که مشکلات این سیستمعامل بیشتر به «پوسته» مربوط میشوند تا به هسته ارتباط داشته باشد. بخش قابل توجهی از انتقادهای اخیر به ویندوز ۱۱، از واکنش منفی به ایده سیستمعاملهای عاملمحور گرفته تا اظهارات مدیران مایکروسافت درباره تجربه کاربران حرفهای و عملکرد قابلیتهای هوش مصنوعی نیز حول قابلیتهای هوش مصنوعی شکل گرفته بود.
بیشتر بخوانید: Windows 11 26H2 بهزودی برای کاربران منتشر میشود؛ جزئیات آپدیت جدید
با وجود این، مایکروسافت همچنان در حال توسعه کوپایلوت است و این دستیار قرار است با یک بهروزرسانی گسترده، قابلیتهای جدیدی دریافت کند. ساتیا نادلا، مدیرعامل مایکروسافت نیز در توصیف چشمانداز این شرکت، کوپایلوت را تا حد یک «سیستمعامل برای کار» ارتقا داده است. در پایان، وقتی کاربری از کرک پرسید که چگونه میتواند درباره هستهای متنبسته اظهارنظر کند، او پاسخ داد: «شاید چون قبلا آنجا کار میکردم…»، که اشارهای مستقیم به چهار سال سابقه فعالیت او در مایکروسافت است.
ویندوز NT مبتنی بر آبجکت است
خلاصه دیدگاه کرک این است که NT «بیشتر شبیه یک زبان شیگرا ست و از همان روز اول مدل امنیتی قدرتمندی داشته است، در حالی که لینوکس چنین رویکردی ندارد.» البته «شیگرا» در اینجا یک تشبیه است. مایکروسافت گفته است که ویندوز به معنای کلاسیک C++ شیگرا نیست و از اصطلاح «مبتنی بر آبجکت» استفاده میکند. در ویندوز NT، پردازهها، رشتهها، فایلها، دستگاهها، کلیدهای رجیستری، Mutexها، Jobها و توکنهای دسترسی همگی آبجکت محسوب میشوند و بیش از ۲۵ نوع آبجکت وجود دارد. یکی از اجزای اصلی به نام Object Manager وظیفه ایجاد و حذف این آبجکتها، مدیریت فضای نام آنها، ردیابی آبجکتهای در اختیار هر پردازه و کنترل مجوزهای دسترسی را بر عهده دارد. سایر اجزای سیستم فقط از طریق روالهایی که مالک آبجکت ارائه میکند، میتوانند از آن استفاده کنند. به گفته مایکروسافت، این معماری اجازه میدهد ساختار داخلی یک مولفه بدون ایجاد اختلال در سایر بخشها تغییر کند.
توسعهدهندگان، این ساختار را از طریق Handleها میبینند. وقتی یک برنامه فایلی را باز میکند، ویندوز یک Handle در اختیار آن قرار میدهد و مجوزهای اعطاشده را همراه آن ذخیره میکند؛ سپس هر درخواست بعدی بر اساس همان مجوزها بررسی میشود. اگر یک Handle را کپی کنید، میتوان برخی مجوزها را از نسخه کپی حذف کرد، اما امکان اضافه کردن مجوز به نوع آبجکت بستگی دارد. داشتن یک مدل یکپارچه برای مدیریت منابع مختلف، نوعی مزیت معماری به نظر میرسد و به همین دلیل میتوان درک کرد که چرا کرک آن را ساختاری زیبا میداند.
مدل امنیتی ویندوز NT بر منابع و مجوزها بنا شده است
مستندات مایکروسافت مدل امنیتی NT را مبتنی بر مجوزهای اختصاصی هر آبجکت، همراه با تعدادی مجوز سراسری سیستم توصیف میکنند. هنگام ورود به ویندوز، سیستم یک Access Token ایجاد میکند که شناسه امنیتی یا SID، گروههای کاربر و مجوزهای او را در خود دارد. پردازههایی که کاربر اجرا میکند نیز معمولا همین زمینه امنیتی را به ارث میبرند. هر آبجکت قابل محافظت یک Security Descriptor دارد که میتواند شامل Access Control List یا ACL باشد؛ فهرستی که مشخص میکند کدام SIDها به چه مجوزهایی دسترسی دارند یا از آنها محروم هستند. زمانی که برنامهای درخواست دسترسی به یک آبجکت میکند، ویندوز توکن کاربر را با ACL آن مقایسه مینماید و سپس Handleای با مجوزهای تأییدشده در اختیار برنامه قرار میدهد.
همچنین این توصیفگر میتواند System ACL داشته باشد که کنترل ممیزی را بر عهده دارد؛ بنابراین مدیران سیستم در صورت فعال بودن ممیزی، میتوانند دسترسیهای موفق و ناموفق به آبجکتها را ثبت کنند. با وجود این، داشتن یک مدل امنیتی قدرتمند به معنای امن بودن کامل سیستمعامل نیست. ویندوز NT 3.5 به همراه Service Pack 3 در سال ۱۹۹۵ موفق به دریافت رتبه امنیتی C2 شد، اما این رتبه تنها برای یک رایانه مستقل بدون شبکه و پس از سختگیرانهتر کردن مجوزهای پیشفرض فایلها و رجیستری به دست آمد. کن سی، مهندس زیرساخت سابق بلومبرگ و رویترز،از کرک خواست «هر محصول دیگری را نام ببرد که بهروزرسانی ماهانه لازم داشته باشد وگرنه خطر هک شدن آن وجود داشته باشد». در واقع، درایورها، تنظیمات پیشفرض و دههها تلاش برای حفظ سازگاری نرمافزاری، به اندازه خود هسته در امنیت ویندوز نقش دارند.
مدل امنیتی لینوکس پیچیدهتر است
هدف دیگر انتقاد کرک، لینوکس است. او میپرسد: «از UID استفاده میکنید؟ GID؟ ACL؟ CGROUP؟ سیاستهای امنیتی؟ SELinux؟ مجوزهای فایلسیستم؟» و استدلال میکند که لینوکس یک «گراف یکپارچه و منسجم از قابلیتها» ندارد. هرکدام از این سازوکارها وظیفه متفاوتی دارند. UID و GID کاربران و گروهها را شناسایی میکنند و مجوزهای فایل و ACL از فایلها محافظت میکنند. قابلیتها یا Capabilities اختیارات کاربر ریشه را تفکیک میکنند؛ برای مثال، یک وبسرور میتواند بدون داشتن تمام مجوزهای Root به پورت ۸۰ متصل شود. Namespaceها دید یک پردازه را نسبت به Mountها، پردازهها یا شبکهها جدا میکنند و همین سازوکار یکی از پایههای عملکرد کانتینرها است. Cgroupها نیز مصرف CPU و حافظه را محدود میکنند. SELinux و سایر Linux Security Moduleها نیز سیاستهای امنیتی اضافی را اعمال میکنند.
کرک درست میگوید که بخش عمده این سازوکارها بعدها به لینوکس اضافه شدند. مستندات LSM در هسته لینوکس میگویند که آژانس امنیت ملی آمریکا در سال ۲۰۰۱، SELinux را بهعنوان یک وصله جداگانه ارائه کرد. لینوس توروالدز در پاسخ، پیشنهاد ایجاد چارچوبی مبتنی بر Hookها را مطرح کرد تا هر مدل امنیتی بتواند به آن متصل شود؛ این چارچوب در دسامبر ۲۰۰۳ همراه با Linux 2.6.0 عرضه شد. امروزه هسته لینوکس از SELinux، AppArmor، Smack، TOMOYO، Landlock و موارد دیگر پشتیبانی میکند. کن سی معتقد است مدل افزونهای، فلسفه یکپارچه یونیکس و لینوکس و در واقع «تمام هدف» این معماری است. کوین فالکنر نیز اضافه کرده است که امکان استفاده اختیاری از SELinux به برخی پروژههای محاسبات با کارایی بالا اجازه میدهد سرباری را کنار بگذارند که توان تحمل آن را ندارند. در نتیجه، هیچکدام از دو رویکرد را نمیتوان بهسادگی معماری «تمیزتر» دانست. NT معماری خود را حول یک مدل واحد از آبجکتها متمرکز کرده، در حالی که لینوکس روی یک پایه شبهیونیکسی، مجموعهای از سازوکارهای قابل ترکیب را توسعه داده است.
دلیل نگرانی کرک درباره لینوکس در سال ۲۰۲۶
پژوهشگر گوگل مسئله هوش مصنوعی را در یک سوال خلاصه کرده است: «این عامل هوش مصنوعی دقیقا اجازه انجام چه کاری را دارد؟» مدیر سیستم همین حالا هم میتواند وظایف مختلف را خودکار کند، اما یک عامل هوش مصنوعی قادر است در چند دقیقه هزاران عملیات انجام دهد، کدی را که خود او نوشته اجرا کند، فایلها را بخواند و بدون پرسیدن از کاربر، مجوزهای مختلف را به یکدیگر زنجیر کند. بنابراین سیستمعامل باید مشخص کند این نرمافزار چه کارهایی میتواند انجام دهد، آنها را محدود کند و امکان بررسی دقیق این دسترسیها را فراهم سازد. کرک معتقد است ویندوز NT میتواند با استفاده از «منابعی با نوع مشخص» و ارائه «گزارشهای ممیزی متمرکز و قدرتمند هنگام خارجشدن یک عامل از کنترل» چنین مشکلی را مدیریت کند. البته این فعلا یک دیدگاه و فرضیه است.
لینوکس نیز پاسخ قدرتمندی برای این مسئله دارد. Landlock که در Linux 5.13 اضافه شد، به پردازههای حتی بدون دسترسی ویژه اجازه میدهد دسترسی خود به فایلسیستم را محدود کنند و در نسخههای بعدی محدودیتهایی برای برخی عملیات شبکه نیز به آن اضافه شد. این قوانین به پردازههای فرزند منتقل میشوند و فقط میتوانند سختگیرانهتر شوند. در صورت فعال بودن ممیزی نیز درخواستهای ردشده میتوانند در گزارشهای امنیتی ثبت شوند. در کنار seccomp، Namespaceها، Cgroupها و LSMها، لینوکس میتواند یک عامل هوش مصنوعی را در محیط محدودی نگه دارد. البته مستندات Landlock نیز اذعان میکنند که Namespaceها «برای کنترل دسترسی طراحی نشدهاند»؛ نکتهای که تا حدی با انتقاد کرک همخوانی دارد.
بنابراین، بحث اصلی این است که آیا سیستمعاملی که از ابتدا با محوریت عاملهای هوش مصنوعی طراحی شده باشد، کنترل و درک این دسترسیها را سادهتر میکند یا خیر. مایکروسافت نیز در حال کار روی چنین رویکردی است. این شرکت در کنفرانس Build 2026 پیشنمایش اولیه SDK مربوط به Microsoft Execution Containers یا MXC را معرفی کرد؛ چارچوبی که به توسعهدهندگان اجازه میدهد مشخص کنند یک عامل به چه منابعی دسترسی دارد و ویندوز نیز این محدودیتها را هنگام اجرا اعمال میکند. جداسازی نشستها در MXC، عاملها را با حسابهای کاربری اختصاصی اجرا میکند تا هر عملیات به عامل مربوطه قابل انتساب باشد. قابلیت آزمایشی Agent Workspace در ویندوز ۱۱ نیز از ACL برای کنترل دسترسی حسابهای عاملها به فایلها استفاده میکند.
در نتیجه، عاملهای هوش مصنوعی در ویندوز از SID، توکن و ACL استفاده میکنند؛ همان مدل NT که کرک از آن تمجید کرده است. البته تلاش مایکروسافت برای حرکت به سمت سیستمعاملهای عاملمحور، از عامل هوش مصنوعی روی نوار وظیفه گرفته تا عاملهای پسزمینه با دسترسی به پوشههای شخصی، با هشدارهایی درباره خطر بدافزار نیز همراه بوده است. اقدامات مایکروسافت ثابت نمیکند که این شرکت با دیدگاه کرک درباره لینوکس موافق است، اما نشان میدهد ردموند نیز با همان پرسش اساسی مواجه شده است.
Open NT چیست؟
کرک معتقد است مایکروسافت باید در اوایل دهه ۲۰۰۰ نسخهای «Open NT» ایجاد میکرد؛ نه کاملا مشابه مدل GPL، بلکه سیستمی که در آن یک سازمان بزرگ میتوانست مثلا تخصیصدهنده حافظه را با نمونه اختصاصی خود جایگزین کند. او آمازون را مثال زده و تصور کرده است که این شرکت میتوانست نسخهای به نام «AmazonNT» برای EC2 بسازد و زمانبندیکننده یا پشته شبکه اختصاصی خود را به آن اضافه کند، در حالی که «قرارداد امنیت و سازگاری، یک خط پایه پایدار را در سمت مایکروسافت حفظ میکرد.»
حتما بخوانید: ویندوز ۱۰ امسال پایدارتر از ویندوز ۱۱ است
کرک البته قبول دارد که مایکروسافت تا حدی چنین رویکردی را امتحان کرده بود. برنامه Shared Source این شرکت، کد منبع ویندوز را در اختیار حدود ۱۶۰۰ مشتری سازمانی واجد شرایط قرار میداد و برنامههای جداگانهای نیز برای دانشگاهها و دولتها وجود داشت. در سال ۲۰۰۱، وزارت کشور اتریش نخستین دولت اروپایی بود که به کد منبع ویندوز XP دسترسی پیدا کرد. در سال ۲۰۰۶ نیز Windows Research Kernel به دانشگاهیان اجازه داد زمانبندیکننده و مدیر حافظه NT را تغییر دهند، اما این امکان فقط برای آموزش و پژوهش ارائه شده بود. اما چرا مایکروسافت این مسیر را ادامه نداد؟ بهنظر میرسد درآمد حاصل از مجوزها، مالکیت معنوی، هزینه پشتیبانی و نگرانی از شکستن وعده سازگاری که باعث شد برنامههای Win32 طی سه دهه به کار خود ادامه دهند، از عوامل مهم این تصمیم بودهاند.
بزرگترین استدلال لینوکس علیه Open NT
یکی از جدیترین مخالفتها از سوی دیوید ایرلی، توسعهدهنده باسابقه هسته لینوکس و مسئول نگهداری زیرسیستم گرافیکی آن مطرح شد. او نوشت: «فورکها اینطور کار نمیکنند؛ نگهداری آنها در بلندمدت بیش از حد پرهزینه است.» ایرلی از کرک خواست تصور کند که یک سازمان باید ۲۰ سال بعد همچنان فورک اختصاصی مدیر حافظه NT را نگهداری کند. کرک به جاوا اشاره کرد؛ جایی که پروژههایی مانند Corretto، GraalVM، Azul و OpenJ9 توزیعها یا پیادهسازیهای متفاوتی از ماشین مجازی جاوا ارائه میکنند که همگی استانداردهای یکسانی را هدف گرفتهاند. ایرلی در پاسخ گفت که این پروژهها مشتریانی دارند که برای آنها پول پرداخت میکنند و یک فورک داخلی از NT که درآمدی ایجاد نکند، دائما با خطر کنار گذاشته شدن مواجه خواهد بود. او اضافه کرد: «خیلیها لینوکس را فورک میکنند، یک یا پنج سال ادامه میدهند و بعد متوجه میشوند بهدلیل فشار هزینه باید تغییرات خود را به پروژه اصلی برگردانند.»
اگر آمازون زمانبندیکننده NT را بازنویسی میکرد، وصلههای امنیتی مرتبط مایکروسافت باید با این نسخه ادغام و دوباره آزمایش میشدند؛ تا جایی که این فورک به یک تیم توسعه هسته دوم نیاز پیدا میکرد. در لینوکس، شرکتها میتوانند تغییرات مفید خود را به پروژه اصلی برگردانند و جامعه توسعهدهندگان مسئول نگهداری آنها باشد؛ بنابراین معماری لینوکس را نمیتوان از مدل توسعه آن جدا کرد. فرض کرک این است که وجود یک قرارداد پایدار برای NT میتوانست نگهداری فورکها را امکانپذیر کند. ایرلی در مقابل معتقد است حتی وقتی کد منبع کاملا باز باشد، نگهداری یک هسته جداشده و متفاوت هزینه زیادی دارد؛ استدلالی که دستکم از منظر هزینه و نگهداری، وزن قابل توجهی دارد.
ویندوز NT هم میراث و مشکلات خود را دارد
کن سی، متخصص باسابقه حوزه فناوری اطلاعات و قابلیت اطمینان سیستمها، معتقد است بخشی از انسجام VMS به NT منتقل شد، اما این انتقال کامل نبود. او این پرسش را مطرح کرده است که چگونه میتوان از یک سیستمعامل غیر بلادرنگ مانند NT عملکردی قطعی و قابل پیشبینی دریافت کرد، بدون آنکه مجبور به خرید سختافزار بیش از نیاز باشیم. همچنین او تأکید کرد که تعابیری که برای توصیف رجیستری ویندوز به کار برده است، «مناسب یک محیط حرفهای نیستند».
ریکاردو بانفی، مهندس ارشد نرمافزار نیز به این نکته اشاره کرده است که NT 4.0 برای دستیابی به عملکرد گرافیکی بهتر، درایورهای گرافیکی را به فضای کرنل منتقل کرد. مستندات رسمی مایکروسافت این موضوع را تأیید میکنند و نشان میدهند که Window Manager، GDI و درایورهای گرافیکی در NT 4.0 وارد فضای کرنل شدند. در نتیجه، یک درایور گرافیکی معیوب میتوانست کل سیستمعامل را دچار Crash کند. ویندوز ۲۰۰۰ نیز با افزودن Windows Driver Model، پشتیبانی کامل از Plug and Play، مدیریت توان، یکپارچهسازی WMI و Job Objectها، قابلیتهای خانواده NT را گسترش داد و نسخههای بعدی نیز لایههای بیشتری به این معماری اضافه کردند. بنابراین هسته NT در ویندوز ۱۱ همان طراحی سال ۱۹۹۳ نیست که در گذر زمان دستنخورده باقی مانده باشد، که اشارهای طنزآمیز به پارک ژوراسیک است. کرک در واقع درباره ایدههای معماری بنیادی NT صحبت میکند و بسیاری از تصمیمات و قابلیتهایی که مایکروسافت بعدها به این سیستمعامل اضافه کرده است، میتوانند جداگانه محل بحث و نقد باشند.
استدلال مهم علیه سناریوی تاریخ جایگزینی ویندوز NT
لینوکس توانست در سرورها و رایانش ابری جایگاه گستردهای پیدا کند، زیرا هر فرد یا سازمانی میتوانست کد آن را تغییر دهد، آن را روی سختافزار ارزان اجرا کند و تغییرات مفید آن را به پروژه اصلی بازگرداند. همین مدل به شکلگیری فناوریهایی مانند کانتینرها، ابزارهای توسعه و اندروید کمک کرد. در واکنشها به این بحث، توسعهدهندهای به نام اولیور ام. اس. کارایی و کنترل را از عوامل مهم موفقیت لینوکس دانست. شان مرت، بنیانگذار و مدیرعامل نیز دیدگاه یک مدیر سیستم در نزدک را نقل کرد که بر اساس تجربه او، تنها VMS توانسته بود زیر بار کاری در سطح یک بازار بورس، ثبات خود را حفظ کند. البته این موارد دیدگاههای متخصصان و تجربههای شخصی آنها هستند.
خبر پیشنهادی: نسخه فعالنشده ویندوز روی کامپیوتر پوتین سوژه کاربران شد + ویدیو
طنز ماجرا این است که مایکروسافت در سال ۲۰۲۶ بخش قابل توجهی از تلاش خود را صرف بهبود جایگاه لینوکس در ویندوز کرده است. اوبونتو از طریق WSL سریعتر از نصب روی رایانههای لینوکسی بومی در حال رشد است و WSL نیز بهبودهایی در سرعت دسترسی به فایلها و عملکرد شبکه دریافت میکند. همچنین مایکروسافت، WSL Containers را معرفی کرده است که اجرای کانتینرهای لینوکس را بدون نیاز به Docker Desktop امکانپذیر میکند. حتی گوگل نیز در حال افزودن پشتیبانی WSL به ابزارهای هوش مصنوعی خود است. مایکروسافت علاوه بر این، ابزاری توسعه داده است که ویندوز ۱۱ را به یک رایانه آماده برای توسعه نرمافزار تبدیل میکند و نسخهای اختصاصی از ویندوز ۱۱ را نیز برای کاربران حرفهای ارائه کرده است. با وجود این اقدامات، یک نظرسنجی اخیر نشان میدهد ویندوز تنها ۱۲ درصد از میان پاسخدهندگان آن نظرسنجی را به خود اختصاص داده است.
ویندوز چه چیزهایی میتواند از BSD یاد بگیرد؟
همچنین کرک گفته است که اگر امروز، در سال ۲۰۲۶، یک هسته سیستمعامل از ابتدا طراحی شود، احتمالا شباهت بیشتری به NT یا حتی یک فورک از BSD خواهد داشت. او معماری BSD را «مرتبتر» میداند، زیرا روشهای همپوشان کمتری برای تعریف قابلیتها دارد و Jailها را نیز به دلیل سابقه طولانی آن در ایزولهسازی تحسین میکند. FreeBSD Jailها امکان میدهند دید یک پردازه نسبت به فایلسیستم، کاربران و شبکه ایزوله شود. Capsicum حتی ارتباط مستقیمتری با استدلال کرک دارد، زیرا پردازهای که در حالت Capability اجرا میشود، دسترسی عمومی خود به Namespaceهای سراسری را از دست میدهد و باید صرفا به حقوقی متکی باشد که بهطور صریح از طریق File Descriptorها یا نگاشتهای حافظه در اختیار آن قرار گرفتهاند. نکته جالب این است که Capsicum در دانشگاه کمبریج و با دریافت کمک مالی از گوگل توسعه یافت. امنیت مبتنی بر Capability ابداع ویندوز نیست و بحث کرک در اصل به نحوه مدلسازی و نمایش اختیارها در معماری سیستمعامل مربوط میشود.
پرسش نهایی
مدل ویندوز NT بر این ایده استوار است که منابع باید انواع مشخص و تعریفشدهای داشته باشند، مجوز دسترسی باید به همان منابع متصل شود و سیستمعامل نیز سازوکارهای مشترکی برای بررسی و ممیزی این دسترسیها فراهم کند. در مقابل، لینوکس از یک پایه انعطافپذیر شبهیونیکسی استفاده میکند، مجموعهای از سازوکارهای قابل ترکیب در اختیار میگذارد و به توزیعها و مدیران سیستم اجازه میدهد ترکیبی متناسب با نیاز خود انتخاب کنند. هیچیک از این مدلها بهتنهایی تضمینکننده امنیت سیستمعامل نیستند. با ظهور عاملهای هوش مصنوعی، صورت مسئله نیز تغییر کرده است. سؤال دیگر فقط این نیست که «کاربر چه کسی است؟» بلکه باید پرسید یک عامل نرمافزاری دقیقا چه اقداماتی میتواند انجام دهد، به کدام منابع دسترسی دارد، این دسترسی را برای چه مدتی حفظ میکند، از طرف چه کسی عمل میکند و چگونه میتوان اقدامات انجامشده را اثبات و ممیزی کرد.
ویندوز NT هرگز به سیستمعامل غالب در دنیای سرورها و رایانش ابری تبدیل نشد و این جایگاه به لینوکس رسید. با وجود این، آبجکتها، Handleها، Tokenها و ACLها همچنان ۳۳ سال پس از عرضه NT 3.1 بخش جداییناپذیر ویندوز هستند و مایکروسافت اکنون از همین مؤلفهها برای محدودسازی و کنترل عاملهای هوش مصنوعی استفاده میکند. سناریوی «Open NT» که لوری کرک برای تاریخ جایگزین مایکروسافت تصور کرده است، احتمالا هیچگاه فراتر از یک فرضیه نخواهد رفت. اما اکنون که رایانهها بهتدریج از ابزارهایی که صرفا منتظر فرمان کاربر میمانند، به سامانههایی تبدیل میشوند که به نمایندگی از او اقدام میکنند، هر سیستمعاملی باید پاسخ روشنتری برای این پرسش داشته باشد: تا کجا باید به این عاملها اجازه فعالیت بدهیم؟
