Natalie Protasevich, помогающая Andrew Morton в разборе новых сообщений об ошибках в Linux ядре обратила внимание на несколько десятков ошибок в ядре, на которые не спешат реагировать разработчики проблемных подсистем. Печально, что только семь проблем из списка находятся на стадии устранения, двадцать семь остаются просто проигнорированы. По этому поводу в списке рассылки разработчиков Linux ядра возникла дискуссия (http://www.linuxworld.com/news/2007/112007-kernel.html).
David Miller высказал предположение, что ошибки не игнорируют, просто до них не успевают дойти руки (более приоритетные ошибки, требуют первоочередного решения, а менее значительные проблемы остаются в конце списка задач). Andrew Morton считает, что первым делом нужно исправлять проблемы, возникшие в текущем релизе, но отсутствующие в прошлых (regression).
По мнению Ingo Molnar необходимо, пока не поздно, разработать инфраструктуру для всестороннего тестирования подсистем ядра, для выявления ошибок всплывающих только при редком стечении обстоятельств.URL: http://www.linuxworld.com/news/2007/112007-kernel.html
Новость: http://www.opennet.me/opennews/art.shtml?num=12893
Ключевые слова - пока не поздно....
>... нужно исправлять проблемы, возникшие в текущем релизе,
> но отсутствующие в прошлых (regression)Если устранять в текущем, то в будущем ошибок не будет в прошлых.
Ибо если они буду, значит они небыли устранены в текущем.
Если устранять в текущем, то в будущем, ошибок не будет в прошлых.
Ибо если они буду, значит они небыли устранены в текущем.
P.S. Очень нужная запятая.
> для выявления ошибок всплывающих только при редком стечении обстоятельств.Насколько помню и теории вероятностей,
случайные события умножаются, а не скаладываются.
Следовательно три мелких ошибки, это не в три раза больше одной,
а в степени 3, т.е. 27.
Это я к тому, что комбинация редко используемых элементов ядра,
которые содержат ошибки, могут привести в болле опасной, нежели каждая в отдельности, ситуации.
сильна твоя трава, Павлинух.Но высказывание Инго прост овзяло за душу.
Я буквально месяц назад чуть ли не начал что-то подобное проектировать.
Потому как была проблема, которую я не мог поймать, но она все-же происходила.Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
Который мог бы просчитать все случаи race contitions и проанализировать
правильность расстановки локов в критических местах.В теории, подобная софтина могла бы прямо указывать на ошибки кода...
Но _что_ это будет - это уже флейм на пару лет...
Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума.
Не говоря про других менее известных людей.
Всё придёт в конце-концов к тому, что уже придумано.
Жаль, что многие люди могут учиться только на своих ошибках :-(> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор?
Представляете, что будет, если в коде анализатора будет ошибка из-за которой он сам её не сможет найти? Усложнение сложного - очень плохой путь, однако.
>Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума.
>Не говоря про других менее известных людей.
>Всё придёт в конце-концов к тому, что уже придумано.
>Жаль, что многие люди могут учиться только на своих ошибках :-(да обратил и давно...
уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и
заложит 3-ю версию Линуха - устремив его в микроядерном направлении.
>> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
>
>Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор?
>Представляете, что будет, если в коде анализатора будет ошибка из-за которой он
>сам её не сможет найти?Абсолютно ничего страшного.
Ложные срабатывания на несуществующую ошибку - просто повод пересмотреть
указанное место и не найти в нем проблем.
Ну а если софтина не увидит существующих проблем - то она их УЖЕ не видит,
т.к. не существуюет :) Это просто задача продолжать ее развивать.Так что, любая такая софтина - была бы ЗНАЧИТЕЛЬНО лучше, чем ничего...
>Усложнение сложного - очень плохой путь, однако.неа. Это разные вещи: ядро и анализатор. Усложная/создавая анализатор, код самого Линуха
не может становиться хуже. Что, собсно, и есть самоцель.
>уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и
>заложит 3-ю версию Линуха - устремив его в микроядерном направлении....а в итоге получится тормознутая по сравнению даже с вистовсом система (а когда переключения между кольцами были дешевой операцией?В микроядре переключений в разы больше, деградеж скорости работы системы - гарантирован) а индусы поняв что теперь дрова могут безнаказанно падать забьют на контроль качества полный болт сэкономив пару копеек на тесте и дебаге.
А в итоге получится тормозная и глюкавая система а-ля Win95 (в которой далеко не любой bsod ронял систему, после многих она отскребалась от асфальта и бежала дальше).Набитая дерьмовым закрытым индусским кодом.Который 1 раз написали по принципу "вроде работает" и более не поддерживают вообще, так что выпустить качественный дистрибутив станет фантастикой.Вам и правда нужна такая система?Мне - нет.Зачем надо облегчать индусам создание закрытых дров в которых к тому же можно халтурить - не очент понятно.Кернел девелоперам Linux и GPLнутому коду я как-то сильно больше доверяю чем кривому индусскому закрытому драйверу пусть и не в ядре.
>...а в итоге получится тормознутая по сравнению даже с вистовсом системашифровать траффик от памяти до видухи вряд ли кто додумаеццо в Линухе ;)
а также, искать налету в копируемых файлах копирайтный контент...так что даже не переживай по этому поводу
>(а= когда переключения между кольцами были дешевой операцией?
всегда.
Переключение между кольцами - это одна инструкция: int XXты кольца точно ни с чем не перепутал?? ;)
>В микроядре переключений в разы
>больше, деградеж скорости работы системы - гарантированобеими руками за. Деградеж, потери...
Аж 2-3% :)))И это именно процессора.
Не памяти и не винта (а именно винт - самое узкое место в системе...)
Так что, ради того чтобы разбить посудину по имени Линух на отдельные отсеки - отдать немного самого простаивающего ресурса - по мне - так не проблема, а счастье.>а индусы поняв что
>теперь дрова могут безнаказанно падать забьют на контроль качества полный болт
>сэкономив пару копеек на тесте и дебаге.а какая мне разница что там индусы напишут для маздая?? %))
Это ползателей маздая можешь индусами пугать.Меня и пряником не заманишь их поделия в ядро пихать,
разве что они дровишко под какой-нить хитрый девайс сделают (и только!).
И в таком стремном случае уж лучше пусть их поделие в отдельном процессе крутиццо,
чем как щас - все-в-одном...Ну а принимать в микрядро полное гумно никто не начинать не будет.
Так что закрытые поделия туда не попадут.
>А в итоге получится тормозная и глюкавая система а-ля Win95 (в которой
>далеко не любой bsod ронял систему, после многих она отскребалась от
>асфальта и бежала дальше).Набитая дерьмовым закрытым индусским кодом.Который 1 раз написали
>по принципу "вроде работает" и более не поддерживают вообще, так что
>выпустить качественный дистрибутив станет фантастикой.Остапа понесло...
Индусское гумно там может отвечать за какой-то хитрый девайс и все
(и только в случае крайней необходимости, а, также, отсутсвия свободного аналога).
И то лишь потому что до написание дров под тот девайс пошли потому, как под микроядро
это много менее ответственно, чем под монолит, где ошибка валит все ядро, а не только
твой девайс.Вобщем, ты вообще не понимаешь о чем говоришь.
Или ты решил, что JFS драйвер или драйвер винта я резко побегу заказывать у индусов??
Мне и дрова из mainstream нравяццо %)))
>Вам и правда нужна такая система?То, что ты описал - это бред в страшной агонии.
Это не имеет ничего общего с GPL'ed микроядром.>Мне - нет. Зачем надо облегчать индусам создание закрытых дров в которых к тому
>же можно халтурить - не очент понятно.расскажу еще раз.
Все что сейчас есть в Линухе под свободными лицензиями и будет продолжать использоваться.
Те конторы, которые сейчас не спешат вкладывать деньги в надежную разработку под микроядро - и не поддерживают свои девайсы на Линухе. Т.е. под линухом щас много чего просто НЕКАК использовать.
Если же этот некий закрытый драйвер будет жить в отдельном процессе - то его качество действительно может быть не таким высоким (при этом будет страдать _ТОЛЬКО_ сам же драйвер). А это меньше затрат на создание такого драйвера. Это понизит планку для контор, которые в принципе хотели бы поддерживать линух, но пока что дорого.
Или ты не хочешь чтоб Линух стал еще популярнее за счет большего количества поддерживаемых девайсов?? Напомню, что сейчас очень многим "принимающим решение" важна именно официальная поддержка какого-то нужного девайса ОСью. Нет официальной поддержки в Линухе - для них нет и Линуха...
Жизнь несколько сложнее, как ты видишь...>Кернел девелоперам Linux и GPLнутому
>коду я как-то сильно больше доверяю чем кривому индусскому закрытому драйверу
>пусть и не в ядре.Ты не оригинален в этом %))
Только я не пойму: кто тебя заставит использовать гумно, если уже есть нормальные GPL дрова? И каким образом тебе помешают какие-то закрытые дрова под какие-то хитрые девайсы,
(которых, может, у тебя никогда и не будет)?
Или ты не хочешь, чтоб Линух становился распространеннее за счет тех, кому нужна официальная поддержка?
Еще добавить в плане скорости хотелось.Вот прямо сейчас на Линухе может крутиццо тысяча процессов без особых проблем (ну, нужно соотв. памяти... все понятно).
И переключение между ними происходят ОЧЕНЬ часто. И нечего. И все живут, рады и счастливы.Те несколько десятков процессов, которые драйвера в ядре, как либо радикально НЕ изменят картину с переключаениями контекстов. Больше проблем будет разве что с вводом/выводом у драйверов. Но это уже детали реализации.
Так что, как видишь, вынос драйверов в отдельные процессы радикально не изменит картину с переключениями.
>... если в коде анализатора будет ошибка...Тут можно разбить на две подпроблемы:
* Ошибка самого алгоритма.
* Ошибка реализации алгоритма.Первое, решается (или нет), аналитическими методами, логикой.
Второе, ну извините, прокладкой меж креслом и компьютером.
Для локов кое-что уже есть, ещё не все потеряно ;)http://lwn.net/Articles/185666/
да
уже неплохо ;)но этого недостаточно...
>[оверквотинг удален]
>Я буквально месяц назад чуть ли не начал что-то подобное проектировать.
>Потому как была проблема, которую я не мог поймать, но она все-же
>происходила.
>
>Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
>Который мог бы просчитать все случаи race contitions и проанализировать
>правильность расстановки локов в критических местах.
>
>В теории, подобная софтина могла бы прямо указывать на ошибки кода...
>Но _что_ это будет - это уже флейм на пару лет...Попробую угадать.. dtrace?
>Попробую угадать.. dtrace?слив защитан
Мы не юзер-левел дебагим, а ядро.
>слив защитан
>
>Мы не юзер-левел дебагим, а ядро.Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже.
>Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже.ок, защитал по Dtrace слив себе.
Но ниче подобного нам не поможет в проблема Линуха.
Нужно нечто совершенно иное, работающее с исходниками...
>Попробую угадать.. dtrace?Может быть, что-то похожее на WITNESS во FreeBSD? :-)
>>Попробую угадать.. dtrace?
>
>Может быть, что-то похожее на WITNESS во FreeBSD? :-)неа.
Такое уже есть, срежство слежения за локами, но это не то... Совсем...
> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
> Который мог бы просчитать все случаи race contitions и проанализировать
> правильность расстановки локов в критических местах.начать с coverity? http://www.coverity.com/ тем более, что AFAIK ядро под ней уже проверяли.
// wbr
>начать с coverity? http://www.coverity.com/...и закончить ее лицензией
>тем более, что AFAIK ядро под ней уже проверяли.
показуха... а нам бы работу
А вообще-то, это не того масштаба анализ.
Там проверки буферов, возможных переполнений, какие-то прочие "мелочи"...Нам бы логику проверять... причем, на уровне потоков, многозадачности...
не знаю... мысль пока не устоялась по этому вопросу
>Нам бы логику проверять... причем, на уровне потоков, многозадачности...А еще, чтобы программы сами писались.
Дело в том что если каждая ошибка сама по себе редко проявляется, например с вероятностью P (предположим у всех трех вероятность одинаковая), то 3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть МЕГАредко. А еще в теории вероятностей есть теорема о том, что очень редкие события никогда в реальности не происходят. Просто потому что время до их наступления так никто и не дожидается ;)
>Дело в том что если каждая ошибка сама по себе редко проявляется,
>например с вероятностью P (предположим у всех трех вероятность одинаковая), то
>3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть
>МЕГАредко. А еще в теории вероятностей есть теорема о том, что
>очень редкие события никогда в реальности не происходят. Просто потому что
>время до их наступления так никто и не дожидается ;)эх....
именно поэтому "теория вероятности" и остаеццо _теорией_.
Вреале такие ошибки весьма охотно происходят, не дожидаясь конца жизни админа :)
А ещё есть такая штука: если неприятность может произойти, то она обязательно произойдёт :-)
>А ещё есть такая штука: если неприятность может произойти, то она обязательно
>произойдёт :-)ну это некритично если кто маздай поставил случайно...
снести то всегда можно :)
тоже случайно, даже и подозревая того...
>даже и подозревая того...еще и как подозревая!
это маздай люди ставят неосознанно, а Линух как правило - находясь весьма в трезвом уме
:)
>А еще в теории вероятностей есть теорема о том, что очень
>редкие события никогда в реальности не происходят.Угу. И симметричная теорема о том, что при очень долгом ожидании
либо очень частом повторении эксперимента (как раз компьютерный
случай) с вероятностью почти 1 происходят почти невозможные
события ;)
Я предлагаю отделить разработку драйверов от разработки ядра.
>Я предлагаю отделить разработку драйверов от разработки ядра.если это лишь организационного плана предложение - то оно равно нулю.
Девелоперы разных подсистем и так уже разделены дальше некуда :)
А если по дереву разработки просто - тоже мало толку.
Какая разница: лить отдельно ядро и другим файлом дрова - но оно все равно будет все жить в одном ядресном пространстве (монолит, как щас) - тоже толку ноль, тока гемор с архивами исходников.Если же про микроядро, чтоб дрова жили в своем адресном пространстве - это тема.
> ...ядресном пространстве...гы, ну и опечатка :)
весьма точно и коротко описывает суть ;)))
Хорошо, что не написал ПРОСРАНСТВЕ :)
>Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>это тема.да еще каждый в своем....
вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым переключением задач без потери кэшей, вот тогда можно будет со спокойной душой заводить микроядерность и прочую изоляцию
>>Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>>это тема.
>
>да еще каждый в своем....и никак иначе.
>вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым
>переключением задач без потери кэшейкак это все сладко звучит.... %)
>вот тогда можно будет со спокойной
>душой заводить микроядерность и прочую изоляциюна самом деле чем раньше, тем лучше.
Ну а прямо сейчас - сам Пенгуин велел.
Процы бешенные, их по несколько штук...Думаю, кому нужна надежность со спокойной душей отдаст даже 10% производительности.
(лично я верю - это это будет ~2-3%)Самое время... ИМО Торвальдс тут несколько... кхм... небыстр...
Про QNX и L4 когда-нибудь слышали? Почему-то у них сильных проблем с производительностью при переключении контекстов не возникает. Возможно, потому, что, в отличие от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без сложных проверок безопасности ( в смысле разграничения доступа ), и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания критических ветвей кода на ассемблере.
>Про QNX и L4 когда-нибудь слышали?
>Почему-то у них сильных проблем с
>производительностью при переключении контекстов не возникает.В Линуксе тоже с этим нет проблем :)
1:1
Просто товарисч решил, что еще есть время чего-то ждать,
когда самое время начинать действовать.
>Возможно, потому, что, в отличие
>от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без
>сложных проверок безопасности ( в смысле разграничения доступа ),угу. Особенно в QNX, без особой проверки безопасности... именно... %)))
>и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания
>критических ветвей кода на ассемблерену, критическими по производительности секциями на асме хвастаться надо.
Это обыденность. И Линух девелоперы тоже об этом знают ;)
>вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщенийНеплохой способ заранее приготовить качественный трындец вашей системе в виде мины замедленного действия.Более качественный саботаж придумать трудно.Что будет с такой системой когда данную модель процессоров снимут с производства?Правильно, ей настанет пиндык.Советую подумать о том что какой-нибудь микрософт может даже этому поспособствовать.
Для тех кто в танке намекаю: на интеле и сраном х86 мир не заканчивается.Так, для сведений, Linux работает еще на PowerPC (32\64 и Cell), MIPS, ARM, SPARC, ... - а вы портировать ваши чудеса на архитектуры отличные от х86 кадавра не заколебетесь?Или всякие там гаджеты, мобильные ниши, роутеры, сервера и прочее предлагается сдать без боя проприетарщиками и виндусю?Спасибо, но их и так слишком много.Так не пойдет.А сделав то что вы предлагаете - вы фрагментируете усилия по разработке системы, нельзя будет просто взять систему и поюзать в энном девайсе.Микрософт годами добивается того чтобы усилия по разработке фрагментировались.Вы предлагаете им помочь, притормозив развитие системы и фрагментировав усилия по разработке?
>если это лишь организационного плана предложение - то оно равно нулю.А как же Dell с DKMS?Правда вы видимо не совсем то имели в виду.
>Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>это тема.А в чем тема?Значительно затормозить ядро ос?Вылезут MS и всякие там SUN и *BSD с бенчами где их системы делают это чуть ли не в разы.А индусы обнаглевшие от безнаказанности (ведь крах драйвера не выносит систему - баг более не критичный а ерундовый!) просто начнут клепать глючные и кривые дрова сами.Вместо того чтобы дать спеки вменяемым кернел-девелоперам.Майнтайнить эти дрова никто не будет - да нафиг оно кому?Получится что дрова как бы есть но закрытые и бажные.В силу закрытости фиг поправишь а баги индусы чинить не будут, раз система не грохается - дескать переживут.
Есть такая поговорка, от добра добра не ищут.На данный момент линукс достаточно резвая и достаточно стабильная система, с минимум проприетарного кода (в идеале - без оного) способная работать месяцами или годами без крашей в ядре.Зачем чинить то что не сломано?Чтобы потом сказать "хотели как лучше а получилось как всегда"?
Извините но я знаю линукс таким каким он есть.И мне он таким нравится.Если вы считаете что сможете лучше - сделайте лучше.Но называть это линуксом не надо.Я понимаю что всем нравятся buzzword-ы, но тормозная система с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у кого-то отождествляться с тем что сегодня называют словом Линукс.
про весь бред о тормозах и глбкалове - я уже сказал выше.
>Извините но я знаю линукс таким каким он есть.И мне он таким
>нравится.Если вы считаете что сможете лучше - сделайте лучше.Я один - нет. Если бы мог - я бы именно ним щас и занималсо, не рассказывая тебе
как это было бы хорошо.>Но называть это линуксом не надо.
А вот тут, похоже, тебя никто спрашивать не будет. Равно как и меня, впрочем.
Но если же Торвальдс решит (ну, например) 3-ю ветку делать микроядерной,
то это будет Linux 3.nn.mm ядро и тебе придетсья с этим жить (даже если ты будешь до конца дней оставаться на монолите 2-ой ветки).
Торвальдс владеет копирайтом на это название - ему и решать.
>Я понимаю что всем нравятся buzzword-ы, но тормозная система
>с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у
>кого-то отождествляться с тем что сегодня называют словом Линукс.тормозная и с индусскими закрытыми дровами - это название уже занято конторой негросовт ;)
Ессьно, это не может ассоциироваться с Линуксом :)
тыкс.. ксорг до 6.8 откатил, терь пора 23.8 на 19 сменить ^_^ фигли игры стали медленнее работать
Тетрис тормозит?? %)
> Тетрис тормозит?? %)чукча блин.
как мне оставаться папой в ut4 если у меня лага ?
если лажа - то никак конечно
У меня 17.13 по некоторым причинам. То что Патрик предлагает в дистре. 23.1 мне не нужно.
>У меня 17.13 по некоторым причинам.ухты.
Ты представляешь собой ОЧЕНЬ интересный экспонат...А серьезно, че ты на древности живешь? Ну, елси не секрет.
Мож че подсказать?
>>У меня 17.13 по некоторым причинам.
>
>ухты.
>Ты представляешь собой ОЧЕНЬ интересный экспонат...
>
>А серьезно, че ты на древности живешь? Ну, елси не секрет.
>Мож че подсказать?Да я писал здесь. Я привык к песочнице qemu. Она открывает tap интерфейсы. На одном и том же хосте в одной кофигурации на 17.13 от пользователя работает. Пробовал 19, 23 работает только от рута. Мне виртуалки от рута нафик не нужны. Разработчик tun модуля ответил что так теперь будет долго, видимо слишком много перестроили над модулем.
Вот такая мелочь.
>Да я писал здесь. Я привык к песочнице qemu. Она открывает tap
>интерфейсы. На одном и том же хосте в одной кофигурации на
>17.13 от пользователя работает. Пробовал 19, 23 работает только от рута.
>Мне виртуалки от рута нафик не нужны. Разработчик tun модуля ответил
>что так теперь будет долго, видимо слишком много перестроили над модулем.
>
>Вот такая мелочь.Ну, я так и знал шо какая-то ерунда :)
Радуйся, ибо твоей проблеме (это, собсно, даже не проблема... просто маны нужно читать ;)
есть вполне логичный фикс.В версиях после .17 (видимо именно тогда ;) люди решили прекратить интерфейсиный беспредел и запретить юзеру без CAP_NET_ADMIN capability рулить девайсами через уже открытый (!!)
/dev/net/tun... Ну, хрен его знает... кто-то может думал, что этот файлик везде 666 %)
не знаю... Параноик, вобщем. За сим, попросту говоря, тока рут может рулить семи девайсами, потому как грамотно порулить этими capability весьма непросто...За сим, все шо тебе надо - это создавать просто нужные интерфейсы от рута и пускать
свои qemu потом :) с указанием имен интерфейсов (!!) чтоб он не тужилсо их сам создавать.Для этого поставь пакеты "openvpn" _или_ (по вкусу, вобщем) "usermode-utilities".
И создавай интерфесы вот так:
# openvpn --mktun --dev-type tap --dev tap500
или
# tunctl -u <your_username> -t tap500во втором случае интерфейсу будет назначен владелец-юзер, который сможет с ним вытворять всякое, что, впрочем, тебе не понадобиться.
Ну и там же от рута цепляешь ИПшники (если надо ;))
и все :)
Qemu готов пускать твои песочницы в сеть.
Не знаю что у тя за дистр. Но в конфиге Генту это все выглядит вот так просто:# cat /etc/conf.d/net
......
tuntap_tap500="tap"
config_tap500=( "10.0.1.1/24" )
tunctl_tap500="-u <username>"
......# cd /etc/init.d && ln -s net.lo net.tap500
# /etc/init.d/net.tap500 start
# rc-update -a net.tap500 default (чтоб сам подымалсо)и будет тебе счастье :)
>Для этого поставь пакеты "openvpn" _или_ (по вкусу, вобщем) "usermode-utilities".
>
>И создавай интерфесы вот так:
> # openvpn --mktun --dev-type tap --dev tap500
>или
> # tunctl -u <your_username> -t tap500Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo.
Тока до 660 с нужной группой на tun я и сам могу додуматься без ядрёных параноиков :)
>Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo.угу :)
>Тока до 660 с нужной группой на tun я и сам могу
>додуматься без ядрёных параноиков :)ну, видать кто-то че-то перекурил ;))
Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19, как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....).
>Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19,
>как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....).не тот богат, у кого много денег, а тот - кому хватает ;)
ну, а мне и .23-го уже мало ;))
Тебе одновременно нужно CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ?
>Тебе одновременно нужно CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ?не
мне нуна одновременно CONFIG_CGROUPS ;)
А по моему мнению (то биш ИМХО) этим разработчикам надо приостановить выпуск релизов хотябы на год, и конкретно сесть за исправление ошибок, а то вперед ног бегут :), того и гляди ##нутся, и ядро точго в кашей станет из ошибок и ошибок :(P.S. А когда все видымые ошибки будут выловлены необходимо создать фонд платы за найденные баги, и подождать еще пол года а уж затем цикл ражработки как у FreeBSD , выпускать когда ядро действительно готово а не когда появятся новые строки кода.
Согласитесь, ядро уже созрело, теперь его осталось "вылизать" и по мере необходимости улучшать.
>релизов хотябы на год,На сто лет, фигли.Чтобы всякие саны, бсд и микрософт могли уж наверняка на хвост сесть.
>то вперед ног бегут :), того и гляди ##нутся, и ядро
>точго в кашей станет из ошибок и ошибок :(Такое ощущение что вас с ножом к горлу заставляют юзать самое-самое ядро да еще и не релизное.А по мне так как не глянешь на список изменений - душа радуется.Система становится реально лучше.
>цикл ражработки как у FreeBSD
Да, пример для подражания конечно сильный.Это чтобы линукс тоже прозябал на задворках цивилизации пока рулит микрософт и может быть, SUN и Apple?
У тебя пена щас пойдет изо рта, орнитолог.