| 1.3, Аноним (-), 18:30, 28/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
1. Допустим писать операционку ради операционки, а не ради например работы с реальными проектами иммет смысл.
2. Тогда почему если я работаю не с прикладными программами а с асбтрактной по применению сущностью - нет УДОБНОГО инструментария НОРМАЛЬНО работать именно с параметрами самой системы: управления и просмотра плнировщика, процессов потоков, подключаемых модулей и тд и тп, что за черное нечтно для ковыряния в коде, которое даже непонятно РАДИ ЧЕГО ковырять.
| | |
| |
| 2.26, Аноним (-), 10:08, 29/11/2014 [^] [^^] [^^^] [ответить]
| +5 +/– |
Не надо операционку писать, в данном случае действие диаметрально обратное. Операционка "отрывается" от оборудования, обезжиривается и становится фреймворком-окружением для запуска огромной тучи легаси-кода.
| | |
| 2.59, noize (ok), 17:44, 04/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
 "Мы встроили операционную систему в твою операционную систему чтобы ты мог пользоваться операционной системой пока ты пользуешься операционной системой"
| | |
|
| 1.6, Аноним (-), 21:18, 28/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Не вижу никакой смысл садится на микроядро - неоправданный расход ресурсов системы.
| | |
| |
| 2.10, Аноним (-), 23:37, 28/11/2014 [^] [^^] [^^^] [ответить]
| –4 +/– |
вы бредите.
в микроядерных ОС - оверхэд МЕНЬШЕ, внезапно.
да и задержки, переключение - тоже.
если откинуть наиболее одиозные реализации, вроде квалкомоского REX в кремнии или форков VxWorks от WindRiver, то вещи вроде Zero Overhead Linux(от Tilera) прочие вещи(от EMC, HP и CERN, соотв) вполне себе смотрятся. готовыми к развертыванию в рабочей среде.
| | |
| |
| 3.11, Аноним (-), 23:38, 28/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
плюс профит по стабильности и секьюрности, ради которого изначально затевалось.
плюс портабельность итд итп.
| | |
| |
| 4.24, Аноним (-), 07:47, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> плюс профит по стабильности и секьюрности, ради которого изначально затевалось.
Да вот, говорят что жить в бетонном бункере на солидной глубине - несколько безопаснее чем в обычном доме. Вот только так делать хотят почему-то далеко не все. Ну и с микроядрами как-то так же получилось.
| | |
| |
| 5.27, Аноним (-), 13:33, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
В микроядер единое неоспоримое преимущество - минимальность кода ядра (в будущем простота).
Монолитные ядра всех сегодняшних ОС слишком жирны, замусоренены и не удобны.
Будущие именно за микроядрами, просто человечество пока нужную мат модель для них не придумало..
| | |
| |
| 6.30, Аноним (-), 15:55, 29/11/2014 [^] [^^] [^^^] [ответить] | +2 +/– | В результате сложный код лишь немного меняет место жительства Что мало влияет н... большой текст свёрнут, показать | | |
| 6.34, Аноним (-), 16:26, 29/11/2014 [^] [^^] [^^^] [ответить] | +1 +/– | Вы опечатались, наверное хотели сказать у микроядер Если вы хоть раз смотрели... большой текст свёрнут, показать | | |
| |
| 7.36, MIRV (?), 19:44, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Да ладно, это же лабух который поверил какерам-школьникам как он сам, которые в отличии от него хоть что-то осилили где-то прочесть. Только вот что он, что они - не в курсе про одну вещь - "там где теория и практика сталкиваются - побеждает практика". Микроядро (в том смысле что его понимает школота) красиво на бумаге, но на практике - это жуть.
| | |
| |
| 8.39, Аноним (-), 20:20, 29/11/2014 [^] [^^] [^^^] [ответить] | +/– | А вот педвзятое отношение в исполнении очередного болвана, который даже не поним... текст свёрнут, показать | | |
|
| 7.52, Аноним (-), 08:20, 02/12/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
http://www.opennet.ru/openforum/vsluhforumID3/100354.html#51
В ядрах ОС разбираюсь достаточно. Основная проблема сегодняшних монолитных ядер - их проектирование на основе моделей конца 80 годов прошлого века. Тогда люди не учли необходимости в трёх очень нужных вещах:
1. Многопроцесорность
2. Виртуализация
3. Кластер единого системного образа (SSI)
И сегодня в Linux, FreeBSD их реализация очень накладна и выглядит очень костильно!
Исправить сие в монолитных ядрах Linux, FreeBSD не возможно, надо придумывать новую мат модель и писать новое ядро лучше с нуля.. А для совместимости драйверов и приложений лучше, напервых порах, написать эмулятор Линукс API...
| | |
| 7.56, softfire (?), 15:19, 02/12/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > > Ну а неудобны вообще пишется слитно и это вообще субъективная оценка зависящая от индивида. Вообщем вы совсем не инженер, зачем тут третесь, не понятно.
"Непонятно".
нутыпонел.
| | |
| |
| 8.58, опять (?), 11:22, 03/12/2014 [^] [^^] [^^^] [ответить] | +/– | прежде, чем умничать, почитай, когда непонятно используется раздельно, а когда... текст свёрнут, показать | | |
|
|
|
| 5.37, chinarulezzz (ok), 19:49, 29/11/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
 >Да вот, говорят что жить в бетонном бункере на солидной глубине - несколько безопаснее чем в обычном доме
