>>Всем нужны _просто_ драйвера. Но вот кое-кому не хочеться терять всю систему
>>если один драйвер стал раком.
>А мне не хочется наблюдать как драйвера становятся раком.Очень приятно если я
>захочу посмотреть киноху а мне скажут "бсст!" - "прости чувак, но
>кина не будет - тута у нас драйвер упал и оставил
>видяху\звуковуху в неопределенном состоянии из которого хз как их выбить".Вот хочется
>чтобы этому коду можно было доверять не меньше чем ядру.Иначе будет
>вакханалия сплошная.
если ты мечтаешь о том, что все дрова будут открыты (и как следствие - более надежны),
то расстроить тебя проще простого: та же видуха уже имеет ненадежный драйвер,
т.к. закрытый. Дальше будет только больше. Линуху рано ли поздно предстоит заменить венду на компах простых юзерей - дрова будут писаццо под что угодно и кем угодно. Открытые и закрытые. Ситуация с дровами будет та же, что и в оффтопе сейчас, пусть с чуть большим процентом открытых вещей. Так что со старым подходом - вакханалия обеспечена: по несколько закрытых дров у среднего юзера в ядре - будет нормой.>>готовый драйвер и в нем произошел сбой.
>Рассуждения на уровне "есть метеорит и он даже прилетел вам на голову.Ваши
>действия?Хренли вы не в каске?И почему вы все еще не закопались
>в бункер?!".Т.е. рассматривать можно и в принципе ничему не противоречит.Но метеориты
>не падают на голову всем подряд и часто, поэтому несмотря на
>маленькую вероятность получить метеорит на голову, никто не сидит в бункерах
>в ожидании попадания в их голову мелкого космического булыжничка.
ну когда ты уже перестанешь путать теплое и трансформаторное?
Вероятность падения метеорита на голову жителю Земли много менее вероятна, нежели сбой в одном из сотен миллионов(??) компьютеров на планете из-за кривого китайского драйвера.
>>Речь о пункте "б" - реакия системы.
>>И тут выбор прост: отдаццо на волю случая (драйвера) или что-то решать.
>А ядро не владеет ситуацией в каком состоянии железо.Что-то решить не зная
>в каком состоянии заклинило железку довольно странно.Возможность это сделать зависит от
>того что за железка.Ну да, без звуковухи в принципе работу продолжить
>можно, хотя особого кайфа юзеру сий факт не доставит.
ядро может взаимодействовать с железом лишь посредствам дров. Драйвер упал - выбор прост: либо его перезапустить, либо смириться с отсутствием железки в системе до ребута.
>>Вы ясно дали понять, что готовы отдаться на волю случая, т.е. лучше
>>чтоб все упало разом.
>Разумеется - при этом будет минимизирован шанс что-то испортить в файловой системе
>и прочем.
расстрою: падение чего-либо в монолите ядра в общем случае _может_ повредить _любые_ данные.
И твоя ФС - не исключение. А защитить в монолите можно лишь код, сделав его RO.
>В частности и при неидеальности железа - система сразу грохнется
>что при сколь-нибудь заметной повторяемости ситуации спровоцирует юзера на поиск проблемы.
или N-денежный downtime....
>А система рестартящая драйвера рассчитывает на то что драйвера ненадежны и будет
>существенно меньше мозолить глаза этим фактом.
Зато когда ты поставишь дистр на монолите, который все нахваливая юзают, и он у тебя будет нае***ываться каждые 5 минут - то через какое время у тебя мозоли появяццо?
Железные проблемы - это отдельная тема. Софтом тут много не нарулишь, когда комп, например, включаеться даже под настроение.
>Итого при скажем глючащем железе разрушенная
>оперативка будет успешно писаться на диск.Ну да, будут порой драйвера рестартить
>в случае чего но система то не зашатдаунится.Ну как минимум пока
>не сбойнет что-то в самом ядре (а драйверов как было уже
>сказано больше ядра...)
ни ты ни я не можем сказать в общем случае где похериццо микруха памяти - ни под ядром ни под дровами. Посему, давай не будет об этом.
МЫ - о софтовых проблемах! Или опять съехать с темы потому как сказать нечего - это привычка?
>Поддержка на уровне железа изоляции вообще всех частей системы друг от друга,
>допустим, по потокам.Но это увы надо и новый хард и новый
>софт.Можно например на Cell глянуть для некоторого понимания о чем я
>примерно говорю.
1. опять съехал на железо
2. ...и проиграл на своем же поле. x86: 4 кольца защиты и MMU позволяют то, чего ты нажелал тут про изоляцию по потокам. Либо поясни "изоляцию вообще всех частей системы"
3. смотрел на Cell - ниче так трава в IBM ;) но это не решает проблему подавляющего числа компов с мире - x86 архитектуры.
4. Какой такой "новый" софт ты имеешь ввиду?
>>А пользовательские прграммы - железно в другом. Хотя и несколько пользовательских
>>процессов так же могут жыть в общем (для них) адрессном пространстве.
>Угу, все замечательно, кроме того что переключение между кольцами в принципе не
>очень шустрая операция обычно, to the best of my knowledge.
х**реновый у тя knowledge. Это одна иструкция. Например: int 80, sysenter (intel),
syscall (AMD)
>>3. У вас явно проблемы с иксами :)
>Да не только у меня одного.Народных плачей что можно уронить иксы -
>я так смотрю в интернете есть.И при том кажись побольше чем
>мата на падучие драйвера.
этих падучих драйверов будет все больше - народ начинает ставить пингвинов на свои компы.
Дрова не за горами...
>Я просто нашел 1 последовательность действий которая роняет
>иксы лично у меня.Редкая.Случайно выполнить все эти действия трудно.Однако последствия сравнимы
>разве что с рестартом - не дохнут только консольные демоны всякие,
демоны не бывают консольными ;) демон - это прога бещ управляющего терминала
>то наврядли сильно утешит среднестатистического юзера.
Ессьно, иксы тоже нужно отлаживать. Но... это уже напоминает ситуацию с ядром и дровами :)
Да и решение мы уже примерно знаем ;)
Вынести базу из Х сервера в отдельную прогу, к которому будут коннектиццо клиентские проги. И уже эта прога запустит X сервер просто как метод прорисовки в видуху того, чего просят проги. Ну, упадет X сервер - и хрен с ним :) эта прога просто его передернет и продолжит рисовать через новые иксы картинку в видуху. Клиентские проги и слухом не услышат, что X сервер падал...
Ниче не напоминает? ;)
>>запустите какой-нить виртуальный X сервер (типа vnc, например), и подключайтесь к
>>нему уже из обычных иксов.
>А где гарантии что те иксы не упадут, унеся за собой "важные
>процессы"?
в простоте Xvnc процесса. Там - только протокол исковый, который уже весьма неплохо отлажен. Драйвера видух и прочие потенциально менее стабильные вещи - в вашем X сервере, который может быть без потери информации перезапущен.
Вот как раз vnc сервер и есть реализация того, что я описал в предыдущем абзаце.
>Да и вообще изврат получается.
Тебе нужна была надежность? Вот. Что не так? А как так чтоб без извратов и не зависеть от падений X cервера? Вариант перепроверить все иксы и убедиться в отстутствии глюков - бесполезно. Это делают много и часто. Результат пока что налицо - все-таки падает.
Так что, разделяй и властвуй.
Или есть опять же предложения какие? (кроме каких-то железных изменений. Разве что ты себе Cell процессор в иксы поставишь :D )
>>Если они упадут - ну придеццо просто переподключиться к vnc серверу :)
>При этом почему-то допускается что он упасть не может.А кто это гарантирует
>собственно?
его простота. Меньше кода - с большей вероятностью можно лучше отладить, чем гору дров в X сервере.
>>Ниче не будет потеряно.
>>Неправда ли, разнесение функционала в самостоятельные процессы - несколько сглаживает
>>(если не решает) данную проблему? Ну так почему же вы тогда так против
>>подобного решения для драйверов?
>Потому что это сделает систему тормознее
производительность и надежность - это обратнопропорциональные вещи.
Математика.
Или у тебя есть какие предложения? ;)
>и кроме того, драйверам по роду
>деятельности нужны привилегии которые нафиг не впились юзерским процессам.
X серверу (как праобразу ядра но для GUI) тоже нужны достаточно некислые привилегии - посему он работает от рута. X-клиенты же могут работать без особых привилегий, от юзера.
>Отнять их по простому трудновато.
Чисто ваше незнание x86 делает это "трудноватым".
>Нужны какие-то левые костыли которые все притормозят.Если бы все современное
>железо предусматривало бы такое деление без performance penalty - было бы
>замечательно.Потому что ничего не стоит а система типа надежнее.
во-первых, так не бывает: см. пост о производительности/надежности.
Это конкурирующие вещи. Остаеться лишь найти нужную золотую середину.
>Ну... нечто типа ACL-ов для каждого потока на железном уровне, раздавать их могло бы
>ядро
Если процессор контролирует каждый поток, то он должен помнить сразу (т.е. одновременно)
инфу о всех этих потоках. ACLи эти, LTD, регистры и много еще чего - все это нужно для одного потока.
Потоков должно быть не меньше, чем это щас позволяет линух (хотя-бы по дефолту):
kernel.threads-max = 24549
Это все нужно где-то хранить. Если внутри процессора - он будет дороже хорошей машины и негибким (если понадобиццо больше потоков - добалвение памяти в проц ?? :)
Если хранить вне проца, а в оперативе, то это уже нужно процу договариваццо с ОС (!!) о том, где бы ему положить эту инфу... и для обработки каждого потока - лазать за инфой этого потока туда! Безусловно, можно сделать внутриядерное кеширование и пару-тройку конвееров обработки инструкций, чтоб меньше зависеть от тормозов оперативы - теперь вспоминаем цену самолета при количестве ядер в 25 тищ %)))))) Так что с кешем внутренним и количеством конвееров особо не разгуляешьсо....
Ну так это и есть современный x86 %))))
кеш в проце, 2 ядра (а интел уже и 4 заявило) - все как вы хотели :))
И вот у мну дома уже стоит такой проц. А проблема дров все как-то нерешена ;)))
>а потоки вообще при этом можно не делить на юзера
>и систему в принципе - ACL поделил бы их намного точнее
>чем только программа, или только драйвер.Скажем чему противоречит что программа которой
>надо нестандартный прямой доступ в железо не реализованный встроенными драйверами сама
>попросит его?И или пойдет нафиг или поработает с железом - в
>зависимости от ACL-ов.Становясь на время сама себе драйвером, если угодно.
вот тут - чистое 5.
Абсолютно верно: грань между пользовательсикм процессом и драйвером стираеться, когда все они в отдельных процессах с заданными правами в каждом.
Только почему вы решили, что это не есть микроядро? :) Где все то же самое: все живут у себя в песочницах и могут только позволенное. И драйвер и прога ...ах да, разницы то уже и нет.... ;))
>>Вот после схемы с vnc - так оно и будет. У вас
>>упадет просто "консоль" к вашим программам,
>Замечательно, а если упадет то на чем эта консоль "хостится" то мне
>стал быть останется оболочка от сосиски?)
с какой вероятностью может сломаццо баш скрипт? (т.е. сам цикл):
while :; do X -query xxxxxxx ; done
думаю, вам хватит на пару жизней его работы ;))))
> А программы то мои того, тю-тю.
тю-тю они если будут подключены к этому X серверу, а не к тому, к чему он сам коннектиццо.
>Спасибо,
>я с вмварями всякими и разными видами ремотных десктопов дело имел
>- представляю себе как это и что поолучится.По сути вы спихнете
>проблемы надежности с 1 машина на другую.
спихнуть проблему надежности с падающих иксов на более надежную прогу (VNC сервер) - это неправильно? Опять бредите....
>>ну так веть вот он. Шанс ваш ;)
>"В винде есть такая утилитка, ahui.exe" - в смысле, если упадет "хостящий"
>икс - ну тады ой.У меня останется консолька.Работающая.Но без моих программ.Которые
>навернутся, очевидно, без доступа к этому иксу, ага?Ну или куда они
>графику денут?И чо мне с ней делать?Программы то от ее наличия
>у меня не вернутся?!Ну или почему на той стороне иксы будут
>надежнее моих?Аргументы их большей надежность можно в студию?Я так понимаю что
>мы сбагрили проблему с одного места в другое.Почему она там не
>возникнет - не понятно.
Размер X сервера:
-rw-rw-r-- 1 root portage 6014596 Янв 23 08:15 xorg-server-1.2.0.tar.bz2
VNC клиента и сервера:
-rw-rw-r-- 1 root portage 1766473 Июн 16 07:43 tightvnc-1.3.8_unixsrc.tar.bz2
Надежность пргограммы обратно-пропорциональна ее размеру.
Абсолютная надежность бывает только в одном бите.
А если вы имете дело со столь сложными программами - то можно говорить лишь о вероятность возникновения ошибки. Размер программы имеет пусть и не единственное, но ключевое значение.
>>4. Очевидно, вы не совсем понимаете о чем спор.
>Не спорю, это не исключено.Я не сильно давно пользую *никсы.
Ничего, правильный спор - потенциальный ключ к познанию.
>Можете посмотреть выше - я только что сбредил ибо спать хочу
>и придумал вообще иначе - а нафиг ядра, в **пу драйвера,
>в п*** процессы.Если б поддержало железо - зафигарить fine-grained разделение прав
>у потоков и раздать кому надо столько сколько надо, а при
>вылезании за дозволенный минимум необходимого зарвавшийся поток просто мочить.С разными последствиями
>в зависимости от того что замочено... :).Ядро при этом сведется к
>диспетчеру задач и манагеру разрешений.В принципе даже не обязательно одним потоком
>наверное - ну, несколько привилегированных потоков, которые мы типа посчитаем ядром
>:)
Вот тут и я задам вопрос: а кто сказал, что это все на уровне железа будет надежнее? ;))
И есть ли смысл делать и новое железо (с новыми F00F багами) и к нему новый софт чтобы решить проблему?
Не надежнее ли не менять процессор, архитектура которого уже отлажена годами?
А просто разграничить программный код и видеть какие отдельные компоненты в нем настабильны? Твоя же идея с разделением на потоки, но в программной реализации ;)
Потому как ты предлагал микродерный подход, но на уровне проца :)
>>И у вас какие-то комплексы по поводу названия подобного ядра...
>Есть опасения что тормозить будет.
в третий раз за пост говорю: производительность и надежность - разных полей ягоды.
>Почему-то никто еще не сделал БЫСТРУЮ и РАЗВИТУЮ
>микроядерную систему.
Потому что лишь в последние года процессоры стали настолько быстры, что часть их мощьности уже можно без проблем отдать на подъем наджености, которая как раз нормально так и хромает все эти годы бурного развития софта :)
>Все хотят чтобы это сделали другие :) например, Линус :).
я такого не говорил. У меня мало надежд, что Линус займеться микроядром.
Пока только на себя надеюсь, но понимаю что одному человеку переделать подобным образом Линух практически нереально. Есть ведь хочеццо... приходиццо иногда работать ;)
>И еще есть подозрения что многих кернел девелоперов не пропрет писать юзер-мод
>процессы, посему это ставшее довольно беспонтовым занятие будет оставлено на откуп
>индусам всяким.
Это проблемы тех, кого не прет :) А меня вот прет :D
>А куда деть кучку квалифицированных кернель программеров не понятно.Для микроядра
>их столько нафиг не сдалось.
Переписывание Линуха - офигенная задача им всем на несколько лет... Не будут без работы.
>Писать юзермод код они имхо не станут - специфика не та.
Только API смениться. Суть и желание сделать надежно - останеццо ;)
Ведь если упавший драйвер не проблема для остальных подсистем - то это все еще проблема девелопера этого упавшего процесса :)
Всегда есть куда расти.
>Ну, лично я бы во всяком случае на
>их месте не стал, пусть лучше такие драйвера индусы и Таненбаум
>пишут, а меня такое изучать как бы эт сказать, заломало :).
Не заломало бы. Им весьма интересно решать какие-либо реальные проблему: отсутсивие нужных дров под линух или повышение надежности ядра.
>Если
>серьезно то я бы вероятно хотел со временем освоить кернель мод
>програминг в линуксе(но пока я слишком мало знаю эту систему).А вот
>програмить драйвера в юзере я бы точно не хотел - это
>пущай индусы и Таненбаум свои высокие концепции продвигают, а я в
>таком случае найду чегонить другое на попрограммить.Уровнем пониже :)
_сейчас_ программинг модуля ядра есть изучение API и его применение.
Например: делаешь свою ФС.
Смотришь: нужно заполнить структурку вот такого вида своими указателями на свои функции (myfs_open, myfs_read, myfs_write...) и позвать такую-то функцию с укзателем на эту структурку. Зарегистрировались в ядре.
Потом начинаешь реализовывать эти функции, что ты заявил в структуре. Нужно че-то сказать другому модулю - зови вот такую функцию вот так-то. еще чего - такую функцию.
Практически суть не измениться для программирования под микроядро.
Просто эти функции, что ты зовешь будут другими и совершать общение с другими модулями будут по-другому. Но ты об этом, вообщем-то, не обязан будешь волноваться. Ну, ессьно, какие-то принципы поменяються, но особых проблем не вызовет:
то ты раньше просто обращался к глобальной переменной, а теперь нужн обудет позвать функцию, чтобы получить/установить ее значение. Разница небольшая.
Главная работа ляжет на создателей API, которым ты будешь пользоваться...
>>Да, это мог бы быть Линух. Если переделывать его - то это
>>именно и будет Линуксом.
>А что там будет от линукса кроме названия?Ядро будет совсем другое, драйвера
>другие.И wtf оно именно линукс?
Потому что оно щас линукс :) как минимум. Не нравиться - форк проекта - и бери другое имя если Линух ты видишь только микроядерным.
Я - нет :)
Линух для меня - это, прежде всего, свобода действий ;)
>А не minix например?
Напороться на наезд Таненбаума? Нафик.
>Чтобы примазаться к раскрученному Линусом бренду? oO
Ну..... Линукс с патчем - остаеться ли Линуксом? :)))
Как только _ты_ определишься с ответом на это - сразу решишь и проблему названия _для_себя_.
Я уже ответил для себя на этот вопрос :) Линукс - это конструктор. Я могу его менять, добавлять в него что-то, удалять. Эт этого сей конструктор не перестает быть Линуксом :)
>Судя по всему это получится совсем новое ядро у которого с старым
>общее ... название и высокоуровневое апи?
Ну и ради бога :) Все равно это будет Линукс ;) Ибо конструктор :)
Просто в нем какие-то части переставлены по-другому.
>>А про "линукс это круто" - да, круто. Пока в нем больше
>>всего открытый драйверов, чем в любом другом ядре на Земле -
>>да, это круто.
>И заметьте, они не падают каждые 5 минут. И вообще система в целом
>устраивает народ такой какая есть.
Сейчас Линух активно занимает настольные компы юзерей - уж больно глиста указалась уродом ;) Много вендузятнегов закипишевало. (Сам то чего на Линух перешел? :)
Будут поялвяться сторонние дрова ко всяким новым железкам - и не обязательно эти дрова будут как открытыми как и стабильными. Совсем необязательно...
Где выход? Архитектура железа - практически константа в данном вопросе.
А Линух - конструктор. Очевидно что нужно менять... Разве нет?
>Примерно как НТя мало поменялась с 4-й
>до 6-й версии внутрях.А нафига ломать то что работает и довольно
>неплохо?
чтобы гарантировать это "неплохо", а не "поставил новый драйвер - вроде система не падает пока..."
>>Его можно изменять и дорабатывать безо всяких лицензионных проблем. Это круто.
>А зачем при этом пытаться примазываться к славе Линуса?
я его уже использую - уже примазалсо :)
К нему много кто так примазалсо ;) Так что ж мне делать?
Не использовать Линукс, чтоб не примазываться к славе Линуса? :)
А использовать и дорабатывать - это одно и то же для Линуха. Можно и то и другое.
Кроме того, если уж подобное когда-нибудь увидет свет _не_ от Линуса - то название типа "MicroLinux" будет весьма ок (RTLinux например - все ок с этим). Да и все дистры используют слово Linux в своих названиях - никто не видит в этом проблем :) Хоть и все хотят "примазаццо" к славе Линуса ;))
>Линукс стал известен таким
>какой он есть сейчас.
а кто сказал, что он не станет более популярен в виде микроядра?
Или кто-то (кроме всяких бздшников и вендузятнегов) считает достигнутой популярности Линуха - достаточной? ;)
>Пытаться сделать из него "миникс но только популярный"
>извините не очень хорошо пахнет.
Это кто как воспринимает мир :) Будет такая версия для кого-то "популярным миниксом" - ну наздоровье :)
>А почему бы Таненбауму или кто там
>еще так фанатеет не сделать СВОЮ систему?У нее ведь 1 фиг
>с Линуксом общего юудет только ... название.Что не особо честно.
Еще одно ядро Linux - это повод получить пиндюлей от Торвальдса как держателя торговой марки Linux :) Кому охота? Вопрос просто в том: зачем и как будет использован/создан тот второй линух. Если под GPL'ем и во благо миру - просто попросит (может этот кто-то не знал, шо Linux уже есть??) Линус сменить что-то в названии. Хоть пару букв добавить - чтоб народ не путалсо. Будет этот кто-то выеживаццо - права на марку у Торвальсда.... ;)
Вот дистры тоже используют торговую марку Линуса. Но под GPL'ью, во благо и имя отличаеться от просто "Linux" - все довольны, всех можно различить :)
>>Переделать именно Линукс БЕЗ потери _всей_ его функциональности (допустима некоторая
>>потеря производетельности,
>Не думаю что юзеры положительно оценят допустимость в этом случае.Хотелось бы чтобы
>базовая часть системы была так быстра как возможно.
кого достали тормоза - будет все так же рад монолиту.
Кого зае**т глюки - с радостью заюзает микро версию.
Свобода выбора :)
>А насколько притормозят аппликухи...
>ну они и созданы чтобы жрать ресурсы - не системное это
>дело, даденые ресурсы хавать :)
хорошо сказал ;))
>> _не_ функциональности) - самый простой и быстрый путь к постоению
>>микроядра уровня Линуха (меньше - просто не нужно).
>Так и хочется сказать - к построению популярного миникса с другим названием
>руками линуксоидов за их счет :)
ну так скажи, коль хочеться :)
Какая разница как оно будет называться, если будет под GPL и решит кому-то его проблемы? :)
>>остаються доступными всем на RW. И не в них ли собираеться
>>отспамиться перед смертью очередной кривой ядерный процесс??
>По хорошему должно быть разделение и в ядре кому куда можно писать.На
>оснвании ID потока и соотв. ACLs или типа того :)
>см. бред про ACLs.Увы, я так понимаю что сие не поддерживается
>железом а потому не судьба.
см. пост про твое новое железо на основе "бреда" про ACLи %)
x86 _МОЖЕТ_ это, поэтом судьба, еще и как.
>>работы. Шаг влево/право ему не даст сделать ядро.
>А по хорошему не должно давать железо :) эх, вредно читать про
>Cell под утро :).После чтения про изолированный режим и прочая в
>голову лезет совсем необычная байда.
представь новость: "Вышел новый проц от Интел с поддержкой потоков венды. Линукс не совместим.". Просто пиздец.... Вот к чему ведет отсутствие гибкости аппаратными решениями заведомо софтверных проблем.
Сделаешь проц с вот такой поддержкой защиты потоков - потеряешь возможность гибкого подхода в софте. А в чем проще поменять что-либо: в проце или софтине?
Проц - лишь движок, дающий базовые возможности управления.
Остальное - дело софта. Потому как гибкость. А с ее помощью можно делать упор и на производительность (монолит) и на надежность (микроядро).
Вот надо тебе погамиццо - ребутнулсо в монолит и поимел свой быстрый FPS %)
Надо предметно поработать - бутнул микроядро.
ELF формат программ и там и там один и тот же :)
>>Еще и как прыгает. Каждый (!!) системный вызов наделяеться дополнительными проверками по
>>таблице разрешений.
>Эээ... а что, для этого ядро прыгает между кольцами?Сомневаюсь что-то.
нет конечно. Но ты ж на что давишь:
что на переключение контекста (даже кольца тут непричем - они за 1 инструкцию переключаються) - уходит много времени (кста, всего 60 инструкций. см. arch/i386/kernel/process.c: __switch_to())
так вот пробежаться по таблицам доступа SELinux (те же твои ACLи) - это тоже такты! тоже затраченное время.
Следовательно, старый факт: защита требует каких-то ресурсов, как ни крути.
>Угу.И вопрос в том когда существующих решений уже достаточно а для особо-параноидальных
>есть специфичные решения типа qnx-ов всяких.
заметь: было бы таких параноиков мало - QNX мог бы и не существовать.
Но почему-то он есть же.... И много в него сил вложено - кому-то это надо.
Почему бы не заиметь такое же, но GPLное? :)
>>У микроядра НЕ эта задача. Тут опять идет путаница понятий из первого
>>пункта.
>>Микроядро, если драйвер упал, - пытаеться решить что делать софту дальше.
>...если возможности того что работает позволят это сделать :)
разумно заметил, хотя с этим никто и не спорил.
Сгоревшему процу на однопроцессорной смистеме не помогут уже никакие алгоритмы ядра...
>>Если новоперезапущенный драйвер видухи не справляеться с ней - то это точно
>>не проблема микроядра. Оно свое дело сделало. Остальное - проблема производителя
>>видухи и драйвера.
>Т.е. глючный драйвер 1 фиг сможет прилично поднасрать.Ну и нахрен этот огород
>нужен?
Сам себе и видухе он может поднасрать.
Если для тебя система нужна только для видео - то вместе с видео драйвером ты теряешь _ВСЮ_ функциональность и ессьно пойдешь ребутиться.
А огород этот нужен тем, кого интересует функциональность не одного драйвера, а нескольких. Вот люблю я под сон поставить музычку себе и заставку какую присыпляющую на монике. Ну была заставка кривая и навернула все иксы с драйвером видухи с концами... ну полный пиздец, а не случай конечно... Но я то уже почти заснул и музыку слушаю дальше - потому как запускаю я ее в mpd ;)) и звуковуха никуда не отпала.
Так что на видуху мне пофик (до утра конечно ;) и буду спать под музыку как и люблю :)
А если с моего компа кто чего пользует по сетке... файлопомойка какая или той же X сессией зашел со своего компа потому как OOo ставить влом... %)
Почему все эти люди тоже должны немедля пасть жертвами кривых ati-шных дров?
Или мне отдельный комп покупать для них??? жирновато....
>>Так может не будем путать теплое с мягким: поведение ядра при падении
>>драйвера и починит ли производитель этот драйвер когда-нибудь?
>А одно напрямую связано с другим.Чем серьезнее последствия бага, тем быстрее починят
>этот баг и тем больше шансы что это вообще произойдет.Это увы,
>особенно актуально для нвидий и ати всяких как и прочих корпораций
>- я так понимаю вы их атакуете намеками на жирные проприетарные
>бинари.Если баг вычищает хард в ноль - его починят завтра же.Если
>баг раз в час вызывает мерцание пары пикселей скрина не там
>где надо, на это положат болт.
именно. Но это уже политические и экономические вопросы. Проблема
больших корпораций. Там бюрократия развита дальше некуда.
А если мне дядя Вася из соседнего подъезда склепает видуху и дрова (да, вот есть у меня такой дядя Вася и все тут :)),
и будут какие-то глюки - то, ессьно, я его найду очень шустро и все мне будет пофикшено.
Но пока я соберусь к нему в гости сходить поведать о баге - то все так же не хочу, чтоб мои друзья были отрезаны в это время от сервисов моего компа. Иначе проблема с фидухой становиться критичной для меня, а мне например на работу бежать...
Нахрена мне _срочные_проблемы_ если можно это починить и попожже без приостановки других сервисов?
>>8. Ну и конечно же стоит бороться за открытость драйверов.
>>Но, это не тема текущего разговора. Это политика. А мы - про
>>технику пока что.
>Одно от другого не отделить.Потому что это не сферический конь в вакууме
>как у Таненбаума.Это реальная система в реальном мире для людей которые
>ее реально используют, а не просто смотрят на систему как на
>экспонат как это в случае Таненбаума происходит.Это как жить в 3-мерном
>мире но рассматривать только 1 измерение и потому верить что мир
>одномерный :).
да, согласен :) хорошее сравнение ;)
>Система для реального мира должна отвечать требованиям разработчиков и пользователей,
>даже если это вносит некоторую неидальность в систему.Иначе она будет никому
>нафиг не нужна.Примерно как таненбаумовский миникс - при такой оторванности от
>реального мира совершенно все-равно насколько он там круто задуман внутри, будет
>игрушкой для кучки студентов и академиков:)
Если говорить именно о миниксе (этих 600 килах в архиве) - то он просто страдает от нехватки драйверов по большому счету. Ядро вроде и есть, но надо еще поискать винт, на который эта система встанет. Нет дров - мало кто ее будет пользовать и находить баги...
А раз есть Линух - то и подавно средний юзер не будет исследовать какое-то непонятное ядро без драйверов...
Вобщем, идея разделения модулей ядра в отдельные виртуальные пространства - самое ценное, что можно взять из идеи Таненбаума.
(ппц. 4 часа над ответом просидел!!)
