|
| 1.4, pavlinux (??), 22:20, 22/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 >... нужно исправлять проблемы, возникшие в текущем релизе,
> но отсутствующие в прошлых (regression)
Если устранять в текущем, то в будущем ошибок не будет в прошлых.
Ибо если они буду, значит они небыли устранены в текущем.
| | |
| |
| 2.5, pavlinux (??), 22:22, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Если устранять в текущем, то в будущем, ошибок не будет в прошлых.
Ибо если они буду, значит они небыли устранены в текущем.
P.S. Очень нужная запятая.
| | |
|
| 1.6, pavlinux (??), 22:28, 22/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> для выявления ошибок всплывающих только при редком стечении обстоятельств.
Насколько помню и теории вероятностей,
случайные события умножаются, а не скаладываются.
Следовательно три мелких ошибки, это не в три раза больше одной,
а в степени 3, т.е. 27.
Это я к тому, что комбинация редко используемых элементов ядра,
которые содержат ошибки, могут привести в болле опасной, нежели каждая в отдельности, ситуации.
| | |
| |
| 2.7, Nick (??), 22:41, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 сильна твоя трава, Павлинух.
Но высказывание Инго прост овзяло за душу.
Я буквально месяц назад чуть ли не начал что-то подобное проектировать.
Потому как была проблема, которую я не мог поймать, но она все-же происходила.
Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
Который мог бы просчитать все случаи race contitions и проанализировать
правильность расстановки локов в критических местах.
В теории, подобная софтина могла бы прямо указывать на ошибки кода...
Но _что_ это будет - это уже флейм на пару лет...
| | |
| |
| 3.8, ДяДя (?), 23:01, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума.
Не говоря про других менее известных людей.
Всё придёт в конце-концов к тому, что уже придумано.
Жаль, что многие люди могут учиться только на своих ошибках :-(
> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор?
Представляете, что будет, если в коде анализатора будет ошибка из-за которой он сам её не сможет найти? Усложнение сложного - очень плохой путь, однако.
| | |
| |
| 4.9, Nick (??), 23:18, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума.
>Не говоря про других менее известных людей.
>Всё придёт в конце-концов к тому, что уже придумано.
>Жаль, что многие люди могут учиться только на своих ошибках :-(
да обратил и давно...
уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и
заложит 3-ю версию Линуха - устремив его в микроядерном направлении.
>> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
>
>Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор?
>Представляете, что будет, если в коде анализатора будет ошибка из-за которой он
>сам её не сможет найти?
Абсолютно ничего страшного.
Ложные срабатывания на несуществующую ошибку - просто повод пересмотреть
указанное место и не найти в нем проблем.
Ну а если софтина не увидит существующих проблем - то она их УЖЕ не видит,
т.к. не существуюет :) Это просто задача продолжать ее развивать.
Так что, любая такая софтина - была бы ЗНАЧИТЕЛЬНО лучше, чем ничего...
>Усложнение сложного - очень плохой путь, однако.
неа. Это разные вещи: ядро и анализатор. Усложная/создавая анализатор, код самого Линуха
не может становиться хуже. Что, собсно, и есть самоцель.
| | |
| |
| 5.50, R007 (?), 03:14, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и
>заложит 3-ю версию Линуха - устремив его в микроядерном направлении.
...а в итоге получится тормознутая по сравнению даже с вистовсом система (а когда переключения между кольцами были дешевой операцией?В микроядре переключений в разы больше, деградеж скорости работы системы - гарантирован) а индусы поняв что теперь дрова могут безнаказанно падать забьют на контроль качества полный болт сэкономив пару копеек на тесте и дебаге.
А в итоге получится тормозная и глюкавая система а-ля Win95 (в которой далеко не любой bsod ронял систему, после многих она отскребалась от асфальта и бежала дальше).Набитая дерьмовым закрытым индусским кодом.Который 1 раз написали по принципу "вроде работает" и более не поддерживают вообще, так что выпустить качественный дистрибутив станет фантастикой.Вам и правда нужна такая система?Мне - нет.Зачем надо облегчать индусам создание закрытых дров в которых к тому же можно халтурить - не очент понятно.Кернел девелоперам Linux и GPLнутому коду я как-то сильно больше доверяю чем кривому индусскому закрытому драйверу пусть и не в ядре.
| | |
| |
| 6.54, Nick (??), 13:24, 24/11/2007 [^] [^^] [^^^] [ответить] | +/– | шифровать траффик от памяти до видухи вряд ли кто додумаеццо в Линухе а также... большой текст свёрнут, показать | | |
| |
| 7.56, Nick (??), 13:38, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Еще добавить в плане скорости хотелось.
Вот прямо сейчас на Линухе может крутиццо тысяча процессов без особых проблем (ну, нужно соотв. памяти... все понятно).
И переключение между ними происходят ОЧЕНЬ часто. И нечего. И все живут, рады и счастливы.
Те несколько десятков процессов, которые драйвера в ядре, как либо радикально НЕ изменят картину с переключаениями контекстов. Больше проблем будет разве что с вводом/выводом у драйверов. Но это уже детали реализации.
Так что, как видишь, вынос драйверов в отдельные процессы радикально не изменит картину с переключениями.
| | |
|
|
|
| 4.11, pavlinux (??), 23:26, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>... если в коде анализатора будет ошибка...
Тут можно разбить на две подпроблемы:
* Ошибка самого алгоритма.
* Ошибка реализации алгоритма.
Первое, решается (или нет), аналитическими методами, логикой.
Второе, ну извините, прокладкой меж креслом и компьютером.
| | |
|
| 3.19, oops (?), 06:47, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>Я буквально месяц назад чуть ли не начал что-то подобное проектировать.
>Потому как была проблема, которую я не мог поймать, но она все-же
>происходила.
>
>Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
>Который мог бы просчитать все случаи race contitions и проанализировать
>правильность расстановки локов в критических местах.
>
>В теории, подобная софтина могла бы прямо указывать на ошибки кода...
>Но _что_ это будет - это уже флейм на пару лет...
Попробую угадать.. dtrace?
| | |
| |
| 4.20, Nick (??), 06:49, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Попробую угадать.. dtrace?
слив защитан
Мы не юзер-левел дебагим, а ядро.
| | |
| |
| 5.29, penguin_killer (?), 10:03, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>слив защитан
>
>Мы не юзер-левел дебагим, а ядро.
Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже.
| | |
| |
| 6.31, Nick (??), 10:32, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже.
ок, защитал по Dtrace слив себе.
Но ниче подобного нам не поможет в проблема Линуха.
Нужно нечто совершенно иное, работающее с исходниками...
| | |
|
|
| |
| 5.32, Nick (??), 10:34, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Попробую угадать.. dtrace?
>
>Может быть, что-то похожее на WITNESS во FreeBSD? :-)
неа.
Такое уже есть, срежство слежения за локами, но это не то... Совсем...
| | |
|
|
| 3.35, klalafuda (?), 11:49, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Нужен некий анализатор кода, локов, мутексов.. не знаю чего еще.
> Который мог бы просчитать все случаи race contitions и проанализировать
> правильность расстановки локов в критических местах.
начать с coverity? http://www.coverity.com/ тем более, что AFAIK ядро под ней уже проверяли.
// wbr
| | |
| |
| 4.36, Nick (??), 12:00, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>начать с coverity? http://www.coverity.com/
...и закончить ее лицензией
>тем более, что AFAIK ядро под ней уже проверяли.
показуха... а нам бы работу
А вообще-то, это не того масштаба анализ.
Там проверки буферов, возможных переполнений, какие-то прочие "мелочи"...
Нам бы логику проверять... причем, на уровне потоков, многозадачности...
не знаю... мысль пока не устоялась по этому вопросу
| | |
| |
| 5.37, madcore (?), 13:19, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Нам бы логику проверять... причем, на уровне потоков, многозадачности...
А еще, чтобы программы сами писались.
| | |
|
|
|
| 2.23, Knuckles (?), 08:02, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Дело в том что если каждая ошибка сама по себе редко проявляется, например с вероятностью P (предположим у всех трех вероятность одинаковая), то 3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть МЕГАредко. А еще в теории вероятностей есть теорема о том, что очень редкие события никогда в реальности не происходят. Просто потому что время до их наступления так никто и не дожидается ;)
| | |
| |
| 3.25, Nick (??), 08:55, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Дело в том что если каждая ошибка сама по себе редко проявляется,
>например с вероятностью P (предположим у всех трех вероятность одинаковая), то
>3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть
>МЕГАредко. А еще в теории вероятностей есть теорема о том, что
>очень редкие события никогда в реальности не происходят. Просто потому что
>время до их наступления так никто и не дожидается ;)
эх....
именно поэтому "теория вероятности" и остаеццо _теорией_.
Вреале такие ошибки весьма охотно происходят, не дожидаясь конца жизни админа :)
| | |
| 3.38, ДяДя (?), 14:10, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
А ещё есть такая штука: если неприятность может произойти, то она обязательно произойдёт :-)
| | |
| |
| 4.39, Nick (??), 14:29, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>А ещё есть такая штука: если неприятность может произойти, то она обязательно
>произойдёт :-)
ну это некритично если кто маздай поставил случайно...
снести то всегда можно :)
| | |
| |
| |
| 6.47, Nick (??), 23:02, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>даже и подозревая того...
еще и как подозревая!
это маздай люди ставят неосознанно, а Линух как правило - находясь весьма в трезвом уме
:)
| | |
|
|
|
| 3.40, DeadMustdie (??), 16:35, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >А еще в теории вероятностей есть теорема о том, что очень
>редкие события никогда в реальности не происходят.
Угу. И симметричная теорема о том, что при очень долгом ожидании
либо очень частом повторении эксперимента (как раз компьютерный
случай) с вероятностью почти 1 происходят почти невозможные
события ;)
| | |
|
|
| |
| 2.12, Nick (??), 23:26, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Я предлагаю отделить разработку драйверов от разработки ядра.
если это лишь организационного плана предложение - то оно равно нулю.
Девелоперы разных подсистем и так уже разделены дальше некуда :)
А если по дереву разработки просто - тоже мало толку.
Какая разница: лить отдельно ядро и другим файлом дрова - но оно все равно будет все жить в одном ядресном пространстве (монолит, как щас) - тоже толку ноль, тока гемор с архивами исходников.
Если же про микроядро, чтоб дрова жили в своем адресном пространстве - это тема.
| | |
| |
| 3.13, Nick (??), 23:28, 22/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> ...ядресном пространстве...
гы, ну и опечатка :)
весьма точно и коротко описывает суть ;)))
| | |
| 3.41, opa__ (?), 18:45, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>это тема.
да еще каждый в своем....
вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым переключением задач без потери кэшей, вот тогда можно будет со спокойной душой заводить микроядерность и прочую изоляцию
| | |
| |
| 4.42, Nick (??), 20:39, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>>это тема.
>
>да еще каждый в своем....
и никак иначе.
>вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым
>переключением задач без потери кэшей
как это все сладко звучит.... %)
>вот тогда можно будет со спокойной
>душой заводить микроядерность и прочую изоляцию
на самом деле чем раньше, тем лучше.
Ну а прямо сейчас - сам Пенгуин велел.
Процы бешенные, их по несколько штук...
Думаю, кому нужна надежность со спокойной душей отдаст даже 10% производительности.
(лично я верю - это это будет ~2-3%)
Самое время... ИМО Торвальдс тут несколько... кхм... небыстр...
| | |
| 4.46, penguin_killer (?), 22:47, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Про QNX и L4 когда-нибудь слышали? Почему-то у них сильных проблем с производительностью при переключении контекстов не возникает. Возможно, потому, что, в отличие от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без сложных проверок безопасности ( в смысле разграничения доступа ), и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания критических ветвей кода на ассемблере.
| | |
| |
| 5.49, Nick (??), 23:51, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Про QNX и L4 когда-нибудь слышали?
>Почему-то у них сильных проблем с
>производительностью при переключении контекстов не возникает.
В Линуксе тоже с этим нет проблем :)
1:1
Просто товарисч решил, что еще есть время чего-то ждать,
когда самое время начинать действовать.
>Возможно, потому, что, в отличие
>от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без
>сложных проверок безопасности ( в смысле разграничения доступа ),
угу. Особенно в QNX, без особой проверки безопасности... именно... %)))
>и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания
>критических ветвей кода на ассемблере
ну, критическими по производительности секциями на асме хвастаться надо.
Это обыденность. И Линух девелоперы тоже об этом знают ;)
| | |
|
| 4.53, R007 (?), 03:45, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений
Неплохой способ заранее приготовить качественный трындец вашей системе в виде мины замедленного действия.Более качественный саботаж придумать трудно.Что будет с такой системой когда данную модель процессоров снимут с производства?Правильно, ей настанет пиндык.Советую подумать о том что какой-нибудь микрософт может даже этому поспособствовать.
Для тех кто в танке намекаю: на интеле и сраном х86 мир не заканчивается.Так, для сведений, Linux работает еще на PowerPC (32\64 и Cell), MIPS, ARM, SPARC, ... - а вы портировать ваши чудеса на архитектуры отличные от х86 кадавра не заколебетесь?Или всякие там гаджеты, мобильные ниши, роутеры, сервера и прочее предлагается сдать без боя проприетарщиками и виндусю?Спасибо, но их и так слишком много.Так не пойдет.А сделав то что вы предлагаете - вы фрагментируете усилия по разработке системы, нельзя будет просто взять систему и поюзать в энном девайсе.Микрософт годами добивается того чтобы усилия по разработке фрагментировались.Вы предлагаете им помочь, притормозив развитие системы и фрагментировав усилия по разработке?
| | |
|
| 3.51, R007 (?), 03:27, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>если это лишь организационного плана предложение - то оно равно нулю.
А как же Dell с DKMS?Правда вы видимо не совсем то имели в виду.
>Если же про микроядро, чтоб дрова жили в своем адресном пространстве -
>это тема.
А в чем тема?Значительно затормозить ядро ос?Вылезут MS и всякие там SUN и *BSD с бенчами где их системы делают это чуть ли не в разы.А индусы обнаглевшие от безнаказанности (ведь крах драйвера не выносит систему - баг более не критичный а ерундовый!) просто начнут клепать глючные и кривые дрова сами.Вместо того чтобы дать спеки вменяемым кернел-девелоперам.Майнтайнить эти дрова никто не будет - да нафиг оно кому?Получится что дрова как бы есть но закрытые и бажные.В силу закрытости фиг поправишь а баги индусы чинить не будут, раз система не грохается - дескать переживут.
Есть такая поговорка, от добра добра не ищут.На данный момент линукс достаточно резвая и достаточно стабильная система, с минимум проприетарного кода (в идеале - без оного) способная работать месяцами или годами без крашей в ядре.Зачем чинить то что не сломано?Чтобы потом сказать "хотели как лучше а получилось как всегда"?
Извините но я знаю линукс таким каким он есть.И мне он таким нравится.Если вы считаете что сможете лучше - сделайте лучше.Но называть это линуксом не надо.Я понимаю что всем нравятся buzzword-ы, но тормозная система с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у кого-то отождествляться с тем что сегодня называют словом Линукс.
| | |
| |
| 4.55, Nick (??), 13:31, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
про весь бред о тормозах и глбкалове - я уже сказал выше.
>Извините но я знаю линукс таким каким он есть.И мне он таким
>нравится.Если вы считаете что сможете лучше - сделайте лучше.
Я один - нет. Если бы мог - я бы именно ним щас и занималсо, не рассказывая тебе
как это было бы хорошо.
>Но называть это линуксом не надо.
А вот тут, похоже, тебя никто спрашивать не будет. Равно как и меня, впрочем.
Но если же Торвальдс решит (ну, например) 3-ю ветку делать микроядерной,
то это будет Linux 3.nn.mm ядро и тебе придетсья с этим жить (даже если ты будешь до конца дней оставаться на монолите 2-ой ветки).
Торвальдс владеет копирайтом на это название - ему и решать.
>Я понимаю что всем нравятся buzzword-ы, но тормозная система
>с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у
>кого-то отождествляться с тем что сегодня называют словом Линукс.
тормозная и с индусскими закрытыми дровами - это название уже занято конторой негросовт ;)
Ессьно, это не может ассоциироваться с Линуксом :)
| | |
|
|
|
| 1.17, exn (??), 01:31, 23/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
тыкс.. ксорг до 6.8 откатил, терь пора 23.8 на 19 сменить ^_^ фигли игры стали медленнее работать
| | |
| |
| |
| 3.33, exn (??), 11:15, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> Тетрис тормозит?? %)
чукча блин.
как мне оставаться папой в ut4 если у меня лага ?
| | |
|
| 2.21, tux2002 (?), 07:47, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 У меня 17.13 по некоторым причинам. То что Патрик предлагает в дистре. 23.1 мне не нужно.
| | |
| |
| 3.22, Nick (??), 07:59, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>У меня 17.13 по некоторым причинам.
ухты.
Ты представляешь собой ОЧЕНЬ интересный экспонат...
А серьезно, че ты на древности живешь? Ну, елси не секрет.
Мож че подсказать?
| | |
| |
| 4.24, tux2002 (?), 08:49, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>У меня 17.13 по некоторым причинам.
>
>ухты.
>Ты представляешь собой ОЧЕНЬ интересный экспонат...
>
>А серьезно, че ты на древности живешь? Ну, елси не секрет.
>Мож че подсказать?
Да я писал здесь. Я привык к песочнице qemu. Она открывает tap интерфейсы. На одном и том же хосте в одной кофигурации на 17.13 от пользователя работает. Пробовал 19, 23 работает только от рута. Мне виртуалки от рута нафик не нужны. Разработчик tun модуля ответил что так теперь будет долго, видимо слишком много перестроили над модулем.
Вот такая мелочь.
| | |
| |
| 5.26, Nick (??), 09:20, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Да я писал здесь. Я привык к песочнице 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 (чтоб сам подымалсо)
и будет тебе счастье :)
| | |
| |
| 6.27, tux2002 (?), 09:40, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Для этого поставь пакеты "openvpn" _или_ (по вкусу, вобщем) "usermode-utilities".
>
>И создавай интерфесы вот так:
> # openvpn --mktun --dev-type tap --dev tap500
>или
> # tunctl -u <your_username> -t tap500
Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo.
Тока до 660 с нужной группой на tun я и сам могу додуматься без ядрёных параноиков :)
| | |
| |
| 7.28, Nick (??), 09:41, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo.
угу :)
>Тока до 660 с нужной группой на tun я и сам могу
>додуматься без ядрёных параноиков :)
ну, видать кто-то че-то перекурил ;))
| | |
|
|
|
| 4.44, pavlinux (??), 21:25, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19, как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....).
| | |
| |
| 5.48, Nick (??), 23:09, 23/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19,
>как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....).
не тот богат, у кого много денег, а тот - кому хватает ;)
ну, а мне и .23-го уже мало ;))
| | |
| |
| 6.58, pavlinux (??), 21:33, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Тебе одновременно нужно CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ?
| | |
| |
| 7.59, Nick (??), 00:06, 25/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Тебе одновременно нужно CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ?
не
мне нуна одновременно CONFIG_CGROUPS ;)
| | |
|
|
|
|
|
|
| 1.45, Kern El (?), 22:39, 23/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А по моему мнению (то биш ИМХО) этим разработчикам надо приостановить выпуск релизов хотябы на год, и конкретно сесть за исправление ошибок, а то вперед ног бегут :), того и гляди ##нутся, и ядро точго в кашей станет из ошибок и ошибок :(
P.S. А когда все видымые ошибки будут выловлены необходимо создать фонд платы за найденные баги, и подождать еще пол года а уж затем цикл ражработки как у FreeBSD , выпускать когда ядро действительно готово а не когда появятся новые строки кода.
Согласитесь, ядро уже созрело, теперь его осталось "вылизать" и по мере необходимости улучшать.
| | |
| |
| 2.52, R007 (?), 03:33, 24/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>релизов хотябы на год,
На сто лет, фигли.Чтобы всякие саны, бсд и микрософт могли уж наверняка на хвост сесть.
>то вперед ног бегут :), того и гляди ##нутся, и ядро
>точго в кашей станет из ошибок и ошибок :(
Такое ощущение что вас с ножом к горлу заставляют юзать самое-самое ядро да еще и не релизное.А по мне так как не глянешь на список изменений - душа радуется.Система становится реально лучше.
>цикл ражработки как у FreeBSD
Да, пример для подражания конечно сильный.Это чтобы линукс тоже прозябал на задворках цивилизации пока рулит микрософт и может быть, SUN и Apple?
| | |
|
|