опять метафоры. слава богу не про 21 век, колесницы и прочее.
| | |
| |
| 6.41, Аноним (-), 01:28, 30/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> опять метафоры. слава богу не про 21 век, колесницы и прочее.
Ну вы то и так не можете. А унылое далдонство про то что микроядра рулят - за пару десятков лет уже как-то надоело. Куда-то не туда они у вас рулят, чуваки.
| | |
|
|
|
| 3.12, vi (ok), 23:43, 28/11/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > вы бредите.
> в микроядерных ОС - оверхэд МЕНЬШЕ, внезапно.
> да и задержки, переключение - тоже.
> если откинуть наиболее одиозные реализации, вроде квалкомоского REX в кремнии или форков
> VxWorks от WindRiver, то вещи вроде Zero Overhead Linux(от Tilera) прочие
> вещи(от EMC, HP и CERN, соотв) вполне себе смотрятся. готовыми к
> развертыванию в рабочей среде.
Наверное имелось в виду: оверхеад от переключения контекста процессов.
Наверняка, некоторые процессоры имеют аппаратное переключение контекста (наверняка, для какого то ограниченного числа процессов), тогда другое дело.
| | |
| |
| 4.35, Аноним (-), 16:44, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Наверняка, некоторые процессоры имеют аппаратное переключение контекста (наверняка, для какого то ограниченного числа процессов), тогда другое дело.
И откуда вы только лезете, специалисты.
Интеловские процессоры начиная с i386 имеют аппаратное переключение задач.
| | |
| |
| 5.38, Аноним (-), 20:00, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Наверняка, некоторые процессоры имеют аппаратное переключение контекста (наверняка, для какого то ограниченного числа процессов), тогда другое дело.
> И откуда вы только лезете, специалисты.
> Интеловские процессоры начиная с i386 имеют аппаратное переключение задач.
Вот что пишет википедия:
переключение контекста является очень ресурсоемкой операцией, причем, чем более «навороченым» является процессор, тем более ресурсоемкой эта операция становится.
Так что i386 все таки лучше чем i686 (в этом отношении).
| | |
| |
| 6.42, Аноним (-), 01:29, 30/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Так что i386 все таки лучше чем i686 (в этом отношении).
А если про всякие SIMD и сопроцессоры вспомнить и подумать о том что задачи не должны замечать что их кто-то прерывает или переключает...
| | |
| |
| 7.47, vi (ok), 11:17, 30/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Так что i386 все таки лучше чем i686 (в этом отношении).
> А если про всякие SIMD и сопроцессоры вспомнить и подумать о том
> что задачи не должны замечать что их кто-то прерывает или переключает...
Так разговор идет про оверхед. Или Вы хотите поговорить о том, что мы в не знаем о том, что делает процессор в данный момент? (Но,,, инженеры которые его проектировали, где то и/или как то все таки должны понимать, что там "внутрях" происходит (или что, это "Черная дыра"?))
| | |
|
|
|
|
| 3.23, none7 (ok), 06:31, 29/11/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Задержки на переключение контекста меньше быть не могут, так как они аппаратные. То есть банально чтобы перейти из режима пользователя в режим ядра по sysenter или прерыванию уходит более 1000 тактов процессора. Это на x86 и x86-64 за другие архитектуры говорить не буду, но наверное тоже не быстро, так как дело в объёмной таблице трансляции адресов страниц памяти и прав к ним. И при всём этом мне страшно представить стек USB постоянно обращающийся к ядру для записи в I/O порты очередных 4 байт.
| | |
| |
| 4.28, Аноним (-), 13:40, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> ...банально чтобы перейти из режима пользователя в режим ядра по sysenter или прерыванию уходит более 1000 тактов процессора... не быстро, так как дело в объёмной таблице трансляции адресов страниц памяти и прав к ним...
Это если выполнять все требования безопасности Posix разработаные давно, прямолинейно и для монолитных ядер.
С гибридными ядрами можно достичь быстродействия примерно как в монолитных..
Для микроядер надо изобрести новую мат модель безопасности, а то выполнение всех требуемых Posix проверок сильно замедляет микроядра в сравнении с монолитными.
| | |
| |
| 5.33, Аноним (-), 16:03, 29/11/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> С гибридными ядрами можно достичь быстродействия примерно как в монолитных..
Так у гибридных ядер обычно 1 адресное пространство на ядро и драйвера - там нет такого понятия как переключение контекста: если мы в кернелмоде, данные уже немедленно доступны. Вот только при этом уже не идет никакой речи о защите от сбоев драйверов - у них прав столько же сколько и у ядра и сбои там одинаково фатальны.
> Для микроядер надо изобрести новую мат модель безопасности, а то выполнение всех
> требуемых Posix проверок сильно замедляет микроядра в сравнении с монолитными.
И правда - ну его нафиг права энфорсить. Нехай всем можно все - получится DOS. При этом уже не важно какого размера прогрмама, ибо любая программа сможет гадить остальным. Ну раз проверок прав нет.
| | |
| |
| 6.40, Аноним (-), 20:59, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>При этом уже не важно какого размера прогрмама, ибо любая программа сможет гадить остальным.
windows 9x..
| | |
| |
| 7.43, Аноним (-), 01:30, 30/11/2014 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> windows 9x..
Его сложно назвать микроядерным. Скорее, это коллекция из нескольких ошметков wannabe-ядер по нескольким закоулкам.
| | |
| |
| 8.44, Аноним (-), 08:01, 30/11/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Его невозможно называть микроядерным win9x - это ядро с невытесяняющей многозад... текст свёрнут, показать | | |
|
|
| 6.46, Аноним (-), 08:16, 30/11/2014 [^] [^^] [^^^] [ответить] | –1 +/– | С гибридными ядрами, кроме DragonFLY BSD, смотреть больше неначто А в стрекозе ... большой текст свёрнут, показать | | |
| 6.48, Аноним (-), 15:10, 30/11/2014 [^] [^^] [^^^] [ответить] | +1 +/– | В предыдущем посте с примером seL4 написал мало о ДРУГИХ вариантах безопасности,... большой текст свёрнут, показать | | |
| |
| 7.49, vi (ok), 17:15, 30/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> свои процессы).
> 2. Права и допуски потоку передаются только раз в момент его рождения,
> указываются необходимые адреса пямяти и номера процесов.
> 3. Если процес "не угадал" номер другого процесса, или адреса памяти, или
> параметры выделения памяти (попытка записать в ro или исполнить noexec) то
> против такого процесса вводят санкции (как минимум ядро убивает процес все
> его дочирные и очищает занимаемую им память; максимум убивает все процессы
> пользователя который запустил зловреда и блокирует его учётную запись).
> В sel4 доказали что ДРУГАЯ модель безопасности, не Posix тоже ГАРАНТИРУЕТ БЕЗОПАСНОСТЬ!
> Причём ОЧЕНЬ дёшево и без постоянных проверок!!!
Через сколько попыток 'процесс "не угадал"' мы приходим к максимуму?
И да, если программа "косячит" (читает или не дай Бог пишет не там где надо), то переходящее красное знамя вручается Автору Программы (для работы над ошибками ;)
| | |
| |
| 8.53, Аноним (-), 08:38, 02/12/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Ядро вводит санкции при первой же неудачи Совершенно верно В модели Posix ACL ... большой текст свёрнут, показать | | |
| |
| 9.57, Аноним (-), 20:15, 02/12/2014 [^] [^^] [^^^] [ответить] | +/– | В процессоре с одним ядром ALU в каждый момент времени может выполнятся одна о... текст свёрнут, показать | | |
|
|
| 7.50, Аноним (-), 00:19, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
Идея-то хороша, но как выяснить, является ли конкретное действие процесса "разрешённым" без проверок при каждом действии? Да, оптимизации возможны, но есть предел, за которым или скорость, или безопасность.
| | |
| |
| 8.54, Аноним (-), 08:56, 02/12/2014 [^] [^^] [^^^] [ответить] | –1 +/– | При КАЖДОМ действии проверки должны быть Без проверок никак не обойтись если... большой текст свёрнут, показать | | |
|
|
|
|
| 4.29, Ivan (??), 14:30, 29/11/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 время сохранения/восстановления контекста 65 тактов (0,33 мкс)
завистит от кол-ва строк планировщика
| | |
| |
| 5.31, Аноним (-), 15:59, 29/11/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> завистит от кол-ва строк планировщика
И от того что именно сохранять. Потом окажется что в 65 тактах сохраняется абсолютный минимум нужный для переключения задач, в идеальном случае, а на практике окажется в разы больше, особенно со всякими cache hit/miss, кучей добра в TLB и прочем. И как-то так окажется что микроядро и куча задач сурово вымывают буфера, а адаптировать железо спецом к микроядрам, коих на радаре под линией графика не видно - всем обломно.
| | |
|
|
|
|
| 1.7, Аноним (-), 21:25, 28/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>реализация новой системы динамического связывания, которая на 20% проще прошлой реализации
Интересно, а как они простоту реализации системы динамического связывания измеряли?
| | |
| |
| 2.9, Аноним (-), 23:18, 28/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
Может смогли отладить после написания на 20% больше функционала...)
| | |
| |
| 3.32, Аноним (-), 16:00, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> на 20% больше функционала...)
...по сравнению с кем? С FreeDOS? :)
| | |
|
| 2.18, Аноним (-), 03:06, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>Интересно, а как они простоту реализации системы динамического связывания измеряли?
Я не знаю, но думаю что оценили ее сложность. Я бы рассчитал именно так.
| | |
| 2.20, Аноним (-), 03:51, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Интересно, а как они простоту реализации системы динамического связывания измеряли?
возможно, оценили количество кода, например
| | |
| |
| 3.22, Аноним (-), 04:43, 29/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>возможно, оценили количество кода, например
php-шник или из индус?
вот код длиной в 6 символов
>perl -E'{say 1}'
вот код длиной в 4 символа
>perl -E'say 1'
м?
| | |
|
|
|
