Обсуждение:Сравнение ядер операционных систем

This article is rated List-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Low-importance).

Кто-нибудь хочет добавить DOS в список? Khashishi ( обсуждение ) — Предыдущий недатированный комментарий добавлен 22:55, 3 мая 2011 (UTC). [ ответить ]

А как насчет включения ядра Windows в список? — Предыдущий неподписанный комментарий был добавлен 82.50.31.90 (обсуждение • вклад ) 15:33, 25 января 2006 (UTC). [ ответить ]

Ядро NT есть в списке; оно используется в W2K (NT 5.0), WXP (NT 5.1 в 32-битной форме и 5.2 в 64-битной форме) и WServer2K3 (NT 5.2). Старое ядро ​​"Windows OT" (W95, W98, WMe) может быть или не быть интересным на данный момент; добавьте его, если считаете его интересным. Guy Harris 19:40, 24 февраля 2006 (UTC) [ ответить ]

kenrel — это небольшая часть операционной системы, и по отдельности они бесполезны.

Чтобы быть полезными, некоторые утилиты или API должны быть портированы в ядро.

например, GNu coreutils пришлось перенести на ядро ​​Hurd

и поэтому иногда некоторые люди портируют ядро ​​на несколько API/утилиты, такие как FreeBSD или ядро ​​XNU

некоторые kenrel даже способны иметь различные подсистемы, такие как windowsNT и ядро ​​ReactOS — Предыдущий неподписанный комментарий был добавлен 213.189.165.28 ( обсуждение • вклад ) 15:08, 25 апреля 2006 (UTC). [ ответ ]

можем ли мы считать mklinux полнофункциональным ядром?

потому что я понял, что mklinux был портом ядра Linux на ядро ​​Mach

это как l4linux или colinux

если это правда и мы решили сохранить это, мы должны создать еще одну вкладку для перенесенного ядра в другом разделе, например == == —Предыдущий неподписанный комментарий был добавлен 213.189.165.28 ( обсуждение • вклад ) 15:11, 25 апреля 2006 (UTC). [ ответить ]

Очень старая тема, но я предлагаю удалить строку для MkLinux, потому что это на самом деле просто стандартное ядро ​​Mach с уровнем совместимости Linux. В любом случае, в этой строке нет никакой реальной информации, поэтому ее следует удалить, а MkLinux следует добавить в поле "используется в" для Mach. MFNickster ( обсуждение ) 16:33, 18 ноября 2023 (UTC) [ ответ ]

Так что же означает "поддержка нескольких ЦП"? Означает ли это "поддерживает машину с более чем одним ЦП", что кажется немного излишним, учитывая, что есть столбец для поддержки SMP, или это означает "поддерживает более одного набора инструкций ЦП"? Гай Харрис 23:44, 25 апреля 2006 (UTC) [ ответить ]

Кто-нибудь мог бы прочитать эту статью о TRIX и расширить ее, а также эту статью:

• Уорд, С. А. TRIX: сетевая операционная система. COMPCON, весна 1980 г., стр. 344-349.

- Lentower 00:43, 8 ноября 2006 (UTC) [ ответить ]

Действительно ли уместно указывать "Да" для чего-то, что использует полностью стороннее приложение для выполнения? Я чувствую, что эта таблица будет довольно искажена, когда мы перечислим также эмуляторы. -- Andrz 09:21, 23 марта 2007 (UTC) [ ответить ]

Согласен, я изменил на {{ some }} , хотя я не совсем уверен, что это справедливо. Единственное, что может сделать ядро ​​с исполняемыми файлами PE, — это возможность распознавать произвольные исполняемые заголовки через binfmt_misc и передавать их в программу-обработчик пространства пользователя. Я не уверен, поддерживают ли это другие ОС, где Wine работает поверх.

Также обратите внимание, что технически Wine не является эмулятором — это собственный уровень совместимости. -- intgr 08:42, 4 апреля 2007 (UTC) [ ответить ]

GNU Hurd — это не ядро. Hurd — это набор серверов, работающих на ядре Mach. Читайте веб-сайт. 75.70.143.81 20:05, 25 сентября 2007 (UTC) [ ответить ]

