Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 195
Уровень большинства студентов оставляет желать лучшего, боюсь, это неразумно. Либо ему придется столкнуться с суровой реальностью и упрощать на ходу свой курс, либо читать с очень низким КПД, когда большинство приходит просто посидеть.
Плюс, РеактОС… Странный выбор. Такой курс бы строить с более фундаментальных основ, с чистого линукса. LFS, допустим — очень хорошо пойдет, минимум лишнего, максимум изучения работы ОС.
Плюс, РеактОС… Странный выбор. Такой курс бы строить с более фундаментальных основ, с чистого линукса. LFS, допустим — очень хорошо пойдет, минимум лишнего, максимум изучения работы ОС.
А почему фундаментальные основы и чистый линукс это синонимы? Хотя бы с хронологической точки зрения? )
Линукс популярен (не шайтан-штука, пугающая одним названием), в нём реализована поддержка POSIX, SysV, его ядро легко патчится, а значит можно дать задание на курсач — реализовать многозадачность немного по-другому, например.
Он сложноват, лучше уж что-то в стиле Minix'а.
Пропустил слово «хотя бы» — «с более фундаментальных основ, хотя бы с чистого линукса» Чистый линукс фундаментальнее реактоса, плюс — более общеприменимые знания.
А этот курс я бы вообще с FreeRTOS какой-нибудь начал, куда лучше пойдет, т.к. механизмы все на виду.
А этот курс я бы вообще с FreeRTOS какой-нибудь начал, куда лучше пойдет, т.к. механизмы все на виду.
Мне вот тоже хотелось бы узнать почему линукс фундаментальнее.
Из-за posix*… Многие специализированные системы если и не соблюдают, то берут за основу posix и делают его клоны…
Просто-напросто gnu/linux наиболее полно реализует самые популярные стандарты, которые будут фундаментом в любой практике.
Просто-напросто gnu/linux наиболее полно реализует самые популярные стандарты, которые будут фундаментом в любой практике.
имхо, posix/sus надо изучать отдельным курсом, уже после общей теории ос. это api и конкретная реализация, на теории ос надо изучать разные подходы и базовые принципы
Полностью согласен! Но где брать время на отдельный курс по posix? Да и весь его разбирать, тоже, не надо. Это, наверное, больше к практике должно относиться…
Например, треть курса на теорию с примерами из gnu\linux и три четверти на практику по библиотеками posix.
Например, треть курса на теорию с примерами из gnu\linux и три четверти на практику по библиотеками posix.
Это, наверное, должен быть факультативный курс. Не всем это нужно, довольно объемно и есть ещё масса тонкостей-например, различия в реализации в разных системах. Да и GNU/Linux не является тут какой-то референсной системой, вроде как и нет такой цели во всем соответствовать posix.
Linux важен тем, что он доминирует в эмбеддед системах. Те, что достаточно сильны, чтобы его потянуть, обычно, под ним и работают. К тому же ядро линукса еще и в Андроиде. Поэтому область обширнейшая, особенно для железячников — возможности открывает большие.
РеактОСа нигде нет, кроме некоторых х86 компов, где он в учебных целях. Линукс (как минимум ядро) — почти во всех окружающих системах, где не винда.
Роутеры, отладочные платы, терминалы, мобильные (андроид).
РеактОСа нигде нет, кроме некоторых х86 компов, где он в учебных целях. Линукс (как минимум ядро) — почти во всех окружающих системах, где не винда.
Роутеры, отладочные платы, терминалы, мобильные (андроид).
А ещё в суперкомпьютерах и вебе. И везде своя специфика. В эмбеддед, например, афаик, часто можно встретить 2.4 и урезанную libc
Это не ответ. Теперь Вам придется ответить что «фундаментального» в POSIX.
Вообще, POSIX конечно преподавать надо, но дополнительным материалом в качестве примера того, как не надо делать. Посвящать ему отдельный курс или заменять им курс «Операционные системы» — неприемлемо.
Вообще, POSIX конечно преподавать надо, но дополнительным материалом в качестве примера того, как не надо делать. Посвящать ему отдельный курс или заменять им курс «Операционные системы» — неприемлемо.
Ответ вам выше, http://habrahabr.ru/post/168737/#comment_5848393
Ага, давайте замечать сотни разных линуксов кругом — в тостерах и микроволновках, а реальные Windows-ы (а дизайн ReactOS — это именно что дизайн NT) проигнорируем.
Я еще согласен с предложениями изучать на упрощенных ОС типа Minix-а, но если брать реальную ОС и преподавать ее дизайн, то лучше брать ОС, которая действительно была СПРОЕКТИРОВАНА и имеет этот самый дизайн.
Я еще согласен с предложениями изучать на упрощенных ОС типа Minix-а, но если брать реальную ОС и преподавать ее дизайн, то лучше брать ОС, которая действительно была СПРОЕКТИРОВАНА и имеет этот самый дизайн.
А, так вы из этих.
И что, до сих пор не пришло понимание того, что на х86 у вас не будет возможности (а также, вероятнее всего, необходимости) менять код ядра Windows, в то время как вакансий, связанных с изменением кода ядра линукс и портированием его под новые платформы более чем достаточно?
И что, до сих пор не пришло понимание того, что на х86 у вас не будет возможности (а также, вероятнее всего, необходимости) менять код ядра Windows, в то время как вакансий, связанных с изменением кода ядра линукс и портированием его под новые платформы более чем достаточно?
А, так вы из этих.
Да нет, это Вы из «этих». Одного факта, что человек «болеет за другую футбольную команду» уже достаточно, чтоб снисходительно сбрасывать со счетов любые аргументы.
Есть такая удобная штука, которая называется Open/Closed Principle (буква O вSOLID дизайне). Хороший дизайн должен предоставлять возможность расширения БЕЗ необходимости модификации оригинального кода.
В моем родном городе (Запорожье, Украина) я знаю как минимум ДВЕ конторы, которые занимаются низкоуровневой разработкой под Windows. Это крупный индустриальный центр и глубокая культурная/интеллектуальная провинция. В соседнем Днепропетровске я знаю/слышал о десятке подобных контор (при том, что я там не живу). Не видел ни одной которая бы занималась «изменением кода ядра линукс и портированием его под новые платформы» — может Вы подскажете?
Знание платформы (низкоуровневой или нет) нужно для того, чтобы писать ПОД платформу, а не обязательно заниматься разработкой самой платформы. Но даже это не важно, потому как курс должен быть ОБЩИМ, применимый к операционным системам вообще. И Линукс здесь — один из худших выборов.
Да-да-да, хороший дизайн должен предоставлять, должен не требовать использования дебаггера и еще много чего делать. Но мы живем в реальном мире.
Мало ли чего вы не видели. Ищите на hh по запросу kernel хотя бы. Ваша запорожская компания это, конечно, очень весомо, но мне кажется она несколько проиграет по размерам, например, Самсунгу, который ищет себе специалистов по Embedded Linux.
Вы собираетесь спорить с тем, что доля Windows в эмбеддед намного меньше доли Linux?
«Курс должен быть общим», ну как всегда, давайте учить чему-нибудь бесполезному, а с полезным сами разбирайтесь. Курс должен быть подкреплен практикой, выбор ReactOS еще хуже выбора Linux, оторвано от реальности, обучение ради обучения.
Если уж отвязаться от больших архитектур и стараться дать как можно более фундаментальные знания, то нужно брать какую-нибудь мелкую OS, типа FreeRTOS или аналогичных, куда полезнее будет.
Мало ли чего вы не видели. Ищите на hh по запросу kernel хотя бы. Ваша запорожская компания это, конечно, очень весомо, но мне кажется она несколько проиграет по размерам, например, Самсунгу, который ищет себе специалистов по Embedded Linux.
Вы собираетесь спорить с тем, что доля Windows в эмбеддед намного меньше доли Linux?
«Курс должен быть общим», ну как всегда, давайте учить чему-нибудь бесполезному, а с полезным сами разбирайтесь. Курс должен быть подкреплен практикой, выбор ReactOS еще хуже выбора Linux, оторвано от реальности, обучение ради обучения.
Если уж отвязаться от больших архитектур и стараться дать как можно более фундаментальные знания, то нужно брать какую-нибудь мелкую OS, типа FreeRTOS или аналогичных, куда полезнее будет.
Хороший дизайн должен. Лично мне, да. И если есть пример хорошего дизайна, лично я не вижу ни единой причины использовать плохой при обучении.
Что же до hh и пр, раз уж Вы использовали это как аргумент, то давайте Вы сами посчитаете количество вакансий на одно и на другое, но только в одной и той же выборке (один город, один регион, одна страна и пр..). Прошу отметить, это не я начинал доказывать, что знание устройства одной конкретной ОС — совершенно не котируется на рынке. Постарайтесь доказать Ваше же утверждение. И да, еще раз повторюсь, к «фундаментальности» знаний наличие вакансий на рынке мало относится.
Насчет Самсунга, хоть это и ничего не означает, просто забавно, что Вы упомянули, потому как конкретно для них я разрабатывал НЕСКОЛЬКО драйверов. Под Windows.
Каким образом ReactOS оторван от жизни? Он дает общее представление об архитектуре NT (из-за того, что это реимплементация там, естественно, есть отличия от оригинала, но я сильно сомневаюсь, что в рамках одного курса дело дойдет до рассмотрения подобных нюансов). Да, кстати, почему Вы желаете ограничиться только эмбедом?
Что же до hh и пр, раз уж Вы использовали это как аргумент, то давайте Вы сами посчитаете количество вакансий на одно и на другое, но только в одной и той же выборке (один город, один регион, одна страна и пр..). Прошу отметить, это не я начинал доказывать, что знание устройства одной конкретной ОС — совершенно не котируется на рынке. Постарайтесь доказать Ваше же утверждение. И да, еще раз повторюсь, к «фундаментальности» знаний наличие вакансий на рынке мало относится.
Насчет Самсунга, хоть это и ничего не означает, просто забавно, что Вы упомянули, потому как конкретно для них я разрабатывал НЕСКОЛЬКО драйверов. Под Windows.
Каким образом ReactOS оторван от жизни? Он дает общее представление об архитектуре NT (из-за того, что это реимплементация там, естественно, есть отличия от оригинала, но я сильно сомневаюсь, что в рамках одного курса дело дойдет до рассмотрения подобных нюансов). Да, кстати, почему Вы желаете ограничиться только эмбедом?
А где там хороший дизайн в NT то? Я конечно помню, что начинали ее дизайнить спецы из openVMS, но потом на нее стихийно наложили кучу костылей и заплат и она стала сложной и непонятной.
Лучше уж что-то типа QNXа учить или даже Macos X.
Лучше уж что-то типа QNXа учить или даже Macos X.
Такими умозаключениями дойдём до того, что в качестве материала «Операционные системы» будет матан и кванты… Чтобы точно фундаментально.
Да, posix фундаментален (относительно большинства стандартов) — он везде присутствует в каком-то виде, самодостаточен, охватывает множество механизмов ОС и не привязан к единственной реализации.
Интересно, а чем вам posix не нравится, почему так «не надо делать»?
Да, posix фундаментален (относительно большинства стандартов) — он везде присутствует в каком-то виде, самодостаточен, охватывает множество механизмов ОС и не привязан к единственной реализации.
Интересно, а чем вам posix не нравится, почему так «не надо делать»?
А на фига матан и кванты? Можно миникс, можно вообще Mach или L4. Можно NT (WRK). А можно и Linux — никто не спорит, просто этот выбор надо бы обосновать.
О, на эту тему надо писать длинный пост, на который я не могу собраться уже лет 5. Вкратце — там абсолютно нет дизайна. Грязная заплатка на грязной заплатке и все это выливается в какую то невообразимую кашу. Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Целый раздел посвящен шелл-скриптингу — это вообще закопать, ибо оно не справляется даже с базовыми целями поставленными перед ним: декомпозиция системы на мелкие независимые модули, которые легко комбинируются друг с другом.
В остальном практически каждая существенная подсистема (деление на «подсистемы» чисто условное, ибо никакой подобной группировки POSIX/SUS не описывает) имеет огромные торчащие наружу изъяны: обработка исключительных ситуаций, ввод/вывод, управление памятью и т.д…
Интересно, а чем вам posix не нравится, почему так «не надо делать»?
О, на эту тему надо писать длинный пост, на который я не могу собраться уже лет 5. Вкратце — там абсолютно нет дизайна. Грязная заплатка на грязной заплатке и все это выливается в какую то невообразимую кашу. Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Целый раздел посвящен шелл-скриптингу — это вообще закопать, ибо оно не справляется даже с базовыми целями поставленными перед ним: декомпозиция системы на мелкие независимые модули, которые легко комбинируются друг с другом.
В остальном практически каждая существенная подсистема (деление на «подсистемы» чисто условное, ибо никакой подобной группировки POSIX/SUS не описывает) имеет огромные торчащие наружу изъяны: обработка исключительных ситуаций, ввод/вывод, управление памятью и т.д…
Ну напишите пост, будет интересно почитать. Имхо, то что вы перечислили сделано в nt ещё хуже.
И не забываем, что posix был написан для существующих систем, чтобы сохранить их совместимость и он вообще не касается реализации.
И, кстати, mach/l4/minix — все posix-совместимые(и nt, кстати, тоже вроде как)
И не забываем, что posix был написан для существующих систем, чтобы сохранить их совместимость и он вообще не касается реализации.
И, кстати, mach/l4/minix — все posix-совместимые(и nt, кстати, тоже вроде как)
Я честно говоря затрудняюсь вспомнить вообще хоть одну вещь, которая в Linux-е сделана лучше чем в NT.
Насчет поста — пытаюсь, но по тому сколько времени я уже «пытаюсь» — не уверен, что я его закончу в обозримом будущем.
Mach/L4/Minix не имееют POSIX-а в ядре, а слои совместимости клепать — так это даже хорошо. Вон NT тоже POSIX совместимая (была, пока это еще требовалось для продажи в госучреждения США), при этом насколько я помню, ни одни Linux дистрибутив не получал сертификата POSIX-совместимости.
Насчет поста — пытаюсь, но по тому сколько времени я уже «пытаюсь» — не уверен, что я его закончу в обозримом будущем.
Mach/L4/Minix не имееют POSIX-а в ядре, а слои совместимости клепать — так это даже хорошо. Вон NT тоже POSIX совместимая (была, пока это еще требовалось для продажи в госучреждения США), при этом насколько я помню, ни одни Linux дистрибутив не получал сертификата POSIX-совместимости.
Было бы интересно подискутировать Вот, например, epoll мне видится куда лучше чем iocp/select/etc, fork лучше createprocess, named pipes в \\.\pipe\ — wtf?, unix сокетов нет, mmap только в виде file-mapping. Это просто что пришло на ум, но я в windows слабо разбираюсь
О, epoll — просто отличный пример, ибо в POSIX (к которому epoll не относится никаким боком) и Linux в частности (который относится) традиционно все ОЧЕНЬ ХРЕНОВО с асинхронным вводом/выводом. IOCP появился в винде 20 лет назад и с первой же версии был сделан правильно (хотя бы тот факт, что он до сих пор используется практически без изменений, хотя и с оговоркой, что современные скорости сетевых соединений требуют узких оптимизаций типа registered I/O). select — просто позорище. FD_SET — битовая маска, которая в первых реализациях занимала один регистр — 16 бит, потом ситацию улучшили расширив битовый набор до тысячи (ага, тысячи одновременных соединений достаточно каждому), ухудшив при этом производительность (алгоритмы с линейным временем, там где обычная очередь может обеспечить константное? SRSLY?). /dev/poll — улучшил ситуацию еще немного при этом все еще используя алгоритмы с линейным временем. /dev/epoll — еще чуть улучшил ситуацию, при этом все еще не дотягивает до механизма, который использовался 20 лет назад — он не является асинхронным (в связи с этим возникает еще куча проблем: лишние копирования, локальность кешей, увеличение задержек при hiperf для дополнительных раундтрипов в ядро и пр..). При этом POSIX получил свое асинхронное API (полностью отдельное от синхронного) только, если не ошибаюсь в 2008-м, а тот же Linux имеет ДВЕ реализации aio_* вызовов, ни одна из которых не предназначена для работы с сетью.
fork — настолько плохая идея (он плохо совместим с потоками, он напрочь убивает нормальный аккаунтинг памяти, он смешивает понятия контейнера ресурсов и единицы исполнения и пр..), что POSIX (почитайте о некоторых проблемах прямо в стандарте секция rationale, ну или в этой попытке решить некоторые из проблем) говорит следующее:
Что забавно, в обоих случаях, fork менее эффективен, чем CreateThread и CreateProcess соответственно. Это один из немногих случаев, когда проблемы настолько существенны и очевидны, что их описание включено в текст стандарта (самым большим признанием проблем было исключение любого описания безопасности).
А что не так? Это просто симлинк на \Device\NamedPipe. Причем, если уж мы этого коснулись, скажите мне сами, что лучше для идентификации устройств — free-form строки или два БАЙТА (major/minor number — хотя позднее было введено расширение при помощи магического значения этих байт)? Ну и совсем мелочь, а неприятно: каналы в POSIX не поддерживают фрейминг (message oriented в терминах винды).
Странная претензия, а в POSIX нет LPC/ALPC. Давайте будем обсуждать задачи, а не конкретные способы их решения.
Не очень понимаю о чем Вы. ZwCreateSection/ZwMapViewOfSection дают возможность как мепить файлы, так и разделять память без какого либо файла («pagefile backed» — просто не совсем удачное НАЗВАНИЕ, ибо таким секциям абсолютно плевать на существование pagefile-а). Каким образом это существенно отличается от mmap?
fork — настолько плохая идея (он плохо совместим с потоками, он напрочь убивает нормальный аккаунтинг памяти, он смешивает понятия контейнера ресурсов и единицы исполнения и пр..), что POSIX (почитайте о некоторых проблемах прямо в стандарте секция rationale, ну или в этой попытке решить некоторые из проблем) говорит следующее:
There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.
Что забавно, в обоих случаях, fork менее эффективен, чем CreateThread и CreateProcess соответственно. Это один из немногих случаев, когда проблемы настолько существенны и очевидны, что их описание включено в текст стандарта (самым большим признанием проблем было исключение любого описания безопасности).
named pipes в \\.\pipe\ — wtf
А что не так? Это просто симлинк на \Device\NamedPipe. Причем, если уж мы этого коснулись, скажите мне сами, что лучше для идентификации устройств — free-form строки или два БАЙТА (major/minor number — хотя позднее было введено расширение при помощи магического значения этих байт)? Ну и совсем мелочь, а неприятно: каналы в POSIX не поддерживают фрейминг (message oriented в терминах винды).
unix сокетов нет
Странная претензия, а в POSIX нет LPC/ALPC. Давайте будем обсуждать задачи, а не конкретные способы их решения.
mmap только в виде file-mapping
Не очень понимаю о чем Вы. ZwCreateSection/ZwMapViewOfSection дают возможность как мепить файлы, так и разделять память без какого либо файла («pagefile backed» — просто не совсем удачное НАЗВАНИЕ, ибо таким секциям абсолютно плевать на существование pagefile-а). Каким образом это существенно отличается от mmap?
Да, реализаций asyncIO в ванильном ядре две. И обе работают, и каждая удобнее, чем IOCP.
Fork, простите чего!? Подскажите, сколько планировщиков реализовано для NT, что Create* стал удобнее fork через mingw? Это разные подходы, но использовать удобнее pthead.
Что вы на select наговариваете. Вам в одном потоке зачем 1024 дескриптора? За такое по рукам бьют…
Fork, простите чего!? Подскажите, сколько планировщиков реализовано для NT, что Create* стал удобнее fork через mingw? Это разные подходы, но использовать удобнее pthead.
Что вы на select наговариваете. Вам в одном потоке зачем 1024 дескриптора? За такое по рукам бьют…
Мдя, в линуксе я знаю больше Вашего (хотя я никогда и не особо стремился глубоко его изучать).
Одна из реализаций — в glibc и для каждого запроса создает новый поток. Но вторая реализация асинхронного ввода/вывода в ядре таки есть — в «block layer» (они вообще слышали хотя бы о DRY не говоря уже о более «продвинутых» принципах).
Вы даже примерно не представляете о чем говорите, да? IOCP можно сравнивать с epoll или, там, kqueue. При чем здесь AIO вообще и каким место оно удобнее?
Да, CreateProcess/CreateThread удобнее потому что РАБОТАЕТ, а fork только создает проблемы.
То есть если я правильно понимаю, Вы сейчас хотите «защищать» убожество select? Мдя. Позвольте Вас спросить, Вы вообще хотя бы примерно знаете как работает IOCP, чтобы обсуждать его?
Да, реализаций asyncIO в ванильном ядре две.
Одна из реализаций — в glibc и для каждого запроса создает новый поток. Но вторая реализация асинхронного ввода/вывода в ядре таки есть — в «block layer» (они вообще слышали хотя бы о DRY не говоря уже о более «продвинутых» принципах).
И обе работают, и каждая удобнее, чем IOCP.
Вы даже примерно не представляете о чем говорите, да? IOCP можно сравнивать с epoll или, там, kqueue. При чем здесь AIO вообще и каким место оно удобнее?
Create* стал удобнее fork через mingw? Это разные подходы, но использовать удобнее pthead.
Да, CreateProcess/CreateThread удобнее потому что РАБОТАЕТ, а fork только создает проблемы.
Что вы на select наговариваете. Вам в одном потоке зачем 1024 дескриптора? За такое по рукам бьют…
То есть если я правильно понимаю, Вы сейчас хотите «защищать» убожество select? Мдя. Позвольте Вас спросить, Вы вообще хотя бы примерно знаете как работает IOCP, чтобы обсуждать его?
Не утверждаю что знаю более вашего. Говорю о своём скромном опыте.
С IOCP ковырялся постольку-поскольку, разбирался с dcom в samba.
При чём тут glibc, когда это отдельный проект… С чем предлагаете сравнивать IOCP?
Про fork не надо — это просто отличная система. Про select — сейчас смотрю на его реализацию и не понимаю в чём проблема изменить один макрос, если так надо?
С IOCP ковырялся постольку-поскольку, разбирался с dcom в samba.
При чём тут glibc, когда это отдельный проект… С чем предлагаете сравнивать IOCP?
Про fork не надо — это просто отличная система. Про select — сейчас смотрю на его реализацию и не понимаю в чём проблема изменить один макрос, если так надо?
Всё, признаю свою некомпетентность и вашу безоговорочную победу. Закончим этот интересный (для меня, по крайней мере) спор.
вот видите уже на пол статьи небольшой написали:)
по поводу createprocess — он же такой жутко дорогой, что им стараются не пользоваться, а в linux — fork использует cow и тысячи форков-обычное явление. какие проблемы с fork, сколько использовал, никаких проблем не было, очень удобно. насчет тредов-есть pthreads.
по поводу select-это в винде он используется на всю катушку(а ещё чаще — плодят море тредов). когда и для каких целей он создавался, его ограничения были приемлемы вполне.
про юникс сокеты — ниже заметили, что позволяет файловые дескрипторы передавать в другие процессы, это очень полезно.
и ещё: как мне видится архитектура nt: взяли архитектуру VMS(очень много схожего и делали одни люди, это неплохо кстати кстати), файловую систему и кое что ещё от os/2, заправили слоями совместимости с dos/win16/win32 и posix(который потом выкинули, имхо, по политическим соображениям)
по поводу createprocess — он же такой жутко дорогой, что им стараются не пользоваться, а в linux — fork использует cow и тысячи форков-обычное явление. какие проблемы с fork, сколько использовал, никаких проблем не было, очень удобно. насчет тредов-есть pthreads.
по поводу select-это в винде он используется на всю катушку(а ещё чаще — плодят море тредов). когда и для каких целей он создавался, его ограничения были приемлемы вполне.
про юникс сокеты — ниже заметили, что позволяет файловые дескрипторы передавать в другие процессы, это очень полезно.
и ещё: как мне видится архитектура nt: взяли архитектуру VMS(очень много схожего и делали одни люди, это неплохо кстати кстати), файловую систему и кое что ещё от os/2, заправили слоями совместимости с dos/win16/win32 и posix(который потом выкинули, имхо, по политическим соображениям)
А Вы посмотрите на POSIX тот же — там все написано. fork используется либо для создания потока исполнения, либо для создания нового процесса. Давайте посмотрим на затраты:
fork+exec vs CreateProcess: fork сначала выделяет и инициализирует новое адресное пространство (PDE/PTE) только для того, чтоб немедленно его дискарднуть. Расходы не то, чтобы сильно большие, но линейно зависят от количества физической памяти, доступной родительскому процессу на момент форка. Что еще хуже, любые области доступные родительскому процессу на запись в момент форка должны быть помечены как read-only (чтоб дать pagefault обработчику возможность сделать CoW), а в момент exec — пометить все обратно.
fork vs CreateThread: опять таки, fork КОПИРУЕТ адресное пространство (повторюсь, не саму память, а именно таблицы страниц, которые указывают на те же самые страницы). Точно так же вся r/w память перепомечается как ro и прочая ненужная активность, которой можно избежать при использовании потоков.
В SUS описаны проблемы, возникающие у fork-а с потоками, но этом не все проблемы. К примеру, fork — один из основных виновников того, что приходится overcommit-ить память (помните ту футболку «malloc never fails»? Так вот в случае Линукса — это чистейшая правда.) и вводить OOM Killer. Кстати, NtCreateProcess поддерживает семантику fork: если ему передать родительский процесс, но не передать секцию — родительский процесс форкнется. Для Win32 подсистемы это не работает, потому что каждый win32 процесс регистрируется у csrss, а форкнуть эту регистрацию невозможно, а вот Interix и SFU/SUA использовали эту возможность для нативной реализации fork.
Справедливости ради, стоит отметить, что WinSock-овая реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе, хотя все так же использует алгоритмы с линейной сложностью (это в select by design). И нет ни о какой катушке речи не идет, все хоть минимально претендующее на серьезность использует IOCP.
Что же до юникс сокетов — костыль с пересылкой дескрипторов нужен потому, что нет возможности «открыть» процесс и работать с ним напрямую (ptrace доступен только суперпользователю, который, кстати, является еще один костылем для того чтобы обойти ограничения классической юникс безопасности).
fork+exec vs CreateProcess: fork сначала выделяет и инициализирует новое адресное пространство (PDE/PTE) только для того, чтоб немедленно его дискарднуть. Расходы не то, чтобы сильно большие, но линейно зависят от количества физической памяти, доступной родительскому процессу на момент форка. Что еще хуже, любые области доступные родительскому процессу на запись в момент форка должны быть помечены как read-only (чтоб дать pagefault обработчику возможность сделать CoW), а в момент exec — пометить все обратно.
fork vs CreateThread: опять таки, fork КОПИРУЕТ адресное пространство (повторюсь, не саму память, а именно таблицы страниц, которые указывают на те же самые страницы). Точно так же вся r/w память перепомечается как ro и прочая ненужная активность, которой можно избежать при использовании потоков.
В SUS описаны проблемы, возникающие у fork-а с потоками, но этом не все проблемы. К примеру, fork — один из основных виновников того, что приходится overcommit-ить память (помните ту футболку «malloc never fails»? Так вот в случае Линукса — это чистейшая правда.) и вводить OOM Killer. Кстати, NtCreateProcess поддерживает семантику fork: если ему передать родительский процесс, но не передать секцию — родительский процесс форкнется. Для Win32 подсистемы это не работает, потому что каждый win32 процесс регистрируется у csrss, а форкнуть эту регистрацию невозможно, а вот Interix и SFU/SUA использовали эту возможность для нативной реализации fork.
по поводу select-это в винде он используется на всю катушку
Справедливости ради, стоит отметить, что WinSock-овая реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе, хотя все так же использует алгоритмы с линейной сложностью (это в select by design). И нет ни о какой катушке речи не идет, все хоть минимально претендующее на серьезность использует IOCP.
Что же до юникс сокетов — костыль с пересылкой дескрипторов нужен потому, что нет возможности «открыть» процесс и работать с ним напрямую (ptrace доступен только суперпользователю, который, кстати, является еще один костылем для того чтобы обойти ограничения классической юникс безопасности).
> а вот Interix и SFU/SUA использовали эту возможность для нативной реализации fork.
интересный момент. а cygwin тоже?
> реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе
ну а смысл? select не годится для большого набора никак и ограничения тут более чем разумны.
> «открыть» процесс и работать с ним напрямую (ptrace
ужас какой
p.s. ваши посты интересно читать очень, но уж очень какая-то радикальная позиция
интересный момент. а cygwin тоже?
> реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе
ну а смысл? select не годится для большого набора никак и ограничения тут более чем разумны.
> «открыть» процесс и работать с ним напрямую (ptrace
ужас какой
p.s. ваши посты интересно читать очень, но уж очень какая-то радикальная позиция
Нет, Cygwin работает в Win32 подсистеме и вместо CoW использует полное копирование.
Что ужасного? Процесс в NT — один из нескольких десятков типов объектов ядра, любые операции с ним проходят через Security Reference Monitor и являются securable. Никаких special case-ов: доступ ко всем объектам проверятся одинаково и обязательно. Самое забавное, что больше всего костылей и каких то «отфонарных» правил в USER/GDI — исторически они были полностью в user mode и после переноса в ядро семантику менять было уже поздно.
Ой, да никакой радикальности. Посмотрите сотни постов про «сегодня я перевел на линукс школу» и пр — есть ли ХОТЬ В ОДНОМ что нибудь «Да задолбали со своим линуксом — почему не какая нибудь другая ОС?». Гляньте первый комментарий в этом посте. А теперь представьте на секунду, что дизайн Линукса (и POSIX) действительно убог и лучше бы держаться от него подальше, перечитайте первый комментарий еще раз и попробуйте поставить себя на мое место.
ужас какой
Что ужасного? Процесс в NT — один из нескольких десятков типов объектов ядра, любые операции с ним проходят через Security Reference Monitor и являются securable. Никаких special case-ов: доступ ко всем объектам проверятся одинаково и обязательно. Самое забавное, что больше всего костылей и каких то «отфонарных» правил в USER/GDI — исторически они были полностью в user mode и после переноса в ядро семантику менять было уже поздно.
p.s. ваши посты интересно читать очень, но уж очень какая-то радикальная позиция
Ой, да никакой радикальности. Посмотрите сотни постов про «сегодня я перевел на линукс школу» и пр — есть ли ХОТЬ В ОДНОМ что нибудь «Да задолбали со своим линуксом — почему не какая нибудь другая ОС?». Гляньте первый комментарий в этом посте. А теперь представьте на секунду, что дизайн Линукса (и POSIX) действительно убог и лучше бы держаться от него подальше, перечитайте первый комментарий еще раз и попробуйте поставить себя на мое место.
Ой, чешется.
Отстаньте от pthread, если желаете — заворачивайте в свои функции. Давайте просто… Сколько одновременных процессов пустит за секунду NT и для порядка в winCE, сколько времени уйдёт на разбор ACL? Там же размеры передаваемых «объектов» будет в разы больше таблиц стека.
Вы же, наверняка, знаете и про производительность ngpt/nptl, которые потоки за десяток микросекунд позволяют запускать.
Кстати, сколько раз изменили ACL за время существования NT5.0?
Отстаньте от pthread, если желаете — заворачивайте в свои функции. Давайте просто… Сколько одновременных процессов пустит за секунду NT и для порядка в winCE, сколько времени уйдёт на разбор ACL? Там же размеры передаваемых «объектов» будет в разы больше таблиц стека.
Вы же, наверняка, знаете и про производительность ngpt/nptl, которые потоки за десяток микросекунд позволяют запускать.
Кстати, сколько раз изменили ACL за время существования NT5.0?
Я честно говоря затрудняюсь вспомнить вообще хоть одну вещь, которая в Linux-е сделана лучше чем в NT.
В линуксе можно передавать файловые дескрипторы через локальные сокеты. А как на виндузе передать хэндл в другой процесс? Про DuplicateHandleEx знаю, но это решение на порядки хуже.
В линуксе создание процесса ничего не стоит, в отличие от винды. Это куда более серьезное подспорье для декомпозиции чем так критикуемый вами sh скрипт.
«Безопасность» если что поддерживается — есть базовая UNIX модель прав доступа, есть ACL. Message-oriented каналы тоже есть. Интересно, почему вы считаете что IOCP превосходит epoll/kqueue.
А как на виндузе передать хэндл в другой процесс? Про DuplicateHandleEx знаю, но это решение на порядки хуже.
Потрудитесь показать, чем же хуже. Я вот например увидев на какие извращения пошли бедные создатели Хрома для Линукса — даже зауважал их. Незадача оказалась в том, что seccomp не поддерживает recvmsg. На винде все замечательно работает через NtDuplicateHandle.
В линуксе создание процесса ничего не стоит, в отличие от винды. Это куда более серьезное подспорье для декомпозиции чем так критикуемый вами sh скрипт.
Ответил выше. fork помимо проблем с семантикой, просто тупо дороже. Про vfork знаю, но он вообще ничего не гарантирует. Вот такой вот чистый и красивый POSIX: у нас есть системный вызов, но реализациям позволено его реализовывать как угодно.
«Безопасность» если что поддерживается — есть базовая UNIX модель прав доступа, есть ACL.
Appropriate Privileges
One of the fundamental security problems with many historical UNIX systems has been that the privilege mechanism is monolithic-a user has either no privileges or all privileges. Thus, a successful «trojan horse» attack on a privileged process defeats all security provisions. Therefore, POSIX.1 allows more granular privilege mechanisms to be defined. For many historical implementations of the UNIX system, the presence of the term «appropriate privileges» in POSIX.1 may be understood as a synonym for «superuser» (UID 0). However, other systems have emerged where this is not the case and each discrete controllable action has appropriate privileges associated with it. Because this mechanism is implementation-defined, it must be described in the conformance document. Although that description affects several parts of POSIX.1 where the term «appropriate privilege» is used, because the term «implementation-defined» only appears here, the description of the entire mechanism and its effects on these other sections belongs in this equivalent section of the conformance document. This is especially convenient for implementations with a single mechanism that applies in all areas, since it only needs to be described once.
Вот как то так. Безопасность в POSIX — implementation defined, что уже на много порядков лучше «классической юникс безопасности». ACL-ов в POSIX никогда не было (мы же не будем считать отозванный 15 лет назад ЧЕРНОВИК настоящим стандартом?).
Message-oriented каналы тоже есть
Те, которые pipe() или те которые socketpair()? Если присмотреться, я говорил именно о пайпах.
kqueue использует тот же принцип, что и IOCP. Какие там подробности реализации — уже неважно — огрехи реализации легко исправимы (даже если таковые имеются), огрехи дизайна — нет. epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом.
А как на виндузе передать хэндл в другой процесс? Про DuplicateHandleEx знаю, но это решение на порядки хуже.Потрудитесь показать, чем же хуже.
Ну хотя бы тем, что у процесса, в которого дуплицируется хендл, нет никакого контроля над тем, что в него дуплицирует. Примерная аналогия — два процесса могут общаться через пайп; а могут путем прямой записи в адресное пространство друг друга. Так вот DuplicateHandle — это второе. А если нам нужно получить хендл из непривилегированного процесса?
Для сравнения, при пересылке дескрипторов через UNIX-сокет, дескриптор не появится в целевом процессе до тех пор, пока процесс не извлечет из сокета сообщение, в котором пересылались дескрипторы. При чем если он это сделает при помощи API, не поддерживающего ancillary данные, дескрипторы тут же автоматически закроются.
Вот как то так. Безопасность в POSIX — implementation defined, что уже на много порядков лучше «классической юникс безопасности».
Цитата вобще ни о чем. Всякие сервисы, торчащие в сеть, работают не от рута (собственно как и на винде). Механизмы контроля доступа к объектам ОС — присутствуют. Да на винде права более детализированы, и что? Приведите пример когда не достаточно rwx битов для user, group, other?
Message-oriented каналы тоже естьТе, которые pipe() или те которые socketpair()? Если присмотреться, я говорил именно о пайпах.
Речь про сокеты. Какая разница? Вам шашечки или ехать?
kqueue использует тот же принцип, что и IOCP. Какие там подробности реализации — уже неважно — огрехи реализации легко исправимы (даже если таковые имеются), огрехи дизайна — нет. epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом.
Вы сами себе противоречите. С одной стороны, по вашим словам, kqueue и IOCP используют один и тот же принцип (видимо мультиплексирование нотификаций из множества источников через один ядерный объект). С другой стороны epoll якобы хуже. Отмечу однако, что epoll использует тот же самый принцип, если я вас понял правильно на счет принципа :)
Кстати на MacOS kqueue не поддерживает AIO в принципе. На FreeBSD, не уверен что AIO может работать с чем-то помимо файлов.
Я, честно говоря ожидал, что вы будете сравнивать AIO vs. non-blocking IO. Мое ИМХО — нет никакой принципиальной разницы. При желании, можно изобразить AIO в юзерспейсе через тредпул, и разбирать нотификации в том же epoll/kqueue.
Ответил выше. fork помимо проблем с семантикой, просто тупо дороже.А CreateProcess связывается по LPC с Win-подсистемой, а там внутри неонка :) Я уверен что fork не копирует структуру страниц «в лоб». Например при отображении разделяемой памяти есть опции отложенной модификации таблицы страниц, здесь я думаю используется что-то подобное (таблица она же иерархическая, все ветки можно сразу не заполнять).
Кстати, какие вы видите проблемы в сочетании fork+треды?
Как вы кстати оцениваете концепцию имперсонации в windows?
Ну хотя бы тем, что у процесса, в которого дуплицируется хендл, нет никакого контроля над тем, что в него дуплицирует.
Неправда.
hTargetProcessHandle [in]
A handle to the process that is to receive the duplicated handle. The handle must have the PROCESS_DUP_HANDLE access right.
Все контроллируется теми же средствами, что и весь остальной доступ в системе.
Примерная аналогия — два процесса могут общаться через пайп; а могут путем прямой записи в адресное пространство друг друга. Так вот DuplicateHandle — это второе. А если нам нужно получить хендл из непривилегированного процесса?
Еще раз: весь доступ контроллируется Security Reference Monitor-ом. Если непривелигированному процессу нужно дублировать хендлы в процесс, который не получается открыть самостоятельно, хендл этого процесса с PROCESS_DUP_HANDLE можно получить и из других источников.
Цитата вобще ни о чем.
Цитата о том, что сам POSIX говорит о том, что вопросы безопасности стандарта не касаются.
Повторюсь:
Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Речь про сокеты. Какая разница? Вам шашечки или ехать?
Перечитайте еще раз контекст. Изначально речь шла о пайпах.
Кстати на MacOS kqueue не поддерживает AIO в принципе. На FreeBSD, не уверен что AIO может работать с чем-то помимо файлов.
Спасибо, что поправили — признаться честно, не знал. Хотя могу поклясться, что точно читал про асинхронный ввод/вывод с kqueue: может я ошибаюсь, а может и автор той статьи — найти ее сейчас не представляется возможным, так что готов принять позицию, что kqueue настолько же плох, насколько и epoll.
Я, честно говоря ожидал, что вы будете сравнивать AIO vs. non-blocking IO.
Именно это я и сделал для epoll. И да, принципиальная разница есть, по крайней мере при высоких нагрузках (а зачем еще возиться с epoll/kqueue или IOCP).
таблица она же иерархическая, все ветки можно сразу не заполнять
У иерархии всего два уровня. Зависимость от размера рабочего набора родительского процесса все равно линейная.
Кстати, какие вы видите проблемы в сочетании fork+треды?
А Вы почитайте вот прямо сам SUS, разделы fork, pthread_atfork (ссылки я уже приводил), там все рассматривается.
Как вы кстати оцениваете концепцию имперсонации в windows?
А давайте Вы мне не будете экзамен устраивать. Тем более по «концепциям». Не знаю, что Вы хотите услышать. Поэтому вот Вам такой же расплывчатый ответ: имперсонация имеет области применимости (исполнение доверенного кода с модифицированными правами: чаще всего сервер имперсонирует клиента и исполняет СВОЙ код). Внутри своей области применимости — это отличный механизм, за пределами — иногда может быть с успехом использован (как например в хромовой песочнице для винды), но чаще всего использовать ЛЮБОЙ механизм за пределами области применимости — ОЧЕНЬ плохая идея.
Вы так не нервничайте пожалуйста. Винда ваша не идеальная система, и уж точно не лучше всего на свете, примиритесь с этим.
У меня ощущение, что вы меня не слушаете. Естественно, по умолчанию доступа к процессу ни у кого нет. Как только вы наделили кого-то такими правами — тушите свет. Вам могут сдуплицировать 1 хендл или 1000 или 100000, вы этот процесс уже не можете контролировать. Как в моей аналогии с межпроцесным взаимодействием через прямую запись в адресное пространство друг друга — и так можно, но есть куда более безопасные и контролируемые способы.
Использование DuplicateHandle для обмена хендлами требует полного доверия. Еще такой интересный момент — процесс А дублирует хендл в процесс Б и затем передает полученное значение в Б через какой-то IPC. Как Б может убедиться, что это хендл, открытый процессом А, а не его собственный, или принадлежащий другому клиенту?
Вы как-то странно понимаете термин безопасность. По факту — она есть. Механизмы контроля доступа к объктам ОС точно описаны позиксом. База данных учетных записей и методы аутентификации действительно позиксом не описываются. На это есть отдельные стандарты, см. PAM, SASL и GSS. Вещи вроде SELinux тоже не входят в базовый стандарт, по понятным причинам.
Такого, чтобы все было в одном месте как в MSDN + примеры годные для копипасты, для *NIX нет. Можете считать это фатальным недостатком, если угодно :)
Короче вам асинхронный ввод-вывод подавай, иначе не православно :) Еще раз подчеркну свою позицию — суть механизма IOCP/kqueue/epoll — в предоставлении единственной точки, через которую доставляется поток нотификаций из разных источников. В частности это можно использовать для AIO нотификаций, но это уже частности.
Kqueue поддерживает AIO прямо на уровне интерфейса, по крайней мере теоретически. Epoll также легко может быть расширен для поддержки AIO без изменения интерфейса (см. например как это сделано для сигналов).
Ваши собственные слова. Вот видите — реализацию можно и пофиксить. А тезис об ущербности epoll опровергнут выше.
Пруф или не было.
(Переходим к обсуждению fork, а именно предполагаемых накладных расходов на работу с адресным пространством.) Сами страницы можно за третий уровень посчитать. Кстати стандартом предусмотрена функция posix_spawn(), которая работает как fork+exec и может быть реализована отдельным системным вызовом.
Я их наизусть знаю. Так какие «проблемы» вы видите?
Просто мне идея имперсонации кажется плохим техническим решением. Но по этому вопросу я себя экспертом не считаю, вот и спрашиваю вашего мнения.
Ну хотя бы тем, что у процесса, в которого дуплицируется хендл, нет никакого контроля над тем, что в него дуплицирует.Неправда.
hTargetProcessHandle [in]
A handle to the process that is to receive the duplicated handle. The handle must have the PROCESS_DUP_HANDLE access right.
Все контроллируется теми же средствами, что и весь остальной доступ в системе.
У меня ощущение, что вы меня не слушаете. Естественно, по умолчанию доступа к процессу ни у кого нет. Как только вы наделили кого-то такими правами — тушите свет. Вам могут сдуплицировать 1 хендл или 1000 или 100000, вы этот процесс уже не можете контролировать. Как в моей аналогии с межпроцесным взаимодействием через прямую запись в адресное пространство друг друга — и так можно, но есть куда более безопасные и контролируемые способы.
Использование DuplicateHandle для обмена хендлами требует полного доверия. Еще такой интересный момент — процесс А дублирует хендл в процесс Б и затем передает полученное значение в Б через какой-то IPC. Как Б может убедиться, что это хендл, открытый процессом А, а не его собственный, или принадлежащий другому клиенту?
Цитата о том, что сам POSIX говорит о том, что вопросы безопасности стандарта не касаются.
Вы как-то странно понимаете термин безопасность. По факту — она есть. Механизмы контроля доступа к объктам ОС точно описаны позиксом. База данных учетных записей и методы аутентификации действительно позиксом не описываются. На это есть отдельные стандарты, см. PAM, SASL и GSS. Вещи вроде SELinux тоже не входят в базовый стандарт, по понятным причинам.
Такого, чтобы все было в одном месте как в MSDN + примеры годные для копипасты, для *NIX нет. Можете считать это фатальным недостатком, если угодно :)
Перечитайте еще раз контекст. Изначально речь шла о пайпах.Напомню что речь шла о том что в винде пайпы имеют режим с сохранением границ сообщений, а Linux — нет. Так вот я никак не пойму, как можно создать анонимный пайп с сохранением границ сообщений. А именованные пайпы надо с локальными сокетами сравнивать.
Хотя могу поклясться, что точно читал про асинхронный ввод/вывод с kqueue: может я ошибаюсь, а может и автор той статьи — найти ее сейчас не представляется возможным, так что готов принять позицию, что kqueue настолько же плох, насколько и epoll.
Короче вам асинхронный ввод-вывод подавай, иначе не православно :) Еще раз подчеркну свою позицию — суть механизма IOCP/kqueue/epoll — в предоставлении единственной точки, через которую доставляется поток нотификаций из разных источников. В частности это можно использовать для AIO нотификаций, но это уже частности.
Kqueue поддерживает AIO прямо на уровне интерфейса, по крайней мере теоретически. Epoll также легко может быть расширен для поддержки AIO без изменения интерфейса (см. например как это сделано для сигналов).
Какие там подробности реализации — уже неважно — огрехи реализации легко исправимы (даже если таковые имеются), огрехи дизайна — нет. epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом.
Ваши собственные слова. Вот видите — реализацию можно и пофиксить. А тезис об ущербности epoll опровергнут выше.
Я, честно говоря ожидал, что вы будете сравнивать AIO vs. non-blocking IO.Именно это я и сделал для epoll. И да, принципиальная разница есть, по крайней мере при высоких нагрузках (а зачем еще возиться с epoll/kqueue или IOCP).
Пруф или не было.
таблица она же иерархическая, все ветки можно сразу не заполнятьУ иерархии всего два уровня. Зависимость от размера рабочего набора родительского процесса все равно линейная.
(Переходим к обсуждению fork, а именно предполагаемых накладных расходов на работу с адресным пространством.) Сами страницы можно за третий уровень посчитать. Кстати стандартом предусмотрена функция posix_spawn(), которая работает как fork+exec и может быть реализована отдельным системным вызовом.
Кстати, какие вы видите проблемы в сочетании fork+треды?А Вы почитайте вот прямо сам SUS, разделы fork, pthread_atfork (ссылки я уже приводил), там все рассматривается.
Я их наизусть знаю. Так какие «проблемы» вы видите?
Как вы кстати оцениваете концепцию имперсонации в windows?А давайте Вы мне не будете экзамен устраивать. Тем более по «концепциям».
Просто мне идея имперсонации кажется плохим техническим решением. Но по этому вопросу я себя экспертом не считаю, вот и спрашиваю вашего мнения.
Вы так не нервничайте пожалуйста. Винда ваша не идеальная система, и уж точно не лучше всего на свете, примиритесь с этим.
Я абсолютно спокоен. Более того, это один из нечастых случаев, когда вместо обсуждения моей матушки завязалась техническая дискуссия (хотя и были попытки в духе «вы их этих» и «застрял в прошлом веке»). Я могу ошибаться (все могут), я могу не суметь донести свою точку зрения, но само наличие такой дискуссии — огромный плюс. Что же до идеальности. У меня вот есть тяга к микроядрам с capability-based безопасностью. Ничего не могу с собой поделать. NT не является ни тем ни другим (хотя по многим пунктам достаточно близко — особенно секьюрити), так что нет — не идеально даже ядро, а уж про юзермод (и особенно про Win32 как прямого наследника Win16) я и сам порассказать могу. Моя позиция касательно конкретно данного поста в том, что NT ЗНАЧИТЕЛЬНО лучше Linux в плане дизайна.
Вам могут сдуплицировать 1 хендл или 1000 или 100000, вы этот процесс уже не можете контролировать
...
Ну, ок. Для предметного разговора мне нужна модель угрозы. Покажите, пожалуйста, конкретный пример ситуации, когда процесс, наделенный правами станет эти права абьюзить (не из-за бага — которых может быть полно и в любом другом месте, а именно как угрозу). Отмечу лишь, что sendmsg/recvmsg легко реализуется на основе NtDuplicateHandle при помощи доверенного брокера (если это ДЕЙСТВИТЕЛЬНО понадобится, что само по себе еще не доказано), а вот реализовать NtDuplicateHandle на основе сокетов — не получится (как пример: как мне восстановить связь с клиентами после рестарта демона). Ну или уже приведенный пример seccomp sandbox. При этом на момент написания данного сендбокса Windows версия уже давно существовала и не требовала написания кода без использования памяти (даже стека). Вообще идея запуска двух потоков с разным уровнем доверия в одном процессе кажется мне несколько, как бы это сказать… неочевидной, что ли.
О полном доверии речи не идет — лишь о доверии, необходимом для дублирования хендлов. Не доверяешь процессу — ставь брокера. Вот только чаще всего хендлы открываются процессом с более высокими привилегиями и копируются в процесс с более низкими (см, например, инфраструктуру брокеров в win8 или опять же песочницы Хрома/ИЕ).
Вы как-то странно понимаете термин безопасность. По факту — она есть.
В POSIX она «implementation defined». Даже для файлов, где chmod сотоварищи пришлось оставить (посмотрите так же всякие open/fopen и прочие — попробуйте найти хоть какое то упоминание того, что конкретно может привести к EACCES), не говоря уже о kill и прочих штуках традиционно требовавших рута (и целого букета дополнительных ad-hoc правил, позволяющих обойти ограниченность классической модели безопасности).
Так вот я никак не пойму, как можно создать анонимный пайп с сохранением границ сообщений. А именованные пайпы надо с локальными сокетами сравнивать.
Ок. Вот только это Win32 вызов (к некоторым частям которого я имею немало претензий). И именованные и анонимные пайпы сводятся к NtCreateNamedPipeFile, который позволяет указать режим.
Короче вам асинхронный ввод-вывод подавай, иначе не православно :)
Да, именно так :-)
Ваши собственные слова. Вот видите — реализацию можно и пофиксить. А тезис об ущербности epoll опровергнут выше.
В целом вынужден согласиться. epoll в будущем вполне можно будет использовать для ожидания окончания асинхронных операций. Причем в рамках текущего интерфейса — не прибегая к костылям типа signalfd сотоварищи. Кстати, насчет kqueue, официальная документация прямо и непосредственно упоминает AIO. Кроме того, поверхностный поиск вернул множество результатов с таким контекстом использования. Так что похоже kqueue все-таки получше epoll прямо сейчас.
Пруф или не было.
Очередная самоцитата:
epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом
И да, я уже согласился, что epoll «в принципе» может быть использован. В данном случае я самоцитируюсь для того, чтобы показать, что моя претензия к epoll изначально заключалась в отсутсвии поддержки асинхронного I/O.
Кстати стандартом предусмотрена функция posix_spawn(), которая работает как fork+exec и может быть реализована отдельным системным вызовом
Так а кто ж спорит. posix_spawn и pthread_create — то что должно было использоваться изначально. Речь о том, что проблемы у fork-а (причем опять же, не я начал это сравнение), а не о том, что ничего другого нет.
Я их наизусть знаю. Так какие «проблемы» вы видите?
Проблема в том, что fork предполагает исключительно однопоточный контекст (при этом «поток» является одновременно и «процессом» — контейнером ресурсов). «Разветвление» потока исполнения автоматически приводит к «разветвлению» ресурсов, что уже требует всяких хитростей в случае эксклюзивного владения. Введение POSIX thread-ов запутало ситуацию еще больше. pthread_atfork — попытка решения проблемы и, соответственно, признание ее существования.
Просто мне идея имперсонации кажется плохим техническим решением. Но по этому вопросу я себя экспертом не считаю, вот и спрашиваю вашего мнения.
Не знаю откуда у Вас такое впечатление. Может Вы просто не совсем правильно понимаете призвание имперсонации. Это не механизм защиты (например, понижения привилегий для исполнения недоверенного кода), это механизм, облегчающий написание сервера: вместо того, чтобы самостоятельно сверять токен с дескриптором безопасности перед каждой операцией, эта работа возлагается на ОС: «пока не попрошу обратного сверяй весь доступ из этого потока с вот этим вот токеном, потому что мне лень делать это самостоятельно». То есть он позволяет сэкономить на вызовах Get(Named)SecurityInfo/AccessCheck и больше ничего (при этом делая код более надежным исключая человеческий фактор).
Вам могут сдуплицировать 1 хендл или 1000 или 100000, вы этот процесс уже не можете контролироватьНу, ок. Для предметного разговора мне нужна модель угрозы.
А ограничений на количество открытых хендлов на процесс вобще нет? Можно пооткрывать файлов в эксклюзивном режиме и закинуть их хендлы в другой процесс, в результате все «шишки» достанутся жертве. Но самая главная проблема, которую я вижу — нет механизма, подтверждающего что клиент в самом деле сдуплицировал хендл, а не передал отфанарное значение. Насколько непредсказуемые значения получают новые хендлы, есть ли там аналог ASLR? Я бы попытался угадать хендл другого клиента или вынудить процесс закрыть какой-нибудь критичный LPC порт (в предположении, что полученный от клиента хендл рано или поздно будет закрыт).
Отмечу лишь, что sendmsg/recvmsg легко реализуется на основе NtDuplicateHandle при помощи доверенного брокера (если это ДЕЙСТВИТЕЛЬНО понадобится, что само по себе еще не доказано), а вот
Принимается. Кстати считаю это очередным подтверждением моего тезиса о том, что не так уж и важно, насколько ОС замечательная сама по себе; многие проблемы могут быть решены в юзерспейсе при наличие адекватной базы со стороны ОС.
реализовать NtDuplicateHandle на основе сокетов — не получится (как пример: как мне восстановить связь с клиентами после рестарта демона).
Не понял кейс с рестартом демона. Клиенты сами переподключаются при обрыве соединения.
Вы как-то странно понимаете термин безопасность. По факту — она есть.В POSIX она «implementation defined». Даже для файлов, где chmod сотоварищи пришлось оставить (посмотрите так же всякие open/fopen и прочие — попробуйте найти хоть какое то упоминание того, что конкретно может привести к EACCES), не говоря уже о kill и прочих штуках традиционно требовавших рута (и целого букета дополнительных ad-hoc правил, позволяющих обойти ограниченность классической модели безопасности).
Ок, в классической модели не получится выдать права на посылку сигналов процессу, формально это ограничение. Вот только зачем это может потребоваться на практике, ума не приложу.
Так вот я никак не пойму, как можно создать анонимный пайп с сохранением границ сообщений. А именованные пайпы надо с локальными сокетами сравнивать.Ок. Вот только это Win32 вызов (к некоторым частям которого я имею немало претензий). И именованные и анонимные пайпы сводятся к NtCreateNamedPipeFile, который позволяет указать режим.
AFAIK неименованные пайпы сделаны из именованных under the hood. И я все меньше понимаю предмет дискуссии, честно говоря. На UNIX можно получить message-oriented дуплексный канал на основе UNIX сокетов. Какая разница, что внутри, если функционал такой же?
Ваши собственные слова. Вот видите — реализацию можно и пофиксить. А тезис об ущербности epoll опровергнут выше.В целом вынужден согласиться. epoll в будущем вполне можно будет использовать для ожидания окончания асинхронных операций. Причем в рамках текущего интерфейса — не прибегая к костылям типа signalfd сотоварищи.
Не считаю signalfd костылем. Файловый дескриптор — это все равно, что хендл в windows. С готовой инфраструктурой для управлением временем жизни, с механизмом передачи в другие процессы и ип. Логично для управления новыми классами объектов тоже использовать дескрипторы, даже если формально это не файлы.
А еще у дескрипторов есть огромное преимущество — epoll принимает именно дескрипторы, и позволяет ждать события на одном из множества дескрипторов. Таким образом, если мы используем дескриптор для нового класса объектов, мы получаем халявный механизм для асинхронных нотификаций. Обратите внимание — kqueue позволяет подписаться на нотификации при получении сигнала непосредственно на уровне интерфейса (EVFILT_SIGNAL). Epoll принимает исключительно дескрипторы, ожидание сигнала можно реализовать при помощи signalfd.
Точно также для AIO нотификаций можно реализовать гипотетический aiofd и мониторить его при помощи epoll.
Очередная самоцитата:Пруф или не было.Я, честно говоря ожидал, что вы будете сравнивать AIO vs. non-blocking IO.Именно это я и сделал для epoll. И да, принципиальная разница есть, по крайней мере при высоких нагрузках (а зачем еще возиться с epoll/kqueue или IOCP).
epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом
Так откуда берется принципиальная разница между AIO и non-blocking IO при высоких нагрузках?
Проблема в том, что fork предполагает исключительно однопоточный контекст (при этом «поток» является одновременно и «процессом» — контейнером ресурсов). «Разветвление» потока исполнения автоматически приводит к «разветвлению» ресурсов, что уже требует всяких хитростей в случае эксклюзивного владения. Введение POSIX thread-ов запутало ситуацию еще больше. pthread_atfork — попытка решения проблемы и, соответственно, признание ее существования.
А много вы знаете объектов в UNIX с эксклюзивынм владением? Мне кажется что все сложности успешно разрешены в рамках текущего стандарта.
Просто мне идея имперсонации кажется плохим техническим решением. Но по этому вопросу я себя экспертом не считаю, вот и спрашиваю вашего мнения.Не знаю откуда у Вас такое впечатление. Может Вы просто не совсем правильно понимаете призвание имперсонации. Это не механизм защиты (например, понижения привилегий для исполнения недоверенного кода), это механизм, облегчающий написание сервера: вместо того, чтобы самостоятельно сверять токен с дескриптором безопасности перед каждой операцией, эта работа возлагается на ОС: «пока не попрошу обратного сверяй весь доступ из этого потока с вот этим вот токеном, потому что мне лень делать это самостоятельно». То есть он позволяет сэкономить на вызовах Get(Named)SecurityInfo/AccessCheck и больше ничего (при этом делая код более надежным исключая человеческий фактор).
Вообще идея запуска двух потоков с разным уровнем доверия в одном процессе кажется мне несколько, как бы это сказать… неочевидной, что ли.
Ну вот именно поэтому у меня идея имперсонации вызывает подозрения. А на счет человеческого фактора вы не правы AFAIK — насколько я помню, нужно приложить определенные усилия для того, чтобы не было имперсонации при обычном вызове CreateFile (если вместо файла нам подсунули пайп, на другом конце которого сидит злоумышленник).
Можно пооткрывать файлов в эксклюзивном режиме и закинуть их хендлы в другой процесс, в результате все «шишки» достанутся жертве.
То есть процесс, наделенный полномочиями, может аьюзить свои полномочия? Ну да, точно то же самое можно сделать ptrace-ом (ну не считая того, что я вообще считаю идею суперпользователя глупой — одна из немногих вещей, в которых я полностью согласен с POSIX). Рандомизации хендлов вроде нет, но опять таки, хотелось бы увидеть реалистичную атаку. Если действительно очень нужно, чтобы на этом уровне доверия действовала система — ну так и сделайте брокер, который бегает от имени системы (или вообще отдельного пользователя/группы) и всем остальным запретите доступ к своему процессу.
Принимается. Кстати считаю это очередным подтверждением моего тезиса о том, что не так уж и важно, насколько ОС замечательная сама по себе
Вот только юзермод винды мне тоже нравится гораздо больше, чем юзермод линукса. Вот начиная прямо с юзермода, описанного в POSIX — шелл скриптинг. Поскорей бы он помер — есть же куча нормальных скриптовых языков. Еще я люблю COM (и в частности насколько широко он применяется в винде) — я вообще предпочитаю структурированные интерфейсы (в том числе объектно-ориентированное ABI) неструктурированным (в частности CLI-как-API или до некоторой степени даже Plain C API). И даже если взять те же IOCP — уж как его изуродовали по пути из ядра (и Native API) в Win32, а все ж таки это IOCP и он ВСЕ ЕЩЕ лучше текущего положения дел с epoll (не говоря уже о положении дел в POSIX в целом).
Не понял кейс с рестартом демона. Клиенты сами переподключаются при обрыве соединения.
У меня сейчас ощущение, что я чего то недопонимаю, но разве юникс-сокеты не анонимные? А именованные fifo объекты разве умеют в фреймы и обмен дескрипторами? Мне аж интересно стало, как можно переподключиться.
AFAIK неименованные пайпы сделаны из именованных under the hood.
Все правильно, CreatePipe открывает \Device\NamedPipe\ (корневой каталог NPFS), а потом открывает второй конец «относительным» открытием уже имеющегося хендла.
Какая разница, что внутри, если функционал такой же?
Ну, честно говоря я тоже удивился, когда в недостатки винды записали отсутствие unix domain сокетов, но по мере обсуждения даже интересно стало — функционал все таки разный. Пайпы можно именовать, а сокеты — фреймить и кидаться дескрипторами.
Не считаю signalfd костылем. Файловый дескриптор — это все равно, что хендл в windows.
Он был бы аналогом хендла, если бы была хоть какая то типизация. А так open/read/write/close для всех — для всего остального «неструктурированный» ioctl. Ну не всем объектам годится семантика файлов. Ну хоть ты тресни. В частности, сигнальные, таймерные и событийные дескрипторы накладывают такие странные ограничения на «файлы», что по сути уже и не являются файлами. Кстати, даже «как бы файлы» в sysfs тоже фактически делают любую промежуточную буферизацию семантически некорректной. Например для одного и тоже файла и одних и тех же данных fopen/fwrite может сработать, в то время как open/write — нет.
Так откуда берется принципиальная разница между AIO и non-blocking IO при высоких нагрузках?
Неблокирующий доступ требует больше раундтрипов в ядро и больше промежуточной буферизации. Чем неизбежно увеличивает задержки (latency) при обработке данных. Более того, эти задержки ВСЕГДА находятся на критическом пути, что неизбежно ведет еще и к снижению пропускной способности. Если интересно, рекомендую посмотреть доклад о registered IO, в котором обсуждаются проблемы обычных IOCP (да, с современными скоростями сетевых соединений уже даже IOCP оказываются узким местом, не говоря уже о non-blocking IO).
А много вы знаете объектов в UNIX с эксклюзивынм владением? Мне кажется что все сложности успешно разрешены в рамках текущего стандарта.
Взять те же mandatory lock-и на файлы — уж сколько лет продолжались попытки сделать вид, что они как бы и не нужны, а жизнь (и Big Data) все равно берет свое — нужны они. Да, для fork-ов придумываются всяческие workaround-ы, чтоб с этими проблемами хотя бы можно было жить, но существование этих обходных путей не отменяет факта несовместимости fork-а с экслюзивным владением ресурсами.
Забавным образом, в том же линуксе игнорирование семантики блокирования файлов привело к появлению «необновляющих обновлений» — по своему гениальное изобретение.
Ну вот именно поэтому у меня идея имперсонации вызывает подозрения.
Так у всех потоков уровень доверия один. Имперсонирован он или нет — один вызов RevertToSelf позволяет развеять все сомнения насчет возможности использования имперсонирования для безопасного исполнения недоверенного кода. А вот seccomp sandbox весь построен на совмещении потоков с разным доверием в одном адресном пространстве.
А на счет человеческого фактора вы не правы AFAIK — насколько я помню, нужно приложить определенные усилия для того, чтобы не было имперсонации при обычном вызове CreateFile
Хороший пример имперсонирования, это, например UMDF драйвер, которому требуется открыть файл. Он не хочет заниматься самостоятельной возней с проверкой прав поэтому просто говорит системе: «Слушай, я тут обрабатываю запрос от какого-то пользователя, открой мне вот этот файл с ЕГО правами». После чего продолжает работу с полученным хендлом уже со своими правами — все проверки уже сделаны в момент открытия. Та же история с OutOfProc (или даже DCOM) COM серверами. Вот крутится себе WMI провайдер с правами системы и вдруг его по RPC дергает пользователь. WMI провайдер имперсонирует клиента и исполняет СВОЙ код, после чего немедленно возвращается к собственному основному токену. Никогда и ни при каких условиях нельзя использовать имперсонацию для «защиты» от недоверенного кода.
> случаев, когда вместо обсуждения моей матушки завязалась техническая дискуссия
действительно, очень интересное обсуждение вышло, в отличие от бесконечных holywar`ов
> так что нет — не идеально даже ядро, а уж про юзермод (и особенно про Win32 как прямого наследника Win16) я и сам порассказать могу.
вот, кстати, ядро делали очень талантливые люди, это факт, это наследие dec/vms. что не нравится-winapi, то что много лишнего в ядро запихнули ради скорости(графику, куски iis).
по поводу микроядер-а они где-нибудь на практике используются сейчас? вот, в apple, хотели, взяли mach, но в итоге оно «разжирело» до обычного гибридного ядра
действительно, очень интересное обсуждение вышло, в отличие от бесконечных holywar`ов
> так что нет — не идеально даже ядро, а уж про юзермод (и особенно про Win32 как прямого наследника Win16) я и сам порассказать могу.
вот, кстати, ядро делали очень талантливые люди, это факт, это наследие dec/vms. что не нравится-winapi, то что много лишнего в ядро запихнули ради скорости(графику, куски iis).
по поводу микроядер-а они где-нибудь на практике используются сейчас? вот, в apple, хотели, взяли mach, но в итоге оно «разжирело» до обычного гибридного ядра
«На практике» микроядра, похоже, заходят с «черного хода». Ну во всяком случае именно такое у меня ощущение, когда я вижу внедрение систем виртуализации не только в серверные, но и в клиентские версии ОС (OSX пока «тормозит» — не знаю надолго ли). По очень многим параметрам гипервизоры похожи на микроядра, а гостевые ОС — на сервисные «процессы».
вы так интересно прыгаете с linux на posix, выше говорилось про linux и acl там. да и в других юникс-подобных ос такие механизмы есть и это не мешает быть им совместимыми с posix
А я ли «прыгаю». Повторю еще раз:
Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
> Я честно говоря затрудняюсь вспомнить вообще хоть одну вещь, которая в Linux-е сделана лучше чем в NT.
почему тогда unix-подобные ос существуют десятилетиями и только плодятся и у них столько поклонников среди программистов? а на основе vms/nt разве что reactos?
даже ibm похоронила os/2 свою, но вкладывается в aix и linux.
все дураки?
почему тогда unix-подобные ос существуют десятилетиями и только плодятся и у них столько поклонников среди программистов? а на основе vms/nt разве что reactos?
даже ibm похоронила os/2 свою, но вкладывается в aix и linux.
все дураки?
Ну справедливости ради просто MS отгородились от всего мира стеной с колючей проволкой и оказались в итоге ни с чем не совместимы кроме себя самих. Вот у меня и у многих просто нет желания шагать строем и копать от забора до обеда.
Многие идеи, воплощенные в VMS и позже NT существовали еще в MULTICS и при создании UNIX были просто напросто выброшены. Так что Вы уж определитесь с позицией: либо конкретные реализации живут с 70-х и юниксы тех времен те же, что сейчас, либо идеи живут и развиваются. Идеи, воплощенные в NT тоже не возникли на пустом месте и тоже постепенно переносятся в те же юниксы (взять хотя бы ту же модель безопасности: солярисы, BSD, XNU/OSX и прочие переняли NT-шное файловое подмножество ACL-ов один в один)
Ну и тем более, в MS практически ничего принципиально нового не придумали, но система у них закрытая и от всего остального мира отгороженная колючей проволкой. Проще взять и сделать очередную posix like систему, чем иметь дело с MS. Им бы по хорошему всю свою политику переделать в сторону открытости, тогда бы может мы и видели клоны NT в реальной жизни, а не в виртуалках, показываемые на презентациях.
а acl это впервые появились в nt? в википедии как-то мало вообще про это. мне кажется это появилось где-то в теории, а потом различные системы это реализовали
Кстати, прокомментируйте, пожалуйста, а то сам по вики смотрю.
ACL, реализованная в NT — это дискретный контроль (DAC), который был полностью описан в отозванном проекте POSIX 1.b/c, а сейчас реализован в большинстве *nix по POSIX 1.e (источник). В тоже время ACL в vista и win7 реализуются мандатами, как AppArmor в linux (MAC)
И раз уж речь о правах, то есть ли в ядрах win механизмы аналогичные SElinux, с возможностью гибкого описания политик? Верно ли утверждение, что реализация ACL в win построена на тех же функциях Бесселя, но с большими порядками?
ACL, реализованная в NT — это дискретный контроль (DAC), который был полностью описан в отозванном проекте POSIX 1.b/c, а сейчас реализован в большинстве *nix по POSIX 1.e (источник). В тоже время ACL в vista и win7 реализуются мандатами, как AppArmor в linux (MAC)
И раз уж речь о правах, то есть ли в ядрах win механизмы аналогичные SElinux, с возможностью гибкого описания политик? Верно ли утверждение, что реализация ACL в win построена на тех же функциях Бесселя, но с большими порядками?
Разделение DAC и MAC было введено в оранжевой книге (TCSEC) в 80-х годах. Причем был введен строго в контексте MLS (multilevel security). С тех пор каждый кому не лень пытался «доопределить» эти понятия. Наиболее близкое к изначальному и имеющее смысл заключается в том, что MAC в принципе не позволяет обычным пользователям задавать какой либо контроль для файлов: вся политика задается администратором безопасности (security officer). Например, даже если Вы создадите файл в своей домашней директории Вы не будете иметь права менять для него метку доступа.
TCSEC прямым текстом говорил (сейчас он уже давно устарел и замещен новым стандартом — т.н. «Common Criteria»), что вообще говоря права раздаются при помощи DACL, но «уровень допуска» — это уже парафия MAC. Что делать MAC (модель Белла-ЛаПадулы) на домашних компьютерах я, честно говоря, затрудняюсь представить. Гораздо полезнее MIC (Mandatory Integrity Control — модель Биба) — собственно она и является частью UAC. Для описания политик доступа субъектов к объектам более чем достаточно DACL-ов. Стоит отметить, что политики доступа к сети в NT определяются файрволом (Window Filtering Platform) в остальном же, я бы хотел увидеть пример политики SELinux, которую нельзя выразить при помощи ACL-ов.
Функции Бесселя — не имеют к безопасности вообще никакого отношения. Упомянул я их потому, что POSIX требует их реализации в интерфейсе ОПЕРАЦИОННОЙ СИСТЕМЫ, а вот какой либо реализации системы безопасности — не требует.
TCSEC прямым текстом говорил (сейчас он уже давно устарел и замещен новым стандартом — т.н. «Common Criteria»), что вообще говоря права раздаются при помощи DACL, но «уровень допуска» — это уже парафия MAC. Что делать MAC (модель Белла-ЛаПадулы) на домашних компьютерах я, честно говоря, затрудняюсь представить. Гораздо полезнее MIC (Mandatory Integrity Control — модель Биба) — собственно она и является частью UAC. Для описания политик доступа субъектов к объектам более чем достаточно DACL-ов. Стоит отметить, что политики доступа к сети в NT определяются файрволом (Window Filtering Platform) в остальном же, я бы хотел увидеть пример политики SELinux, которую нельзя выразить при помощи ACL-ов.
Функции Бесселя — не имеют к безопасности вообще никакого отношения. Упомянул я их потому, что POSIX требует их реализации в интерфейсе ОПЕРАЦИОННОЙ СИСТЕМЫ, а вот какой либо реализации системы безопасности — не требует.
Спасибо за справку.
Вы запутали немного. Почему MAC является моделью Белла-ЛаПадулы? Модель Биба это тоже MAC.
Про UAC, как-раз и речь (он же MIC) он попадает под определение MAC в чистом виде (справедливо для over vista). В XP UAC не было (собственно, из-за этого и совместимость между версиями плохая получилась).
Т.е. изменение модели секьюрности от XP к vista — это шаг аналогичный обязательной интеграции SElinux/AppArmor в linux и утверждению posix1.e…
Пример правил —при полной луне разрешить чтение для определённой группы При запуске процесса с использованием вывода на монитор запретить трансляцию в сеть определённым пользователям (по мотивам функциональности SElinux).
Про функции Бесселя — троль проснулся (так и не обнаружил ничего, кроме функций в math.h, но не третьего порядка).
Вы запутали немного. Почему MAC является моделью Белла-ЛаПадулы? Модель Биба это тоже MAC.
Про UAC, как-раз и речь (он же MIC) он попадает под определение MAC в чистом виде (справедливо для over vista). В XP UAC не было (собственно, из-за этого и совместимость между версиями плохая получилась).
Т.е. изменение модели секьюрности от XP к vista — это шаг аналогичный обязательной интеграции SElinux/AppArmor в linux и утверждению posix1.e…
Пример правил —
Про функции Бесселя — троль проснулся (так и не обнаружил ничего, кроме функций в math.h, но не третьего порядка).
Тут смотря что называть «появились». ACL-ы как таковые были уже как минимум в MULTICS. В «изначального» наследника MULTICS — VMS — они перекочевали и даже «похорошели», а ко времени NT они стали вообще почти «идеальными»: шутка ли — они вообще не претерпели концептуальных изменений за последние 20 лет (вот только в последние годы были «разбавлены» динамическим контролем доступа), хотя расширялись и дополнялись в рамках существующей модели практически в каждом релизе NT линейки.
UNIX же начал разрабатываться как ответ на «затянутую» разработку VMS (хотя обе системы вышли на рынок примерно одновременно, но с огромной разницей в качестве) и ACL-ы были оттуда исключены.
UNIX же начал разрабатываться как ответ на «затянутую» разработку VMS (хотя обе системы вышли на рынок примерно одновременно, но с огромной разницей в качестве) и ACL-ы были оттуда исключены.
Я работал со стандартами, обеспечивающими безопасность систему на уровне ядра и кода… В дальние дали это, на десктопах и серверах не упало ни каким боком! Для этого есть 1000 и 1 патч на ядро, соответствующий тому или иному промышленному стандарту.
Выбор ядра linux обосновывается: огромной распространённостью, большим выбором инструментария и подробной документированностью. Ни одно ядро на сегодня не сравниться по этим показателям с linux. Можете подойти к нему с любого бока и ковырять (собирайте-конфигурируйте, работайте с системными службами, пишите модули).
C mach бардак (лучше minix3), L4 ничего не умеет, миникс2 сдох (даже автор отсылает к linux), minix3 ещё пилится (недокументирован, код постоянно меняется), NT — не libre.
Не в обиду, но вы застряли в прошлом веке — и средствами, и инструментами, и мыслями... Что можно сегодня противопоставить gnu/linux и posix/sus и по каким критериям?
Выбор ядра linux обосновывается: огромной распространённостью, большим выбором инструментария и подробной документированностью. Ни одно ядро на сегодня не сравниться по этим показателям с linux. Можете подойти к нему с любого бока и ковырять (собирайте-конфигурируйте, работайте с системными службами, пишите модули).
C mach бардак (лучше minix3), L4 ничего не умеет, миникс2 сдох (даже автор отсылает к linux), minix3 ещё пилится (недокументирован, код постоянно меняется), NT — не libre.
Не в обиду, но вы застряли в прошлом веке — и средствами, и инструментами, и мыслями... Что можно сегодня противопоставить gnu/linux и posix/sus и по каким критериям?
Да что ж это такое.
С распространенностью я еще готов отчасти согласиться. Эмбед кругом и там частенько Линукс. В остальном — мимо. Инструментарий убог: для ядра — так вообще даже отладчика не было еще 5 лет назад — а все потому что Линус «не верит» в интерактивную отладку да и сейчас отладчик хромой и кривой. Статические/динамические анализаторы кода уровня driver verifier/static driver verifier? Да блин, автоматический поиск символов и чекаут соответствующих исходников есть хотя бы (symbol server/source server)?
Что же до подробной документированности, я давно ищу что-нибудь поновее этого. Да, я знаю о kernel-docs.txt и проблема как раз в том, что это лучший источник, который там приводится. И это не говоря уже о чем нибудь типа MSDN с подробными секциями описательными и референсными секциями.
Мдя, не в обиду, конечно, но именно ЛЮДИ, подобные Вам — основная проблема Линукса. Вы совершенно не знаете ничего ни о винде («средствах, инструментариях»), ни обо мне («мылях»), но при этом УВЕРЕНЫ, что противопоставить нечего.
С распространенностью я еще готов отчасти согласиться. Эмбед кругом и там частенько Линукс. В остальном — мимо. Инструментарий убог: для ядра — так вообще даже отладчика не было еще 5 лет назад — а все потому что Линус «не верит» в интерактивную отладку да и сейчас отладчик хромой и кривой. Статические/динамические анализаторы кода уровня driver verifier/static driver verifier? Да блин, автоматический поиск символов и чекаут соответствующих исходников есть хотя бы (symbol server/source server)?
Что же до подробной документированности, я давно ищу что-нибудь поновее этого. Да, я знаю о kernel-docs.txt и проблема как раз в том, что это лучший источник, который там приводится. И это не говоря уже о чем нибудь типа MSDN с подробными секциями описательными и референсными секциями.
Не в обиду, но вы застряли в прошлом веке — и средствами, и инструментами, и мыслями…
Мдя, не в обиду, конечно, но именно ЛЮДИ, подобные Вам — основная проблема Линукса. Вы совершенно не знаете ничего ни о винде («средствах, инструментариях»), ни обо мне («мылях»), но при этом УВЕРЕНЫ, что противопоставить нечего.
SystemTap для динамической работы есть с огромными подборками скриптов, он с 2005 выпускается. Линус не отвечает за подсистемы и их реализации; не язвите, пожалуйста. Для профилирования есть Valgrid… Да и в целом инструменты это и gnu toolchain, если мы ещё о gnu/linux, есть инструменты на шланг завязанные.
В целом, куча скриптов и вспомогательного ПО (например git).
Доки — и навигация в IDE, и google с кучей разжёвыванией, а не только офф. Да, msdn удобный, но исключительно для windows. И его удобство никак не влияет на его бесполезность. Функции с 10-20 аргументами, закрытая реализация и частое недокументирование — спасибо, обойдусь man-ом в консоли.
С момента расставания с win прошло 5 лет и что-то не заметил стабильного положения монополии win на рынке… Два раза работал с nt за это время и оба раза c XP/ce.
Да, в винде есть множество хороших решений, но речь идёт не о замере в выделенном направлении половых органов, а о курсе «ОС» в ВУЗе. Выше написал, что по критериям «пригодности к обучению» не вижу альтернативы linux. Если говорить о жизнеспособности винды, то у неё проблемы с динамикой разработки, а не качеством.
PS: Под «мыслями подразумевал написанное вами.»
В целом, куча скриптов и вспомогательного ПО (например git).
Доки — и навигация в IDE, и google с кучей разжёвыванией, а не только офф. Да, msdn удобный, но исключительно для windows. И его удобство никак не влияет на его бесполезность. Функции с 10-20 аргументами, закрытая реализация и частое недокументирование — спасибо, обойдусь man-ом в консоли.
С момента расставания с win прошло 5 лет и что-то не заметил стабильного положения монополии win на рынке… Два раза работал с nt за это время и оба раза c XP/ce.
Да, в винде есть множество хороших решений, но речь идёт не о замере в выделенном направлении половых органов, а о курсе «ОС» в ВУЗе. Выше написал, что по критериям «пригодности к обучению» не вижу альтернативы linux. Если говорить о жизнеспособности винды, то у неё проблемы с динамикой разработки, а не качеством.
PS: Под «мыслями подразумевал написанное вами.»
> Ни одно ядро на сегодня не сравниться по этим показателям с linux
а ещё списком поддерживаемых платформ, это тоже очень важный фактор. наверное на всех платформы, где linux может работать, он работает.
> C mach бардак
да оно тоже ничего не умеет и умерло. то что в macos-уже давно не mach ни разу.
> миникс2 сдох
оно изначально создавалось сознательно сильно урезанным, чисто для обучения
> Что можно сегодня противопоставить gnu/linux
solaris
а ещё списком поддерживаемых платформ, это тоже очень важный фактор. наверное на всех платформы, где linux может работать, он работает.
> C mach бардак
да оно тоже ничего не умеет и умерло. то что в macos-уже давно не mach ни разу.
> миникс2 сдох
оно изначально создавалось сознательно сильно урезанным, чисто для обучения
> Что можно сегодня противопоставить gnu/linux
solaris
Так а зачем ориентироваться на большинство? Надо ориентироваться на тех, на кого имеет смысл ориентироваться. К тому же всегда есть альтернативы: читать как курс по выбору (кому не надо — пойдут по более халявному пути), либо работать с тему, кому интересно, а кому неинтересно — сами не будут ходить, система же прекрасно саморегулируется.
Именно, иначе будет все печально и уныло как в романе «Атлант расправил плечи».
Тогда надо курс читать на уровне университета а не кафедры. То есть, чтобы любой учащийся любой кафедры мог на него записаться. Иначе придется читать курс для 5 человек — это неэффективно и дорого.
А для такой реализации у нас нет базы, т.к. не практикуется выбор курсов учащимся (то есть, не просто выбор курса как необязательного, а включение его в учебную программу)
Это, кстати, многое бы решило — по крайней мере, набирались бы аудитории заинтересованных в курсе.
А для такой реализации у нас нет базы, т.к. не практикуется выбор курсов учащимся (то есть, не просто выбор курса как необязательного, а включение его в учебную программу)
Это, кстати, многое бы решило — по крайней мере, набирались бы аудитории заинтересованных в курсе.
Не вижу принципиальный ограничений, дабы какой-то курс читался одновременно для тематических кафедрах как курс по выбору (а они есть), но аудитория была с запасом, дабы могли прийти все желающие (да и на пару в неделю кафедральную аудиторию тоже выделить реально, было бы желание).
А я вижу. В расписание «всех желающих» не включены часы для факультативных курсов. И деканату не важны ваши факультативы, они не входят в учебный план. Чтобы это стало частью образовательной программы, должна быть предусмотрена возможность выбора таких курсов а также аттестация по нему.
То есть выделить день и сказать «студент обязан выбрать N курсов для посещения и сдать в конце семестра по ним зачет наравне с остальными предметами». Тогда это будет работать эффективно.
То есть выделить день и сказать «студент обязан выбрать N курсов для посещения и сдать в конце семестра по ним зачет наравне с остальными предметами». Тогда это будет работать эффективно.
Тематические кафедры в теме, там это программа (курс по выбору), с аттестацией, а для студентов кафедры «Стартовые ракетные комплексы» в программе никаким боком не стоит ReactOS — они имеют право ходить как вольнослушатели, а иначе и никак. А есть в это время другие пары — ну не повезло, бывают в жизни огорчения, тут ничего не поделаешь.
>Тематические кафедры в теме, там это программа (курс по выбору), с аттестацией
Да ладно? Это в бауманке так теперь можно? А какие кафедры считаются тематическими?
Что-то я не верю что с нашими договорились, чтоб можно было этот курс взять.
Да ладно? Это в бауманке так теперь можно? А какие кафедры считаются тематическими?
Что-то я не верю что с нашими договорились, чтоб можно было этот курс взять.
Я про теорию (я написал в неверном настоящем времени то, что должно быть с частицей «бы»), если есть желание рассказывать как можно большему количеству людей. Тематические — где уже есть курсы сиспрога и проектирования ОС. Их зав.кафедры, скорее всего, положительно воспримут идею увеличить количество курсов по выбору, если текущий эксперимент с чтением на, как я понял, ИУ-9 окажется успешным. А если нет, то что уж говорить про расширение?
Я ходил в МГУ на курс по операционным системам. Нам рассказали много интересного не затронув никаких деталей (было показано ровно 0 строчек на си) строения конкретных операционных систем. Так что у них все может получится.
Теория без практики — очень плохо. Период полураспада знаний сильно падает.
Нужно совмещать теорию с практическими занятиями.
Нужно совмещать теорию с практическими занятиями.
В Бауманке нам считали курс по ОС на основе Линукс, плюс немного про винду. На практике были самые основы Линукса (команды cd, ps, cat, mv....). Лабы были также на Линуксе (какой-то embedded Linux). Были казусы и нестыковки когда в тексте написано перейти в такую-то директорию, а ее на лабораторном Линуксе не было.
З.Ы. я на втором высшем.
З.Ы. я на втором высшем.
По мне, лучше бы читали на основе Minix 3 — код ядра можно разобрать за семестр.
Уровень большинства студентов оставляет желать лучшего, боюсь, это неразумно
Я верю в людей. К тому же, это не «большинство», а одна из лучших ИТ кафедр, и если там у кого-то «уровень оставляет желать лучшего», то образовательный процесс для них уже завершён.
Завершен? Удивительно, тогда, наверное, тонны выпускников МГТУ с нулевыми знаниями получили диплом средствами шантажа и вымогательства.
Когда я учился (1999-2005) на ИУ-7, то я Вас уверяю: все выпускники нашей кафедры обладали очень серьёзным уровнем подготовки.
Вы говорите, наверное, о всяких СМ, МТ и прочих, но я к этому не имею никакого отношения, кроме того, что в 2006 проводил там семинары и лаб. работы по языку Си.
Вы говорите, наверное, о всяких СМ, МТ и прочих, но я к этому не имею никакого отношения, кроме того, что в 2006 проводил там семинары и лаб. работы по языку Си.
Нет, я говорю именно про ИУ, ИУ7 в частности. Есть выпускники с очень серьезным уровнем подготовки, но это больше исключения — те, кто сами на это нацелил и тратил бОльшую часть времени на самообразование. При этом, те кто не тратил совершенно спокойно выпустились. Да, процент отчисления большой, но те, кого отчислили это уже вообще отдельный разговор, я сейчас о тех, кто дошел до диплома.
Неужели ситуация так изменилась с 2000х?
Неужели ситуация так изменилась с 2000х?
А, ну про ИУ, тогда расскажу поподробней :)
После моего выпуска, ситуация там изменилась в худшую сторону. Что там конкретно сейчас происходит, я даже не знаю, и скорее всего даже знать не хочу. Но, вот относительно недавно познакомился с кафедрой ИУ-9, и что мне там понравилось: свой учебный план, где большой упор на всё то, что нужно конкретно разработчику программного обеспечения. Т.е. физики мало, химии нет вообще, теор. меха тоже. Зато есть куча дисциплин по специальности, и математическая подготовка сильная.
И всё это читают люди, которые являются специалистами в своих областях.
Поэтому и уровень подготовки студентов на этой кафедре на порядок выше.
После моего выпуска, ситуация там изменилась в худшую сторону. Что там конкретно сейчас происходит, я даже не знаю, и скорее всего даже знать не хочу. Но, вот относительно недавно познакомился с кафедрой ИУ-9, и что мне там понравилось: свой учебный план, где большой упор на всё то, что нужно конкретно разработчику программного обеспечения. Т.е. физики мало, химии нет вообще, теор. меха тоже. Зато есть куча дисциплин по специальности, и математическая подготовка сильная.
И всё это читают люди, которые являются специалистами в своих областях.
Поэтому и уровень подготовки студентов на этой кафедре на порядок выше.
Хочется верить. В самом деле хочется, чтобы бауманка не продолжала по инерции жить за счет «бренда», все больше разрушаясь изнутри, а действительно поддерживала свой статус.
А то я видел своими глазами этот адский порочный круг — когда с одной стороны засилье некомпетентных преподов, которые не могут и не хотят преподавать как следует, а с другой — тупых студентов, которые пришли отсидеться и вполне рады сдавать для отчетности какую-нибудь ересь, лишь бы вовремя, чтоб проставить предмет и забыть.
В результате проблемы появляются как у хороших преподавателей, так и у заинтересованных студентов.
Первых напрочь игнорит студенческий «балласт», проставляют оценки в обход, через завкафов, деканат, других преподов, жалуясь что «курс слишком трудный, мы ничего не понимаем, преподаватель плохо ведет» — в итоге препод, политый грязью, уходит из универа (лично это видел).
Вторые пытаются получить адекватные познания, тратят время на самообразование, в итоге имеют проблемы со старыми (и молодыми) маразматиками, которые часто просто намеренно начинают валить. При этом, человека уровнем на порядок выше, чем большинство студентов, отчисляют, а балласт, с липовыми чужими работами — пропускают. Это тоже лично видел.
Поэтому на всякий случай будьте готовы к пониженной посещаемости и попробуйте продвинуть идею об открытости лекций, вдруг получится. Может, это будет первый шаг к нормальному образованию у нас.
А то я видел своими глазами этот адский порочный круг — когда с одной стороны засилье некомпетентных преподов, которые не могут и не хотят преподавать как следует, а с другой — тупых студентов, которые пришли отсидеться и вполне рады сдавать для отчетности какую-нибудь ересь, лишь бы вовремя, чтоб проставить предмет и забыть.
В результате проблемы появляются как у хороших преподавателей, так и у заинтересованных студентов.
Первых напрочь игнорит студенческий «балласт», проставляют оценки в обход, через завкафов, деканат, других преподов, жалуясь что «курс слишком трудный, мы ничего не понимаем, преподаватель плохо ведет» — в итоге препод, политый грязью, уходит из универа (лично это видел).
Вторые пытаются получить адекватные познания, тратят время на самообразование, в итоге имеют проблемы со старыми (и молодыми) маразматиками, которые часто просто намеренно начинают валить. При этом, человека уровнем на порядок выше, чем большинство студентов, отчисляют, а балласт, с липовыми чужими работами — пропускают. Это тоже лично видел.
Поэтому на всякий случай будьте готовы к пониженной посещаемости и попробуйте продвинуть идею об открытости лекций, вдруг получится. Может, это будет первый шаг к нормальному образованию у нас.
А почему вы решили что там ситуация изменилась в худшую сторону, если вы не знаете, что там сейчас происходит? :) Физику насколько я понимаю на ИУ7 тоже сократили, химии тоже нет. Теор. мех есть не у всех (хотя может сейчас уже и нету).
Да, у нынешней «девятки» все очень неплохо.
Все, кто учился и самообразовывался неплохо устроились.
Вот последний пост о моей группе, например: iu9.info — там как раз кто и где сейчас.
Все, кто учился и самообразовывался неплохо устроились.
Вот последний пост о моей группе, например: iu9.info — там как раз кто и где сейчас.
Получить диплом технического университета, прослушав мало физики и никак термех и сопр — я этого не понимаю. За хорошей математической подготовкой добро пожаловать на ВМиК.
Вот у нас было много физики с огромным количеством сложных формул по квантовой механике, которые надо было обязательно выучить на экзамен. Ну прослушал я этот курс, сдал экзамен, при этом в голове из школьной программы и википедии я запомнил больше, чем из этих формул.
А что касается термеха, то лучше бы он был тоже более практическим. Например освещал конструирование игровых (в реальном времени) или научных физических движков.
А что касается термеха, то лучше бы он был тоже более практическим. Например освещал конструирование игровых (в реальном времени) или научных физических движков.
Для прикладного есть моделирование(I).
Физические движки. Сначала на маш.графе надо бросать со 100500 методами заливки тогда уж=) Впрочем, я верю, что всё будет хорошо.
Физические движки. Сначала на маш.графе надо бросать со 100500 методами заливки тогда уж=) Впрочем, я верю, что всё будет хорошо.
Знать формулы не надо было, их надо было уметь вывести.
Кстати, по поводу «огромного количества сложных формул» — это к квантовой хромодинамике, то что было у нас — в сравнение не идет даже.
Кстати, по поводу «огромного количества сложных формул» — это к квантовой хромодинамике, то что было у нас — в сравнение не идет даже.
На ИУ7 все же относительно хороший курсы (как мне кажется) по операционным системам и протоколам вычислительных сетей благодаря одному преподу, только почему-то это почти никому не интересно. Во всяком случае зачет он просто так к счастью не поставит, а курсовые проверяет в отношении плагиата.
Ну там ещё есть Рязанова Н.Ю .(Системное программирование) — я на самом деле, не смотря ни на что, высоко оцениваю её работу, как преподавателя в области системного программирования (да и получил я отл. так что неначто жаловаться :))
; не забываем закрыть линию А20
Не сказал бы, что никому не интересно. Дети разбираются, сами делают лабы, большая часть даже в срок. Да и к тому же, 1 из наиболее современных курсов.
Не сказал бы, что никому не интересно. Дети разбираются, сами делают лабы, большая часть даже в срок. Да и к тому же, 1 из наиболее современных курсов.
Если говорить исключительно о познаниях в архитектуре ОС, то может оно и так :) Только в этом смысла не больше, чем если сравнивать выпускников этих факультетов по уровню подготовки в сопромате.
как вы могли оценить уровень выпускников, если сами были студентом?
Мне кажется, что курс «Операционные системы» должен рассматривать принципы работы ядра и нет разницы какой дистрибутив здесь применяется.
Выбор ReactOS мне тоже кажется довольно загадочным… Да и Linux для таких целей представляется довольно громоздким.
У MIT есть хороший курс на база xv6 — unix-подобная ОС на примерно 8к строк кода. Ну или можно применять различные микроядра для обучения, так как это делают в TUDе.
Выбор ReactOS мне тоже кажется довольно загадочным… Да и Linux для таких целей представляется довольно громоздким.
У MIT есть хороший курс на база xv6 — unix-подобная ОС на примерно 8к строк кода. Ну или можно применять различные микроядра для обучения, так как это делают в TUDе.
Записывать лекции будете? Хотелось бы посмотреть видео.
Минусующим: если вам не надо, не значит что и другим не надо!
Хм, даже не знаю. По-крайней мере, будут слайды к лекциям, и, если осилю, то и текст курса лекций.
Очень рекомендую записывать видео и выкладывать в открытый доступ, на ютуб допустим. Если курс действительно стоящий это сразу поднимет престиж и курса, и ваш, как автора и преподавателя, и уберет подозрения о качестве курса, которые сейчас высказываются в этой теме.
В идеале хотелось бы видеть курс в онлайн-варианте, оформленный по аналогии с coursera.
В яростном восторге!
Я думаю, майкрософт будет никак.
скорее это им на руку, ведь, фактически, изучают архитектуру nt(её клон)
Вот тут Вы сильно неправы — если сравнить с Windows 8 то проекту ReactOS еще ОЧЕНЬ много чего допиливать нужно.
Даже сейчас с хорошим темпом разработки — еще очень много чего требуется реализовать.
Даже сейчас с хорошим темпом разработки — еще очень много чего требуется реализовать.
Это им никак не наруку. Наберутся разработчики в ReactOS в итоге вместе винды в офисы начнут ставить именно реакт. Да и сама идея свободного ПО заставит делать софт под реакт более открытым. А значит софт будет и под линукс и под мак. В итоге пользователи сами смогут решать что им взять реакт, линукс, мак или виндовс 8 с неудобными для офисной работы плитками?
Оно, конечно, здорово, но с другой стороны — yet another OS course?
P.S. В МГТУ, мне кажется, полезнее будет что-нибудь вроде «как оторваться от учебы и начать жить». :-)
P.S. В МГТУ, мне кажется, полезнее будет что-нибудь вроде «как оторваться от учебы и начать жить». :-)
Я тоже вначале думал «yet another». Но достаточно подробный поиск дал только курс Столярова из МГУ, который можно считать, наверное, единственным авторским курсом ОС в нашей стране. Естественно, что во-многом я хотел бы видеть подобный курс по-другому. Это и стало мотивацией.
Мой курс состоит из двух частей — первой исключительно теоретической, без привязки к конкретной реализации вообще, и второй, уже рассматривающей конкретно архитектуры UNIX/Linux, OS X, Windows NT/ReactOS.
Мой курс состоит из двух частей — первой исключительно теоретической, без привязки к конкретной реализации вообще, и второй, уже рассматривающей конкретно архитектуры UNIX/Linux, OS X, Windows NT/ReactOS.
Спасибо за пояснение. Стоило включить его в анонс, думаю, тогда и комментариев сомневающихся было бы поменьше.
Кстати, не хотите ли, если появится возможность, давать еще альтернативные архитектуры ОС, чтобы слушателям не казалось, что перечисленными операционками все и ограничивается? Мне, скажем, крайне симпатичны всякие вещи вроде xach.com/rpw3/articles/qLKdnWnvHKZvH9_VnZ2dnUVZ_jOdnZ2d%40speakeasy.net.html (кусочек описания архитектуры ОС для PDP-8, которая работала без прерываний). Для расширения кругозора жуть как полезно. :-)
Кстати, не хотите ли, если появится возможность, давать еще альтернативные архитектуры ОС, чтобы слушателям не казалось, что перечисленными операционками все и ограничивается? Мне, скажем, крайне симпатичны всякие вещи вроде xach.com/rpw3/articles/qLKdnWnvHKZvH9_VnZ2dnUVZ_jOdnZ2d%40speakeasy.net.html (кусочек описания архитектуры ОС для PDP-8, которая работала без прерываний). Для расширения кругозора жуть как полезно. :-)
Да я понимаю, наш PR-щик jedi-to-be любит выдавать провокационные статьи, я доверяю ему в этом вопросе — ему виднее, как лучше и интереснее подать новость, а я допишу в комментариях.
Насчёт альтернативных — обязательно! Я уже для себя сделал обзор из примерно 8 исследовательских ОС, которые реализованы по технологии экзо и наноядер. Всё это будет во второй части курса, касающейся практической реализации ОС.
Насчёт альтернативных — обязательно! Я уже для себя сделал обзор из примерно 8 исследовательских ОС, которые реализованы по технологии экзо и наноядер. Всё это будет во второй части курса, касающейся практической реализации ОС.
Странно это. РеактОС — попытка сделать «как windows», где, как я понимаю, в угоду совместимости жертвуют архитектурными решениями и проч. Это при том, что и в самой windows в угоду той же совместимости приходится тянуть тонны плохих решений из прошлого. Короче, это как учить пошиву обуви с помощью китайских шлёпок, мне кажется.
Слава Микрософту за обратную совместимость, однако. Идеализм — дело хорошее, конечно, но иногда хочется, чтобы оно все просто работало.
Это да, я не про идеализм, я про то, что учиться на этом странно.
Когда курс называется «ОперационнЫЕ системЫ», то вот я бы, например, выбрал какую-нибудь базовую ОС (не суть важно — *них, винды, реактос или хоть фантом от Завалишина, хотя я бы лично выбрал винды просто по причине распространенности), а вот все остальные давал бы в сравнении с ней. Т.е. информация-то все равно будет про все ОС, но отталкиваться нужно от чего-то конкретного.
Я вам по секрету скажу, что в Linux тоже в угоду совместимости тянут тонны плохих решений из прошлого
Угу… Плохие решения-то тянут, а вот с обратной совместимостью дела так себе… Помню, когда мы писали аппу под линух, заказчик выкатил список из 20+ таргетов, и практически в каждом простая задача поместить иконку приложения на десктоп выливалась в совершенно отдельный геморрой… И это не считая кучи вариантов сочетаний версий ядра, либси и нужных нам библиотек, часть из которых (сочетаний) оказывались тупо нерабочими… А уж две версии одного и того же линуха, но под разными версиями KDE и/или Gnome — это просто убиться веником сразу.
Всем бы линух хорош был, если бы не зоопарк.
Всем бы линух хорош был, если бы не зоопарк.
Ясное дело. Поэтому и на современных дистрибутивах линукса учиться не надо. Вот выше кто-то миникс предлагал — это более правильная идея. Или freedos можно, наверно.
На какой именно кафедре курс?
Почему не Minix?
А я разве Эндрю С. Танненбаум?
Во многих российских университетах аналогичный курс читается на основе minix-а и книги Тоненбаума, в том числе и у нас. В этом году собираются перейти на xv6. Выбор для этих целей NT-подобной операционной системы кажется странным, а выбор в качестве учебной реализации боевой операционной системы (будь то linux или другая ОС) кажется еще более странным.
Ребята я все понимаю. Но изучать курс операционных систем по ReactOS?
А зачем при изучени курса «Операционные системы» уделять внимание какой-то определенной ОС? Разве не важнее ознакомить студентов с основными приципами планирования, блокировки, управления памятью и тд? А если понадобиться практика, то я думаю, лучше linux использовать.
Ну так преподаватель расскажет лучше всего на примере той ОС, которую разрабатывает.
полностью согласен. а также модели многозадачности, ipc, планировщики и т.п. нас так и учили, без привязки к конкретной ос вообще. на зачете/экзамене надо было рассказать какой-нибудь алгоритм просто словами или псевдокодом.
а если уж брать пример какой-то ос, то специально созданной для обучения и minix тут идеальный кандидат. да и литература по ней соответствующая есть
а если уж брать пример какой-то ос, то специально созданной для обучения и minix тут идеальный кандидат. да и литература по ней соответствующая есть
Таненбаум к литературе прилагается бесплатно?
Лучшее враг хорошего. Зачем Алексею удовлетворительно и хорошо рассказывать про миникс, если он может превосходно и отлично учить на примере РеактОС?
Лучшее враг хорошего. Зачем Алексею удовлетворительно и хорошо рассказывать про миникс, если он может превосходно и отлично учить на примере РеактОС?
ReactOS сейчас и есть ОС для обучения. Для реального использования нехватает стабильности, над этим работают люди, а для обучения — прекрасна, т.к. полностью открыта, все алгоритмы и прочее хорошо описано, есть среда сборки (также открытая и бесплатная), и т.д. и т.п.
Миникс тут вообще ни к чему. Кстати, ещё есть и пинтос и многое другое. Но мне жаль студентов, которые будут всегда обучаться на каких-то игрушках. Надо смотреть на реальные вещи, приобретать полезные практические навыки и теоретические знания.
Миникс тут вообще ни к чему. Кстати, ещё есть и пинтос и многое другое. Но мне жаль студентов, которые будут всегда обучаться на каких-то игрушках. Надо смотреть на реальные вещи, приобретать полезные практические навыки и теоретические знания.
теоретические знания-обязательно. мне кажется в курсе ОС надо делать больше упор на теорию. а игрушечные системы(типа minix и прочих) — это просто как иллюстрация, их вообще не обязательно совсем изучать.
что меня смущает в вашей системе(я её никогда не использовал, но читал ваши записи в жж и ещё где-то)-сильная ориентированность на nt и привязка к её интерфейсам и решениям. конечно, это может быть полезно для студентов, но изначально толкает их в сторону nt(и скорее всего они будут писать именно для неё, а не для reactos).
P.S. это всё исключительно моё имхо, к тому же я сильно фанат unix-подобных систем
что меня смущает в вашей системе(я её никогда не использовал, но читал ваши записи в жж и ещё где-то)-сильная ориентированность на nt и привязка к её интерфейсам и решениям. конечно, это может быть полезно для студентов, но изначально толкает их в сторону nt(и скорее всего они будут писать именно для неё, а не для reactos).
P.S. это всё исключительно моё имхо, к тому же я сильно фанат unix-подобных систем
Вы очень вежливый фанат, спасибо.
Да, но с другой стороны — всё же лучше, чем изучать Windows на основе Windows Curriculum Kit, который уж точно полностью проприетарен. А unix-подобные системы заслуженно занимают своё положение, и я обязательно буду про них рассказывать. Никакой однобокой подачи информации не будет.
Да, но с другой стороны — всё же лучше, чем изучать Windows на основе Windows Curriculum Kit, который уж точно полностью проприетарен. А unix-подобные системы заслуженно занимают своё положение, и я обязательно буду про них рассказывать. Никакой однобокой подачи информации не будет.
и да, я абсолютно согласен с «Зачем Алексею удовлетворительно и хорошо рассказывать про миникс, если он может превосходно и отлично учить на примере РеактОС?», тем более прекрасно понимаю ваш интерес привлечь студентов к разработке реактос. да и для них это прекрасная практика и мало кто в России имеет возможность учиться у практикующего разработчика с вашим опытом.
Давайте немного пофантазируем и заменим «ReactOS» на гипотетический открытый тяжёлый истрибитель Су-57, целью которого быть совместимым с F-22, а Minix на Як-130.
— Windows-совместимая ОС по-моему никак не подходит под разряд «для обучения студентов (sic!)».
Су-57 сейчас и есть самолёт для обучения. Для реального использования не хватает стабильности, над этим работают люди, а для обучения — прекрасен, т.к. полностью открыт, все приборы и прочее хорошо описано, есть руководство по сборке (также открытое и бесплатное), и т.д. и т.п.
Як-130 тут вообще ни к чему. Кстати, ещё есть и L-39 и многое другое. Но мне жаль студентов, которые будут всегда обучаться летать на каких-то игрушках. Надо смотреть на реальные вещи, приобретать полезные практические навыки и теоретические знания.
— Windows-совместимая ОС по-моему никак не подходит под разряд «для обучения студентов (sic!)».
Есть множество операционных систем. Какого, простите, черта из всего их многообразия выбрана та, у которой нет и никогда не будет промышленного применения?
ИМХО, я конечно уважаю то что делают ребята из команды reactos(хотя и не пользовался ей, только на скринах видел). Но выбрать практически не известную ОС в качестве изучения это маразм.
Как юридически оформили, если не секрет? Насколько я помню, список курсов определяется профильным министерством, и менять там что-то, добавлять, изменять программу запрещено. Что-то вроде «дополнительного курса» сделали? Или какой-то другой способ?
Я прямо представил, как очкастые тетки из «профильного министерства» решают что поставить в программу: миникс или реактос… (facepalm)
К счастью, этот вопрос руководство кафедры решает само, за что им большое спасибо. Я только делюсь знаниями и опытом, полученным за 10 лет работы в области разработки операционных систем.
Блин, у нас этот курс читали без привязки к определенным ОС. И было очень круто и интересно. Микро ядро — QNX, гибридное ядро — Windows, монолитное ядро — Unix. ОС это только примеры. Это все равно, что учить рисовать на примере красной краски.
Зачем тут реакт ос я не знаю. Помоему это самое странное решение какое только можно было выбрать. Давайте еще курс по сетям читать не на примере цисок, а на примере какого-нибудь mikrotic.
Очень обидно за родной университет :(
Зачем тут реакт ос я не знаю. Помоему это самое странное решение какое только можно было выбрать. Давайте еще курс по сетям читать не на примере цисок, а на примере какого-нибудь mikrotic.
Очень обидно за родной университет :(
Вы ещё ничего не слышали, а уже обижаетесь за универ :).
Конечно, вместо использования WRK, будет использоваться ReactOS, что очевидно положительно. В остальном же, будут рассматриваться различные архитектуры построения операционных систем.
Александр (автор новости) просто сделал акцент на ReactOS.
Конечно, вместо использования WRK, будет использоваться ReactOS, что очевидно положительно. В остальном же, будут рассматриваться различные архитектуры построения операционных систем.
Александр (автор новости) просто сделал акцент на ReactOS.
кстати, было бы весьма полезно на курсах по сетям про Mikrotik тоже рассказывать. Ибо для понимания того, как все устроено, он полезен. Что не отменяет надобности рассказывать и про Cisco ios тоже.
Тьфу ты, только я прочитал выделенный текст как «курс по операционным системам с ReactOS в качестве предмета и примера для сочувствия»?
Топикстартеру нужно начать с курса русского языка данного заведения.
Эпиграфом взять слова американца и не найти ничего из русских классиков или великих людей как Ю. А. Гагарин. Его легендарное «Поехали!» было бы ближе к смыслу статьи.
Фи-иии
Фи-иии
Что это у вас за американофобия, вы — латентный американец?)
Я просто считаю, что большинство болеет промыто-полосатозвёдной болезнью.
Топикстартер имеет полное право на свой эпиграф к своей статье, но я просто понимаю откуда «ноги». Всё вокруг «не русское», откуда же взяться в голове эпиграфам из «русского».
Топикстартер имеет полное право на свой эпиграф к своей статье, но я просто понимаю откуда «ноги». Всё вокруг «не русское», откуда же взяться в голове эпиграфам из «русского».
О да, кухонная психология. Tell me more about it)
Почему кухонная?
Бытие определяет сознание.
Если по множеству видеоматериалов видно, что первые в космосе американцы и сразу на Луне с фразой от всего человечества, то как можно вспоминать про Гагарина и Леонова?
Цитата — это же умная «выжимка» твоей работы и эпиграфом выбираешь то, что знаешь и ближе тебе.
Бытие определяет сознание.
Если по множеству видеоматериалов видно, что первые в космосе американцы и сразу на Луне с фразой от всего человечества, то как можно вспоминать про Гагарина и Леонова?
Цитата — это же умная «выжимка» твоей работы и эпиграфом выбираешь то, что знаешь и ближе тебе.
Когда курс читает препод с хардкорным опытом по предмету — это очень круто и надо ходить. Нам на восьмой кафедре курс ОС читали два раза, оба раза сухо и скудно. Реактос для изучения даже лучше. По моим ощущениям, в потрохах винды продвинутые студенты в итоге разбираются хуже, чем в линуксе. Юниксы они и сами хорошо ботают, а вот с виндой надо помочь. Желаю Алексею раскрыть преподавательский талант на этом курсе!
МГТУ им.Баумана?
Да я же по их проге МВТУ 3.7 диплом писал год назад.
Каждую секунду работы с этой дьявольской прогой я представлял как несколько мужиков-профессоров, не умеющих даже почту проверять на пк, стоят и пинают бедолагу студента, на которого повесили написание этой проги. Результат соответственно отвратителен, о юзабилити вообще говорить нечего: даже CTRL+X/C/V не работают.
Да я же по их проге МВТУ 3.7 диплом писал год назад.
Каждую секунду работы с этой дьявольской прогой я представлял как несколько мужиков-профессоров, не умеющих даже почту проверять на пк, стоят и пинают бедолагу студента, на которого повесили написание этой проги. Результат соответственно отвратителен, о юзабилити вообще говорить нечего: даже CTRL+X/C/V не работают.
Все проплачено, потому и реакт ос а не minix или xv6(которая от MIT). Кому какая разница, что студентам проще понять, по чему больше материалов и курсов других вузов / книг… Пусть минусуют, но я такие затеи наблюдаю для пиара, уровень студентов таков, что этот курс, мягко говоря, подходит 2-3 студентам из группы, хотя может у меня своя параллельная реальность
Имхо, в полку бессмысленных предметов прибыло. Сам недавно закончил данное учреждение по специальности ИТ.
А можно план попила глянуть?
Я изучал код ядра ReactOS. Мне очень понравилась архитектура ядра. Все четко и понятно. Много идей оттуда почерпнул. Даже нашел баг при просмотре кода, который был впоследствии принят и пофикшен. Код ядра линукса просматривал бегло в паре мест — понравилось гораздо меньше. Так что я одобряю решение обучать архитектуре ОС на базе ReactOS. Все-таки ее ядро в значительной мере повторяет архитектуру Windows NT, а последняя была создана высоким мастером этого дела Dave Cutler.
Меня поражает пафос вашего текста, его канцеляризм, пассивные залоги, все эти «был сделан, объявил,… принял приглашение»
Сам обучаюсь в МГТУ Баумана, но не на ИУ-9. Можно ли будет приходить вольнослушателям на лекции/семинары?
Первая лекция была весьма многообещающей, ждем продождения. Особенно более конкретного и практического материала — вы этом же Ваша сила!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
МГТУ им.Баумана запускает дисциплину «Операционные системы» на базе ReactOS