Вышло (http://groups.google.com/group/fa.linux.kernel/msg/1d34bcc6b...) Linux ядро 2.6.16.38 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.38) с исправлением накопившихся ошибок, 10 из которых связанны с проблемами безопасности (в 2.6.19.2 (http://www.opennet.me/opennews/art.shtml?num=9480) данные ошибки исправлены):- incorrect user space access locking in mincore()
- i386: save/restore eflags in context switch
- Call init_timer() for ISDN PPP CCP reset state timer
- x86_64: Don't leak NT bit into next task
- grow_buffers() infinite loop fix
- corrupted cramfs filesystems cause kernel oops
- handle ext3 directory corruption better
- ext2: skip pages past number of blocks in ext2_find_entry
- hfs_fill_super returns success even if no root inode
- Bluetooth: Add packet size checks for CAPI messagesURL: http://groups.google.com/group/fa.linux.kernel/msg/1d34bcc6b...
Новость: http://www.opennet.me/opennews/art.shtml?num=9588
Вступайте и компелируйте!
:-(
Смайлик грусти что исправили? Больше радовало наличие дыр? :)
ну видимо не компилируется тазик, потому и грустный смайлик ))
Что-то я уже путаться стал в этих ядрах...
заголовок *дцать лет спустя: в linux ядре 2.9.40.55.78.65.34.80 исправлено 10 проблем безопасности
>что-то вам всем плохо от наличия выбора... ;)Похоже, что ты прочитал где-то маркетинговую мантру "выбор это хорошо, он у вас есть и это круто!", но не анализировал.
Не то что мне плохо, смотрю вот сюда http://www.gentoo.org/doc/en/gentoo-kernel.xml и просто хренею. Даже новичок будет думать а что ему поставить - ванилу или женту. И спрашивается нафига же тогда ванилла? Чьих баг бояться - родных или напатченых? Да и в списке маловато ядер. Кол-во этих ядер там должно быть 2^(кол-во фич) или 2^(кол-во патчей), а там их около полутора десятка.
Выбор, мой друг, радости никому не приносит. Разве что тем, кто коллекционирует мысли о возможности выбора под воздействием внешнего запудривания мозгов, да и то пользы от этого - в форуме пописать. Выбор - это всегда путь к сомнениям и бездействию. Выберешь одно - будешь хотеть фичи из другого. Да и сам факт наличия нескольких инструментов, которые должны решать одни и те же проблемы, ставит под сомнение факт, что хоть какой-то из них решает эти проблемы хорошо. И что какой-то из них продолжит свою жизнь а не станет заброшеным проектом, а тебе потом "мигрировать".
И даже если ты ориентируешься в инструментах, если ты выбираешь одно решение из десяти приблизительно одного уровня качества, то толку в таком выборе нет. Если же из десяти решений только одно является стоящим, а остальные просто поделки, то это также уже не выбор, тут у тебя его нет.
Смотрю как знакомые прыгают по дистрам и понимаю, что они только и делают, что "выбирают".
>Даже новичок будет думать а что ему поставить - ванилу или женту
Это если придурок какой-нить ему посоветовал или то, или то. Новичку ни то, ни то нафиг не упало.>И спрашивается нафига же тогда ванилла?
Для разработчиков и майнтейнеров, вестимо. И тех, кому так на проекте написано (железом, например, и/или специфическим сочетанием левых патчей).Вообще это давно известная официальная позиция kernel.org -- "ядра для пользователей живут в дистрибутивах". Равно как и libc-alpha@.
>Чьих баг бояться - родных или напатченых?
Тех, которые могут быть актуальны. Выбирать же осмысленно в т.ч. с учётом того, кого как получается пинать. В дистрибутиве на "а у меня тут не работает" могут ещё потратить время на разборки, а вот в LKML могут и послать учить матчасть для начала.>Выбор, мой друг, радости никому не приносит.
Отучитесь расписываться за всех, а? Ещё как приносит, когда результат оказывается хорош. Иначе вся жизнь безрадостная [была бы] ;-)>Выбор - это всегда путь к сомнениям и бездействию.
"Категоричные утверждения абсолютно неверны!">Выберешь одно - будешь хотеть фичи из другого.
Ну так человек с головой выбирает по взвешенной совокупности фич и проблем, а совсем с головой -- ещё и в контексте временнЫх изменений этого баланса.>Да и сам факт наличия нескольких инструментов, которые
>должны решать одни и те же проблемы, ставит под сомнение факт,
>что хоть какой-то из них решает эти проблемы хорошо.
Ещё одно бессмысленное по сути утверждение.>Смотрю как знакомые прыгают по дистрам и понимаю, что они только и
>делают, что "выбирают".
Я вот давно "допрыгался". Ключик в том, что разевать рот на "чужие фичи" или рукомашествовать, что из них непременно надо втянуть разработчикам используемого дистра -- не помогает.Помогает:
- выбрать дистр, который в основном имеет нужное;
- при расширении или сдвиге понятия "нужное" помогать дорабатывать дистрибутив или производить переоценку факторов (повторный SWOT, например).См., например, http://www.freesource.info/wiki/AltLinux/Features#h3455-4
>Не то что мне плохо, смотрю вот сюда http://www.gentoo.org/doc/en/gentoo-kernel.xml и просто хренею.
>Даже новичок будет думать а что ему поставить - ванилу или
>женту. И спрашивается нафига же тогда ванилла? Чьих баг бояться -
>родных или напатченых? Да и в списке маловато ядер. Кол-во этих
>ядер там должно быть 2^(кол-во фич) или 2^(кол-во патчей), а там
>их около полутора десятка.аа... вы - тот человек, у которого мозг заточен под *BSD?
дык это... откройте для себя overlays наконец-то =)
И ещё: это ветка 2.6.16.х, которую поддерживает один энтузиаст.
Интересно как вы бы реагировали, если бы в феврале-марте месяце нашли бы дыру в freebsd 4?
>аа... вы - тот человек, у которого мозг заточен под *BSD?Не под БСД. Просто заточен. БСД хорошо вписалось.
>
>дык это... откройте для себя overlays наконец-то =)на той страничке генту нет такого слова.
>И ещё: это ветка 2.6.16.х, которую поддерживает один энтузиаст.
>Интересно как вы бы реагировали, если бы в феврале-марте месяце нашли бы
>дыру в freebsd 4?Причём тут это? Те вопросы что я тут высветил это вопросы любого кто сталкивается с этим впервые. И на них ответа _там_ нет. И вообще не видно.
>>аа... вы - тот человек, у которого мозг заточен под *BSD?
>Не под БСД. Просто заточен.
Претенциозно, но некорректно.>БСД хорошо вписалось.
Интересно, что при этом выписалось...>>И ещё: это ветка 2.6.16.х, которую поддерживает один энтузиаст.
>>Интересно как вы бы реагировали, если бы в феврале-марте месяце нашли бы
>>дыру в freebsd 4?
>Причём тут это? Те вопросы что я тут высветил это вопросы любого
>кто сталкивается с этим впервые.
Нет, это вопросы или ламера (не путать с чайником!), или обманутого ламером.>И на них ответа _там_ нет. И вообще не видно.
Знаете, боюсь, это к качеству или вообще пригодности того, чем затачивали. Даже с моими -3.5 на глаз ответы на такие банальные вопросы прекрасно и давно видны. И даже не потому, что "места знать надо".Просто вписалось -- другое. И выписывалось, видимо, тоже другое.
>>дык это... откройте для себя overlays наконец-то =)
>на той страничке генту нет такого слова.Т.е. набрать в google "gentoo overlays" и попасть на http://overlays.gentoo.org/ совсем не судьба? :)
>Те вопросы что я тут высветил это вопросы любого
>кто сталкивается с этим впервые. И на них ответа _там_ нет.
>И вообще не видно.
А вот почему в freebsd handbook так мало про MAC написано? :)
>Т.е. набрать в google "gentoo overlays" и попасть на http://overlays.gentoo.org/ совсем не
>судьба? :)
Ага! Т.е. чтоб узнать женту поближе сайта http://www.gentoo.org недостаточно. Ну, во-первых, я ламер, и слово overlays ещё не состоит в ассоциативном ряду со словом gentoo. Побродив по нескольким страничкам документации на http://www.gentoo.org, где-то вглубинке нашёл слово overlays в разделе diverting from main tree или типа такого, но объяснения что это и ссылки на http://overlays.gentoo.org/ не нашёл. Что же это за документация что для того чтоб это увидеть нужно зайти на опеннет и там найти ацкого анонимуса который пошлёт на гугл который потом пошлёт на другой сайт в домене gentoo.org.
А вот как ты, ацкий анонимус, нашёл этот сайт? Тоже через гугл?
Кстати, замечу, тот же сайт http://www.freebsd.org/ в самом верху имеет прекрасный маленький квадратик куда я могу вбить слово и нажать кнопку search. Но с официальным сайтом женту без гугла, видимо, не обойтись. ;)
>Кстати, замечу, тот же сайт http://www.freebsd.org/ в самом верху имеет прекрасный маленький
>квадратик куда я могу вбить слово и нажать кнопку search. Но
>с официальным сайтом женту без гугла, видимо, не обойтись. ;)
Аа... а я то думаю, чего это Free BSD машины в рунете - часто фигурируют как самые дырявые сервера, что вообще-то нонсенс для такой надежной системы как FreeBSD (достаточно почитать securitylab.ru - сводки о взломаных серверах).А это оказывается не ос дырявая, это админы там такие вот бакланы которым гуглю поюзать - сложная наука :).Ну тогда понятно все, а то я всю бошку сломал - каким макаром бздя может оказываться по статистике самой дырявой :).Думал селаб жулит, не, судя по прочитанному - похоже, не жулит...
>>что-то вам всем плохо от наличия выбора... ;)>Не то что мне плохо, смотрю вот сюда http://www.gentoo.org/doc/en/gentoo-kernel.xml и просто хренею.
не смотри раз хренеешь, ато моск сломаешь %)>Даже новичок
это как раз для них и написано. Кто уже у руля - туда не ходят>будет думать а что ему поставить - ванилу или
>женту. И спрашивается нафига же тогда ванилла? Чьих баг бояться -
>родных или напатченых? Да и в списке маловато ядер. Кол-во этих
>ядер там должно быть 2^(кол-во фич) или 2^(кол-во патчей), а там
>их около полутора десятка.ой-ой! мы не мошем понять нужен ли нам саспенд на винт или параноидальное секурити??
товарисч, какого вы тогда туда пошли??
Тем более что для тех "кто не уверен" есть просто gentoo-sources. И там об этом сказано:
----------CUT-----------
General purpose: gentoo-sourcesFor most users, we recommend the gentoo-sources kernel.
----------/CUT-----------
>Выбор, мой друг, радости никому не приносит.
забрось эти масштабные заявления о том, что ты не в теме.>Разве что тем, кто коллекционирует
>мысли о возможности выбора под воздействием внешнего запудривания мозгов,
а если еще кому? или тебя это выводит из понимания ситуации?? ну так чьи это проблемы?>да и то пользы от этого - в форуме пописать.
не спорю, _и_ в форуме пописать тоже.
Елси у кого проблема воспользоваться тем, о чем он пишет - ну так, опять же: чьи это проблемы?>Выбор - это
>всегда путь к сомнениям и бездействию.
странное у тя понимание о выборе.
Есть сказочка про ослика, который умер от голода между двумя стогами сена. Не мог решить что вкуснее.
Кажись, это про тебя было ;)))>Выберешь одно - будешь хотеть
>фичи из другого.
слава богу не только бинарями распространяются ядра.
Знаешь, что такое патч?? Так вот если тебе нужно и того и другого - берешь и патчишь
себе кернель нужными вещами.
Или это слишком сложно для дохлого ослика?? %)>Да и сам факт наличия нескольких инструментов, которые
>должны решать одни и те же проблемы, ставит под сомнение факт,
>что хоть какой-то из них решает эти проблемы хорошо. И что
>какой-то из них продолжит свою жизнь а не станет заброшеным проектом,
>а тебе потом "мигрировать".
О. че-то новенькое :)
Это уже ослик, который _не_ хочет хавать из обеих стогов, потому как сомневаеться в
качестве их сена.
Ну так иди жуй бздю или соляру какую :)
Кто тебе не дает?
Выбор (о, какую боль несет это слово....) то никто не отнимал у тебя ;)
>И даже если ты ориентируешься в инструментах, если ты выбираешь одно решение
>из десяти приблизительно одного уровня качества, то толку в таком выборе
>нет. Если же из десяти решений только одно является стоящим, а
>остальные просто поделки, то это также уже не выбор, тут у
>тебя его нет.
ЕСЛИ>Смотрю как знакомые прыгают по дистрам и понимаю, что они только и
>делают, что "выбирают".
святая правда. Они выбирают.
Могут и надо им, значит.
Кто не может или не надо - не выбирает :)Значит, рано или поздно они найдут кому что по душе и будут счастливы с этим.
А какова судьба того, кто не хочет именно _выбирать_??? С чем ему жить решает просто фортуна :))
Я же хочу верить, что я хоть чуток управляю своей судьбой ;)
>А какова судьба того, кто не хочет именно _выбирать_???
Простая.За них все решают в Редмонде, в местечке с говорящим названием One Microsoft Place... :)
Да всех на венду уж... Ток потом чур не кричать: "Эй, где вы есть?" (с) Джентельмены удачи.
>Да всех на венду уж... Ток потом чур не кричать: "Эй, где
>вы есть?" (с) Джентельмены удачи.а что толку звать иди***ов, которые готовы платить за кусок г***на???
Поверьте, всё не так уж сложно!
уж сколько лет ext2, а все и там дыры находят, даже сендмыло почти от дыр очистили :-) Никогда не юзал линукс отсудя вопрос, вот дырку в ванильном ядре заклеили, потом все дистростроители должны накатить патчи на свои ядра и раздать это все на обновления, как быстро происходит этот процесс в разных попсовых дистрах? гента там или дебиан, или скажем убунта?
>уж сколько лет ext2, а все и там дыры находят, даже сендмыло
>почти от дыр очистили :-) Никогда не юзал линукс отсудя вопрос,
>вот дырку в ванильном ядре заклеили, потом все дистростроители должны накатить
>патчи на свои ядра и раздать это все на обновления, как
>быстро происходит этот процесс в разных попсовых дистрах? гента там или
>дебиан, или скажем убунта?попсовые - авторитетное заявление от чела, который "Никогда не юзал линукс". ошибки безопасности в ядре не устраняются разработчиками дистров.
>>уж сколько лет ext2, а все и там дыры находят
Это вообще-то проблема языка C, что никак не дотумкают некоторые из неуловимых джо.>>даже сендмыло почти от дыр очистили :-) Никогда не юзал линукс отсудя вопрос,
Ну-ну. Мне нравится это "почти".>>вот дырку в ванильном ядре заклеили, потом все дистростроители должны накатить
>>патчи на свои ядра и раздать это все на обновления, как
>>быстро происходит этот процесс
Depends, см. secunia.com.>>в разных попсовых дистрах? гента там или дебиан, или скажем убунта?
>попсовые - авторитетное заявление от чела, который "Никогда не юзал линукс".
И при этом решил повыглядеть круто. Ну, повыглядел.>ошибки безопасности в ядре не устраняются разработчиками дистров.
В свою очередь, и Вас посылаю на secunia.com или lwn.net/security. Дабы не разбрасывались не менее авторитетными заявлениями, хорошо?
ух, как вы остро на все реагируете, а не дай Бог линукс виндовсом обзову наверно клаву об монитор разобьете :-)
Попсовость любого дистрибутива определяецо просто на дистровотче, те кто в первой десятке те ПОПулярны ака попсовы, и не надо так бурно реагировать. :) Так вот авторитеты окружающие меня советуют либо генту либо дебиан... попробую наверное и то другое, диск с гентой уже помел, пока накачу на тестовый комп посмотрю что из себя представляет линукс в обработке от генты, насколько действительно опасны все эти дырки, ато может это и не дырки вовсе а так пугают просто и суточной задержки в накатывании патча вполне достаточно чтобы чувствовать себя вплоне защищенным.
Вот еще один вопрос кстати, куча мануалов и хаутушек содержит рекомендации по установке того или иного софта через tar -zxvf ... затем ./configure и вперед, понятно что это потом фик обновишь и тд, кто-то из вас - гуру, реально ставит так софт, или все строго через портежи/пакаджи?
>ух, как вы остро на все реагируете, а не дай Бог линукс
>виндовсом обзову наверно клаву об монитор разобьете :-)
:)>Попсовость любого дистрибутива определяецо просто на дистровотче, те кто в первой десятке
>те ПОПулярны ака попсовы, и не надо так бурно реагировать. :)
Технически говоря(TM), там счётчик накручивается. Ну или накручивался несколько лет назад, Ладиславу было так же влом это дело фиксить, как мне -- обеспечить нахождение того же ALT (или чего угодно) на первой позиции. :)>Так вот авторитеты окружающие меня советуют либо генту либо дебиан...
Хотите хороший, хоть и бесплатный, совет? Взвешивайте советы авторитетов с учётом того, какое время они готовы выделить на помощь, и её результативности.А то развелось либо советчиков, которые потом как-то пропадают с горизонта при вопросах, либо вроде бы и охочих помочь даже, но вот незадача -- у них для этого знаний недостаёт.
>попробую наверное и то другое
Эт разумно и похвально. В смысле проверять и сравнивать самому. А то "мне тут Рабинович напел" бывает ;-)>насколько действительно опасны все эти дырки, ато может это
>и не дырки вовсе а так пугают просто и суточной задержки
>в накатывании патча вполне достаточно чтобы чувствовать себя вплоне защищенным.
Многие дырки в том же ядре Linux неактуальны вне определённых архитектур (например, IA64); или железа (например, ISDN); или настройки (например, разрешено дампанье коры, бишь core dumps). Дырка дырке тоже рознь, особенно когда их многовато по сумме -- спички не брёвна.Это же касается и софта вообще (что юниксового, что виндового или иного). "Аналитика", где циферки отчётов о проблемах просто суммируются без ранжирования и взвешивания -- заведомая туфта, в чью бы сторону их не подгибали.
>Вот еще один вопрос кстати, куча мануалов и хаутушек содержит рекомендации по
>установке того или иного софта через tar -zxvf ... затем ./configure
>и вперед, понятно что это потом фик обновишь и тд
Опять же хорошо, что понятно. "и т.д." в т.ч. включает "фиг удалишь", между прочим.>кто-то из вас - гуру, реально ставит так софт, или все строго
>через портежи/пакаджи?
Я не гуру, просто когда чего-то не хватает -- собираю пакеты. Результаты -- в основном можно посмотреть здесь: http://sisyphus.ru/packager/mike/srpmsНа самом деле это действительно кругом лучше, кроме того, что _сходу_ приходится потратить больше (порой в два, три или более раза) времени: разбираешься с софтиной и тем, как её готовить, не только для себя, но и для других. И если хорошо разобрался и оформил понятое (или даже уже опыт) в пакет, то через год или два, когда всё напрочь забудется (а можешь продолжать считать, что "знаешь" -- настраивал же!), пакет просто встанет и заработает. Ну мож пересобрать придётся.
Соответственно опытные майнтейнеры пакетов в дистрибутивах зачастую или участвуют в проектах, результаты которых упаковывают, или являются опытными администраторами, которым тем меньше мороки по работе, чем лучше работает пакет. Но и у них зачастую бывает куча всяких мелочей, до которых руки не доходят -- поэтому даже в большом и оживлённом дистрибутиве и сообществе вроде дебиана есть чем помочь и "начинающему", который уловил эти вот особенности "разбирательств не только для себя".
P.S. См. тж. о делах пакетных:
http://lists.altlinux.org/pipermail/devel/2007-January/04048...
http://lists.altlinux.org/pipermail/devel/2007-January/04050...
http://lists.altlinux.org/pipermail/devel/2007-January/04050...А вот и про "ванильное ядро" (вообще тред интересный местами вышел, как и всегда про наболевшее):
http://lists.altlinux.org/pipermail/devel/2007-January/04048...
>>Так вот авторитеты окружающие меня советуют либо генту либо дебиан...
>Хотите хороший, хоть и бесплатный, совет? Взвешивайте советы авторитетов с учётом
>того, какое время они готовы выделить на помощь, и её результативности.
>
>А то развелось либо советчиков, которые потом как-то пропадают с горизонта при
>вопросах, либо вроде бы и охочих помочь даже, но вот незадача
>-- у них для этого знаний недостаёт.dvl_lab,
по этому вопросу - могу предложить свою помощь.
Если будут вопросы по Генту или Дебиану - милости прошу:
gentuu ЭТъ gmail _ comну или в любом форуме опеннета соответствующей тематики :)
>Вот еще один вопрос кстати, куча мануалов и хаутушек содержит рекомендации по
>установке того или иного софта через tar -zxvf ... затем ./configure
>и вперед, понятно что это потом фик обновишь и тд, кто-то
>из вас - гуру, реально ставит так софт, или все строго
>через портежи/пакаджи?отнюдь
полюбопытствуйте, например, здесь:
http://gentoo-wiki.com/HOWTO_EncFSкак видно, хауту состоит из некоторого просвещения о том, что нужно сделать
и собственно сами действия: че-то за'emerge'ить, где че вписать в конфиг:
----------CUT----------
Start by emerging the necessary packageemerge encfs
At this point it is probably necessary to load the newly created module using
modprobe fuse
----------CUT----------
ессьно, все, что советуеться к утсановке, ставиццо из портеждей и, ессьно, обновляемо/выносимо
>уж сколько лет ext2, а все и там дыры находят, даже сендмыло
>почти от дыр очистили :-) Никогда не юзал линукс отсудя вопрос,
>вот дырку в ванильном ядре заклеили, потом все дистростроители должны накатить
>патчи на свои ядра и раздать это все на обновления, как
>быстро происходит этот процесс в разных попсовых дистрах? гента там или
>дебиан, или скажем убунта?в генте иной раз быстрее ваниллы.
Если проблема некритична - то Торвальдс может и не зарелизить очередное ядро пока не наберет больше патчей.
в гентушном же ядре применяеться комплексный патч, состоящий из 2 наборов патчей:
- base (фиксы)
- extras (фичи)вот base и полниться патчами пока незакрытых проблем ваниллы, причем в течении дня после публикации проблемы. Иной раз просто обновиться некогда, хотя фикс уже в портаже.
в генте быстро, сразу новый 2.6.??-r? выходит
В месте мы сила!
технологиям пора бриться. девелам придется
полностью переделывать ядро, чтобы такие
ошибки были невозможны впринципе.
Слова абсолютно некомпетентного человека, не разбирающегося в разработке.
Невозможно написать софт без ошибок, потому что его пишут люди, а не машины.
Другое дело что в ядре линукса секюрити багов на порядок меньше, чем в конкурирующей системе.
угу. именно по тому, что "меньше security holes, чем в
конкурирующей системе" рекомендуют пользовать самое
последнее ядро, ибо еще эксплойт не успели написать.
и что? по 10 раз на дню ядро компилить?
про конкурирующие системы. вы не про *BSD упоминаете?
>про конкурирующие системы. вы не про *BSD упоминаете?BSD про конкуренцию Линуху пока мечтать тока приходиццо
>технологиям пора бриться. девелам придется
>полностью переделывать ядро, чтобы такие
>ошибки были невозможны впринципе.
Видите ли, это из серии "остановите Землю, я сойду". Пока человечеству весьма посредственно удаётся исправлять или не допускать вновь куда более серьёзные и дорогие ошибки, а тут -- "технологии"...Страшная штука -- historical reasons и backwards compatibility.
Ребят, вы видимо не в курсе, что любой кривой драйвер
может Линукс завесить. а это так полагаю еще предстоит
девелам исправлять. А то, что технологиям пора бриться,
так это слова господина Торвальдса.
>Ребят, вы видимо не в курсе, что любой кривой драйвер
>может Линукс завесить.
А Вы, видимо, не в курсе, что на некоторых интеловских матерях можно убить boot block последовательностью команд специального вида. Это даже не BIOS, это bb, который во впаянной микросхеме, а не флэше/кроватке. Кажется, вне зависимости от архитектуры ядра.И что с того?
>а это так полагаю еще предстоит девелам исправлять.
Вашим? Ну, удачи. Ядерные отчасти уже высказались, причём на LCA некоторые -- будто вполне определённо "ой хорошо, что драйверы в ядре решили оставить".>А то, что технологиям пора бриться, так это слова господина Торвальдса.
Им это не поможет, поскольку проблема не в них даже.
>И что с того?
То что некоторые не знают что сдуру можно и х** сломать.И хотят чтобы система их связывала по рукам и ногам и не давала это сделать даже если хочется.Только вот любая защита мигом превращается в ... тюрьму, когда перестает позволять сделать "запрещенное" действие в случае когда очень надо.>>а это так полагаю еще предстоит девелам исправлять.
>Вашим? Ну, удачи. Ядерные отчасти уже высказались, причём на LCA
>некоторые -- будто вполне определённо "ой хорошо, что драйверы в ядре
>решили оставить".
А если выкинут - сами и будут пользоваться своим тормозиловом.В линуксе и так предостаточно не особо быстрых драйверов.Если их перенести в юзерспейс, скорость работы будет чебурашья.Лично мне нужна операционка а не еще одно подобие тормознутой JVM.>>А то, что технологиям пора бриться, так это слова господина Торвальдса.
>Им это не поможет, поскольку проблема не в них даже.
А кто побреет людей?Дело то не в технология.Root cause - в людях...
>>а это так полагаю еще предстоит девелам исправлять.
>Вашим? Ну, удачи. Ядерные отчасти уже высказались, причём на LCA
>некоторые -- будто вполне определённо "ой хорошо, что драйверы в ядре
>решили оставить".
Ща я переплюну Танненбаума и даду вам урок правильного программировния XXII века :)
Машинный код, даже в ring3 - он, сцуко, опасный.Хакеры могут устроить buffer overrun и вообще, не модно как-то... поэтому...
...давайте будем выполнять драйвера в виртуальной среде.Пущай дрова пишутся на перле, питоне, пхп, яве, дотнете, или даже шеллскрипте, а уже оно делает вызов в user-mode фреймворк который потом передаст это ядру.Вот.Тормозно?Зато красиво :) никаких переполнений буфферов, а от упавшего скрипта ни один бурундучок не пострадает, юзера даже крашдампы и дампы регистров не побеспокоят - у системы просто отвалится железка и все :).Правда я еще не придумал что система должна сделать если грохнулся драйвер харда и она не может получить доступ к свопу но это уже детали :).Хотя для пущей важности - мы напишем на перле интерпретатор питона, на нем сделаем JVM которая будет интерпретировать жабистый байткод а поверх всего этого вкорячим дотнет(куда ж без него?), в котором и будет крутиться наш драйвер, вот.Манагер драйверов напишем на PHP на котором наваяем интерпретатор Ruby (а чтоб никому не было обидно, и все фреймворки при деле).В итоге хакеры просто сойдут с ума ломая такую систему и пытаясь вкурить где же заканчивается виртуальность.Для пущей важности число слоев виртуализации надо сделать рандомным, тогда хакеры стопудово загремят в дурку :).Ах да.Почему XXII века?Да дело в том что современные процессоры слишком слабы и убоги.У них нет аппаратного ускорения перлов, питонов, руби и жаб.Редкий процессор сможет что-то кроме выполнения самой такой операционки, хотя нет, пара инструкций в час от особо приоритетных процессов все-таки сможет наверное прорваться (назовем их реалтаймными, посколько это единственные которые хоть как-то работают а время все-таки реально существует :D).
OFFTOP:тьажолая у тебя работа, lamer :)
или трава сильная ;))стока напостил всего в разные темы, хрен перечитаешь... :)
>стока напостил всего в разные темы, хрен перечитаешь... :)
<off>Я не Танненбаум, меня не требуется цитировать или читать все мои сообщения до буквы:).Читай только то что тебе интересно в интересных темах.А так я иногда позволяю себе высказать свое мнение, редко собираюсь а потому делаю это сразу кучей... :)</off>
>Ребят, вы видимо не в курсе, что любой кривой драйвер
>может Линукс завесить.
Угу, а кухонным ножом можно и человека зарезать.И что?Запретить кухонные ножи?У вас каждый день падает линукс из-за сбоев в драйверах?У меня не падает... вы еще предъяву выкатите что баг в ядре может уронить систему, давайте типа, пускать системы как виртуалки на гипервизоре.Только окажется что баг в гипервизоре может повесить систему.Придется вам повеситься тогда самому, на сетевом шнуре...>а это так полагаю еще предстоит
>девелам исправлять. А то, что технологиям пора бриться,
>так это слова господина Торвальдса.
Разные времена, разные требования.Побрили бы позиксные RWXRWXRWX чтоли до полноценных ACL как дефолтного стандарта...
>технологиям пора бриться. девелам придется
>полностью переделывать ядро, чтобы такие
>ошибки были невозможны впринципе.
Сколько не брей технологии а брить то надо не их а людей.Идиоты-биллингисты или создатели ПО для банков из числа индусов например на "безопасной технологии Java" или оной же но дотнет умудряются такое откаблучивать что просто диву даешься.Ну да, нет у них переполнений буфферов.Зато есть какоенить КГАМ типа недостаточной валидации входных данных, покладание **я на ошибки, SQL-injections, XSS, а чаще - просто махровый дебилизм, который не лечится.Они умеют кодить.Но ни в зуб ногой не умеют ДУМАТЬ и понимать как оно будет работать.Поэтому появляются биллинги и банковский софт с идиотскими логическими ошибками, непродуманным дизайном и глюками которые намного более опасны чем взлом биллингового сервера через buffer overflow (это заметить сравнительно несложно на достаточно ранней стадии когда потери от этого не особо то и велики...).Потому что обладатель биллинга или никогда не узнает о них и втихарика пролетает силами находчивых юзеров на много денег, или, если слишком много народа начинает прокидывать обладателя биллинга и он начинает конкретно опускаться в денежную задницу - хватаются за голову и начинают спешно чинить сраный код.Через сколько найдут аналогичную дыру - остается только догадываться.Ибо их в таком сраном коде полно.
>на некоторых интеловских матерях можно убить boot block последовательностью команд специального вида. Это даже не BIOS, это bb, который во впаянной микросхеме, а не флэше/кроватке
Скорее всего, доступ по записи к этой м/с через какие-то порты В/В, которые доступны только из кольца 0 CPU в защищённом режиме или только в реальном. В защищённом из кольца 3 недоступны.
>Скорее всего, доступ по записи к этой м/с через какие-то порты В/В,
>которые доступны только из кольца 0 CPU в защищённом режиме или
>только в реальном. В защищённом из кольца 3 недоступны.
Я к тому, что при кривом железе страдать перфекционизмом по идеальному софту, мягко говоря, непрактично. Разумеется, это не повод делать Windows 95, но бессмысленно закалять колосса на заведомо глиняных ногах.
>>>Ребят, вы видимо не в курсе, что любой кривой драйвер может Линукс завесить.>> А Вы, видимо, не в курсе, что на некоторых интеловских матерях можно убить boot block
>> последовательностью команд специального вида. Это даже не BIOS, это bb, который во
>> впаянной микросхеме, а не флэше/кроватке. Кажется, вне зависимости от архитектуры ядра.этот глюк в материнской плате очень легко устраняется,
выпуском новой версии PCB, или новой прошивки биоса.проблема с тем, что любой кривой драйвер может заглючить всю систему -
не имеет такого легкого и простого решения. количество оборудования постоянно увеличивается, также увеличивается и количество драйверов в ядре Linux и от сторонних
разработчиков. следовательно количество падений системы и прочих проблем из-за кривых драйверов будет со временем также увеличиваться. если ничего не делать, то при таком же количестве драйверов, как во всех Windows вместе взятых - стабильность работы линукса
как раз и опустится где-то на уровень Windows 95-98.поэтому желательно уже сейчас начинать задумываться, как не превратить Linux в Windows 95.
> Я к тому, что при кривом железе страдать перфекционизмом
> по идеальному софту, мягко говоря, непрактично.эта ошибка не в софте, эта ошибка - в архитектуре ядра операционной системы.
мелкие баги возможно будут всегда, но архитектура должна стремиться к идеальной.
только таким способом у Linux есть безоблачное будущее и персперктивы развития.> бессмысленно закалять колосса на заведомо глиняных ногах.
полная смена аппаратной платформы - этот процесс происходит каждые 5-10 лет.
вспомни, что было раньше - отсутствие PNP, слоты ISA, дисковые контролеры PIO only.
сейчас - мало кто уже помнит, как загрузка процессора вырастала до 100%
при интенсивной работе с жестким диском. а это ведь была проблема посерьезнее,
чем тот мелкий дефект в некоторых интеловских материнских платах.операционные же системы - меняются гораздо реже, чем аппаратные платформы.
первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
>>> А Вы, видимо, не в курсе, что на некоторых интеловских матерях можно убить boot block
>этот глюк в материнской плате очень легко устраняется,
>выпуском новой версии PCB, или новой прошивки биоса.
Фигассе очень легко, даже если это было бы так... BIOS тут ни при чём AFAIK, его самого бутблок как раз грузит; как и PCB.>проблема с тем, что любой кривой драйвер может заглючить всю систему -
>не имеет такого легкого и простого решения.
В общем случае -- да, так и Ваше "решение" для ткнутой пальцем проблемки является весьма частным (и насколько знаю -- неверным). Сложные системы, как в программной, так и в аппаратной части, уже давно не подлежат полному описанию совокупности состояний по факту как минимум в "бытовых" (non-MCA) приложениях.Ну да это было как раз мелкой иллюстрацией более общей проблемы...
>> бессмысленно закалять колосса на заведомо глиняных ногах.
>полная смена аппаратной платформы - этот процесс происходит каждые 5-10 лет.
Да ладно. Вон Intel попытались раньше времени выкатить _действительно_ другую IA64 вместо IA32 -- это как раз конает на _смену_ -- и что? Пшик. При этом AMD, выкатившие продолжение той же старой истории о костылях, подпорках и bug compatibility, "вдруг" оказались на коне со своей x86_64.Похоже, что от i386 девяностых до x86_64 _прыжок_ произойдёт действительно *только* через 4Gb памяти в домохозяечной машине, как и пишет ESR в на удивление толковой бамаге World Domination 201.
>вспомни, что было раньше - отсутствие PNP, слоты ISA, дисковые контролеры PIO
>only. сейчас - мало кто уже помнит, как загрузка процессора вырастала до 100%
>при интенсивной работе с жестким диском. а это ведь была проблема посерьезнее,
>чем тот мелкий дефект в некоторых интеловских материнских платах.
Нет, конечно. Это была _другая_ проблема. Не блокер.>операционные же системы - меняются гораздо реже, чем аппаратные платформы.
Скорее operating environments как платформы тогда уж.>первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
Угу, но пока это неудобнее всего в VFS +/- с горячим подключением. Поскольку на шкафах такое было событием.
>>>> на некоторых интеловских матерях можно убить boot block>> этот глюк в материнской плате очень легко устраняется,
>> выпуском новой версии PCB, или новой прошивки биоса.> Фигассе очень легко, даже если это было бы так... BIOS тут
> ни при чём AFAIK, его самого бутблок как раз грузит; как и PCB.биос сначала инициализирует оборудование, и только потом уже
отдает управление операционной системе. совсем не обязательно
при этом оставлять открытой возможность модификации бутблока.
если програмно эта ошибка не устранятся - тогда новая версия PCB.>> проблема с тем, что любой кривой драйвер может заглючить
>> всю систему - не имеет такого легкого и простого решения.> В общем случае -- да
потому что проблема не в этом конкретном драйвере, а в архитектуре
взаимодействия ядра операционной системы и драйверов оборудования.например, если ядро пускать на 0-м кольце, а драйвера на 1-м, эта
проблема устраняется. появляется новая, с производительностью,
практически всегда голая производительность без надежности не нужна.потому и процессоры работают в защищенном режиме, а не Big Real Mode,
когда любая задача реального режима может адресовать все 4 гигабайта
оперативной памяти без страничных преобразований и прочих тормозов...например, на 386 машине с частотой ядра в 25 мегагерц Линус был вынужден
делать ядро монолитным, потому что потери производительности были очень
большими. но если бы он начинал писать свою операционку имея под рукой
двух- и четырех- ядерные процессоры, я почти уверен, что он тогда разнес
бы ядро операционной системы и драйвера оборудования по разным кольцам защиты.тем более, что 4-х ядерные процессоры - это совсем не предел,
частоту дальше повышать уже нерационально, при уменьшении техпроцесса
будут увеличивать количество ядер в одном корпусе. 8, 16, 32, 64, ...> Сложные системы, как в программной, так и в аппаратной части, уже давно
> не подлежат полному описанию совокупности состояний по факту как минимум
> в "бытовых" (non-MCA) приложениях.потому и перешли от DOS-like операционных систем к защищенным операционным
системам, кода глючная програма не может завалить операционку, или другие
программы. максимум что произойдет - аварийное завершение работы только
этой сбойной программы.> Ну да это было как раз мелкой иллюстрацией более общей проблемы...
если проблему не получается сформулировать - может быть есть проблемы с ее пониманием?
>>> бессмысленно закалять колосса на заведомо глиняных ногах.
>>полная смена аппаратной платформы - этот процесс происходит каждые 5-10 лет.> Да ладно. Вон Intel попытались раньше времени выкатить _действительно_
> другую IA64 вместо IA32 -- это как раз конает на _смену_ -- и что?например, интерфейсные шины ISA, MCA, VESA, PCI, PCI-X, AGP, PCI-Express...
или интерфейсы доступа к накопителям информации IDE, EIDE, ATAPI, SCSI, SATA, SAS...> Похоже, что от i386 девяностых до x86_64 _прыжок_ произойдёт
> действительно *только* через 4Gb памяти в домохозяечной машинеогромный прыжок уже произошел, например, при появлении технологии PnP.
(эту технологию использует не только Windows 95, но также и ядро Linux)
без этой технологии - современное состояние индустрии было бы невозможным.
>потому что проблема не в этом конкретном драйвере, а в архитектуре
>взаимодействия ядра операционной системы и драйверов оборудования.
>
>например, если ядро пускать на 0-м кольце, а драйвера на 1-м, эта
>
>проблема устраняется. появляется новая, с производительностью,
>практически всегда голая производительность без надежности не нужна.
>
>потому и процессоры работают в защищенном режиме, а не Big Real Mode,
>
>когда любая задача реального режима может адресовать все 4 гигабайта
>оперативной памяти без страничных преобразований и прочих тормозов...
>
>например, на 386 машине с частотой ядра в 25 мегагерц Линус был
>вынужден
>делать ядро монолитным, потому что потери производительности были очень
>большими. но если бы он начинал писать свою операционку имея под рукой
>
>двух- и четырех- ядерные процессоры, я почти уверен, что он тогда разнес
>
>бы ядро операционной системы и драйвера оборудования по разным кольцам защиты.очень похоже на правду.
Странно однако, что же курил в то время Таненбаум, развивая теорию микроядра _уже_тогда_... Может стоит просто попробовать?
Жаль что для всего-лишь "попробовать" нужно проделать _огромную_ работу...
Будем надеяццо, Торвальдс изменит свое мнение рано или поздно...
>тем более, что 4-х ядерные процессоры - это совсем не предел,
>частоту дальше повышать уже нерационально, при уменьшении техпроцесса
>будут увеличивать количество ядер в одном корпусе. 8, 16, 32, 64, ...
>если програмно эта ошибка не устранятся - тогда новая версия PCB.
Программно как раз, только в не-EPROM. PCB как Printed Circuit Board (печатная плата) тут ни при чём, разве что если Вы в курсе, что принято из-за смены прошивки одного ROM менять ревизию _платы_, а я -- нет (что тоже вариант).>например, на 386 машине с частотой ядра в 25 мегагерц Линус был вынужден
>делать ядро монолитным, потому что потери производительности были очень
>большими. но если бы он начинал писать свою операционку имея под рукой
>двух- и четырех- ядерные процессоры, я почти уверен, что он тогда разнес
>бы ядро операционной системы и драйвера оборудования по разным кольцам защиты.
Что характерно, эта операционка была бы точно так же никому не нужна, как и миникс. Поскольку историческим фактом является то, что в 91 были 386, а не core duo, и что тайминги по возникновению линукса были достаточно острыми и критичными для того, чтобы он стал тем, чем есть -- довольно популярной серверной и маргинально существующей десктопной системой.Это называется "дорога ложка к обеду", а не покрасивше да помельхиоровей, и пониманием этой простой вещи и отличаются линусы-инженеры от таненбаумов-теоретиков.
>> Сложные системы, как в программной, так и в аппаратной части, уже давно
>> не подлежат полному описанию совокупности состояний по факту как минимум
>> в "бытовых" (non-MCA) приложениях.
>потому и перешли от DOS-like операционных систем к защищенным операционным
>системам, кода глючная програма не может завалить операционку, или другие
>программы. максимум что произойдет - аварийное завершение работы только
>этой сбойной программы.
Вы не поняли. В чём-то наоборот -- для критичных задач минимизируют объём всего кода, причастного к решению таковых. Насколько знаю, при этом DOS-like может оказаться и предпочтительней именно по причине простоты.>> Ну да это было как раз мелкой иллюстрацией более общей проблемы...
>если проблему не получается сформулировать - может быть есть проблемы с ее
>пониманием?
>>>> бессмысленно закалять колосса на заведомо глиняных ногах.
Вот Вам и формулировка.>>>полная смена аппаратной платформы - этот процесс происходит каждые 5-10 лет.
>> Да ладно. Вон Intel попытались раньше времени выкатить _действительно_
>> другую IA64 вместо IA32 -- это как раз конает на _смену_ -- и что?
>например, интерфейсные шины ISA, MCA, VESA, PCI, PCI-X, AGP, PCI-Express...
>или интерфейсы доступа к накопителям информации IDE, EIDE, ATAPI, SCSI, SATA, SAS...
Полноте, какая-такая смена. Это вопрос драйверов, а не платформы. И только.>> Похоже, что от i386 девяностых до x86_64 _прыжок_ произойдёт
>> действительно *только* через 4Gb памяти в домохозяечной машине
>огромный прыжок уже произошел, например, при появлении технологии PnP.
>(эту технологию использует не только Windows 95, но также и ядро Linux)
>без этой технологии - современное состояние индустрии было бы невозможным.
Ладно, предлагаю завершить разговор слепого (меня, поскольку -3.5) с какой уж титул себе выберете. :-)
>> если програмно эта ошибка не устранятся - тогда новая версия PCB.> Программно как раз, только в не-EPROM. PCB как Printed Circuit Board
> (печатная плата) тут ни при чём, разве что если Вы в курсе,
> что принято из-за смены прошивки одного ROM менять ревизию
> _платы_, а я -- нет (что тоже вариант).ЕСЛИ ( проблема_не_устранятеся_програмно )
ТО { проблема_устраняется_аппаратно }
ИНАЧЕ { kernel_panic( "проблема не устранима?" ) };> Это называется "дорога ложка к обеду", а не покрасивше да помельхиоровей,
> и пониманием этой простой вещи и отличаются линусы-инженеры от таненбаумов-теоретиков.а как насчет QNX ?
ведь эту операционку делали совсем не теоретики,
и кроме высочайшей надежности эта microcernel OS является также и hard real time OS.
используется QNX именно там где нужна наибольшая надежность работы оборудования,
приведу только один пример - машрутизатор Cisco CRS-1. IOS предыдущих маршрутизаторов Cisco построена на основе монолитного BSD ядра, с казалось бы высокой скоростью работы.>>> Сложные системы, как в программной, так и в аппаратной части, уже давно
>>> не подлежат полному описанию совокупности состояний по факту как минимум
>>> в "бытовых" (non-MCA) приложениях.>> потому и перешли от DOS-like операционных систем к защищенным операционным
>> системам, кода глючная програма не может завалить операционку, или другие
>> программы. максимум что произойдет - аварийное завершение работы только
>> этой сбойной программы.>Вы не поняли. В чём-то наоборот -- для критичных задач минимизируют
>объём всего кода, причастного к решению таковых. Насколько знаю, при
>этом DOS-like может оказаться и предпочтительней именно по причине простоты.чем инженеры-практики Cisco Systems отличаются от различных писателей-теоретиков,
так это тем, что для критических задач используют не DOS-like (шаг назад),
а QNX-like (шаг вперед) операционные системы.>>> Ну да это было как раз мелкой иллюстрацией более общей проблемы...
>> если проблему не получается сформулировать -
>> может быть есть проблемы с ее пониманием?>>>>> бессмысленно закалять колосса на заведомо глиняных ногах.
>Вот Вам и формулировка.
это метафора, а не формулировка.
проблему построения надежных систем из ненадежных компонентов
решают с помощью избыточности и резервирования (например, RAID-1, RAID-10,...)
и кластеризации (поисковая машина Google и т.п.) кстати, Google использует Linux.> Ладно, предлагаю завершить разговор слепого (меня, поскольку -3.5)
> с какой уж титул себе выберете. :-).
>этот глюк в материнской плате очень легко устраняется,
Аж два раза, ага... кувалдой.Бац и нету биоса и бутблока :)>выпуском новой версии PCB,
Очень легко.Особенно юзерам...> или новой прошивки биоса.
Blah-blah-blah... не, бутблок конечно тоже можно перешить(и угробить в этом процессе тоже можно), и это даже не дыра.Просто нехер софту прямой доступ к железу разрешать кому попало.А так у того же аварда что в биосе что в его бутблоке по жизни была тонна багов, достаточно посмотреть на чанжлоги.Не давать перешить бажный бутблок извините, дебилизм.Потому что вот завалите вы апдейт биоса а бутблок то бац и виснет например.И чего?Даже зная о проблеме хрен перешьешь.Можно конечно хардварно решить вопрос - перемычку поставить на мамке, запрет записи в бутблок.Только тут еще веселые грабли есть.Льете вы новый биос.А старый бут с ним несовместим.Если флешер его не заапдейтит (а при перемычке он реально не сможет...) - например все может взвиснуть в момент когда бут отдает управление биосу.При этом чексумм валиден и у бута нет причин не запускать биос.В итоге оказывается что приплыли.Система оживляется только на программаторе.Клево, да?Прикольно чувствовать себя самыми умными но то что есть сегодня - это компромис при котором юзеры не особо интенсивно ломают зубы при апгрейде и биосы не мрут пачками.Нормальный вполне компромисс.А то что код в ядре может биос перешить - так простите, а что, флешеры отменить и при обнаружении бага в биосе менять мамку или паять микросхемы как в лохматых 90х?>проблема с тем, что любой кривой драйвер может заглючить всю систему -
>не имеет такого легкого и простого решения.
Имеет: просто не использовать кривые драйвера.Вы блин еще потребуйте дать вам возможность работать в режиме ядра и чтоб вы систему не могли завалить.Хотя ядро по определению это может.>как раз и опустится где-то на уровень Windows 95-98.
9х падали отнюдь не из-за кривых драйверов, стыдно это не знать.Они падали из-за того что кривые ПРИЛОЖЕНИЯ могли попортить память СИСТЕМЫ (в частности и виндовых кусков ядра и драйверов).Что неминуемо вызывало кирдык.Линукс кстати таких вольностям приложениям как правило не позволяет, посему 9х из линукса не выйдет.>поэтому желательно уже сейчас начинать задумываться, как не превратить Linux в Windows
>95.
Ага, б**ть, идите нафиг.Возьмите и купите себе 64-битную висту.Там как раз это реализовано: вы не можете запустить свой драйвер не подписанный микрософтом или одобренным ими списком вендоров.Даже если вам надо для ваших целей.Даже если сильно надо.И вообще в кернель вас не пускают.Получается кульный админ.Который не может попасть в ядро.На своей собственной системе.... а если мне например надо прямой доступ к некоторым железкам?Я не думаю что микрософт мне подпишет дравйверок типа giveio.sys :).А то я ведь чего доброго смогу в их DеRьMе через него копаться и спиратить премиум контент, вы прикиньте!>эта ошибка не в софте, эта ошибка - в архитектуре ядра операционной
>системы.
Используйте правильную висту - там только микрософт может быть избранным, а лохам типа вас вход в ядро закрыт.Ибо нефиг :)>мелкие баги возможно будут всегда, но архитектура должна стремиться к идеальной.
Угу, микрософт вон стремится.И даже наверное и такое сделает.Чтобы драйвера и вообще вы сами не могли нихера без микрософтовского благословления.Спасибочки.Сами такое и пользуйте.>операционные же системы - меняются гораздо реже, чем аппаратные платформы.
>первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
Тогда пора хотя-бы узаконить ACLs вместо прав RWX на уровне дефолтов.Куда важнее чем какие-то там баги в каких-то там драйверах, которые лично мне никак пока не мешали.
>>> на некоторых интеловских матерях можно убить boot block последовательностью команд
>>> специального вида. Это даже не BIOS, это bb, который во впаянной микросхеме,
>>> а не флэше/кроватке. Кажется, вне зависимости от архитектуры ядра.GM>> этот глюк в материнской плате очень легко устраняется,
GM>> выпуском новой версии PCB, или новой прошивки биоса.??> Не давать перешить бажный бутблок извините, дебилизм.
...
??> Можно конечно хардварно решить вопрос - перемычку поставить на мамке,
??> запрет записи в бутблок. Только тут еще веселые грабли есть. Льете вы новый биос.
??> А старый бут с ним несовместим. Если флешер его не заапдейтит
??> (а при перемычке он реально не сможет...) - например все может взвиснуть
??> в момент когда бут отдает управление биосу. При этом чексумм валиден
??> и у бута нет причин не запускать биос. В итоге оказывается что приплыли.
??> Система оживляется только на программаторе.проблема решается очень просто: флешер перед тем, как обновлять биос,
смотрит, удалось ли ему успешно обновить boot block, и только в этом случае
приступает к перепрошивке BIOS. если не получилось - завершается с сообщением про ошибку.
а каким именно способом защита бутблока сделана - перемычкой на материнской плате,
или опцией в биосе - это без разницы.??> то что есть сегодня - это компромис при котором юзеры не особо интенсивно
??> ломают зубы при апгрейде и биосы не мрут пачками. Нормальный вполне компромисс.в данном случае - это компромис цена/качество (hardware и software)
а не безопасность/производительность.GM>> проблема с тем, что любой кривой драйвер может заглючить
GM>> всю систему - не имеет такого легкого и простого решения.??> Имеет: просто не использовать кривые драйвера.
других драйверов нет.
??> Вы блин еще потребуйте дать вам возможность работать в режиме ядра
??> и чтоб вы систему не могли завалить. Хотя ядро по определению это может.драйвер - это интерфейс между оборудованием и ядром операционной системы.
ошибке в драйвере совсем не обязательно валить всю операционную систему.
например, ошибки в приложениях не могут повлиять на ядро и другие приложения.у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной системы.GM>> если ничего не делать, то при таком же количестве драйверов,
GM>> как во всех Windows вместе взятых - стабильность работы линукса
GM>> как раз и опустится где-то на уровень Windows 95-98.??> 9х падали отнюдь не из-за кривых драйверов
"стыдно не знать" прогремевший на весь мир случай на чикагской выставке Comdex: стоило
Биллу Гейтсу в ходе демонстрации Windows 98 подключить к компьютеру USB-сканер,
как тут же появился "синий экран смерти". причиной этого был кривой драйвер.??> Они падали из-за того что кривые ПРИЛОЖЕНИЯ могли попортить память СИСТЕМЫ
??> Что неминуемо вызывало кирдык. Линукс кстати таких вольностям приложениям
??> как правило не позволяет, посему 9х из линукса не выйдет.и что с того? линукс сейчас позволяет такие вольности драйверам оборудования,
которые написаны сторонними разработчиками. драйвер - это такое специальное
"приложение" которое имеет возможность "попортить память СИСТЕМЫ".GM>> поэтому желательно уже сейчас начинать задумываться,
GM>> как не превратить Linux в Windows 95.??> Ага, б**ть,
[...истерика опущена...]
GM>> мелкие баги возможно будут всегда, но архитектура должна стремиться к идеальной.
GM>> операционные же системы - меняются гораздо реже, чем аппаратные платформы.
GM>> первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
>драйвер - это интерфейс между оборудованием и ядром операционной системы.
>ошибке в драйвере совсем не обязательно валить всю операционную систему.
>например, ошибки в приложениях не могут повлиять на ядро и другие приложения.
>
>
>у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
>сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
>наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
>
>этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
>при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной
>системы.поэтому идея микроядра соответствует реалиям Линукса больше, чем это себе представляет Торвальдс...
>>у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
>>сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
>>наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
>>этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
>>при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной
>>системы.
Очень смешно. Но касается исключительно закрытых драйверов, причём и там денег или ещё чего на нормальных драйверописателей не хватает из заметных поставщиков разве что у ATI. Более последовательные вроде NVIDIA уже откатали и оно просто работает, победней вроде C-Media -- делились спеками и имели открытый драйвер ещё в 1999.>поэтому идея микроядра соответствует реалиям Линукса больше, чем это себе представляет Торвальдс...
Боюсь, "это" он представляет себе как раз получше нас с Вами. С индусами (в худшем смысле слова, бишь дешёвыми кодерами драйверов) бороться имеет смысл не на техническом уровне, а на организационном -- не столь давняя очередная волна по части запрета загрузки закрытых драйверов вполне является показательной (и есть подозрение, что в какой-то момент пингвин будет иметь достаточный разгон, чтобы производители прогибались, а не Линус тормознул поезд со словами "непрактично").На техническом имеет смысл растить внятное молодое поколение, которое не захочет выпускать кривой код и будет иметь это чувство вкуса... вот только тут как свернувший с программерской дороги тоже помолчу.
>>> у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
>>> сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
>>> наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
>>> этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
>>> при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной
>>> системы.> Очень смешно. Но касается исключительно закрытых драйверов, причём и там денег
> или ещё чего на нормальных драйверописателей не хватает из заметных поставщиков
> разве что у ATI. Более последовательные вроде NVIDIA уже откатали
> и оно просто работает, победней вроде C-Media -- делились спеками
> и имели открытый драйвер ещё в 1999."открытый драйвер" и "безглючный драйвер" - это не синонимы.
например, в 2002 году народ из Стэнфордского Университета сделал исследование
кода Linux начиная с самой первой версии и до последней на тот момент версии 2.4.1.и оказалось, что за эти 7 лет развития и становления Linux, ошибки в коде драйверов
встречались от 3 до 7 раз чаще, чем в остальных подсистемах ядра (количество ошибок
на 1000 строк кода). на момент выхода версии 2.4.1 код драйверов составлял уже 70%
от всего обьема ядра, хотя в момент выпуска версии 2.1 соотношение было примерно 50/50.статья большая, полностью пересказывать не буду.
"An Empirical Study of Operating Systems Errors"
http://pdos.csail.mit.edu/6.097/readings/osbugs.pdf>> поэтому идея микроядра соответствует реалиям Линукса больше,
>> чем это себе представляет Торвальдс...> Боюсь, "это" он представляет себе как раз получше нас с Вами.
> С индусами (в худшем смысле слова, бишь дешёвыми кодерами драйверов)
> бороться имеет смысл не на техническом уровне, а на организационном --
> не столь давняя очередная волна по части запрета загрузки закрытых драйверов
> вполне является показательной (и есть подозрение, что в какой-то момент пингвин
> будет иметь достаточный разгон, чтобы производители прогибались,
> а не Линус тормознул поезд со словами "непрактично").проблема не в том, что закрытые драйвера - плохие, а открытые - хорошие.
производители уже начинают прогибаться, и тактически это все правильно.более того, - это самый эффективный метод сейчас повысить надежность ядра,
не изменяя его архитектуру, и в этом основные разработчики ядра 100% правы.но стратегически - это всеравно не решает проблему, потому что драйверов
становится все больше, и количество проблем от глючных драйверов со временем
будет только увеличиваться, особенно у новых десктопных пользователей Linux,
которым для офисной работы совсем не нужно выжимать из процессора 120%,
но падения системы от нестабильных драйверов будут самыми неприятными.кардинально улучшить ситуацию можно только изменив архитектуру ядра операционной
системы. это произойдет не сейчас, не с этим ядром, может быть в 2.7 или даже 2.9,
но обязательно произойдет, потому что выиграш от экономии производительности будет
постоянно уменьшаться, и со временем станет меньше 1%. а общий проиграш от падения
всей системы - будет постоянно увеличиваться, особенно на фоне других ОС будущего.например, Microsoft сейчас работает над своей новой операционной системой будущего,
Singularity, которая имеет microkernel-архитектуру, и весь код операционной системы
и драйверов является managed кодом. сейчас, на современном оборудовании она будет
тормозить. но в будущем современное оборудование будет там, где сейчас находится
IBM PC XT с его 8088 процессором и 640 килобайт оперативной памяти. например,
Intel уже сейчас демонстрирует прототип процессора, который имеет 80 ядер...
>проблема не в том, что закрытые драйвера - плохие, а открытые -
>хорошие.
>производители уже начинают прогибаться, и тактически это все правильно.
>
>более того, - это самый эффективный метод сейчас повысить надежность ядра,
>не изменяя его архитектуру, и в этом основные разработчики ядра 100% правы.
>
>
>но стратегически - это всеравно не решает проблему, потому что драйверов
>становится все больше, и количество проблем от глючных драйверов со временем
>будет только увеличиваться, особенно у новых десктопных пользователей Linux,
>которым для офисной работы совсем не нужно выжимать из процессора 120%,
>но падения системы от нестабильных драйверов будут самыми неприятными.
>
>кардинально улучшить ситуацию можно только изменив архитектуру ядра операционной
>системы. это произойдет не сейчас, не с этим ядром, может быть в
>2.7 или даже 2.9,
>но обязательно произойдет,присоединяюсь к этим практически пророческим словам.
Разеделение пространств ядра и драйверов - неизбежно.Очень хочеться верить, что 2.7. ветка родиться именно ради микроядра.
>потому что выиграш от экономии производительности будет
>постоянно уменьшаться, и со временем станет меньше 1%. а общий проиграш от
>падения
>всей системы - будет постоянно увеличиваться, особенно на фоне других ОС будущего.ИМО, уже сейчас даже 5-10% производительности за кардинально большую надежность многие готовы были бы заплатить
>> но стратегически - это всеравно не решает проблему, потому что драйверов
>> становится все больше, и количество проблем от глючных драйверов со временем
>> будет только увеличиваться, особенно у новых десктопных пользователей Linux,
>> которым для офисной работы совсем не нужно выжимать из процессора 120%,
>> но падения системы от нестабильных драйверов будут самыми неприятными.>> кардинально улучшить ситуацию можно только изменив архитектуру ядра
>> операционной системы. это произойдет не сейчас, не с этим ядром,
>> может быть в 2.7 или даже 2.9, но обязательно произойдет> присоединяюсь к этим практически пророческим словам.
> Разеделение пространств ядра и драйверов - неизбежно.но для этого нужно будет переписать ядро и переписать все драйвера устройств.
на такой шаг пойдут когда теперешняя ситуация станет уж слишком неудобной,
а потери производительности будут не такими большими, как сейчас.> Очень хочеться верить, что 2.7. ветка родиться именно ради микроядра.
микроядро и линукс - это вещи мягко говоря, несовместимые.
хотя и существует в природе проект MkLinux (Линукс на микроядре)
но при таком варианте развития событий есть свои собственные проблемы.тормоза системы - это проблема в принципе решаемая в будущем, при возрастании
мощности процессоров. но есть и другая - очень сильное усложнение операционной
системы, так что дописать какие-то новые модули/сервисы - это становится
нетривиальной задачей, и сама архитектура будет способствовать появлению
большого количества ошибок в системных сервисах из-за слишком сложного
взаимодействия между ними (проблемы синхронизации и т.п) Линус где-то
об этом уже рассказывал, когда его спрашивали о перспективах микроядра
так что я сейчас просто пересказываю его слова, как запомнил...поэтому в теории - http://citforum.ru/operating_systems/reliable_os/
это все выглядит просто замечательно, но вот на практике получается
как-то не очень: GNU HURD, Minix3, ...>> потому что выиграш от экономии производительности будет постоянно уменьшаться,
>> и со временем станет меньше 1%. а общий проиграш от падения всей системы -
>> будет постоянно увеличиваться, особенно на фоне других ОС будущего.> ИМО, уже сейчас даже 5-10% производительности
> за кардинально большую надежность многие готовы были бы заплатитьстоимость разработки ядра операционной системы - это очень большие деньги.
например, 1 миллиард долларов IBM когда-то инвестировала в разработку Linux
в основном ради того, чтобы Linux нормально работал на IBM`овских серверах.
и 1 миллиард долларов потратила Microsoft на разработку SP2 для Windows XP.создать операционную систему, которая будет хотя бы аналогична по своим возможностям
теперешнему Linux`у - на это надо будет потратить несколько сотен миллиардов долларов.это примерно несколько десятков лет напряженной работы
сотен тысяч высококвалифицированных программистов.на эту тему есть очень хорошая книжка "Мифический человеко-месяц" Ф.Брукса,
он был в свое время руководителем проекта создания Operating System/360 в IBM,
и эта книжка - его бесценный опыт. "В США полагают, что без прочтения книги Брукса
не может состояться ни один крупный руководитель программного проекта."
>но для этого нужно будет переписать ядро и переписать все драйвера устройств.
да, это неизбежно, если все-таки этим заняццо
>но есть и другая - очень сильное усложнение операционной
>системы, так что дописать какие-то новые модули/сервисы - это становится
>нетривиальной задачей, и сама архитектура будет способствовать появлению
>большого количества ошибок в системных сервисах из-за слишком сложного
>взаимодействия между ними (проблемы синхронизации и т.п) Линус где-то
>об этом уже рассказывал, когда его спрашивали о перспективах микроядра
>так что я сейчас просто пересказываю его слова, как запомнил...
да, известные слова Торвальдса...
тяжело ему не доверять, но так хочеться... :)
>на эту тему есть очень хорошая книжка "Мифический человеко-месяц" Ф.Брукса,
>он был в свое время руководителем проекта создания Operating System/360 в IBM,
>
>и эта книжка - его бесценный опыт. "В США полагают, что без
>прочтения книги Брукса
>не может состояться ни один крупный руководитель программного проекта."
посмотрел на книгу - сильна. Найти бы еще время прочитать..
>"открытый драйвер" и "безглючный драйвер" - это не синонимы.
Это и не утверждалось. Просто видя, как годами исправляются крупные проблемы (вроде отсутствия Xv в том же fglrx) при закрытом коде -- приходится полагать, что нужному драйверу полезней быть открытым.>статья большая, полностью пересказывать не буду.
>"An Empirical Study of Operating Systems Errors"
>http://pdos.csail.mit.edu/6.097/readings/osbugs.pdf
Спасибо.>но стратегически - это всеравно не решает проблему, потому что драйверов
>становится все больше, и количество проблем от глючных драйверов со временем
>будет только увеличиваться, особенно у новых десктопных пользователей Linux,
>которым для офисной работы совсем не нужно выжимать из процессора 120%,
>но падения системы от нестабильных драйверов будут самыми неприятными.
BTW http://lwn.net/Articles/219791/>например, Microsoft сейчас работает над своей новой операционной системой будущего,
>Singularity, которая имеет microkernel-архитектуру, и весь код операционной системы
>и драйверов является managed кодом.
Ой, эти балаболы уже выкатили сколько -- две или три? -- ОС, все из себя managed (на считанные проценты). В процессе подменяя запланированное улучшение системы ограничением пользователя и разработчика. А их mindshare, как и их банковский счёт -- велики, но не безграничны.>сейчас, на современном оборудовании она будет
>тормозить. но в будущем современное оборудование будет там, где сейчас находится
>IBM PC XT с его 8088 процессором и 640 килобайт оперативной памяти.
>например,
>Intel уже сейчас демонстрирует прототип процессора, который имеет 80 ядер...
И так вернёмся к лисп-машинам? ;-) (касательно managed, по крайней мере...)
>> но стратегически - это всеравно не решает проблему, потому что драйверов
>> становится все больше, и количество проблем от глючных драйверов со временем
>> будет только увеличиваться, особенно у новых десктопных пользователей Linux,
>> которым для офисной работы совсем не нужно выжимать из процессора 120%,
>> но падения системы от нестабильных драйверов будут самыми неприятными.> BTW http://lwn.net/Articles/219791/
да, это хорошая инициатива, и тактически шаг в правильном направлении.
[...]
>> сейчас, на современном оборудовании она будет тормозить.
>> но в будущем современное оборудование будет там, где сейчас находится
>> IBM PC XT с его 8088 процессором и 640 килобайт оперативной памяти.
>> например, Intel уже сейчас демонстрирует прототип процессора, который имеет 80 ядер...> И так вернёмся к лисп-машинам? ;-) (касательно managed, по крайней мере...)
история развивается по спирали. например, в 1969 году UNIX была первой операционной
системой, полностью написанной на языке высокого уровня. тогда - на машинах с 32
килобайтами оперативной памяти и CPU несколько мегагерц. все остальные операционные
системы того времени были написаны на ассемблере. посмотри, какого уровня развития
сейчас достигла UNIX (AS Linux), и где сейчас находятся все остальные ОС того времени...так что при кардинальном увеличении производительности, например, с 3 MHz до 3 GHz,
был произведен переход с asm на С/С++ в качестве основных языков системного/прикладного
программирования. каким будет следующий шаг, при аналогичном возрастании мощности CPU?
когда будущие настольные компьютеры будуть иметь мощность сегодняшних суперкомпьютеров."Java" / ".NET" - это ответ "SUN" / "Microsoft" на проблему возрастающей сложности кода.
пока что - это только на уровне низкоквалифицированных разработчиков прикладных программ.
в будущем, если ничего не изменится, то и в системном программировании, при создании ОС.твой вариант ответа - ?
>твой вариант ответа - ?
"Не знаю".Поскольку до сих пор эта спираль была завита не хуже, чем толкиеновское взятие твертыквы двумя хоббитами, перебегать дорогу книгописателям вроде Гейтса с Торвальдсом мне никак ;-)
(с аргументацией-то согласен и сам предпочитаю, скажем, ejabberd...)
>проблема решается очень просто: флешер перед тем, как обновлять биос,
>смотрит, удалось ли ему успешно обновить boot block,
Ага.Но не все такие умные - до некоторых доходит что грабли могут жахнуть в лоб только когда они на них наступят.Да и юзеры не любят перемычки.Нынче рулит jumperless.Лезть в системник, искать мелкую перемычку и матерясь переставлять ее в принципе по юзабельности решения не сильно лучше чем выдергивать чип из кроватки и менять на новый.И так кстати везде где вопрос касается безопасности.Вот и выбирайте - или постоянный геморрой с защитами или безопасность ради удобства страдает.А истина - где-то посередине, в разных пропорциях для разных людей.>а каким именно способом защита бутблока сделана - перемычкой на материнской плате,
>или опцией в биосе - это без разницы.
А вырусс что, не сможет снять софтварный лок на запись?Хотя ... можно сделать так что не сможет - если при активации (в соответствии с настройками) запрета на запись биосом запись блокируется до хардварного ресета.Т.е. после включения блокировки она не отключается иначе чем хардварным ресетом... тады да, вирусу придется неудобно весьма а ребут вообще событие заметное да и пережить его вирус не сможет :)>в данном случае - это компромис цена/качество (hardware и software)
>а не безопасность/производительность.
Это еще и компромисс удобства юзера и безопасности.>??> Имеет: просто не использовать кривые драйвера.
>других драйверов нет.
Праздравляю.Даже если вы их вынесете в юзер мод они от этого лучше не станут.Хуже запросто, поскольку станут более наплевательски относиться к качеству кода - а чо, система не падает, баг не фатальный и нии**т.>драйвер - это интерфейс между оборудованием и ядром операционной системы.
Ага.Вообще, шедевральное решение - юзерский процесс просит ядро - сделай то-то.То вместо того чтобы взять и сделать (с помощью дравйеров) валит обратно в "юзера" и просит дрова в "юзере" сделать это.Для этого опять придется (несколько раз) свалить в кернель (в конченом итоге прямой доступ к железу "юзеру" никто не даст ибо самоубийство).Прыгать туда-сюда это да, это шедевр творческой мысли.Не, давайте лучше пусть оно ваще на виртуалке выполняется, чтобы уж наверняка.Ну скажем, JVM.Или там вообще на интерпретируемом языке, ну пусть питоне, чем он хуже других?А чо, драйвер девайса на жабе и на питоне.Разве не круто звучит?Тучи сертифицЫрованных спецЫалистофф \m/ \m/ побросают свои дела и вдарятся в драйверописательство.Тут то качество дров и взлетит, правда непонятно куда но это уже детали :)>ошибке в драйвере совсем не обязательно валить всю операционную систему.
А это еще зависит от того что упало.Что должна сделать система если упал драйвер диска на котором был своп?Или если драйвер успел при помирании такого напихать в железку что она из этого состояния только ресетом выводится?Бывает кстати и более весело.Если в системе с амдшным процом (Cool'n'Quiet которым в линуксе занимается powernowd) записать неверные FID и VID - проц немедленно встанет раком.И будет в оной позиции даже после ресета кнопкой(!!).Спасет только отключение питания.При этом как вы понимаете проблема именно в неверных значениях параметров переданных железу, никакое микроядро от такого не спасет.Ну или что делать если упал драйвер видяхи, попутно поставив видяху в раскоряку?>например, ошибки в приложениях не могут повлиять на ядро и другие приложения.
Разделение на систему и юзера задумано.Оно есть в процессоре на уровне железа.Разделения ядра и драйверов в железе нет.Посему это придется делать программно.Соответственно будет тормозилово.>у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
>сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
>наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
>этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
>при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной
>системы.
О да.Конечно же осознание того факта что теперь ляпы в дровах может быть и не завалят систему (если повезет) наверное резко прибавит каКчества драйверам.Имхо так это прибавит рас...ства программерам и тестерам и дрова станут еще поганее.Когда дрова крашат систему это веский повод ловить баг - ибо фатально.А если не крашат - ну на баг забьют болт да и все дела.Чем менее серьезны последствия бага тем охотнее на него кладут.>??> 9х падали отнюдь не из-за кривых драйверов
>"стыдно не знать" прогремевший на весь мир случай на чикагской выставке Comdex:
>стоило Биллу Гейтсу в ходе демонстрации Windows 98 подключить к компьютеру USB-сканер,
>как тут же появился "синий экран смерти". причиной этого был кривой драйвер.
Я отлично знаю что 98 можно завалить из юзерского процесса.Прибегать к помощи драйверов при этом - вообще лишний понт.Убить эту систему насмерть может просто кривая программа.>и что с того? линукс сейчас позволяет такие вольности драйверам оборудования,
>которые написаны сторонними разработчиками. драйвер - это такое специальное
>"приложение" которое имеет возможность "попортить память СИСТЕМЫ".
А кто это определил?Вы?Таненбаум?Ох какие резвые перцы.А если я скажу что драйвер это часть системы, то что?Why not?Многие дрова входят прямо в ядро линукса чем неплохо подтверждают эту точку зрения.НТя тоже так сделана.А почему нет?Микроядро - это попытка исправить криворукость драйверописателей за счет ядрописателей?Тогда маразм.Это как анек про мужика который ищет ключи под фонарем не потому что он их там потерял, а потому что там светлее :).Лично я за предсказуемую работу низкоуровневых частей моей системы.Там просто не должно быть таких багов.А прибамбасы для халявщиков которые дадут системе шанс может быть и не подохнуть если их сраный код изволит встать раком - это костыли.Которые дадут возможность писать дрова совсем уж халтурщикам (т.е. не дровописателям и не кернель программмерам) - качество драйверов от этого упадет ниже плинтуса имхо.Понимание того что баг вероятно уронит систему как-то способствует качеству кода...>[...истерика опущена...]
Ну как, уже купили себе Висту?:)>GM>> мелкие баги возможно будут всегда, но архитектура должна стремиться к идеальной.
>GM>> операционные же системы - меняются гораздо реже, чем аппаратные платформы.
>GM>> первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
Краш в драйвере - это не мелкий баг.И вообще на этом свете никто никому нихрена не должен.Например, дерьмовая архитектура х86 времен царя гороха спокойно уделывает в плане продаж куда более нормальные и современные, и ничо, все черпают это г ложками и нахваливают его - как оно дескать вкусно.Так что старина Таненбаум может и дальше гундеть, а толку то?Лучше б Таненбаум убогий х86 хоронил, а то правильная система на дерьмовом железе - форменное кощунство 8)
>>> Можно конечно хардварно решить вопрос - перемычку поставить на мамке,
>>> запрет записи в бутблок. Только тут еще веселые грабли есть. Льете вы новый
>>> биос. А старый бут с ним несовместим. Если флешер его не заапдейтит
>>> (а при перемычке он реально не сможет...) - например все может взвиснуть
>>> в момент когда бут отдает управление биосу. При этом чексумм валиден
>>> и у бута нет причин не запускать биос. В итоге оказывается что приплыли.
>>> Система оживляется только на программаторе.>> проблема решается очень просто: флешер перед тем, как обновлять биос,
>> смотрит, удалось ли ему успешно обновить boot block,
>> и только в этом случае приступает к перепрошивке BIOS.> Ага. Но не все такие умные - до некоторых доходит
> что грабли могут жахнуть в лоб только когда они на них наступят.столько много букв было написано с целью доказать: "современное железо в принципе кривое,
и поэтому не имеет смысла на кривом железе даже пытаться делать не кривые операционные
системы." в результае обсуждения выяснилось, что эти "жуткие проблемы" являются мелкими,
легко устранимыми багами, чаще всего - только с помощью перепрошивки новой версии BIOS`а.
отмотай выше по теме почитай контекст, про "коллоса на глиняных ногах" и тому подобное.> Да и юзеры не любят перемычки. Нынче рулит jumperless. Лезть в системник, искать
> мелкую перемычку и матерясь переставлять ее в принципе по юзабельности решения
> не сильно лучше чем выдергивать чип из кроватки и менять на новый.лично мне например, "переставить джампер" СИЛЬНО ЛУЧШЕ чем "возиться с программатором".
> И так кстати везде где вопрос касается безопасности. Вот и выбирайте -
> или постоянный геморрой с защитами или безопасность ради удобства страдает.
> А истина - где-то посередине, в разных пропорциях для разных людей.в данном конкретном случае - я уверен, что большинству людей намного удобнее
будет возиться с перестановкой джампера или переключением настройки в BIOS Setup,
чем потом искать способы как отремонтировать полностью не рабочую материнскую плату,
которая "случайно" навернулась из-за "удобных" настроек производителей software/hardware.аналогично и замедление работы CPU на 5-10% на десктопной машине я уверен будет удобнее
полного сноса операционной системы, всех приложений и несохраненных данных практически
любому десктопному пользователю, будь то секретарка или крутой системный администратор.
особенно, если у них будет возможность выбора - запускать драйвера без ограничения
привилегий доступа, или же с ограниченным уровнем привилегий.и плохо, если такой возможности выбора нет, будь то глюки в hardware
или в software, какой бы пиар при этом не разводили криворукие разработчики.>> а каким именно способом защита бутблока сделана -
>> перемычкой на материнской плате, или опцией в биосе - это без разницы.> А вырусс что, не сможет снять софтварный лок на запись?
а кто ему даст возможность прямого доступа к hardware?
нормальная операционная система такого любым пользовательским программам не позволяет.
даже если вдруг, каким-то образом кривой софт сможет попортить настройки в nvram,
тогда при включении компьютера BIOS скажет "checksum error" и предложит загрузить
настройки по умолчанию.>> в данном случае - это компромис цена/качество (hardware и software)
>> а не безопасность/производительность.> Это еще и компромисс удобства юзера и безопасности.
с каких это пор юзеру стала удобной возможность аппаратного приведения
его компа в нерабочее состояние любой кривой программой или "вирусом"?>>>> проблема с тем, что любой кривой драйвер может заглючить
>>>> всю систему - не имеет такого легкого и простого решения.>>> Имеет: просто не использовать кривые драйвера.
>> других драйверов нет.
> Праздравляю. Даже если вы их вынесете в юзер мод они от этого лучше не станут.
я говорю сейчас не о качестве драйверов, а той проблеме, что любой кривой драйвер
может в любой момент заглючить всю операционную систему, вместе со всеми прикладными
приложениями и всеми несохраненными данными пользователя.> Хуже запросто, поскольку станут более наплевательски относиться
> к качеству кода - а чо, система не падает, баг не фатальный и нии**т.если следовать этой логике, тогда и прикладные программы надо вернуть
на 0-й уровень привилегий, чтобы разработчики стали очень внимательно
относиться к качеству и безглючности своего кода. я правильно понимаю?>> драйвер - это интерфейс между оборудованием и ядром операционной системы.
> Ага. Вообще, шедевральное решение - юзерский процесс просит ядро - сделай то-то.
> То вместо того чтобы взять и сделать (с помощью дравйеров) валит обратно в
> "юзера" и просит дрова в "юзере" сделать это. Для этого опять придется
> (несколько раз) свалить в кернель (в конченом итоге прямой доступ к
> железу "юзеру" никто не даст ибо самоубийство).полный доступ абсолютно ко всему железу любому драйверу -
не нужен для выполнения его узкоспециализированных задач.и от того, что драйвер какой-то кривой звуковой карточки
будет иметь доступ кроме диапазона портов только своей
звуковухи еще и полный доступ к видеокарте, всем жестким
дискам - особых каких-то преимуществ нет, а вот проблемы быть могут.
если оно вдруг заглючит, и уничтожит важные данные на жестком диске.> Прыгать туда-сюда это да, это шедевр творческой мысли.
лично мне например, не жалко несколько процентов производительности процессора
для того, чтобы получить более стабильную и защищенную от сбоев операционную систему.доплатив еще 20-50 долларов можно получить большую производительность,
которая полностью перекроет всю ту дополнительную нагрузку на центральный процессор.преимуществом будет возможность не потерять не сохраненные данные,
и большая защищенность и стабильность работы системы. стоит ли овчинка
выделки? лично для меня - да. у тебя разумеется может быть свое собственное мнение
по этому поводу, и тебе проще переделать работу за полдня, или восстановить с резервных
копий (если они есть) данные на жестком диске, чем заплатить несколько десятков долларов.>>ошибке в драйвере совсем не обязательно валить всю операционную систему.
> А это еще зависит от того что упало.
> Что должна сделать система если упал драйвер диска на котором был своп?однако, глюки в таких драйверах - это ОЧЕНЬ редкое явление.
для возможности найти и устранить причину падения -
надо как минимум снять и сохранить дамп памяти.
вариант сохранения - на флешку, или по сети.гораздо чаще глючат всякие звуковухи/сетевухи/видяхи и прочая периферия.
> Или если драйвер успел при помирании такого напихать
> в железку что она из этого состояния только ресетом выводится?заглючит какой-то там сканнер, или звуковая карточка - мне это пофигу.
главное - это иметь возможность спокойно сохранить не сохраненные данные,
и корректно завершить работу операционной системы и файловых систем.сейчас этого не делается потому, что заглючивший драйвер имеет доступ
к памяти ядра и может испортить как само ядро, так и код других драйверов.> Бывает кстати и более весело.Если в системе с амдшным процом (Cool'n'Quiet
> которым в линуксе занимается powernowd) записать неверные FID и VID
> - проц немедленно встанет раком. И будет в оной позиции даже после
> ресета кнопкой(!!). Спасет только отключение питания.
> При этом как вы понимаете проблема именно в неверных значениях параметров
> переданных железу, никакое микроядро от такого не спасет.ислючения только подтверждают правило. если раком встал центральный
процессор - тогда действительно, операционная система уже мало что
может сделать. если этот процессор в компьютере был только один...> Ну или что делать если упал драйвер видяхи,
> попутно поставив видяху в раскоряку?если эта видяха нужна для игр - это проблема, без нажатия
на reset играться дальше действительно будет невозможно.если же код драйвера видеокарточки изолирован от пользовательских
процессов, кода ядра и кода других драйверов, и при глюке он мог
привести в нерабочее состояние только сам себя и свое hardware -
тогда операционная система остается живой и вполне работоспособной.остается возможность сохранить не сохраненные данные, и корректно
завершить работу операционной системы. каким именно способом это будет
сделано - по сети, через ком-порт, или просто нажатием на кнопку Power -
это уже нюансы. кстати, драйвер видяхи заглючил, но драйвер звуковой карточки
то остался живым... и комп вполне может сообщить о проблеме через колонки...
нет звуковой карточки - комбинацией светодиодов на клавиатуре или через PC-спикер.
десктопные пользователи будут очень благодарны, что им не придется потерять
все свои несохраненные данные только потому что заглючил драйвер видеокарточки.>> например, ошибки в приложениях не могут повлиять на ядро и другие приложения.
> Разделение на систему и юзера задумано.
> Оно есть в процессоре на уровне железа.
> Разделения ядра и драйверов в железе нет.
> Посему это придется делать программно.
> Соответственно будет тормозилово.уровень понимания архитектуры IA32 очевиден. дальше можно не продолжать.
http://developer.intel.com/products/processor/manuals/
4.5 PRIVILEGE LEVELS
The processor’s segment-protection mechanism recognizes 4 privilege levels,
numbered from 0 to 3. The greater numbers mean lesser privileges. Figure 4-3
shows how these levels of privilege can be interpreted as rings of protection.
The center (reserved for the most privileged code, data, and stacks) is used for the
segments containing the critical software, usually the kernel of an operating system.
Outer rings are used for less critical software. (Systems that use only 2 of the 4
possible privilege levels should use levels 0 and 3.)Protection Rings
0 - Operating System Kernel
1 - Operating System Services
2 - Operating System Services
3 - Applications[...]
> А кто это определил? Вы? Таненбаум? Ох какие резвые перцы.
> старина Таненбаум может и дальше гундеть, а толку то?
> Лучше б Таненбаум убогий х86 хоронил, а то правильная система на дерьмовом железе
СЛОН И МОСЬКА
По улицам Слона водили,
Как видно, напоказ.
Известно, что Слоны в диковинку у нас,
Так за Слоном толпы зевак ходили.
Отколе ни возьмись, навстречу Моська им.
Увидевши Слона, ну на него метаться,
И лаять, и визжать, и рваться;
Ну так и лезет в драку с ним.
"Соседка, перестань срамиться, -
Ей Шавка говорит, - тебе ль с Слоном возиться?
Смотри, уж ты хрипишь, а он себе идет
Вперед
И лаю твоего совсем не примечает. -
"Эх, эх! - ей Моська отвечает, -
Вот то-то мне и духу придает,
Что я, совсем без драки,
Могу попасть в большие забияки.
Пускай же говорят собаки:
"Ай, Моська! знать, она сильна,
Что лает на Слона!"
>столько много букв было написано с целью доказать: "современное железо в принципе
>кривое,
Кривое.Достаточно на х86 посмотреть :) старый уродец с кучкой костылей, а бегает на удивление резво :)>лично мне например, "переставить джампер" СИЛЬНО ЛУЧШЕ чем "возиться с программатором".
Ну так флаг вам в руки - можете порыться на помойке и в хламежниках и найти таких мамок.А так - это приведет к тому что 99% юзеров просто не смогут заапдейтить bios и это будет эквивалентно тому как если бы в плату был запаян mask ROM.В итоге юзеры будут до скончания века сидеть с граблями если они не фатальны.Или попрут плату в гарантийку\магазин на возврат если баг мешает жить.Итого вендор безбедно живет до первого про**а.После которого влетает на очень много денег на возвратах и гарантии.И вообще если вам так хочется правильного, купите какойнить итаниум чтоли.Под него и софта то нет, а уж вирусов и подавно :)>в данном конкретном случае - я уверен, что большинству людей намного удобнее
>будет возиться с перестановкой джампера или переключением настройки в BIOS Setup,
А я как специалист по юзабилити говорю вам: 99% юзеров не дотянется до нужной перемычки.В случае если в биосе или бутблоке про*б - если программка апдейтера не отстреляется без проблем, плата а то и вся машина пойдет на возврат\в гарантию.Потому что юзер - это не вы.Он о биосе в лучшем случае что-то слышал.Классно, да?Довольный по уши юзер которому надо куда-то переться и налетевшая на бабки контора.И все ради защиты от призрачной угрозы что какой-то там вирус в принципе даже может что-то записать куда-то... (правда ни 1 современная система этого ему не даст сделать но это уже другой вопрос)
>чем потом искать способы как отремонтировать полностью не рабочую материнскую плату,
>которая "случайно" навернулась из-за "удобных" настроек производителей software/hardware.
Если бы это было сколь-либо массово, это бы давно уже исправили.Кто вам виноват что вам обычная машина кажется ненадежной для езды по улице и вам надо никак не меньше танка?>аналогично и замедление работы CPU на 5-10% на десктопной машине я уверен
>будет удобнее полного сноса операционной системы,
А от rm -rf спасет только отъем данной привилегии у админа.Извините, но админить систему в которой я как админ что-то не могу я попросту не хочу.>всех приложений и несохраненных данных практически
>любому десктопному пользователю, будь то секретарка или крутой системный администратор.
>особенно, если у них будет возможность выбора - запускать драйвера без ограничения
>привилегий доступа, или же с ограниченным уровнем привилегий.
О да, частичное ограничение привилегий драйверов конечно же решит все мирские проблемы.Прямо гербалайф номер два какой-то :)>и плохо, если такой возможности выбора нет, будь то глюки в hardware
>или в software, какой бы пиар при этом не разводили криворукие разработчики.
Почему нет?Ставите себе MINIX и выбираете :)>> А вырусс что, не сможет снять софтварный лок на запись?
>а кто ему даст возможность прямого доступа к hardware?
Кстати с однократно взводимыми флажками в чипсете(биосом, на основании настроек) которые не сбрасываются без хардварного ресета можно было бы замочить это на уровне железа.Тогда вирь бы при активной настройке несмотря на ее программность слил бы даже из доса :)>нормальная операционная система такого любым пользовательским программам не позволяет.
Ага, посему параноя с дровами выглядит лишней...хотя не, я понимаю что Таненбаум придумал что его идея самая-самая и теперь вещает об этом.Вполне нормальное явление.>с каких это пор юзеру стала удобной возможность аппаратного приведения
>его компа в нерабочее состояние любой кривой программой или "вирусом"?
Ну хорошо, если я плохой парень, я допустим кладу в сетку исошку "супер виндовс 2010" и наблюдаю как орава леммингов начинает резать ее, бутиться с нее и ... отдавать свой комп под контроль на ранней стадии загрузки.Где прямой доступ к железу никто не отбирал.И?Что, компы не угробятся?А из нормальной операционки вирус и так в железо никто не пустит без должных прав.А так я как локальный юзер всегда могу комп угробить.У меня вон кувалда есть, например :).Странно у меня отбирать права угробить систему еще как-то.Мне от системы надо чтобы посторонний код не одобренный мной не мог понаделать лишнего, а это и существующие системы в принципе обеспечивают.А кто вас заставляет разрешать грузить драйвера и вызывать из кому попало?А без этого хрен вы в винде или линуксе в железо попадете.>я говорю сейчас не о качестве драйверов, а той проблеме, что любой
>кривой драйвер может в любой момент заглючить всю операционную систему, вместе со всеми прикладными приложениями и всеми несохраненными данными пользователя.
Дык падеж многих из драйверов 1 фиг вызовет потери данных которые не были успешно обработаны драйвером.>если следовать этой логике, тогда и прикладные программы надо вернуть
>на 0-й
Не совсем так.Приложений много и они глючные.Ядра и драйверов не много, они маленькие, стабильные и подконтрольные.>уровень привилегий, чтобы разработчики стали очень внимательно
>относиться к качеству и безглючности своего кода. я правильно понимаю?
А это зависит от системы.В некоторых системах нет разделения кода на юзера и систему, ибо нафиг не надо (скажем любой сбой фатален и по этому поводу лучше сбросить систему для заведомо нормальной инициализации чем работать с возможно засранной памятью и некорректными данными).Обычно это небольшие системы где качественное тестирование может быть проделано для всего кода а не только небольшого ядра.>полный доступ абсолютно ко всему железу любому драйверу -
>не нужен для выполнения его узкоспециализированных задач.
Ага, но только на уровне железа оно как-то не особо то здорово поддержано.Да и честно говоря не видел я как-то драйверов которые портят жизнь чужой железке, это уж совсем клиника.>дискам - особых каких-то преимуществ нет, а вот проблемы быть могут.
>если оно вдруг заглючит, и уничтожит важные данные на жестком диске.
И часто у людей дрова звуковухи стирают диски?Готов поспорить что реже чем легитимные rm -rf даденые от юзера с должными правами...>> Прыгать туда-сюда это да, это шедевр творческой мысли.
>лично мне например, не жалко несколько процентов производительности процессора
Есть подозрение что при большом числе прерываний там будут не несколько % процессора.>для того, чтобы получить более стабильную и защищенную от сбоев операционную систему.
...с глюкавыми дровами которые теперь будут писать те же индусы что и остальное.Да, стабильность будет окуенная - будут грохаться не только проги но и дрова.А чо, не фатально же!Упало?Ну и черт с ним, отряхнется и дальше пойдет :)>доплатив еще 20-50 долларов можно получить большую производительность,
>которая полностью перекроет всю ту дополнительную нагрузку на центральный процессор.
Осталось убедить юзеров что им надо заплатить 50 баксов непонятно за что.>преимуществом будет возможность не потерять не сохраненные данные,
Ага.Особенно если накрылся драйвер контроллера диска например =)>и большая защищенность и стабильность работы системы. стоит ли овчинка
>выделки? лично для меня - да. у тебя разумеется может быть свое
>собственное мнение
Да я просто думаю что тормозов добавят, рас3.14..и дровописатели станут писать дрова более халтурно и в итоге будет веселая картина: система тормозит, дрова грохаются не реже апликух, но оно таки не дохнет совсем, имитируя какую-то деятельность.Только вот такая система врядли кому сильно нужна кроме вас и Таненбаума.>чем заплатить несколько десятков долларов.
Я заплачу, если увижу в этом необходимость.За 12 лет у меня ничего не слетело на дисках по вине посторонних драйверов "что-то не то записавших на диск".Вот по вине кривых драйверов контроллеров диска или файловой системы и т.п. касающегося дисковой подсистемы - да, видел несколько случаев.Но там не важно в каком они кольце - если драйвер разрушает данные, он это на любом кольце сделает.>однако, глюки в таких драйверах - это ОЧЕНЬ редкое явление.
Однако глюки в результате которых драйвер одной железки напакостит другой - это вообще чуть ли не фантастика.В теории конечно возможно но на практике это на уровне фантастики.Так же в теории вам может прямо сейчас метеорит на голову упасть, это ничему не противоречит.А вот на практике вы скорее помрете от старости или попав под камаз, чем дождетесь попадания метеорита в голову.Вы же предлагаете всем по поводу теоретической вероятности попадания метеорита в бошку засунуться в укрепленный железобетонный бункер, где и просидеть всю жизнь.Возникает резонный вопрос - а так ли оно надо?>для возможности найти и устранить причину падения -
>надо как минимум снять и сохранить дамп памяти.
А регистры?>гораздо чаще глючат всякие звуковухи/сетевухи/видяхи и прочая периферия.
Ага.Ну встало у вас видео раком и ничего не показывает.Вам сильно полегчало что система не совсем сдохнет а только наполовину?Вы конечно же на ощупь сохраните документы и сделаете перезагрузку как супер профи? oO>заглючит какой-то там сканнер, или звуковая карточка - мне это пофигу.
...но ребутнуться придется 1 фиг.>главное - это иметь возможность спокойно сохранить не сохраненные данные,
Ага, а это еще зависит от того что навернется, не так ли?:)>и корректно завершить работу операционной системы и файловых систем.
Опять же.Скажем навернулся драйвер контроллера дисков.И куды корректно завершаться?В /dev/null? :).А так банальный эдитор может навернуться похерив результат вашей работы за пол дня забыв у вас спросить нужны ли вам эти данные.И никакие дрова вас от этого не спасут, если вы забудете засэйвить документ вовремя.>сейчас этого не делается потому, что заглючивший драйвер имеет доступ
>к памяти ядра и может испортить как само ядро, так и код
>других драйверов.
Может.А заглючившая от некорректных действий драйвера железка тоже может неизвестно что сделать.>ислючения только подтверждают правило. если раком встал центральный
>процессор - тогда действительно, операционная система уже мало что
>может сделать. если этот процессор в компьютере был только один...
Ядер два, а фигли.Они оба раком встают при неверной комбинации FID и VID и сохраняют данное положение до power off системы :).При том действие легитимное - управление частотой проца через документированный интерфейс.То что выданы значения которые для конкретно этого проца недопустимы - ну и кто дурак кроме драйвера и возможно приложния которым это понадобилось?>если эта видяха нужна для игр - это проблема, без нажатия
>на reset играться дальше действительно будет невозможно.
Да даже для веб браузинга.Один фиг.А для серверов - так там проценты производительности роляют...>если же код драйвера видеокарточки изолирован от пользовательских
>процессов, кода ядра и кода других драйверов, и при глюке он мог
>привести в нерабочее состояние только сам себя и свое hardware -
>тогда операционная система остается живой и вполне работоспособной.
А радости с этого?Походите вокруг системника, поймете что сделать ничего не можете да нажмете ресет :).Во всяком случае это типовая реакция юзеров на проблемы видео или клавиатуры даже если остальная часть системы живая.>остается возможность сохранить не сохраненные данные, и корректно
>завершить работу операционной системы. каким именно способом это будет
>сделано - по сети, через ком-порт, или просто нажатием на кнопку Power
Ага, рядовой юзер уже держит приблуды для сети и компорта, чтобы зашатдаунить систему, ага.Они обычно подносят палец к кнопке Reset :)
>это уже нюансы. кстати, драйвер видяхи заглючил, но драйвер звуковой карточки
>то остался живым... и комп вполне может сообщить о проблеме через колонки...
%) не требуется.Юзер сам сообщит голосом о данном факте, как в том приколе про "Your bunny wrote" :)
>десктопные пользователи будут очень благодарны, что им не придется потерять
>все свои несохраненные данные только потому что заглючил драйвер видеокарточки.
Я думаю, они не увидев картинки на экране жахнут ресет.Разумеется потеряв что не успели сохранить.Потому что вслепую они это сделть не смогут.>уровень понимания архитектуры IA32 очевиден. дальше можно не продолжать.
:) так написано же - ламер.В IA32 я вполне себе он и есть.Только вот вы забыли что линукс например существует не только на IA32 и ради войны с призраками ограничивать его архитектурой довольно странно.Более того, этого никто не будет делать.>4.5 PRIVILEGE LEVELS
А вам не кажется что это IA32-специфично а я о ней нигде не говорил?Тот же линукс используется на еще туевой хуче архитектур.>> А кто это определил? Вы? Таненбаум? Ох какие резвые перцы.
>> старина Таненбаум может и дальше гундеть, а толку то?
>> Лучше б Таненбаум убогий х86 хоронил, а то правильная система на дерьмовом железе
> СЛОН И МОСЬКА
Это вы о Таненбауме чтоли?Ну, он то может лаять сколько влезет, а линукс и винды будут делать весьма скромно считаясь с его мнением.Даже если он в чем-то и прав.
> это приведет к тому что 99% юзеров просто не смогут заапдейтить bios
> и это будет эквивалентно тому как если бы в плату был запаян mask ROM.> А я как специалист по юзабилити говорю вам:
> 99% юзеров не дотянется до нужной перемычки.если юзер не в состоянии переставить джампер,
самостоятельно перешить BIOS он тоже не сможет.для этого нужно ведь переставить порядок загрузки в BIOS Setup,
сделать загрузочную дискету с DOS, положить туда флешер и образ
нового биоса, загрузиться с этой дискеты, запустить перепрошивку,
потом обратно вернуть последовательность загрузки в BIOS Setup.[...]
>> я говорю сейчас не о качестве драйверов, а той проблеме, что любой
>> кривой драйвер может в любой момент заглючить всю операционную систему,
>> вместе со всеми прикладными приложениями и всеми несохраненными данными пользователя.> Дык падеж многих из драйверов 1 фиг вызовет потери данных
> которые не были успешно обработаны драйвером.потеря "данных", которые не успел обработать драйвер сканнера,
звуковой карточки, видеокарточки, принтера и т.п. - это не проблема.>> если следовать этой логике,
>> тогда и прикладные программы надо вернуть на 0-й уровень привилегий,> Не совсем так. Приложений много и они глючные.
> Ядра и драйверов не много, они маленькие, стабильные и подконтрольные.количество подсистем ядра небольшое, они хорошо документированы,
для понимания логики их работы есть вся необходимая информация.количество драйверов для различных устройств в ядре операционной системы
большое, еще больше их не входит в состав ядра, а поставляются отдельно.понять алгоритм работы драйвера не имея полной спецификации оборудования -
очень трудно, часто оборудования документировано только частично, иногда -
вообще не документировано. многие драйвера сделаны через reverse engineering.сейчас драйверов различной периферии уже много, со временем их количество будет
только увеличиваться, этот процесс будет идти по возрастающей, как снежный ком.соотношение примерно такое:
count(subsystems) / count(drivers) ~= count(drivers) / count(applications)
subsystems - это подсистемы ядра, например, файловые системы, сетевые протоколы и т.п.
drivers - драйвера оборудования, который исполняются в ядре операционной системы.
applications - прикладные программы.
сейчас - ситуация со стабильностью и надежность работы операционной системы
вполне приемлимая. проблемы сейчас в другом - очень мало оборудования поддерживается.
поэтому со временем количество драйверов оборудования для Linux будет только
увеличиваться.например, постоянное увеличение количества прикладных программ - это очень хорошо,
и никаких проблем с собой не несет. некорректная работа любой прикладной программы
никак не может повлиять на стабильность работы операционной системы и других программ.постоянное же увеличение количества драйверов - это уже проблема стабильной работы.
если принять среднее количество ошибок в коде драйверов за константу, то при увеличении
количества драйверов, например, в 10 раз - стабильность работы ядра в среднем уменьшится
также в 10 раз. (при условии что все оборудование используется более-менее равномерно).
увеличится количество драйверов в 100 раз - стабильность работы операционной системы
также уменьшится примерно в 100 раз. например, через 10-20 лет для Linux может быть
выпущено в 1000 раз больше драйверов, чем их существует сегодня.например, на эти грабли майкрософт уже наступила, потому что под Windows существует
гораздо больше драйверов, чем их существует под Linux. и это при этом, что kernel API
стабильно, существует огромное количество литературы, курсов, треннингов, примеров кода,
и т.п. всеравно, причина примено 80% BSOD операционной системы Windows NT/2K/XP/2K3 -
это кривые драйвера, которые исполняются в с привилегиями ядра операционной системы.по сути, код сторонних, низкоквалифицированных разработчиков
имеет MS Windows NT/2K/XP/2K3, как любая прикладная программа имеет MS DOS.>> чтобы разработчики стали очень внимательно
>> относиться к качеству и безглючности своего кода. я правильно понимаю?> А это зависит от системы. В некоторых системах нет разделения кода
> на юзера и систему, ибо нафиг не надо (скажем любой сбой фатален
> и по этому поводу лучше сбросить систему для заведомо нормальной инициализации
> чем работать с возможно засранной памятью и некорректными данными).
> Обычно это небольшие системы где качественное тестирование
> может быть проделано для всего кода а не только небольшого ядра.системы которые исполняются на микроконтроллерах, например, VxWorks
имеют такой дизайн потому что микроконтроллеры не имеют защиты памяти.
и практически по всем параметрам VxWorks хуже QNX. особенно в тех
случаях, где нужна максимально возможная надежность и устойчивость.
например, маршрутизаторы Cisco серии CRS-1 и 12000 построены
на основе QNX, это между прочим, microkernel-based operating system.>> полный доступ абсолютно ко всему железу любому драйверу -
>> не нужен для выполнения его узкоспециализированных задач.> Ага, но только на уровне железа оно как-то не особо то здорово поддержано.
99% персональных компьютеров используют процессоры Intel,
или совместимые с ними по наборам команд. на уровне железа
разграничение доступа к оборудованию поддержано просто отлично.позволю себе напомнить, что мы говорим о проблеме в контексте
прихода Linux на десктопы, основным сдерживающим фактором здесь
является отсутствие драйверов ко всему этому зоопарку оборудования.написать быстро, качественно и бесплатно несколько десятков тысяч
драйверов к различному оборудованию, часто без наличия документации
- это практически нереально. пока что это делается не быстро.
если будет быстро - тогда это будет сделано некачественно.> Да и честно говоря не видел я как-то драйверов
> которые портят жизнь чужой железке, это уж совсем клиника.у тебя просто нет возможности об этом узнать, потому что падать и глючить
в этом случае будет не тот драйвер, который является причиной сбоев,
а тот драйвер и та железка, которые не являются причиной проблем.еще одна неприятная ситуация - это когда драйвер просто тупо портит
память ядра операционной системы. и тогда проблемы могут проявиться
любым способом - от внезапного зависания или перезагрузки до разрушения
файловых систем, или нарушения целостности данных любой прикладной программы.>> лично мне например, не жалко несколько процентов производительности процессора
> Есть подозрение что при большом числе прерываний
> там будут не несколько % процессора.на десктопе процессор в среднем загружен на 3-5%.
он всеравно проистаивает, а так - мог бы работать обеспечивая дополнительную защиту.>>для того, чтобы получить более стабильную и защищенную от сбоев операционную систему.
> ...с глюкавыми дровами которые теперь будут писать те же индусы что и остальное.
глючащий драйвер звуковухи, сканера, модема, принтера, или wi-fi адаптера -
это серьезная проблема, если он время от времени будет ронять операционную систему,
и совсем не конец света, если глюки этого драйвера изолированы, и не могут повлиять
на остальные части ОС.>> преимуществом будет возможность не потерять не сохраненные данные,
>> и большая защищенность и стабильность работы системы.> Ага.Особенно если накрылся драйвер контроллера диска например =)
различных контроллеров жестких дисков - очень мало.
драйвера для них уже написаны, отлажены и работают.проблема с другими драйверами - для всего этого зоопарка различной
периферии, которой очень много и к которой сейчас у линукса драйверов нет.> Да я просто думаю что тормозов добавят, рас3.14..и дровописатели
> станут писать дрова более халтурноесли производитель оборудования пишет драйвера - он является наиболее заинтересованым
лицом, чтобы эти драйвера работали максимально надежно и стабильно. ведь от этого напрямую
зависит возрастание количества продаж и соответственно, увеличение лично его прибыли.> и в итоге будет веселая картина: система тормозит, дрова грохаются
> не реже апликух, но оно таки не дохнет совсем, имитируя какую-то деятельность."система тормозит" на любом медленном процессоре. если процессор имеет 4, 8
или больше ядер затормозить такую операционку дополнительной нагрузкой ядра
даже в 10-15% очень трудно. всеравно на десктопе больше 90% ресурсов CPU
не используются.>> для возможности найти и устранить причину падения -
>> надо как минимум снять и сохранить дамп памяти.> А регистры?
и регистры тоже. и состояние стека. это разве не очевидно?
[...]
>> ислючения только подтверждают правило. если раком встал центральный
>> процессор - тогда действительно, операционная система уже мало что
>> может сделать. если этот процессор в компьютере был только один...> Ядер два, а фигли.
Вы понимаете разницу между терминами "два ядра" и "два процессора"?
>> уровень понимания архитектуры IA32 очевиден. дальше можно не продолжать.
> :) так написано же - ламер. В IA32 я вполне себе он и есть.
это я уже понял... а откуда такая враждебность к Таненбауму и microkernel-based OS ?
ведь в плане надежности, устойчивости работы до QNX большинству ОС еще очень далеко...PS на всякий случай: "ограничение полномочий доступа драйверов устройств",
и "микроядерная архитектура операционной системы" - это не одно и то же.PPS у меня сейчас мало свободного времени, чтобы переливать из пустого с порожнее.
и уж меньше всего я хочу тратить свое время на то, чтобы спорить с "ламерами".
>если юзер не в состоянии переставить джампер,
>самостоятельно перешить BIOS он тоже не сможет.
Да что вы говорите?Вы наверное задержались в 1990-х?Никогда не видели виндовый awdflash который шьет биос прямо из под винды?(ессно подгрузив драйвер, и для этого ессно должны быть права).Впрочем, досовую дискету часто нынче дают как программку-selfextractor которая сама же и режет образ на флоппик.Охренеть как трудно - стартануть прожку, засунуть флоп, потом в биос сетапе указать загрузку с флопа.Особенно если учесть что у современных сетапов есть меню откуда грузиться так что даже в сетап лезть не надо...
[skip...]>потеря "данных", которые не успел обработать драйвер сканнера,
>звуковой карточки, видеокарточки, принтера и т.п. - это не проблема.
А это как повезет.У меня в Win98 когда-то падал драйвер принтера.Падучий был по жизни.Ну вот, принтер оставался в раскоряченном состоянии и до power off не работал.А система после синего скрина и предложения нажать any key работала как ни в чем не бывало, правда, без принтера.Я бы не сказал что меня перло такое поведение драйвера.В итоге принтер был сбагрен к ядреной фене - пользоваться им было невозможно.>> Не совсем так. Приложений много и они глючные.
>> Ядра и драйверов не много, они маленькие, стабильные и подконтрольные.
>количество подсистем ядра небольшое, они хорошо документированы,
>для понимания логики их работы есть вся необходимая информация.
В ядре линукса полно драйверов.Они его часть.Вопросы?>большое, еще больше их не входит в состав ядра, а поставляются отдельно.
Угу.Я аж целые дрова видяхи ставил отдельно, во!Писец, сколько у меня в системе драйверов не вошедших в ядро!Аж 1 драйвер!Это ж ужас!Представил что сможет продемонстрировать драйвер видяхи в user mode... не, нафиг такое счастье.Сами его там и пользуйте, а микрософт один разок уже нечто такое делал - в NT 3.51.Ужаснулись и сделали NT 4 :)>вообще не документировано. многие драйвера сделаны через reverse engineering.
Угу, поэтому пусть их теперь еще и индусы и прочие пишут для полного счастья.>сейчас драйверов различной периферии уже много, со временем их количество будет
>только увеличиваться, этот процесс будет идти по возрастающей, как снежный ком.
Ага.В висте уже 22 000 дров.И ничего, в ядре работают.>сейчас - ситуация со стабильностью и надежность работы операционной системы
>вполне приемлимая.
Типа отмазались.А нахрен чинить то что не сломано?>проблемы сейчас в другом - очень мало оборудования поддерживается.
Вариант решения этой проблемы путем ослабления требований к качеству оных меня как-то не прет.Нахрен нужна еще одна Win98 которая не подыхает совсем после сбоя драйвера, но зато дрова у которой глючные а оборудование отказывает в самый неподходящий момент?После того как микрософт сделал в NT по сравнению с 9x синий скрин 1-разовым и фатальным, без шанса потрепыхаться дальше как в 9х - качество драйверов предсказуемо резко скакнуло вверх.Вы предлагаете вернуть как было.А нахрена?>например, постоянное увеличение количества прикладных программ - это очень хорошо,
>и никаких проблем с собой не несет. некорректная работа любой прикладной программы
>никак не может повлиять на стабильность работы операционной системы и других программ.
Ахха, расскажите это авторам иксов :).Вроде юзерский процесс а как упадет - так как серпом по яйцам.А вроде даже не драйвер...>постоянное же увеличение количества драйверов - это уже проблема стабильной работы.
Я понимаю что нынче много любителей воевать с ветряными мельницами и искать проблему где ее нет.>увеличится количество драйверов в 100 раз - стабильность работы операционной системы
>также уменьшится примерно в 100 раз.
Теория, конечно, круто, но вот что до стабильности - я самолично видел линуксный сервер с аптаймом 2 года и виндовый, с аптаймом полгода(был перегружен чтобы апдейты поставить, а вы что подумали).Зафиг чинить то что не сломано?>например, на эти грабли майкрософт уже наступила,
Ага, в висте 22 000 драйверов, в ядре, и ничего, никто не помер...>гораздо больше драйверов, чем их существует под Linux. и это при этом,
>что kernel API стабильно,
Да что вы, и недокументированное тоже?Да и меняется оно малость между версиями.Дрова NT4, 2k, XP и 2003 не полностью совместимы.>и т.п. всеравно, причина примено 80% BSOD операционной системы Windows NT/2K/XP/2K3 -
Ага, только если не покупать говенное железо с такими же драйверами к нему - все прекрасно работает годами.К тому же дешевое железо обычно юзает референсные реализации и посему цепляется стандартными дровами из ядра.>системы которые исполняются на микроконтроллерах, например, VxWorks
>имеют такой дизайн потому что микроконтроллеры не имеют защиты памяти.
Микроконтроллеры разные бывают.А uCLinux кстати по вашему это что?Не, я понимаю что некоторым насрать на линукс на не очень толстых камнях, но это зря.>и практически по всем параметрам VxWorks хуже QNX. особенно в тех
>случаях, где нужна максимально возможная надежность и устойчивость.
Да что вы говорите?А теперь найдите в ответственных областях, там где отказ девайса может создать реальные проблемы людям или окружающей среде, хотя-бы писюк вообще в качестве логики которой доверено опасные решения принимать.А простые процессоры с несложной фирмварью как-то справляются без микроядер, параноидальных защит от хз чего и т.п. - просто за счет предсказуемости и выверенностикода, безопасного дизайна системы (аппаратные блокировки) и вачдога.>например, маршрутизаторы Cisco серии CRS-1 и 12000 построены
>на основе QNX, это между прочим, microkernel-based operating system.
Насчет цисок ничего не скажу, не интересовало меня на чем они их делают, но вот насчет их безотказности есть существенные опасения.Кошаки судя по виденному мной - те еще халтурщики.Просто маркетинг у них хороший, это не отнять.А остальное у них как-то средненько, особенно для своих денег :)ЗЫ что до меня так лично я предпочитаю юзать систему которая бегает не спотыкаясь а не такую которая запнувшись и растянувшись не сходит с дистанции а вместо этого быстренько отскребается с асфальта и пробует двинуть дальше, если состояние позволяет.Де факто узаконеный костыль.
>99% персональных компьютеров используют процессоры Intel,
Linux используется не только в персональных компьютерах.>позволю себе напомнить, что мы говорим о проблеме в контексте
>прихода Linux на десктопы,
А откуда вы это взяли?Вы может и говорите конечно, но я что-то не вижу куч микроядерных систем на десктопах пока.Приведенные вами в качестве примера циски никак не десктоп например.>является отсутствие драйверов ко всему этому зоопарку оборудования.
Да там не так уж и много всего неподдерживаемого осталось...>если будет быстро - тогда это будет сделано некачественно.
Предлагаете упростить написание некачественных драйверов?Спасибо.Сами и будете потом пользовать получившийся Win98 номер два.>а тот драйвер и та железка, которые не являются причиной проблем.
Ага, только почему-то я обычно вижу как наворачивается или сбоит именно проблемный драйвер.А научная фантастика это круто но практика обычно прозаичнее.>еще одна неприятная ситуация - это когда драйвер просто тупо портит
>память ядра операционной системы.
...поэтому то винды нынче и грохаются сразу в бсод, а ядро в кору.Чтобы минимизировать риск работы с глючным железом или битой\засраной памятью.Кстати этот подход за который так ругают существующие системы в качестве ПЛЮСА _минимизирует_ урон от заглючившего железа.На сбоящем железе микроядерная система запросто будет напоминать фоменковское "мыши кололись, плакали но продолжали жрать кактус" - т.е. будет перезапускать сбойнувшие дрова и корраптить дисковые структуры и файлы дальше, как ни в чем не бывало.>на десктопе процессор в среднем загружен на 3-5%.
Вы знаете, мне пофигу на температуру в среднем по больнице.В моем понимании процессор должен мало кушать в крейсерском режиме и быть способным на хорошую пиковую скорость когда это надо.В этом случае вырастет и жрач в крейсерском режиме и упадет производительность в пиковом режиме.Трудно приветствовать это.Особенно когда цель - война с мифическими чудищами которых никто не видел но которые в принципе существовать могут.
>он всеравно проистаивает, а так - мог бы работать обеспечивая дополнительную защиту.
Ага, воздух сильнее греть будем.А ради чего никому не ведомо.Можно еще сказать что дескать, ядро могут писать в принципе и быдлокодеры - исходники же открыты!Быдлокодеры могут настрогать нестабильных ядер, так вот, чтобы кривое ядро не роняло все вообще, давайте туда засунем гипервизор и пусть можно будет только ему.А ядро - а пусть в юзере целиком клюет, ибо нефиг :)>глючащий драйвер звуковухи, сканера, модема, принтера, или wi-fi адаптера -
>это серьезная проблема, если он время от времени будет ронять операционную систему,
Если у меня будет периодически отваливаться какой-то девайс с побочными эффектами это достаточно серьезная проблема чтобы подумать о выкидывании этого девайса.Халтурить на качестве кода драйверов поганая идея ИМХО, будет Win98 номер два.А узаконивать право на халтуру в драйверах - извините, потакание халтурщикам.>и совсем не конец света, если глюки этого драйвера изолированы, и не
>могут повлиять на остальные части ОС.
Конец света будет тогда когда быдлокодеры решив что раз глюки узаконены то и отлаживать код не обязательно начнут клепать сырые драйвера качеством как современные приложения(которые по любому чиху типа завершения места на диске или окончанию памяти даже ругнуться нормально не в состоянии - тупо крашатся и всё...).Что до меня так выбор из глючных драйверов и совсем никаких извините хреновый.Пусть лучше грамотных кернел кодеров станет больше и они начнут писать отлаженные дрова чем всякие ушлепки начнут писать дрова по принципу как сейчас приложения пишут - "о, вроде работает, подумаешь, падает раз в час, никто и не заметит!"
>различных контроллеров жестких дисков - очень мало.
>драйвера для них уже написаны, отлажены и работают.
У-лю-лю... ага, очень мало, хм... а чойта тогда есть даже страничка посвященная контроллерам S-ATA в линукс, не знаете?>если производитель оборудования пишет драйвера - он является наиболее заинтересованым
>лицом, чтобы эти драйвера работали максимально надежно и стабильно.
Расскажите это ***, хьюлет-пакарду, дрова принтера у которого в вин98 с завидной стабильностью летали в синий скрин.С отваливанием принтера до ребута(система после нажатия на any key выживала и нормально работала).А их же но NTшные (NT имеется в виду технология а ос кажется была 2К) драйвера такого себе не позволяют.Наверно потому что там синий экран куда фатальнее - юзер остается не только без принтера но и без системы вообще :).Выбирая между дровами хьюлета для 98 и NT - понятно какие я предпочту, да?Те которые не отваливаются в ответственный момент, мля и работают как часы.>зависит возрастание количества продаж и соответственно, увеличение лично его прибыли.
В теории все круто а практика - см.выше, ровно наоборот.Если известно что сбой в коде приведет к фатальным последствиям, код отлаживается тщательно, ради этого могут отложить дату релиза, etc, но чтобы было починено и не колебет.Иначе - код отлаживается абы как: скажут "ну и хрен с ним - как-то ведь оно работает, а срывать дату релиза типа нехорошо, выпустим так, потом если много недовольных будет может и починим".>"система тормозит" на любом медленном процессоре. если процессор имеет 4, 8
>или больше ядер затормозить такую операционку дополнительной нагрузкой ядра
>даже в 10-15% очень трудно. всеравно на десктопе больше 90% ресурсов CPU
>не используются.
Угу.Понял:)Все эти ядра делают для понта, ага.Правда ламак с 2-ядерной системой способный пригрузить оба ядра на все сто об этом не знает и дарить 15% CPU непонятно кому и за что желанием особо не горит.Защита?WTF защита?От кого?У меня кроме иксов (и то изредка, в специфичной ситуации) и так ничего не падает.От падения иксов ваша защита 1 фиг не спасет.И нахер она у меня будет жрать 15% процессора, для отопления воздуха чтоли?Спасибо, но это очень уж напоминает желание полечить здорового пациента.>[...]
>Вы понимаете разницу между терминами "два ядра" и "два процессора"?
Я то понимаю.И что?А вы, профессор, если такой умный, устройте лекцию.Расскажите ламаку, чему в принципе противоречит идея менять частоты 2(или более) ядер на 1 кристалле независимо друг от друга, или наоборот, выставлять частоту нескольких физически отдельных процессоров синхронно?(я помолчу о том что некоторые фирмы жульничают и как многоядерные процы продают ... 2 кристалла в 1 упаковке - дык где там грань между 2 ядра и 2 процессора?2 кристалла в 1 порпусе - это у нас что?Два ядра или 2 процессора?Или и то и другое?)>это я уже понял... а откуда такая враждебность к Таненбауму и microkernel-based
>OS ?
Да как вам сказать, когда мне втирают "%s - рулез и решит все мирские проблемы!", я прикидываю, а что оно мне даст, чем придется пожертвовать и что будет взамен.Получается как-то беспонтово - система притормозит ради лечения проблемы которую днем с огнем не найдешь.Враждебности кстати нет - я просто не понимаю зачем нечто надо объявлять рулезом и потом пытаться совать в каждую дырку, насильно пичкая этим всех окружающих "для их же блага".Получается гербалайф :).Да, у микроядра есть плюсы.Но давайте посмотрим как реалисты?Если система и без того не страдающая резвостью в WinE притормозит еще на 15%, гамезы у народа будут ползать куда хуже чем в висте.В серверах тоже как-то 15% не лишние.В мелких девайсах типа наладонников с процессором вообще душно - там и скорость не ахти, и даже если она есть, много им молотить нежелательно - а то батарейка выдохнется быстро.Что останется?Типичный офисный писюк?Эээ.. там драйверов то надо - раз-два и обчелся.>ведь в плане надежности, устойчивости работы до QNX большинству ОС еще очень
>далеко...
Угу, а QNX очень далеко до реальной востребованности.Ну да, где-то она используется.Правда 99% смертных никогда ее не видели и наверное и не увидят.>PS на всякий случай: "ограничение полномочий доступа драйверов устройств",
> и "микроядерная архитектура операционной системы" - это не одно
>и то же.
Это то понятно.Но часто микроядерность преподносится именно под этим соусом.Лично мне не понятным - лечат проблему которой в общем то почти нет и еще гордятся этим.На ум приходит Дон Кихот воюющий с ветряными мельницами :).И почему это должно называться именно линуксом?Чем таненбаумовский minix не система для фанов микроядерности для которых микроядро - это типа круто и типа самоцель?Линукс это то что есть сейчас.Его знают и любят именно таким.Если он кому-то не нравится, зачем его использовать?Возникает ощущение что вам надо совсем другую операционку с другими свойствами...но чтобы она называлась именно Linux :).А зачем?И почему именно Linux?Потому что вы претесь от сочетания именно этих 5 букв и поэтому любая приглянувшаяся вам система должна называться именно так?Странная логика - "хочу совсем другую систему, но чтобы называлась :))) так же как вот эта!">PPS у меня сейчас мало свободного времени, чтобы переливать из пустого с
>порожнее.
> и уж меньше всего я хочу тратить свое
>время на то, чтобы спорить с "ламерами".
Да, флейма развели солидно... давайте сворачивать понемногу.
>> если юзер не в состоянии переставить джампер,
>> самостоятельно перешить BIOS он тоже не сможет.> Никогда не видели виндовый awdflash который шьет биос прямо из под винды?
это без разницы, какой утилитой перепрошивать. в 80% нужно будет после этого
перезагрузить компьютер, войти в BIOS Setup, ресетнуть все настройки на Default,
после этого выставить их в правильные значения. нередко бывает так, что перед тем,
как прошивать последнюю версию - обязательно надо предварительно залить промежуточную.это - невыполнимая задача для юзера,
который не в состоянии переставить джампер из положения 1-2 в 2-3 и обратно.[...]
>> и практически по всем параметрам VxWorks хуже QNX. особенно в тех
>> случаях, где нужна максимально возможная надежность и устойчивость.> Да что вы говорите? А теперь найдите в ответственных областях, там где отказ
> девайса может создать реальные проблемы людям или окружающей среде, хотя-бы писюк
> вообще в качестве логики которой доверено опасные решения принимать."писюк" - это аппаратное обеспечение.
VxWorks и QNX - это операционные системы.там где отказ девайса может создать людям реальные проблемы используют QNX.
например, атомные станции, атомные подводные лодки, маршрутизаторы Cisco CRS-1.там же где используется кривая VxWorks - оно время от времени глючит.
например, Nortel`овская ATS Meridian, или тот же насовский марсоход Spirit.> А простые процессоры с несложной фирмварью как-то справляются без микроядер,
> параноидальных защит от хз чего и т.п. - просто за счет предсказуемости
> и выверенностикода, безопасного дизайна системы (аппаратные блокировки) и вачдога.нет там никакой предсказуемости, когда любой процесс может испортить память любого
другого процесса в системе. и это совсем не обязательно приводит к перезагрузке железки.
глюки вылезают в совершенно неожиданных местах.>> например, маршрутизаторы Cisco серии CRS-1 и 12000 построены
>> на основе QNX, это между прочим, microkernel-based operating system.> Насчет цисок ничего не скажу
> не интересовало меня на чем они их делаюттак вот вместо того, чтобы писать по 150 килобайт флейма - поинтересуйся,
это очень интересные устройства, и пользы лично тебе от этого будет больше.> но вот насчет их безотказности есть существенные опасения.Кошаки судя по
> виденному мной - те еще халтурщики.Просто маркетинг у них хороший, это
> не отнять.А остальное у них как-то средненько, особенно для своих денег :)старые циски сделаны на основании монолитного BSD ядра,
за которое ты тут так агитируешь. кстати, совсем недавно
в этих "монолитных" IOS`ах нашли новые критические уязвимости...[...]
> ЗЫ что до меня так лично я предпочитаю юзать систему которая бегает не спотыкаясь
разумеется, лучше быть здоровым и богатым, чем бедным и больным.
[...]
> я что-то не вижу куч микроядерных систем на десктопах пока.
Mac OS X, например. посмотри на Appl`овском сайте, например,
ролики про их новую версию - http://www.apple.com/macosx/leopard/
особенно мне понравилась их новая фича под названием Time Machine.[...]
>> является отсутствие драйверов ко всему этому зоопарку оборудования.
> Да там не так уж и много всего неподдерживаемого осталось...
еще много осталось...
[...]
> В теории все круто а практика - см.выше, ровно наоборот. Если известно что
> сбой в коде приведет к фатальным последствиям, код отлаживается тщательно,
> ради этого могут отложить дату релиза, etc, но чтобы было починено и не колебет.например, французская ракета-носитель, завалившаяся через две минуты после
старта из-за ошибки в программе. - http://www.ci.ru/inform11_97/vzrv.htm[...]
>> "система тормозит" на любом медленном процессоре. если процессор имеет 4, 8
>> или больше ядер затормозить такую операционку дополнительной нагрузкой ядра
>> даже в 10-15% очень трудно. всеравно на десктопе больше 90% ресурсов CPU
>> не используются.> Угу.Понял:) Все эти ядра делают для понта, ага.
в основном да. потому что если Intel перестанет выпускать новые процессоры -
у нее не будет источников дохода, соответственно фирма обанкротится. аналогично AMD.
для того, чтобы получать деньги с юзеров Microsoft и Intel делают все более тормозные
операционные системы и все более быстрые процессоры. иначе - застой и IBM PC XT forever.[...]
> нахер она у меня будет жрать 15% процессора, для отопления воздуха чтоли?
например, то что твой процессор работает в protected mode с включенным страничным
преобразованием - это как раз и дает минус 15% производительности по сравнению
с real mode или big real mode. и ничего, никто вроде не страдает из-за потери этих 15%.[...]
> В серверах тоже как-то 15% не лишние.
в серверах когда стоит вопрос что выбрать - скорость или надежность,
всегда выбирают надежность. как пример можно вспомнить видеодрайвер Windows Server 2003.
>>других драйверов нет.
>Праздравляю.Даже если вы их вынесете в юзер мод они от этого лучше
>не станут.Хуже запросто, поскольку станут более наплевательски относиться к качеству кода
>- а чо, система не падает, баг не фатальный и нии**т.>>например, ошибки в приложениях не могут повлиять на ядро и другие приложения.
>Разделение на систему и юзера задумано.Оно есть в процессоре на уровне железа.Разделения
>ядра и драйверов в железе нет.
есть. 1-3 кольца защиты процессора (это же написал тебе и gmm20)>Посему это придется делать программно.Соответственно будет тормозилово.
как видишь - нет>О да.Конечно же осознание того факта что теперь ляпы в дровах может
>быть и не завалят систему (если повезет) наверное резко прибавит каКчества
>драйверам.Имхо так это прибавит рас...ства программерам и тестерам и дрова станут
>еще поганее.Когда дрова крашат систему это веский повод ловить баг -
>ибо фатально.А если не крашат - ну на баг забьют болт
>да и все дела.Чем менее серьезны последствия бага тем охотнее на
>него кладут.ты путаешь две вещи.
существующие дрова и новые, которые будут когда-либо написаны:
- вынесение всех существующих драйверов из кольца ядра и в отдельные процессы _гигантским_ образом подымет надежность системы с потерей производительности в несколько процентов.
- написание нового драйвера с расчетом его работы в ограниченных полномочиях (в отдельном процессе где-нить на 1-2 кольце) - да, с большой вероятностью снизит его качество из-за меньшего внимания программистов к каждой проблеме в нем. Но это не проблема ни системы, ни драйвера. Это проблема человечества - лень :) Но именно она делает человека человеком.
Ведь действительно, программист сможет немного расслабленнее думать о коде, зная, что он уже подстрахован, и не только ядром, а самим процессором.
Не поверишь, но и этом тоже есть плюс! Стоимость разработки _коммерческих_ драйверов заметно снизится. И, ессьно, более мелкие фирмы смогут позволить себе поддержать свое железо в линухе.
Не об этом ли так мечтают все линухоиды?? (по себе скажу - да, именно об этом!)Но тут, как ты справедливо заметил, будет и обратная сторона - более низкое качество, более частые сбои _самого_ драйвера. Ну так это же с лихвой компенсируется его жизнью в отдельном процессе и... микроядерной архитектурой ;)
Ведь неотъемлемой частью микроядра есть служба перезапуска сервисов :)
(по Таненбауму как минимум. Если че - поправьте)
Именно в этом один из глубоких смыслов микроядерной архитектуры. Упавший сервис - тут же перезапускается, чем обеспечивается минимальное время простоя в предоставляемых им услугах. Та же видуха/сетевуха/звуковуха иногда может быть просто переинициализирована заново перезапущенным драйвером - и продолжить работу! При этом данные всех остальных процессов - остаються гарантированно неповрежденными.
А это настолько немало, что оседлать даже спутник Линуху будет просто вопросом желания его туда поставить.
>А если я скажу что драйвер
>это часть системы, то что?Why not?
Конечно они часть системы :)>Многие дрова входят прямо в ядро
>линукса чем неплохо подтверждают эту точку зрения.НТя тоже так сделана.А почему нет?
>Микроядро - это попытка исправить криворукость драйверописателей за счет >ядрописателей?Тогда маразм.Отлично. У тебя _есть_ (это уже состоявщийся факт если не заметил) неопределенное количество _не_идеального качества драйверов _и_ ядро, возможно тоже не идеального качества.
Задача: сделать систему максимально надежной с минимальными усилиями (вполне реальные условия).
Что ты будешь переписывать: ядро или N+1 драйверов (а не ото всех и сырцы есть...)?
Так кто высказал маразм?
>Это как анек про мужика который ищет ключи под фонарем не потому
>что он их там потерял, а потому что там светлее :)
Опять путаешь теплое и мягкое с кошкой.
Мужику в этом анекдоте главное _искать_. Потому как он выбрал для этого место, где именно искать удобно - под фонарем.
Нам же главное - _найти_, т.е. решить проблему. А то, что она решается изменением архитектуры именно ядра - так это просто повезло, что фонарь светит именно туда, где лежат наши ключи, т.е. в каком-то оперделенном месте. И у нас нет необходимости обходить все злачные места, где побывал этот мужик (все дрова), чтобы там поискать ключи (выцепить все проблемы).
>Лично я за предсказуемую работу низкоуровневых частей моей системы.
>Там просто не должно быть таких багов.
Хм... ты какое ядро пользуешь? Вроде ж линух? Может каких патчей кладешь?
Потому как в ванильном ядре таких багов _УЖЕ_ есть. И как раз с _этим_ нужно что-то делать, а не витать в облаках, уверяя всех, что там чего-то не должно быть.
И твоей великожелаемой предсказуемой работы в линухе пока _НЕТ_ (равно как и в других популярных ОС - так, для справедливости замечу), как бы это ни было обидно.
>А прибамбасы для халявщиков которые дадут системе шанс может
>быть и не подохнуть если их сраный код изволит встать раком
>- это костыли.Которые дадут возможность писать дрова совсем уж халтурщикам (т.е.
>не дровописателям и не кернель программмерам) - качество драйверов от этого
>упадет ниже плинтуса имхо.Понимание того что баг вероятно уронит систему как-то
>способствует качеству кода...
см. абзац о коммерческих дровах и среднего производителя железа. Ну и о популярности линуха там же...
Эти же халявщики _напишут_ дрова под какую-то свою ср**ую железку - потому как это будет несколько проще и дешевле, чем сейчас. И на коробке _будет_ написано "Linux supported". И какой-нибудь менеджер Вася может выберет линух (по ценовым соображениям) под какой-то новомодный сканнер, но который _будет_ поддержан в линухе.
>Краш в драйвере - это не мелкий баг.И вообще на этом свете
>никто никому нихрена не должен.Например, дерьмовая архитектура х86 времен царя гороха
>спокойно уделывает в плане продаж куда более нормальные и современные, и
>ничо, все черпают это г ложками и нахваливают его - как
>оно дескать вкусно.Так что старина Таненбаум может и дальше гундеть, а
>толку то?Лучше б Таненбаум убогий х86 хоронил, а то правильная система
>на дерьмовом железе - форменное кощунство 8)опять сырое и холодное спутал...
Речь о неправильном подходе к ненадежному коду драйверов, а не аппаратной платформе (смена которой, к слову, не меняет пробелмы ни на грамм)
>есть. 1-3 кольца защиты процессора (это же написал тебе и gmm20)
А ты за ВСЕ процессоры которые поддерживаются линуксом ответишь?А то он не только на IA32 работает, вот незадача то...мы как, будем плодить драйвера которые годятся только для конкретной системы, потому что у нее есть такая особенность процессора?Хороший способ угробить в перспективе любую операционку...>>Посему это придется делать программно.Соответственно будет тормозилово.
>как видишь - нет
Да?Точно-точно?А что, есть внятный механизм на всех архитектурах куда спортирован линукс?П это для всех архитектур проверили?Или какой-нить линукс на мобильниках и наладонниках можно и отдать в жертву прихотям Таненбаума? oO>ты путаешь две вещи.
>существующие дрова и новые, которые будут когда-либо написаны:
Если их будут писать в юзере - их будут писать олухи.И тады они будут падучие как обычные приложения.
>- вынесение всех существующих драйверов из кольца ядра и в отдельные процессы
>_гигантским_ образом подымет надежность системы с потерей производительности в несколько процентов.
Гигантским?У меня за последние пару лет крашей в драйверах было явно не больше чем отключений питания которые не вытянул упс который осиливает полчаса.Где этот гигантизм то и в чем он провяляется?У вас что, каждый день падает система от глючных дров?Лично я из сбоев в линуксе помню только краш иксов, не понимаю как от него спасет какой-то там драйвер - грохается вообще юзерский процесс с довольно неприятными последствиями.Кстати, данные при этом в основном не сохраняются :).И фигли мне толку с того что кто-то полечит какие-то возможные краши драйверов которых днем с огнем не найдешь?>нем. Но это не проблема ни системы, ни драйвера. Это проблема
>человечества - лень :) Но именно она делает человека человеком.
А систему может сделать неюзабельным дерьмом.Как раз виндовс 95 получится :) где навертываются не только приложения но и драйвера :)>Не об этом ли так мечтают все линухоиды?? (по себе скажу -
>да, именно об этом!)
Ага, будет у вас полуработающий индусский драйвер.Сорцы дать пожлобятся поэтому у вас получится системка с стабильностью 98 винды :).Та тоже - покажет синий скрин, соотв. девайс порой уходит в даун, а система дальше себе пашет как ни в чем не бывало, если память сильно не засралась.Будет то же самое примерно - подыхающие на каждый чих драйвера девайсов.>Ведь неотъемлемой частью микроядра есть служба перезапуска сервисов :)
Угу, win95 тоже обычно не дох после синего экрана... типа, надо этот подвиг повторить?:)>тут же перезапускается,
Ага.Грохнется какойнить драйвер файловой системы, интересно, как он при перезапуске обойдется без потерь данных, если его вышибло не дав доделать дисковые операции?>драйвером - и продолжить работу! При этом данные всех остальных процессов
>- остаються гарантированно неповрежденными.
Ага.Зато при сбое железа система будет засирать память, гадить на диск, перезапускать драйвера, но работать, работать и работать.Забивая диск коррапчеными данными из побившейся памяти... лучше бы сразу упала в бсод и стопорнулась - меньше корапченой дряни на винт попадет.>А это настолько немало, что оседлать даже спутник Линуху будет просто вопросом
>желания его туда поставить.
А может, это должна быть отдельная система или ветка ядра?Я че-то не хотел бы под управлением китаезного десктопнго железа в космос лететь, 1 фиг.>Отлично. У тебя _есть_ (это уже состоявщийся факт если не заметил) неопределенное
>количество _не_идеального качества драйверов _и_ ядро, возможно тоже не идеального качества.
Отлично, но лично мне оно жить не мешает - ну не падает у меня каждый день ни ядро ни дрова.Может это и модно - воевать с ветряными мельницами, но это явно не за мой счет, ага?... (кто там про 50 уе на более мощный проц говорил выше?)>Что ты будешь переписывать: ядро или N+1 драйверов (а не ото всех
>и сырцы есть...)?
>Так кто высказал маразм?
Ну, будут дрова летать как г*вно на голову.Это вы называете стабильной системой?Я это называю маразмом :\>Нам же главное - _найти_, т.е. решить проблему. А то, что она
>решается изменением архитектуры именно ядра - так это просто повезло, что
>фонарь светит именно туда, где лежат наши ключи,
А они там лежат?Такое ощущение что Таненбаум вбил себе в бошку что проблема есть.И теперь усиленно втирает остальным что да, типа, проблема!>>Лично я за предсказуемую работу низкоуровневых частей моей системы.
>>Там просто не должно быть таких багов.
>Хм... ты какое ядро пользуешь? Вроде ж линух? Может каких патчей кладешь?
Ну, линукс.И что?Что мне надо сделать чтобы у меня грохнулось ядро или драйвера?Максимум умею ронять иксы далеко не стопроцентно.Это юзерский процесс вообще.То что вы там вылечите в драйверах, иксам стабильности не прибавит.>Потому как в ванильном ядре таких багов _УЖЕ_ есть. И как раз
>с _этим_ нужно что-то делать, а не витать в облаках, уверяя
>всех, что там чего-то не должно быть.
Эээ... до кучи запретить и ядру работать с железом и иметь полный доступ ко всему?А кто тогда будет это делать?Гипервизор?А кто ему запретит быть бажным и сделать вместо ядра то же самое? :)>И твоей великожелаемой предсказуемой работы в линухе пока _НЕТ_ (равно как и
>в других популярных ОС - так, для справедливости замечу), как бы
>это ни было обидно.
Хм.То-то я смотрю, сервак вон линуксный у перца стоит, аптайм всего-то какая-то пара лет натикала.Наверное, у него полон рот проблем с драйверами и ядром.Давайте его полечим для профилактики, а то работает, сцуко, и не падают там драйвера - непорядок однако, где же г-н Таненбаум и его крахи в драйверах?>см. абзац о коммерческих дровах и среднего производителя железа. Ну и о
>популярности линуха там же...
Угу.Давайте лечить дерьмовость дров отъемом у них прав.Интересный подход, направленный не на устранение проблемы а на хрен знает что.А может, лучше полечим головную боль гильотиной а гланды вырежем через попу автогеном?>>толку то?Лучше б Таненбаум убогий х86 хоронил, а то правильная система
>>на дерьмовом железе - форменное кощунство 8)
>опять сырое и холодное спутал...
>Речь о неправильном подходе к ненадежному коду драйверов, а не аппаратной платформе
>(смена которой, к слову, не меняет пробелмы ни на грамм)
Угу, метод лечения проблемы напоминает вырезание гланд через попу автогеном.Вместо того чтобы писать качественные дрова давайте отнимем у говенных дров права - тогда они дескать не смогут так гадить.Лучше они от этого, конечно, не станут, но кого это **ет?Интересно, много юзеров будут рады тому что железка как бы делает вид что работает но у нее на каждый чих виснет, падает или глючит драйвер?
>А ты за ВСЕ процессоры которые поддерживаются линуксом ответишь?А то он не
>только на IA32 работает, вот незадача то...мы как, будем плодить драйвера
>которые годятся только для конкретной системы, потому что у нее есть
>такая особенность процессора?Хороший способ угробить в перспективе любую операционку...
проблема дров для процов с MMU и не одним кольцом защиты (все современные процы) - то это будет более 99% проблемы. По-моему, неплохо было бы ;)>Да?Точно-точно?А что, есть внятный механизм на всех архитектурах куда спортирован линукс?П это
>для всех архитектур проверили?
см. абзац выше>Или какой-нить линукс на мобильниках и наладонниках можно
>и отдать в жертву прихотям Таненбаума?
например, на PXA2xx от Intel'a, которые используют в КПКшках, проц тоже имеет все те же 4 кольца защиты. И микроядро там смотрелось бы не хуже чем на i386>Если их будут писать в юзере - их будут писать олухи.И тады
>они будут падучие как обычные приложения.
общая идея верна. смотрим ниже....>Гигантским?У меня за последние пару лет крашей в драйверах было явно не
>больше чем отключений питания которые не вытянул упс который осиливает полчаса.Где
>этот гигантизм то и в чем он провяляется?У вас что, каждый
>день падает система от глючных дров?Лично я из сбоев в линуксе
>помню только краш иксов, не понимаю как от него спасет какой-то
>там драйвер - грохается вообще юзерский процесс с довольно неприятными последствиями.Кстати,
>данные при этом в основном не сохраняются :).И фигли мне толку
>с того что кто-то полечит какие-то возможные краши драйверов которых днем
>с огнем не найдешь?
при чем тут ваши бесперебойники??
Вероятность считать умеем? Вот при расчете вероятности критического сбоя в монолите и микроядре разница в несколько порядков - гигантская или нет? ;)
>А систему может сделать неюзабельным дерьмом.Как раз виндовс 95 получится :) где
>навертываются не только приложения но и драйвера :)
смотрим ниже...>Ага, будет у вас полуработающий индусский драйвер.Сорцы дать пожлобятся поэтому у вас
>получится системка с стабильностью 98 винды :).Та тоже - покажет синий
>скрин, соотв. девайс порой уходит в даун, а система дальше себе
>пашет как ни в чем не бывало, если память сильно не
>засралась.Будет то же самое примерно - подыхающие на каждый чих драйвера
>девайсов.
ламер (пардоньте, что я к вам по никнейму ;),
вы не находите разницу между упавшей системой и одним некритичным драйвером какого-нить принтера?>>тут же перезапускается,
>Ага.Грохнется какойнить драйвер файловой системы, интересно, как он при перезапуске обойдется без
>потерь данных, если его вышибло не дав доделать дисковые операции?
этот драйвер _уже_ написан. И по вашим же заверениям "в нем не может быть таких глюков".
Кроме того, работа системы на драйвере не заканчиваеться все равно.
Или вы все так же уверены, что винтом единым и ФСом одним жива любая система?>>драйвером - и продолжить работу! При этом данные всех остальных процессов
>>- остаються гарантированно неповрежденными.
>Ага.Зато при сбое железа система будет засирать память, гадить на диск, перезапускать
>драйвера, но работать, работать и работать.Забивая диск коррапчеными данными из побившейся
>памяти... лучше бы сразу упала в бсод и стопорнулась - меньше
>корапченой дряни на винт попадет.при чем тут сбой железа?
мы о сбоях в софте пока что. Или при отсутствии аргументов - смена темы для вас в порядке вещей?
>>А это настолько немало, что оседлать даже спутник Линуху будет просто вопросом
>>желания его туда поставить.
>А может, это должна быть отдельная система или ветка ядра?Я че-то не
>хотел бы под управлением китаезного десктопнго железа в космос лететь, 1
>фиг.
Так и должна. Думаю, что да, отдельной веткой ядра
(монолит пусть живет своей жизнью/веткой, к нему как к монолиту претезний мало).
Но ее нету. В природе. И она нужна.
Доступно??
>>Отлично. У тебя _есть_ (это уже состоявщийся факт если не заметил) неопределенное
>>количество _не_идеального качества драйверов _и_ ядро, возможно тоже не идеального качества.
>Отлично, но лично мне оно жить не мешает - ну не падает
>у меня каждый день ни ядро ни дрова.Может это и модно
>- воевать с ветряными мельницами, но это явно не за мой
>счет, ага?... (кто там про 50 уе на более мощный проц
>говорил выше?)
не я.
Лично я и на своем проце (если уж мы тут на лица) позволю себе пару процентов потерять ради такого дела.
>>Что ты будешь переписывать: ядро или N+1 драйверов (а не ото всех
>>и сырцы есть...)?
>>Так кто высказал маразм?
>Ну, будут дрова летать как г*вно на голову.Это вы называете стабильной системой?Я
>это называю маразмом :\почему _будут_???? Они _уже_ написаны и кое-как работают. Ну потрудись же прочитать
задачу. А цель - поднять надежность _всей_системы_ со всеми уже существующими дровами
минимальными силами.
Ну а теперь доступнее звучит задача?
>>Нам же главное - _найти_, т.е. решить проблему. А то, что она
>>решается изменением архитектуры именно ядра - так это просто повезло, что
>>фонарь светит именно туда, где лежат наши ключи,
>А они там лежат?Такое ощущение что Таненбаум вбил себе в бошку что
>проблема есть.И теперь усиленно втирает остальным что да, типа, проблема!
а, типа, нету?
Любой драйвер имеет доступ к памяти любого другого драйвера.Если ты не видишь в этом ничего плохого - можно закончить спор. Потому как это - изначальная проблема.
>>Потому как в ванильном ядре таких багов _УЖЕ_ есть. И как раз
>>с _этим_ нужно что-то делать, а не витать в облаках, уверяя
>>всех, что там чего-то не должно быть.
>Эээ... до кучи запретить и ядру работать с железом и иметь полный
>доступ ко всему?А кто тогда будет это делать?Гипервизор?А кто ему запретит
>быть бажным и сделать вместо ядра то же самое? :)
одна из основных задач ядра - предоставление инетрфейса к железу для пользовательских приложений.
Я как-то с трудом себе представляю как это можно соблюсти, запретив ядру такой доступ.Может вы чего знаете и молчите тут немеряными постами? ;)
>Хм.То-то я смотрю, сервак вон линуксный у перца стоит, аптайм всего-то какая-то
>пара лет натикала.Наверное, у него полон рот проблем с драйверами и
>ядром.Давайте его полечим для профилактики, а то работает, сцуко, и не
>падают там драйвера - непорядок однако, где же г-н Таненбаум и
>его крахи в драйверах?
на АЭС, в космосе, в океане....
Или вы считаете, что миру не нужен открытый и функциональный софт, способный предоставить надлежащую надежность?
>Угу.Давайте лечить дерьмовость дров отъемом у них прав.Интересный подход, направленный не на
>устранение проблемы а на хрен знает что.А может, лучше полечим головную
>боль гильотиной а гланды вырежем через попу автогеном?
про SELinux слышали? Судя по вашим словам - эта технология защиты - полный бред.
Но мировое сообщество так не считает, замечу...Так вот какова там основная идея??
Именно _отобрать_ у каждой задачи _ненужный_ ей доступ.Когда процесс работает и выполняет возложенные обязанности - этого достаточно. Отрезать все остальные возможности - значит гарантировать, что этот процесс (даже будучи уязвимым) ничего не сможет сделать иного, чем ему положено.
Будем спорить, что подобный уровень безопасности бред в эпоху неидеального софта?
>Угу, метод лечения проблемы напоминает вырезание гланд через попу автогеном.Вместо того чтобы
>писать качественные дрова давайте отнимем у говенных дров права - тогда
>они дескать не смогут так гадить.
Ты не можешь гарантировать, что закрытый драйвер nvidia не делает ничего плохого в какой-либо ситуации. Это как минимум.
И не позволить ему гадить - большое щастье, потому как иного драйвера с нормальным аппаратным ускорением для nvidia видух не дано, а на некоторых системах подобный уровень "доверия" такому драйверу может быть попросту недопустим.Предложи иной выход?
>Лучше они от этого, конечно, не
>станут, но кого это **ет?
да, это уже действительно не волнует пользователей других сервисов и драйверов.
Потому как проблема в этом nvidia модуле их уже не касается.>Интересно, много юзеров будут рады тому что
>железка как бы делает вид что работает но у нее на
>каждый чих виснет, падает или глючит драйвер?
ну, меняй видуху, раз с ней поставляюццо тока кривые и падучие дрова :)
При чем тут драйвер того же звука, который замечательно работает?
>проблема дров для процов с MMU и не одним кольцом защиты (все
>современные процы) - то это будет более 99% проблемы. По-моему, неплохо
>было бы ;)
Про uCLinux и прочая почему-то забывают :).Не, я не спорю, в разделении прав драйверов что-то и есть но деление дров более тонко чем на user и kernel портабельность попортит, есть опасение что драйвера могут стать платформозависимыми больше чем следует.Хотя можно в принципе сдела HAL которому все можно и дрова которым можно HAL просить сделать нужное действие.HAL мог бы в принципе демонстрировать драйверам кукиш на доступ к ресурсам которые им не нужны.Это было бы более-менее портабельно (по сути доразвитие идеи NT) но, блин, м тормознутее тоже.И это не будет линукс.И обладатели этой системы не смогут говорить как она прекрасно работает на слабом железе как это делают линуксоиды.>>для всех архитектур проверили?
>см. абзац выше
Буду гадом, припомню например uClinux :)>например, на PXA2xx от Intel'a, которые используют в КПКшках, проц тоже имеет
>все те же 4 кольца защиты. И микроядро там смотрелось бы
>не хуже чем на i386
А еще в КПК используют Ti OMAP, Samsung S3C, и еще некоторые выводки ARM.Хотя у ARM и правда более 2 режимов есть, трабла состоит в том что если разделение юзера и системы хоть как-то одинаково, промежуточные уровни привилегий в процессорах не настолько же одинаковы :)>общая идея верна. смотрим ниже....
Смотрим не ниже а на практику.Дрова для 9x летали только в путь, ибо часто это было не фатально(точнее, это называется русская рулетка).Дрова в NT не летают.Потому что падает сразу и насмерть, соблазна забить на краш в драйвере просто нет.>>с того что кто-то полечит какие-то возможные краши драйверов которых днем
>>с огнем не найдешь?
>при чем тут ваши бесперебойники??
При том что меня как юзера слабо волнует по какой именно причине навернется система.>Вероятность считать умеем? Вот при расчете вероятности критического сбоя в монолите и
>микроядре разница в несколько порядков - гигантская или нет? ;)
Мне честно говоря пофиг - раз в 2 или в 20 лет упадет драйвер :).Отказы железа скорее выйдут на первый план.А так - ну не падают у меня драйвера.Ни раз в день, ни раз в месяц, ни за вообще разумный срок.А мне втирают: "Чувак, ты дурак!Мы знаем лучше.Поэтому надо эту проблему лечить!".Имхо если рассматривать ЛИНУКС и ЕГО ПРОБЛЕМЫ, лечить надо ИКСЫ.Чтобы были железобетонно стабильными.Хрена толку с лечения проблемы которая меня не напрягает если я знаю 100% метод уронить в своей системе иксы и это приведет к вылету из графических приложений и потере несохраненных ими данных?На серверах это пох.На десктопе - совсем не пох!Если что-то лечить именно в Линукс - имхо, иксы.А не какие-то абстрактные проблемы которые может быть когда-то кому-то и позволят не перезагружать систему с его кривыми дровами.>вы не находите разницу между упавшей системой и одним некритичным драйвером какого-нить
>принтера?
Я нахожу что меня в той 98 задолбало ребутиться чтобы когда мне надо печатать принтер все-таки соизволил это делать после вылезания bsod-а.А в нтях он просто печатает.Так вот, мне надо драйвер который просто печатает, просто играет звук, просто выводит картинку и просто работает.А краши и запасные парашюты на случай если д*рьмо случится - пожалста оставьте себе.В лучшем случае при отказе драйвера принтера будет засраный лист бумаги, в хучшем - залипший в непонятном состоянии девайс который драйвер не сможет переинициализировать из этого непонятного ему состояния.>Или вы все так же уверены, что винтом единым и ФСом одним
>жива любая система?
Нет конечно :) наворачивание иксов способно порадовать линуксоида невзирая на то что упал всего-то какой-то "юзерский" процесс а вовсе и не драйвер.Данные при этом имеют подлое свойство не сохраняться в этой ситуации.Если вы не сохранили файл, шанса это сделать при падении иксов никто не даст :D>>памяти... лучше бы сразу упала в бсод и стопорнулась - меньше
>>корапченой дряни на винт попадет.
>при чем тут сбой железа?
При том что они тоже бывают.И чем дольше система будет трепыхаться пытаясь выжить, тем больше она успеет насрать подпорченными данными на диск.А софт и железо живут рядом.Странно рассматривать одно в отрыве от другого.>мы о сбоях в софте пока что. Или при отсутствии аргументов -
>смена темы для вас в порядке вещей?
Да нет, просто немедленноый останов системы далеко не всегда зло.Часто он минимизирует потери данных при проблемах железа.Описанная вами система рискует мужественно перезапускать дрова до посинения игнорируя факт что они оперируют с недостоверными данными и корраптят юзерские данные.Благо ядро будет мелкое, вероятность что сбой памяти попадет именно на него довольно невелика.Одно дело если вам в морду вывалится синий скрин (это вы точно не пропустите) и другое если система перезапустит драйвер (а на это забьете).P.S. не спорю, если поступать как Таненбаум и заявлять что на сферическом компьютере в вакууме его система идеальна - ну да... с этой точки зрения все отлично, а всякие memtest86, md5sum и прочие fsck - совершенно бесполезные утилиты написанные маразматиками.Ведь идеальные системы обладают ресурсами как роллс-ройс ("мощность мотора: достаточная"), не глючат, сеть у них не падает и питание внезапно не отключается.
>>А может, это должна быть отдельная система или ветка ядра?Я че-то не
>>хотел бы под управлением китаезного десктопнго железа в космос лететь, 1
>>фиг.
>Так и должна. Думаю, что да, отдельной веткой ядра
Судя по объему желаемых отличий вам нужна совсем другая система которую с существующей бы роднили ... 5 букв названия?!>(монолит пусть живет своей жизнью/веткой, к нему как к монолиту претезний мало).
Я про то и говорю - на кой черт его лечить от того чем он особо и не страдает?>Но ее нету. В природе. И она нужна.
>Доступно??
Доступно.А что в этой системе будет от линукса чтобы ее так назвать?Пять букв названия, потому что "Linux звучит круто"?Ведь линукс это ядро а у вас предъявы именно к ядру и его компонентам.... :)>>счет, ага?... (кто там про 50 уе на более мощный проц
>>говорил выше?)
>не я.
Не вы.Другой оратор :)>Лично я и на своем проце (если уж мы тут на лица)
>позволю себе пару процентов потерять ради такого дела.
Есть подозрения что парой не обойдется.Особенно при интенсивной работе с графикой, звуком, сетью, ... (а нафиг еще система нужна?Для офиса?Офисные крысы ни за что не заплатят лишние 50 баксов за неизвестно что).И еще система рискует стать менее портабельной.И вообще не будет линуксом, строго говоря.Линукс это то что есть сейчас.Если выкинуть оттуда почти все и переписать это так как оно могло бы быть если б его дизайнили в 2007 - это будет что угодно, но только не Линукс.>>>Что ты будешь переписывать: ядро или N+1 драйверов (а не ото всех
>>>и сырцы есть...)?
>>>Так кто высказал маразм?
>>Ну, будут дрова летать как г*вно на голову.Это вы называете стабильной системой?Я
>>это называю маразмом :\
>почему _будут_????
Потому что отношение к написанию юзер-мод дров будет иное.Этим займутся индусы, сроки релиза смогут поставить выше по ценности чем стабильность и т.п. (а чо, краш теперь не фатально же - ну и рвать попу отлавливая его не требуется стал быть).Ну и получится Win98 (ну, минус русская рулетка - будет выживать не в 50% случаев а в 90%, хаха:D).>Они _уже_ написаны и кое-как работают.
И что интересно, даже не падают.То есть, у кернель програмеров может и падают конечно в ходе отладки, но кого это волнует кроме них самих?>задачу. А цель - поднять надежность _всей_системы_ со всеми уже существующими дровами
А существующие написаны для работы в кернеле... это не смущает?>Ну а теперь доступнее звучит задача?
Не очень.Вы думаете что вы сможете переделать линуксное ядро, убрать все особенности его архитектуры которые вам не нравятся, сделать правильнее (по сути сделав новое ядро которое что угодно но только не известный всем линукс) и туда прицепить старые драйвера?Хм.Ну попробуйте.Хотя как Linux 3.x или даже 4.x :D оно может и ничего было бы - типа только наружу интерфейсы старые а внутри все новое )))>Любой драйвер имеет доступ к памяти любого другого драйвера.
Пусть себе имеет.Ядро тоже имеет доступ ко всему.И что?Хотя по логике вещей надо бы развить параною и начать и части ядра изолировать - так типа еще надежнее :).Или в юзера его выкинуть - пусть себе гадит, все VMы не завалит, только свой :)>Если ты не видишь в этом ничего плохого - можно закончить спор.
А можно мне сказать, что я хорошего с юзерской точки зрения должен увидеть в лишних тормозах ради лечения проблемы которая никого особо не донимает, но, в теории оказывается все-таки может? :)>Потому как это - изначальная проблема.
Кстати это... вроде ж современные x86 соблюдают запрет на запись в область памяти даже когда в режиме ядра?Или я глючу?Можно было бы защитить код драйвера от изменений и т.п. - сомнительно что заглючивший драйвер полезет именно снимать защиту от записи с страниц чужого драйвера.Он просто помрет при попытке сунуться туда куда не надо и усе.Только вот это тоже не больно то портабельно, зато драйвера переделывать (почти?) не потребуется.Или это я так красиво глючу от недосыпу?>одна из основных задач ядра - предоставление инетрфейса к железу для пользовательских
>приложений.
>Я как-то с трудом себе представляю как это можно соблюсти, запретив ядру
>такой доступ.
Я думаю что вы можете себе это представить.Посмотрите на VMWare, если я не глючу он делает именно так.С VMTools он, конечно, не составит конкуренцию железячной машине но уже и не такой тормоз как чисто софтварные эмуляторы :).Всякие гипервизоры и прочая в принципе делают эти фокусы возможными.И, кстати, могут ядро ограничить в правах доступа к железу.Вроде, соня в PS3 так и сделала - и линукс запустить можно и сунуться куда низзя и правда низзя, несмотря на то что типа кернель и все такое :)>Может вы чего знаете и молчите тут немеряными постами? ;)
Да настроят вам мегакорпорации чудо-заборчиков из гипервизоров, чтоб вы не лазили из вашего кернеля "куда не надо", не ссыте, к этому все идет... любую хорошую идею можно обернуть во зло.TPM вон тоже может систему круто защищать от хакеров вас.А может столь же круто оттяпывать ваши права в пользу мегакорпораций, защищая их от вас.>на АЭС, в космосе, в океане....
>Или вы считаете, что миру не нужен открытый и функциональный софт, способный
>предоставить надлежащую надежность?
Почему?Считаю.Но только вот не факт что этим должен именно линукс заниматься.Нужна другая арзитектура в которой от линукса ничерта не останется.И wtf это тогда называть линуксом?Потому что типа модно?:)>>боль гильотиной а гланды вырежем через попу автогеном?
>про SELinux слышали? Судя по вашим словам - эта технология защиты -
>полный бред.
Это не бред, я особо с ним не разбирался но в меру моего понимания он реализует слегка через зад то что следовало бы внести в стандарт - более современную систему прав через ACLs а замену старыз позиксных rwx.Только вот SELinux в меру моего тупенького понимания не прыгает по 10 раз между системой и юзеров ради разруливания запроса, в отличие от предлагаемого тут.>Так вот какова там основная идея??
>Именно _отобрать_ у каждой задачи _ненужный_ ей доступ.
Драйвера - не задачи.Они часть ядра.Хотя у ядра тоже можно отобрать "ненужный ему доступ" - см выше :)>остальные возможности - значит гарантировать, что этот процесс (даже будучи уязвимым)
>ничего не сможет сделать иного, чем ему положено.
Еще раз, драйвер в принципе не процесс.Он что-то типа расширения(плагина, модуля) ядра.Удаленное эксплойтирование драйвера будет порождать множество проблем, так же как удаленное эксплойтирование дыры в ядре например.Скажем как вам драйверок который возвращает приложениям не то что они попросили?Например драйвер сети может смотреть и если видит скачку файла по http - отдавать троянца.Рано или поздно юзер не ожидающий такой подставы попадется :)>Будем спорить, что подобный уровень безопасности бред в эпоху неидеального софта?
Уровней виртуализации и защиты можно городить бесконечно, пожрав под это бесконечно ресурсов.Главное понять когда уже достаточно для нормальной работы :).В линуксе на мою имху такой проблемы остро не стоит - стало быть тормозить на 15% систему хз ради чего лично я не хочу.>Ты не можешь гарантировать, что закрытый драйвер nvidia не делает ничего плохого
>в какой-либо ситуации. Это как минимум.
Ну а вы не сможете гарантировать что он, даже не нагадив другим дровам не поставит видяху враскоряку до скажем хардварного ресета.Итого если видяха нужна - маршрут 1 фиг такой же будет - типовой юзер будет ресет жать.А если вам видяха не нужна (сервер) - так нефиг ставить ни видяху от нвидии, ни тем более ее драйвер со всеми наворотами :).Это даже до микрософта доперло, 2003 ставит скромный дефолтный VGA драйвер который прост как валенок, достаточен для администрежа сервера и я лично не знаю что с ним надо сделать чтобы он грохнулся.>И не позволить ему гадить - большое щастье, потому как иного драйвера
>с нормальным аппаратным ускорением для nvidia видух не дано, а на
>некоторых системах подобный уровень "доверия" такому драйверу может быть попросту недопустим.
Вообще, ядро которое само себе не доверяет - это шыза уже.Вы пытаетесь решать человеческие проблемы техническими мерами.Это не работает :).Лучше бороться за открытые драйвера котрым можно доверять а не за то чтобы проприетарный бинарь видите ли был псевдоограничен в правах(это еще кто кого ограничит, большой вопрос: там поддержка DRM вроде есть, так что это оно вас сможет в правах ограничивать чего доброго, гы...).К тому же микрософт уже пробовал выносить драйвер графики в юзера.Ну, NT 3.51 оказалась никому нафиг не нужна.Потому что тормозила графика(2D, замечу, про намного более интенсивный 3D я помолчу).Притормозить все эти 3D навороты выкинув их в юзера - круче не придумаешь, ага :)>Предложи иной выход?
Не чинить то что не сломано.Чинить то где есть проблемы.Не слышал чтобы кто-то ныл как у них крашится драйвер.Зато слышал плевание на краши иксов и несколько раз огребал их.Может, это лечить было бы приоритетнее? :)>>Лучше они от этого, конечно, не
>>станут, но кого это **ет?
>да, это уже действительно не волнует пользователей других сервисов и драйверов.
>Потому как проблема в этом nvidia модуле их уже не касается.
Хм.Интересная все-таки мысль - вместо того чтобы требовать качественных драйверов от вендора народ согласен жрать дерьмовые.Я наверное чего-то не понимаю в этой жизни или просто костылестроительные мероприятия не люблю.>ну, меняй видуху, раз с ней поставляюццо тока кривые и падучие дрова :)
Вот и весь ответ, вы сами все сказали.Если дрова дерьмовые - каких им там костылей и подпорочек не подставляй, а лучше то они от этого не станут...
1. Вы глобально путаете две вещи:
а) сбой в драйвере и
б) реакция ядра на это событиеПример:
"Так вот, мне надо драйвер который просто печатает,
просто играет звук, просто выводит картинку и просто работает.А краши и
запасные парашюты на случай если д*рьмо случится - пожалста оставьте себе."Всем нужны _просто_ драйвера. Но вот кое-кому не хочеться терять всю систему если один драйвер стал раком.
Заметьте, плз, вот здесь речь _НЕ_ о качестве драйвера, т.е. НЕ о сбое в нем. И даже не о процессе создания драйвера: кто в нем на опасность какого креша забил - уже неважно. Есть готовый драйвер и в нем произошел сбой.Речь о пункте "б" - реакия системы.
И тут выбор прост: отдаццо на волю случая (драйвера) или что-то решать.
Вы ясно дали понять, что готовы отдаться на волю случая, т.е. лучше чтоб все упало разом.Но может выскажетесь по второму пункту? Что если воля случая не устраивает - и нужно что-то решать? Идеи кроме микроядра есть?
2. Разница между драйвером/программой/задачей/процессом.
В линуксе она отсутсвует :) Это все почти синонимы.
Просто характеризуют какой-либо набор инструкция процессора, направленных на решение како-либо задачи.
Ну а драйвера - они просто (в монолитном ядре, текущем Линухе) делят адрессное пространство с ядром. Т.е. они все и ядро - в одном адрессном пространстве.
А пользовательские прграммы - железно в другом. Хотя и несколько пользовательских процессов так же могут жыть в общем (для них) адрессном пространстве.3. У вас явно проблемы с иксами :)
Не знаю откуда и почему - не тут это обсуждать.
Просто хотел дать совет (а кто его послушает?? ;)
Если вы теряете такие уж важные данные при падении иксов - ну запустите какой-нить виртуальный X сервер (типа vnc, например), и подключайтесь к нему уже из обычных иксов.
Если они упадут - ну придеццо просто переподключиться к vnc серверу :) Ниче не будет потеряно.
Неправда ли, разнесение функционала в самостоятельные процессы - несколько сглаживает (если не решает) данную проблему? Ну так почему же вы тогда так против подобного решения для драйверов?>наворачивание иксов способно порадовать линуксоида невзирая на то что
>упал всего-то какой-то "юзерский" процесс а вовсе и не драйвер.
Вот после схемы с vnc - так оно и будет. У вас упадет просто "консоль" к вашим программам,
который легко перезапускаеться (и при новая копия ничего не портит по пути, как вы утверждали тут про перезапуск драйверов ФС или винта).>Данные при
>этом имеют подлое свойство не сохраняться в этой ситуации.Если вы не
>сохранили файл, шанса это сделать при падении иксов никто не даст
ну так веть вот он. Шанс ваш ;)4. Очевидно, вы не совсем понимаете о чем спор.
>>(монолит пусть живет своей жизнью/веткой, к нему как к монолиту претезний мало).
>Я про то и говорю - на кой черт его лечить от того чем он особо и не страдает?
монолит действительно я не собираюсь лечить. Как монолит - текущий линух весьма неплох.Я говорю о совершенно другом ядре. Не монолите. И допускаю, что подобные изменения в Линухе заслуживали бы на отдельную major версию: 3.
И у вас какие-то комплексы по поводу названия подобного ядра...
Да, это мог бы быть Линух. Если переделывать его - то это именно и будет Линуксом.
Просто у него будут достаточно большие изменения в структуре, что и молго бы быть отмечено отдельной веткой разработки.А про "линукс это круто" - да, круто. Пока в нем больше всего открытый драйверов, чем в любом другом ядре на Земле - да, это круто.
Его можно изменять и дорабатывать безо всяких лицензионных проблем. Это круто.Переделать именно Линукс БЕЗ потери _всей_ его функциональности (допустима некоторая потеря производетельности, но _не_ функциональности) - самый простой и быстрый путь к постоению микроядра уровня Линуха (меньше - просто не нужно).
Почему тогда какие-то предъявы по этому поводу? Или у вас с крутостью Линукса связаны какие-то другие мысли??
5. Попытки решить проблему есть и в текущем монолите.
Внутриядреное ограничение доступа имееться и может быть включено опцией при сборке.
Это запрет на запись в области кода.
Да, действительно, падающий драйвер вряд-ли будет снимать защиту (хотя он это может)
с областей, где ему срочно нужно попортить память :)
Но это не решает проблему. Потому как данные то всех модулей (драйверов) остаються доступными всем на RW. И не в них ли собираеться отспамиться перед смертью очередной кривой ядерный процесс??6. SELinux. Судя по вашему посту и "замену ACLями rwx" - вы не вкурсе для чего он нужен.
Это нестрашно - прочитаете если будет нужно.
Но вот его суть именно в том, что каждый процесс обладает только теми правами (на ФС это не ограничиваеться), которые ему нужны для работы. Шаг влево/право ему не даст сделать ядро.
Так вот про "не прыгает по 10 раз между системой и юзеров ради разруливания запроса".
Еще и как прыгает. Каждый (!!) системный вызов наделяеться дополнительными проверками по таблице разрешений. Может конечная нагрузка таких проверок и меньше, чем переключения контекста в микроядре, но эти две технологии и разные проблемы то решают...Так что: добавление любой защиты - это почти всегда понижение производительности.
7. Драйвер, в общем случае, может привести устройство, которым он управляет в невменяемое состояние так, что и новая копия драйвера может не разрулить ситуацию. Иной раз даже после ресета...
Так что, не нам страдать от того что драйвер видухи может ее завесить и даже микроядро ничего не сможет с этим сделать.
У микроядра НЕ эта задача. Тут опять идет путаница понятий из первого пункта.
Микроядро, если драйвер упал, - пытаеться решить что делать софту дальше.
Если новоперезапущенный драйвер видухи не справляеться с ней - то это точно не проблема микроядра. Оно свое дело сделало. Остальное - проблема производителя видухи и драйвера.И если вендор не правит свои дрова, зная о проблемах - ессьно, нужно менять вендора.
Но это не касаеться структуры ядра! Это вопросы иного рода совершенно.Самое интересное, что это все не меняеться и для монолитного ядра.
Там все так же чинить драйвер и железо - производителю.
Так может не будем путать теплое с мягким: поведение ядра при падении драйвера и починит ли производитель этот драйвер когда-нибудь?
8. Ну и конечно же стоит бороться за открытость драйверов.
Но, это не тема текущего разговора. Это политика. А мы - про технику пока что.
>1. Вы глобально путаете две вещи:
На самом деле не путаю.Просто в моем понимании драйвера это место где сбои должны быть исключены настолько же насколько они исключены в ядре.Т.е. их качество кода должно быть не ниже.Если это не так - я резонно скажу что это дерьмовые драйвера и буду прав.А раз так - есть у одних парней забавная поговорка, отражающая суть дела."А кто будет проверять проверяющего?".Современный линуксный кернель это довольно немаленькая конструкция.Кто проверит что она тоже rock solid?И кто в случае чего примет меры?Гипервизор?А его кто проверит?>Всем нужны _просто_ драйвера. Но вот кое-кому не хочеться терять всю систему
>если один драйвер стал раком.
А мне не хочется наблюдать как драйвера становятся раком.Очень приятно если я захочу посмотреть киноху а мне скажут "бсст!" - "прости чувак, но кина не будет - тута у нас драйвер упал и оставил видяху\звуковуху в неопределенном состоянии из которого хз как их выбить".Вот хочется чтобы этому коду можно было доверять не меньше чем ядру.Иначе будет вакханалия сплошная.
>готовый драйвер и в нем произошел сбой.
Рассуждения на уровне "есть метеорит и он даже прилетел вам на голову.Ваши действия?Хренли вы не в каске?И почему вы все еще не закопались в бункер?!".Т.е. рассматривать можно и в принципе ничему не противоречит.Но метеориты не падают на голову всем подряд и часто, поэтому несмотря на маленькую вероятность получить метеорит на голову, никто не сидит в бункерах в ожидании попадания в их голову мелкого космического булыжничка.>Речь о пункте "б" - реакия системы.
>И тут выбор прост: отдаццо на волю случая (драйвера) или что-то решать.
А ядро не владеет ситуацией в каком состоянии железо.Что-то решить не зная в каком состоянии заклинило железку довольно странно.Возможность это сделать зависит от того что за железка.Ну да, без звуковухи в принципе работу продолжить можно, хотя особого кайфа юзеру сий факт не доставит.>Вы ясно дали понять, что готовы отдаться на волю случая, т.е. лучше
>чтоб все упало разом.
Разумеется - при этом будет минимизирован шанс что-то испортить в файловой системе и прочем.В частности и при неидеальности железа - система сразу грохнется что при сколь-нибудь заметной повторяемости ситуации спровоцирует юзера на поиск проблемы.А система рестартящая драйвера рассчитывает на то что драйвера ненадежны и будет существенно меньше мозолить глаза этим фактом.Итого при скажем глючащем железе разрушенная оперативка будет успешно писаться на диск.Ну да, будут порой драйвера рестартить в случае чего но система то не зашатдаунится.Ну как минимум пока не сбойнет что-то в самом ядре (а драйверов как было уже сказано больше ядра...)>Но может выскажетесь по второму пункту? Что если воля случая не устраивает
>- и нужно что-то решать? Идеи кроме микроядра есть?
Поддержка на уровне железа изоляции вообще всех частей системы друг от друга, допустим, по потокам.Но это увы надо и новый хард и новый софт.Можно например на Cell глянуть для некоторого понимания о чем я примерно говорю.>2. Разница между драйвером/программой/задачей/процессом.
>В линуксе она отсутсвует :) Это все почти синонимы.
И что из того?От этого драйвера не в кольце 0 или юзерские программы попали в него?
>А пользовательские прграммы - железно в другом. Хотя и несколько пользовательских
>процессов так же могут жыть в общем (для них) адрессном пространстве.
Угу, все замечательно, кроме того что переключение между кольцами в принципе не очень шустрая операция обычно, to the best of my knowledge.>3. У вас явно проблемы с иксами :)
Да не только у меня одного.Народных плачей что можно уронить иксы - я так смотрю в интернете есть.И при том кажись побольше чем мата на падучие драйвера.Я просто нашел 1 последовательность действий которая роняет иксы лично у меня.Редкая.Случайно выполнить все эти действия трудно.Однако последствия сравнимы разве что с рестартом - не дохнут только консольные демоны всякие, что наврядли сильно утешит среднестатистического юзера.>Не знаю откуда и почему - не тут это обсуждать.
Ага, конечно, у нас тут высокие концепции дуром прут а про проблемы юзеров все забыли.А фигли, ну правда, когда богов волновали простые смертные и их проблемы?Главное концепция :).А то что 80% системы вылетает в трубу без сохранения данныых при падеже юзерского процесса х сервера - да подумаешь, фигня какая :)
>запустите какой-нить виртуальный X сервер (типа vnc, например), и подключайтесь к
>нему уже из обычных иксов.
А где гарантии что те иксы не упадут, унеся за собой "важные процессы"?Да и вообще изврат получается.>Если они упадут - ну придеццо просто переподключиться к vnc серверу :)
При этом почему-то допускается что он упасть не может.А кто это гарантирует собственно?>Ниче не будет потеряно.
>Неправда ли, разнесение функционала в самостоятельные процессы - несколько сглаживает
>(если не решает) данную проблему? Ну так почему же вы тогда так против
>подобного решения для драйверов?
Потому что это сделает систему тормознее и кроме того, драйверам по роду деятельности нужны привилегии которые нафиг не впились юзерским процессам.Отнять их по простому трудновато.Нужны какие-то левые костыли которые все притормозят.Если бы все современное железо предусматривало бы такое деление без performance penalty - было бы замечательно.Потому что ничего не стоит а система типа надежнее.Ну... нечто типа ACL-ов для каждого потока на железном уровне, раздавать их могло бы ядро, а потоки вообще при этом можно не делить на юзера и систему в принципе - ACL поделил бы их намного точнее чем только программа, или только драйвер.Скажем чему противоречит что программа которой надо нестандартный прямой доступ в железо не реализованный встроенными драйверами сама попросит его?И или пойдет нафиг или поработает с железом - в зависимости от ACL-ов.Становясь на время сама себе драйвером, если угодно.>Вот после схемы с vnc - так оно и будет. У вас
>упадет просто "консоль" к вашим программам,
Замечательно, а если упадет то на чем эта консоль "хостится" то мне стал быть останется оболочка от сосиски?)А программы то мои того, тю-тю.Спасибо, я с вмварями всякими и разными видами ремотных десктопов дело имел - представляю себе как это и что поолучится.По сути вы спихнете проблемы надежности с 1 машина на другую.>ну так веть вот он. Шанс ваш ;)
"В винде есть такая утилитка, ahui.exe" - в смысле, если упадет "хостящий" икс - ну тады ой.У меня останется консолька.Работающая.Но без моих программ.Которые навернутся, очевидно, без доступа к этому иксу, ага?Ну или куда они графику денут?И чо мне с ней делать?Программы то от ее наличия у меня не вернутся?!Ну или почему на той стороне иксы будут надежнее моих?Аргументы их большей надежность можно в студию?Я так понимаю что мы сбагрили проблему с одного места в другое.Почему она там не возникнет - не понятно.>4. Очевидно, вы не совсем понимаете о чем спор.
Не спорю, это не исключено.Я не сильно давно пользую *никсы.>Я говорю о совершенно другом ядре. Не монолите. И допускаю, что подобные
>изменения в Линухе заслуживали бы на отдельную major версию: 3.
Дык.Спасибо если не отдельного названия операционки.А то ходют тут всякие Таненбаумы с миниксами и мутят воду как у них все хорошо а у других плохо :).Правда, Таненбаум - академик, ему на практику в принципе глубоко фиолетово.Он придумал такую систему.Он считает что все должны ее сделать так.Можете посмотреть выше - я только что сбредил ибо спать хочу и придумал вообще иначе - а нафиг ядра, в **пу драйвера, в п*** процессы.Если б поддержало железо - зафигарить fine-grained разделение прав у потоков и раздать кому надо столько сколько надо, а при вылезании за дозволенный минимум необходимого зарвавшийся поток просто мочить.С разными последствиями в зависимости от того что замочено... :).Ядро при этом сведется к диспетчеру задач и манагеру разрешений.В принципе даже не обязательно одним потоком наверное - ну, несколько привилегированных потоков, которые мы типа посчитаем ядром :)>И у вас какие-то комплексы по поводу названия подобного ядра...
Есть опасения что тормозить будет.Почему-то никто еще не сделал БЫСТРУЮ и РАЗВИТУЮ микроядерную систему.Все хотят чтобы это сделали другие :) например, Линус :).И еще есть подозрения что многих кернел девелоперов не пропрет писать юзер-мод процессы, посему это ставшее довольно беспонтовым занятие будет оставлено на откуп индусам всяким.А куда деть кучку квалифицированных кернель программеров не понятно.Для микроядра их столько нафиг не сдалось.Писать юзермод код они имхо не станут - специфика не та.Ну, лично я бы во всяком случае на их месте не стал, пусть лучше такие драйвера индусы и Таненбаум пишут, а меня такое изучать как бы эт сказать, заломало :).Если серьезно то я бы вероятно хотел со временем освоить кернель мод програминг в линуксе(но пока я слишком мало знаю эту систему).А вот програмить драйвера в юзере я бы точно не хотел - это пущай индусы и Таненбаум свои высокие концепции продвигают, а я в таком случае найду чегонить другое на попрограммить.Уровнем пониже :)>Да, это мог бы быть Линух. Если переделывать его - то это
>именно и будет Линуксом.
А что там будет от линукса кроме названия?Ядро будет совсем другое, драйвера другие.И wtf оно именно линукс?А не minix например?Чтобы примазаться к раскрученному Линусом бренду? oO>Просто у него будут достаточно большие изменения в структуре, что и молго
>бы быть отмечено отдельной веткой разработки.
Судя по всему это получится совсем новое ядро у которого с старым общее ... название и высокоуровневое апи?>А про "линукс это круто" - да, круто. Пока в нем больше
>всего открытый драйверов, чем в любом другом ядре на Земле -
>да, это круто.
И заметьте, они не падают каждые 5 минут.И вообще система в целом устраивает народ такой какая есть.Примерно как НТя мало поменялась с 4-й до 6-й версии внутрях.А нафига ломать то что работает и довольно неплохо?>Его можно изменять и дорабатывать безо всяких лицензионных проблем. Это круто.
А зачем при этом пытаться примазываться к славе Линуса?Линукс стал известен таким какой он есть сейчас.Пытаться сделать из него "миникс но только популярный" извините не очень хорошо пахнет.А почему бы Таненбауму или кто там еще так фанатеет не сделать СВОЮ систему?У нее ведь 1 фиг с Линуксом общего юудет только ... название.Что не особо честно.>Переделать именно Линукс БЕЗ потери _всей_ его функциональности (допустима некоторая
>потеря производетельности,
Не думаю что юзеры положительно оценят допустимость в этом случае.Хотелось бы чтобы базовая часть системы была так быстра как возможно.А насколько притормозят аппликухи... ну они и созданы чтобы жрать ресурсы - не системное это дело, даденые ресурсы хавать :)> _не_ функциональности) - самый простой и быстрый путь к постоению
>микроядра уровня Линуха (меньше - просто не нужно).
Так и хочется сказать - к построению популярного миникса с другим названием руками линуксоидов за их счет :)>Это запрет на запись в области кода.
Ну дык, это логично.В принципе это и для приложений было бы не вредно(только тогда самомодифицирующиеся приложения типа сжатых UPX-ом программ пролетают).Вроде SELinux даже такое умеет...>Да, действительно, падающий драйвер вряд-ли будет снимать защиту (хотя он это может)
Ну, может.Но врядли осилит до того как упадет.>остаються доступными всем на RW. И не в них ли собираеться
>отспамиться перед смертью очередной кривой ядерный процесс??
По хорошему должно быть разделение и в ядре кому куда можно писать.На оснвании ID потока и соотв. ACLs или типа того :) см. бред про ACLs.Увы, я так понимаю что сие не поддерживается железом а потому не судьба.
>6. SELinux. Судя по вашему посту и "замену ACLями rwx" - вы
>не вкурсе для чего он нужен.
В курсе но какого хрена он не включен по дефолту, и на кой черт тогда не выкинуты RWX?Получается довольно черезпопная система которая неудобна для восприятия.>работы. Шаг влево/право ему не даст сделать ядро.
А по хорошему не должно давать железо :) эх, вредно читать про Cell под утро :).После чтения про изолированный режим и прочая в голову лезет совсем необычная байда.>Еще и как прыгает. Каждый (!!) системный вызов наделяеться дополнительными проверками по
>таблице разрешений.
Эээ... а что, для этого ядро прыгает между кольцами?Сомневаюсь что-то.>Так что: добавление любой защиты - это почти всегда понижение производительности.
Угу.И вопрос в том когда существующих решений уже достаточно а для особо-параноидальных есть специфичные решения типа qnx-ов всяких.>У микроядра НЕ эта задача. Тут опять идет путаница понятий из первого
>пункта.
>Микроядро, если драйвер упал, - пытаеться решить что делать софту дальше.
...если возможности того что работает позволят это сделать :)>Если новоперезапущенный драйвер видухи не справляеться с ней - то это точно
>не проблема микроядра. Оно свое дело сделало. Остальное - проблема производителя
>видухи и драйвера.
Т.е. глючный драйвер 1 фиг сможет прилично поднасрать.Ну и нахрен этот огород нужен?>Так может не будем путать теплое с мягким: поведение ядра при падении
>драйвера и починит ли производитель этот драйвер когда-нибудь?
А одно напрямую связано с другим.Чем серьезнее последствия бага, тем быстрее починят этот баг и тем больше шансы что это вообще произойдет.Это увы, особенно актуально для нвидий и ати всяких как и прочих корпораций - я так понимаю вы их атакуете намеками на жирные проприетарные бинари.Если баг вычищает хард в ноль - его починят завтра же.Если баг раз в час вызывает мерцание пары пикселей скрина не там где надо, на это положат болт.>8. Ну и конечно же стоит бороться за открытость драйверов.
>Но, это не тема текущего разговора. Это политика. А мы - про
>технику пока что.
Одно от другого не отделить.Потому что это не сферический конь в вакууме как у Таненбаума.Это реальная система в реальном мире для людей которые ее реально используют, а не просто смотрят на систему как на экспонат как это в случае Таненбаума происходит.Это как жить в 3-мерном мире но рассматривать только 1 измерение и потому верить что мир одномерный :).Система для реального мира должна отвечать требованиям разработчиков и пользователей, даже если это вносит некоторую неидальность в систему.Иначе она будет никому нафиг не нужна.Примерно как таненбаумовский миникс - при такой оторванности от реального мира совершенно все-равно насколько он там круто задуман внутри, будет игрушкой для кучки студентов и академиков:)
>>Всем нужны _просто_ драйвера. Но вот кое-кому не хочеться терять всю систему
>>если один драйвер стал раком.
>А мне не хочется наблюдать как драйвера становятся раком.Очень приятно если я
>захочу посмотреть киноху а мне скажут "бсст!" - "прости чувак, но
>кина не будет - тута у нас драйвер упал и оставил
>видяху\звуковуху в неопределенном состоянии из которого хз как их выбить".Вот хочется
>чтобы этому коду можно было доверять не меньше чем ядру.Иначе будет
>вакханалия сплошная.
если ты мечтаешь о том, что все дрова будут открыты (и как следствие - более надежны),
то расстроить тебя проще простого: та же видуха уже имеет ненадежный драйвер,
т.к. закрытый. Дальше будет только больше. Линуху рано ли поздно предстоит заменить венду на компах простых юзерей - дрова будут писаццо под что угодно и кем угодно. Открытые и закрытые. Ситуация с дровами будет та же, что и в оффтопе сейчас, пусть с чуть большим процентом открытых вещей. Так что со старым подходом - вакханалия обеспечена: по несколько закрытых дров у среднего юзера в ядре - будет нормой.>>готовый драйвер и в нем произошел сбой.
>Рассуждения на уровне "есть метеорит и он даже прилетел вам на голову.Ваши
>действия?Хренли вы не в каске?И почему вы все еще не закопались
>в бункер?!".Т.е. рассматривать можно и в принципе ничему не противоречит.Но метеориты
>не падают на голову всем подряд и часто, поэтому несмотря на
>маленькую вероятность получить метеорит на голову, никто не сидит в бункерах
>в ожидании попадания в их голову мелкого космического булыжничка.
ну когда ты уже перестанешь путать теплое и трансформаторное?
Вероятность падения метеорита на голову жителю Земли много менее вероятна, нежели сбой в одном из сотен миллионов(??) компьютеров на планете из-за кривого китайского драйвера.
>>Речь о пункте "б" - реакия системы.
>>И тут выбор прост: отдаццо на волю случая (драйвера) или что-то решать.
>А ядро не владеет ситуацией в каком состоянии железо.Что-то решить не зная
>в каком состоянии заклинило железку довольно странно.Возможность это сделать зависит от
>того что за железка.Ну да, без звуковухи в принципе работу продолжить
>можно, хотя особого кайфа юзеру сий факт не доставит.
ядро может взаимодействовать с железом лишь посредствам дров. Драйвер упал - выбор прост: либо его перезапустить, либо смириться с отсутствием железки в системе до ребута.
>>Вы ясно дали понять, что готовы отдаться на волю случая, т.е. лучше
>>чтоб все упало разом.
>Разумеется - при этом будет минимизирован шанс что-то испортить в файловой системе
>и прочем.
расстрою: падение чего-либо в монолите ядра в общем случае _может_ повредить _любые_ данные.
И твоя ФС - не исключение. А защитить в монолите можно лишь код, сделав его 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.bz2VNC клиента и сервера:
-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 часа над ответом просидел!!)