На самом деле, они отказались от микроядра Mach и теперь переходят на L4. Хотя само «ядро ядра» действительно является L4 или Mach, микроядра сами по себе никоим образом не сопоставимы с монолитными ядрами современных операционных систем — они могут только выполнять переключение контекста и необходимое управление памятью. Если вы хотите сравнить их, вам нужно сравнить их со всеми службами, которые фактически предоставляют эту функциональность. -- intgr  [обсуждение] 23:17, 25 сентября 2007 (UTC) [ ответить ]

Можете ли вы проверить эту статью?: Сравнение_ядер#Поддержка_двоичных_форматов

Поддерживает ли WinNT a.out, ELF (двоичные файлы UNIX), HUNK (бинарный файл AmigaOS) и Mach-O (бинарный файл OS X/NextStep/Darwin)? Возможно, WinNT поддерживает COFF, поскольку EXE PE — это модифицированная версия формата файлов Unix COFF, но я не знаю, поддерживает ли Windows форматы двоичных файлов Linux, AmigaOS или MacOS X. Windows NT поддерживает только частичную версию POSIX API (и OS/2/NET/Win32), а не UNIX (и Amiga/Darwin).

Извините за мой плохой английский, но это не мой родной язык.

83.23.15.210 (обсуждение) 12:31, 24 декабря 2007 (UTC) [ ответить ]

Заявленная поддержка всех остальных исполняемых форматов была добавлена ​​13 декабря IP с единственным другим изменением, предположительно вандализмом; теперь я отменил его. Спасибо, что указали на это! -- simxp ( talk ) 15:34, 24 декабря 2007 (UTC) [ ответить ]

Если я нажму на значок сортировки рядом с заголовком Intel (чтобы сортировка проводилась по поддерживаемым Intel типам ЦП), таблица перемешается, а не будет отсортирована. Стоит ли мне подать жалобу на MediaWiki? Ярон Шахрабани ( обсуждение ) 21:08, 3 декабря 2009 (UTC) [ ответить ]

Если это действительно сравнение ядер операционных систем , то список форматов исполняемых образов и т. д. не должен содержать двоичные файлы, которые поддерживаются исключительно в пользовательском пространстве; сюда входит предпочтительный формат исполняемых файлов в Mac OS X :

$ ps -ef | egrep Ускорить 501 26287 135 0 0:00.72 ?? 0:04.16 /Система/Библиотеки/Фреймворки/Carbon.framework/Версии/A/Поддержка/ЗапускCFMApp /Приложения/Quicken 2007/Quicken 2007/Содержимое/MacOS/Quicken 2007 501 26290 242 0 0:00.00 ttys000 0:00.00 egrep Ускорить$ '/Приложения/Quicken 2007/Quicken 2007/Содержание/MacOS/Quicken 2007'-bash: /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007: Отказано в доступе$ ls -l '/Приложения/Quicken 2007/Quicken 2007/Содержимое/MacOS/Quicken 2007'-rw-r--r--@ 1 gharris staff 10563774 1 декабря 2006 г. /Приложения/Quicken 2007/Quicken 2007/Содержание/MacOS/Quicken 2007$ chmod a+x '/Приложения/Quicken 2007/Quicken 2007/Содержимое/MacOS/Quicken 2007'$ '/Приложения/Quicken 2007/Quicken 2007/Содержание/MacOS/Quicken 2007'-bash: /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007: невозможно выполнить двоичный файл

Launch Services, получив команду запустить двоичный файл PEF, запускает LaunchCFMApp для его запуска:

$ файл /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp/System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp: исполняемый файл Mach-O ppc$ файл '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'/Приложения/Quicken 2007/Quicken 2007/Содержание/MacOS/Quicken 2007: заголовок для исполняемого файла PowerPC PEF

И нет, ни один из классических двоичных файлов также не считается, поскольку они запускаются исключительно из пользовательского кода.

Если ядро ​​может распознать какой-то конкретный формат исполняемого образа и запустить его, даже если оно использует помощника пользовательского пространства, я, возможно, готов это учесть, так что, возможно, выполнение двоичных файлов PE через Wine учитывается , если ядро ​​их распознает, так что execвызов может использоваться для их запуска. Гай Харрис ( обсуждение ) 07:17, 20 апреля 2011 (UTC) [ ответить ]

Ядро Windows NT действительно поддерживает UT. Это скрытая функция до Windows Vista. Настройка UT от Google в XP и 2000 предоставляет параметры реестра для настройки этого (HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal). Это, как я понимаю, отчасти сделано для сопоставимости с POSIX. Проблемы с поддержкой UT возникают из-за того, что программное обеспечение делает неправильные предположения в пространстве пользователя. ( 24.246.27.22 (обсуждение) 17:29, 28 октября 2011 (UTC)) [ ответить ]

В столбце "Безопасность" в таблице "Обзор функций" перечислены ACL для некоторых ядер; в столбце "Управление доступом к файлам" также перечислены ACL. Относится ли ссылка на ACL в таблице "Обзор функций" только к файлам или она также относится к объектам внутри операционной системы, которые не относятся к файлам? Гай Харрис ( обсуждение ) 01:34, 9 февраля 2012 (UTC) [ ответить ]

Где находится QNX? 147.209.216.245 ( обсуждение ) 04:26, 6 июля 2012 (UTC) [ ответить ]

Нет в этой таблице. Хотите добавить ? Гай Харрис ( обсуждение ) 06:29, 6 июля 2012 (UTC) [ ответить ]

Хотя официально не было гарантированного времени отклика, среди "людей Amiga" общеизвестно, что Exec на самом деле имеет характеристики реального времени, где ни один обработчик прерываний, предоставляемый ОС, не занимает больше, чем очень короткое время для выполнения, а приоритеты задач/процессов являются абсолютными. Возможно, "частичный" — это разумный статус реального времени AmigaOS <=3.x? (Примечание: именно это в сочетании с тем, что gui имеет более высокий приоритет, чем, например, код файловой системы и многие другие части ОС, заставляет людей, привыкших к Amiga, жаловаться на то, что большинство других GUI медлительны...) — Предыдущий неподписанный комментарий добавлен 78.70.109.74 (обсуждение) 16:31, 17 октября 2012 (UTC) [ ответить ]

Exec не может гарантировать время ответа. Приложения могут остановить планирование задач в любое время в любом месте. Xorxos ( обсуждение ) 01:08, 18 октября 2012 (UTC) [ ответить ]

Что означает KVM?-- 141.24.71.10 (обсуждение) 09:39, 12 февраля 2013 (UTC) [ ответить ]

Учитывая, что существует множество файловых систем, для которых поддержка Windows NT указана как «Да, требуется дополнительный драйвер», почти все перечисленные ядра должны иметь тот же статус для NTFS (в дополнение к любой встроенной поддержке) — в конце концов, ntfs-3g предлагает им почти полную поддержку. -- 188.194.184.143 (обсуждение) 14:02, 10 июня 2013 (UTC) [ ответить ]

Разве «ядро» операционной системы не следует называть «ядерной» операционной системой, чтобы исключить возможность того, что люди подумают, что вы говорите о кукурузе, когда говорите «ядро», вместо того, чтобы на самом деле понять, что вы говорите о программном обеспечении?

На румынском языке мы говорим "nucleul sistemului de operare". В переводе на английский это будет означать: "операционная система nucleous". — Предыдущий неподписанный комментарий добавлен 76.115.25.117 ( обсуждение ) 09:40, 4 октября 2013 (UTC) [ ответить ]

Возможно, в качестве термина следовало выбрать "nucleus", а не "kernel" - и некоторая основная часть OS/360 называлась "nucleus" - но, к лучшему или к худшему, "kernel" - это термин, широко используемый в английском языке. Быстро просматривая ссылки "другие языки" для романских и германских языков на странице ядра (вычислений) , романские языки склонны выбирать слова, родственные "nucleus" (я предполагаю, что так переводится французское "noyau", хотя оно немного больше отличается от латыни, чем другие романские языки), а германские языки склонны выбирать слова, родственные "kernel", но этимология OED для "nucleus" говорит "начало 18 века: от латинского, буквально 'ядро, внутренняя часть', уменьшительное от nux, nuc- 'орех'", так что я полагаю, что это выбор между тем, похожа ли операционная система на орех или на початок кукурузы. :-) ( Славянские языки, как правило, используют варианты слова «yadro», которое, исходя из моих не очень хорошо запомнившихся исследований русского языка и из перевода слова «jadro» на словацкий с translate.google.com, является «core», так что это та же основная идея.) Гай Харрис ( обсуждение ) 17:41, 4 октября 2013 (UTC) [ ответить ]

(А еще есть «atomkern», что по-английски означает « атомное ядро ». Во втором абзаце немецкой статьи Википедии, о которой идет речь, даже обсуждаются латинские корни слова «nucleus».) Гай Харрис ( обсуждение ) 08:23, 5 октября 2013 (UTC) [ ответить ]

Вызов CreateProcess () в Windows API — это не простой системный вызов NT. Существует собственный вызов NtCreateUserProcess() , но, согласно Windows Internals, Sixth Edition (издание этой серии, описывающее Windows 7 и Windows Server 2008 R2), Часть 1, в разделе «Поток CreateProcess», NtCreateUserProcess() откроет исполняемый файл PE и сопоставит его, но для других типов исполняемых файлов библиотечная процедура пользовательского режима CreateProcess() должна открыть сам образ и найти «образ поддержки Windows» для запуска исполняемого файла. Это немного похоже на то, как #! обрабатывается в UN*X, а binfmt_misc работает в Linux.

Итак, либо 1) NtCreateUserProcess() может понимать образы ELF и загружать их самостоятельно, в этом случае само ядро ​​NT понимает ELF, либо 2) NtCreateUserProcess() может не понимать их, и CreateProcess() может запустить программу "Linux ELF helper", которая сама по себе будет исполняемым файлом PE, через NtCreateUserProcess() , или подключиться к существующему процессу, запускающему этот helper, и этот процесс загрузит образ. Мы не можем предположить , что поддержка двоичных файлов Linux ELF означает, что само ядро ​​знает о двоичных файлах ELF. Guy Harris ( talk ) 18:47, 31 марта 2016 (UTC) [ reply ]

Вы имеете в виду поддержку ELF, представленную в Windows Subsystem for Linux? Она реализована в ядре (точнее, в драйверах ядра LXSS), чтобы разрешить системному вызову exec функционировать. До Windows Subsystem for Linux Windows не поддерживала файлы ELF ни в каком сценарии. Старая Unix Subsystem работала только с исполняемыми файлами PE, скомпилированными из Unix-совместимых исходников. Zhuman ( talk ) 10:45, 28 марта 2018 (UTC) [ reply ]

Мне кажется странным включать архитектуры процессоров, не поддерживаемые ни одной из перечисленных операционных систем. Bepvte ( обсуждение ) 23:07, 22 октября 2018 (UTC) [ ответ ]

Я не вижу столбцов, полностью залитых красным цветом, в таблице Сравнение ядер операционных систем#Поддерживаемые наборы инструкций ЦП и микроархитектуры . Я вижу несколько столбцов, в которых нет зеленых ячеек, только смесь красных ячеек и серых ячеек "?", но это другое - это говорит о том, что ни одна из ОС не поддерживает эту архитектуру, как известно всем, кто потрудился обновить таблицу, но это не значит, что они ее не поддерживают. Гай Харрис ( обсуждение ) 06:33, 23 октября 2018 (UTC) [ ответить ]

В любом случае, это кажется пустой тратой места и могло бы сделать прокрутку таблицы намного проще. Мне просто не кажется целесообразным иметь столбцы для данных, которых у нас пока нет. Bepvte ( talk ) 16:21, 23 октября 2018 (UTC) [ ответить ]

В диаграмме крайне необходим столбец для указания языка, на котором разработано ядро. Язык является критическим фактором, определяющим надежность ОС и простоту написания программ.