форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от opennews on 22-Ноя-07, 17:20

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.dev/opennews/art.shtml?num=12893

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от creativ (??) on 22-Ноя-07, 17:25

Ключевые слова - пока не поздно....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от pavlinux (??) on 22-Ноя-07, 22:20

>... нужно исправлять проблемы, возникшие в текущем релизе, > но отсутствующие в прошлых (regression) Если устранять в текущем, то в будущем ошибок не будет в прошлых. Ибо если они буду, значит они небыли устранены в текущем.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 22-Ноя-07, 22:22
	Если устранять в текущем, то в будущем, ошибок не будет в прошлых. Ибо если они буду, значит они небыли устранены в текущем. P.S. Очень нужная запятая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от pavlinux (??) on 22-Ноя-07, 22:28

> для выявления ошибок всплывающих только при редком стечении обстоятельств. Насколько помню и теории вероятностей, случайные события умножаются, а не скаладываются. Следовательно три мелких ошибки, это не в три раза больше одной, а в степени 3, т.е. 27. Это я к тому, что комбинация редко используемых элементов ядра, которые содержат ошибки, могут привести в болле опасной, нежели каждая в отдельности, ситуации.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 22-Ноя-07, 22:41
	сильна твоя трава, Павлинух. Но высказывание Инго прост овзяло за душу. Я буквально месяц назад чуть ли не начал что-то подобное проектировать. Потому как была проблема, которую я не мог поймать, но она все-же происходила. Нужен некий анализатор кода, локов, мутексов..  не знаю чего еще. Который мог бы просчитать все случаи race contitions и проанализировать правильность расстановки локов в критических местах. В теории, подобная софтина могла бы прямо указывать на ошибки кода... Но _что_ это будет - это уже флейм на пару лет...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от ДяДя on 22-Ноя-07, 23:01
	Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума. Не говоря про других менее известных людей. Всё придёт в конце-концов к тому, что уже придумано. Жаль, что многие люди могут учиться только на своих ошибках :-( > Нужен некий анализатор кода, локов, мутексов..  не знаю чего еще. Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор? Представляете, что будет, если в коде анализатора будет ошибка из-за которой он сам её не сможет найти? Усложнение сложного - очень плохой путь, однако.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 22-Ноя-07, 23:18
	>Обратите внимание, хотя бы на труда Н.Вирта и Э.Таненбаума. >Не говоря про других менее известных людей. >Всё придёт в конце-концов к тому, что уже придумано. >Жаль, что многие люди могут учиться только на своих ошибках :-( да обратил и давно... уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и заложит 3-ю версию Линуха - устремив его в микроядерном направлении. >> Нужен некий анализатор кода, локов, мутексов..  не знаю чего еще. > >Если в таком анализаторе будет ошибка? Чем анализировать сам анализатор? >Представляете, что будет, если в коде анализатора будет ошибка из-за которой он >сам её не сможет найти? Абсолютно ничего страшного. Ложные срабатывания на несуществующую ошибку - просто повод пересмотреть указанное место и не найти в нем проблем. Ну а если софтина не увидит существующих проблем - то она их УЖЕ не видит, т.к. не существуюет :) Это просто задача продолжать ее развивать. Так что, любая такая софтина - была бы ЗНАЧИТЕЛЬНО лучше, чем ничего... >Усложнение сложного - очень плохой путь, однако. неа. Это разные вещи: ядро и анализатор. Усложная/создавая анализатор, код самого Линуха не может становиться хуже. Что, собсно, и есть самоцель.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от R007 on 24-Ноя-07, 03:14
	>уже жду недождусь когда Торвальдс выдохнет о вреде микроядра и >заложит 3-ю версию Линуха - устремив его в микроядерном направлении. ...а в итоге получится тормознутая по сравнению даже с вистовсом система (а когда переключения между кольцами были дешевой операцией?В микроядре переключений в разы больше, деградеж скорости работы системы - гарантирован) а индусы поняв что теперь дрова могут безнаказанно падать забьют на контроль качества полный болт сэкономив пару копеек на тесте и дебаге. А в итоге получится тормозная и глюкавая система а-ля Win95 (в которой далеко не любой bsod ронял систему, после многих она отскребалась от асфальта и бежала дальше).Набитая дерьмовым закрытым индусским кодом.Который 1 раз написали по принципу "вроде работает" и более не поддерживают вообще, так что выпустить качественный дистрибутив станет фантастикой.Вам и правда нужна такая система?Мне - нет.Зачем надо облегчать индусам создание закрытых дров в которых к тому же можно халтурить - не очент понятно.Кернел девелоперам Linux и GPLнутому коду я как-то сильно больше доверяю чем кривому индусскому закрытому драйверу пусть и не в ядре.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 24-Ноя-07, 13:24
	>...а в итоге получится тормознутая по сравнению даже с вистовсом система шифровать траффик от памяти до видухи вряд ли кто додумаеццо в Линухе ;) а также, искать налету в копируемых файлах копирайтный контент... так что даже не переживай по этому поводу >(а= когда переключения между кольцами были дешевой операцией? всегда. Переключение между кольцами - это одна инструкция: int XX ты кольца точно ни с чем не перепутал?? ;) >В микроядре переключений в разы >больше, деградеж скорости работы системы - гарантирован обеими руками за. Деградеж, потери... Аж 2-3% :))) И это именно процессора. Не памяти и не винта (а именно винт - самое узкое место в системе...) Так что, ради того чтобы разбить посудину по имени Линух на отдельные отсеки - отдать немного самого простаивающего ресурса - по мне - так не проблема, а счастье. >а индусы поняв что >теперь дрова могут безнаказанно падать забьют на контроль качества полный болт >сэкономив пару копеек на тесте и дебаге. а какая мне разница что там индусы напишут для маздая?? %)) Это ползателей маздая можешь индусами пугать. Меня и пряником не заманишь их поделия в ядро пихать, разве что они дровишко под какой-нить хитрый девайс сделают (и только!). И в таком стремном случае уж лучше пусть их поделие в отдельном процессе крутиццо, чем как щас - все-в-одном... Ну а принимать в микрядро полное гумно никто не начинать не будет. Так что закрытые поделия туда не попадут. >А в итоге получится тормозная и глюкавая система а-ля Win95 (в которой >далеко не любой bsod ронял систему, после многих она отскребалась от >асфальта и бежала дальше).Набитая дерьмовым закрытым индусским кодом.Который 1 раз написали >по принципу "вроде работает" и более не поддерживают вообще, так что >выпустить качественный дистрибутив станет фантастикой. Остапа понесло... Индусское гумно там может отвечать за какой-то хитрый девайс и все (и только в случае крайней необходимости, а, также, отсутсвия свободного аналога). И то лишь потому что до написание дров под тот девайс пошли потому, как под микроядро это много менее ответственно, чем под монолит, где ошибка валит все ядро, а не только твой девайс. Вобщем, ты вообще не понимаешь о чем говоришь. Или ты решил, что JFS драйвер или драйвер винта я резко побегу заказывать у индусов?? Мне и дрова из mainstream нравяццо %))) >Вам и правда нужна такая система? То, что ты описал - это бред в страшной агонии. Это не имеет ничего общего с GPL'ed микроядром. >Мне - нет. Зачем надо облегчать индусам создание закрытых дров в которых к тому >же можно халтурить - не очент понятно. расскажу еще раз. Все что сейчас есть в Линухе под свободными лицензиями и будет продолжать использоваться. Те конторы, которые сейчас не спешат вкладывать деньги в надежную разработку под микроядро - и не поддерживают свои девайсы на Линухе. Т.е. под линухом щас много чего просто НЕКАК использовать. Если же этот некий закрытый драйвер будет жить в отдельном процессе - то его качество действительно может быть не таким высоким (при этом будет страдать _ТОЛЬКО_ сам же драйвер). А это меньше затрат на создание такого драйвера. Это понизит планку для контор, которые в принципе хотели бы поддерживать линух, но пока что дорого. Или ты не хочешь чтоб Линух стал еще популярнее за счет большего количества поддерживаемых  девайсов?? Напомню, что сейчас очень многим "принимающим решение" важна именно официальная поддержка какого-то нужного девайса ОСью. Нет официальной поддержки в Линухе - для них нет и Линуха... Жизнь несколько сложнее, как ты видишь... >Кернел девелоперам Linux и GPLнутому >коду я как-то сильно больше доверяю чем кривому индусскому закрытому драйверу >пусть и не в ядре. Ты не оригинален в этом %)) Только я не пойму: кто тебя заставит использовать гумно, если уже есть нормальные GPL дрова? И каким образом тебе помешают какие-то закрытые дрова под какие-то хитрые девайсы, (которых, может, у тебя никогда и не будет)? Или ты не хочешь, чтоб Линух становился распространеннее за счет тех, кому нужна официальная поддержка?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 24-Ноя-07, 13:38
	Еще добавить в плане скорости хотелось. Вот прямо сейчас на Линухе может крутиццо тысяча процессов без особых проблем (ну, нужно соотв. памяти...  все понятно). И переключение между ними происходят ОЧЕНЬ часто. И нечего. И все живут, рады и счастливы. Те несколько десятков процессов, которые драйвера в ядре, как либо радикально НЕ изменят картину с переключаениями контекстов. Больше проблем будет разве что с вводом/выводом у драйверов. Но это уже детали реализации. Так что, как видишь, вынос драйверов в отдельные процессы радикально не изменит картину с переключениями.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 22-Ноя-07, 23:26
	>... если в коде анализатора будет ошибка... Тут можно разбить на две подпроблемы: * Ошибка самого алгоритма. * Ошибка реализации алгоритма. Первое, решается (или нет), аналитическими методами, логикой. Второе, ну извините, прокладкой меж креслом и компьютером.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от s_dog (??) on 23-Ноя-07, 00:04
	Для локов кое-что уже есть, ещё не все потеряно ;) http://lwn.net/Articles/185666/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 00:22
	да уже неплохо ;) но этого недостаточно...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от oops on 23-Ноя-07, 06:47
	>[оверквотинг удален] >Я буквально месяц назад чуть ли не начал что-то подобное проектировать. >Потому как была проблема, которую я не мог поймать, но она все-же >происходила. > >Нужен некий анализатор кода, локов, мутексов..  не знаю чего еще. >Который мог бы просчитать все случаи race contitions и проанализировать >правильность расстановки локов в критических местах. > >В теории, подобная софтина могла бы прямо указывать на ошибки кода... >Но _что_ это будет - это уже флейм на пару лет... Попробую угадать.. dtrace?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 06:49
	>Попробую угадать.. dtrace? слив защитан Мы не юзер-левел дебагим, а ядро.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от penguin_killer on 23-Ноя-07, 10:03
	>слив защитан > >Мы не юзер-левел дебагим, а ядро. Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 10:32
	>Не "защитан". С помощью DTrace можно находить проблемы и в ядре тоже. ок, защитал по Dtrace слив себе. Но ниче подобного нам не поможет в проблема Линуха. Нужно нечто совершенно иное, работающее с исходниками...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от penguin_killer on 23-Ноя-07, 10:06
	>Попробую угадать.. dtrace? Может быть, что-то похожее на WITNESS во FreeBSD? :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 10:34
	>>Попробую угадать.. dtrace? > >Может быть, что-то похожее на WITNESS во FreeBSD? :-) неа. Такое уже есть, срежство слежения за локами, но это не то...  Совсем...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от klalafuda on 23-Ноя-07, 11:49
	> Нужен некий анализатор кода, локов, мутексов..  не знаю чего еще. > Который мог бы просчитать все случаи race contitions и проанализировать > правильность расстановки локов в критических местах. начать с coverity? http://www.coverity.com/ тем более, что AFAIK ядро под ней уже проверяли. // wbr
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 12:00
	>начать с coverity? http://www.coverity.com/ ...и закончить ее лицензией >тем более, что AFAIK ядро под ней уже проверяли. показуха...  а нам бы работу А вообще-то, это не того масштаба анализ. Там проверки буферов, возможных переполнений, какие-то прочие "мелочи"... Нам бы логику проверять...  причем, на уровне потоков, многозадачности... не знаю... мысль пока не устоялась по этому вопросу
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от madcore on 23-Ноя-07, 13:19
	>Нам бы логику проверять...  причем, на уровне потоков, многозадачности... А еще, чтобы программы сами писались.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Knuckles on 23-Ноя-07, 08:02
	Дело в том что если каждая ошибка сама по себе редко проявляется, например с вероятностью P (предположим у всех трех вероятность одинаковая), то 3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть МЕГАредко. А еще в теории вероятностей есть теорема о том, что очень редкие события никогда в реальности не происходят. Просто потому что время до их наступления так никто и не дожидается ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 08:55
	>Дело в том что если каждая ошибка сама по себе редко проявляется, >например с вероятностью P (предположим у всех трех вероятность одинаковая), то >3 мелких ошибки могут случиться одновременно с вероятностью P^3 то есть >МЕГАредко. А еще в теории вероятностей есть теорема о том, что >очень редкие события никогда в реальности не происходят. Просто потому что >время до их наступления так никто и не дожидается ;) эх.... именно поэтому "теория вероятности" и остаеццо _теорией_. Вреале такие ошибки весьма охотно происходят, не дожидаясь конца жизни админа :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от ДяДя on 23-Ноя-07, 14:10
	А ещё есть такая штука: если неприятность может произойти, то она обязательно произойдёт :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 14:29
	>А ещё есть такая штука: если неприятность может произойти, то она обязательно >произойдёт :-) ну это некритично  если кто маздай поставил случайно... снести то всегда можно :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 23-Ноя-07, 21:20
	тоже случайно, даже и подозревая того...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 23:02
	>даже и подозревая того... еще и как подозревая! это маздай люди ставят неосознанно, а Линух как правило - находясь весьма в трезвом уме :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от DeadMustdie (??) on 23-Ноя-07, 16:35
	>А еще в теории вероятностей есть теорема о том, что очень >редкие события никогда в реальности не происходят. Угу. И симметричная теорема о том, что при очень долгом ожидании либо очень частом повторении эксперимента (как раз компьютерный случай) с вероятностью почти 1 происходят почти невозможные события ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от Светочка on 22-Ноя-07, 23:22

Я предлагаю отделить разработку драйверов от разработки ядра.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 22-Ноя-07, 23:26
	>Я предлагаю отделить разработку драйверов от разработки ядра. если это лишь организационного плана предложение - то оно равно нулю. Девелоперы разных подсистем и так уже разделены дальше некуда :) А если по дереву разработки просто - тоже мало толку. Какая разница: лить отдельно ядро и другим файлом дрова - но оно все равно будет все жить в одном ядресном пространстве (монолит, как щас) - тоже толку ноль, тока гемор с архивами исходников. Если же про микроядро, чтоб дрова жили в своем адресном пространстве - это тема.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 22-Ноя-07, 23:28
	> ...ядресном пространстве... гы, ну и опечатка :) весьма точно и коротко описывает суть ;)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 22-Ноя-07, 23:29
	Хорошо, что не написал ПРОСРАНСТВЕ :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от opa__ on 23-Ноя-07, 18:45
	>Если же про микроядро, чтоб дрова жили в своем адресном пространстве - >это тема. да еще каждый в своем.... вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым переключением задач без потери кэшей, вот тогда можно будет со спокойной душой заводить микроядерность и прочую изоляцию
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 20:39
	>>Если же про микроядро, чтоб дрова жили в своем адресном пространстве - >>это тема. > >да еще каждый в своем.... и никак иначе. >вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений с быстрым >переключением задач без потери кэшей как это все сладко звучит.... %) >вот тогда можно будет со спокойной >душой заводить микроядерность и прочую изоляцию на самом деле чем раньше, тем лучше. Ну а прямо сейчас - сам Пенгуин велел. Процы бешенные, их по несколько штук... Думаю, кому нужна надежность со спокойной душей отдаст даже 10% производительности. (лично я верю - это это будет ~2-3%) Самое время...  ИМО Торвальдс тут несколько... кхм...  небыстр...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от penguin_killer on 23-Ноя-07, 22:47
	Про QNX и L4 когда-нибудь слышали? Почему-то у них сильных проблем с производительностью при переключении контекстов не возникает. Возможно, потому, что, в отличие от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без сложных проверок безопасности ( в смысле разграничения доступа ), и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания критических ветвей кода на ассемблере.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 23:51
	>Про QNX и L4 когда-нибудь слышали? >Почему-то у них сильных проблем с >производительностью при переключении контекстов не возникает. В Линуксе тоже с этим нет проблем :) 1:1 Просто товарисч решил, что еще есть время чего-то ждать, когда самое время начинать действовать. >Возможно, потому, что, в отличие >от Mach, там используется весьма облегченный вариант межпроцессных сообщений - без >сложных проверок безопасности ( в смысле разграничения доступа ), угу. Особенно в QNX, без особой проверки безопасности...  именно... %))) >и, насколько мне известно, пересылки сообщений оптимизируются вплоть до написания >критических ветвей кода на ассемблере ну, критическими по производительности секциями на асме хвастаться надо. Это обыденность. И Линух девелоперы тоже об этом знают ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от R007 on 24-Ноя-07, 03:45
	>вот придумает intel быстрый способ передачи межпроцессных и межпроцессорных сообщений Неплохой способ заранее приготовить качественный трындец вашей системе в виде мины замедленного действия.Более качественный саботаж придумать трудно.Что будет с такой системой когда данную модель процессоров снимут с производства?Правильно, ей настанет пиндык.Советую подумать о том что какой-нибудь микрософт может даже этому поспособствовать. Для тех кто в танке намекаю: на интеле и сраном х86 мир не заканчивается.Так, для сведений, Linux работает еще на PowerPC (32\64 и Cell), MIPS, ARM, SPARC, ...  - а вы портировать ваши чудеса на архитектуры отличные от х86 кадавра не заколебетесь?Или всякие там гаджеты, мобильные ниши, роутеры, сервера и прочее предлагается сдать без боя проприетарщиками и виндусю?Спасибо, но их и так слишком много.Так не пойдет.А сделав то что вы предлагаете - вы фрагментируете усилия по разработке системы, нельзя будет просто взять систему и поюзать в энном девайсе.Микрософт годами добивается того чтобы усилия по разработке фрагментировались.Вы предлагаете им помочь, притормозив развитие системы и фрагментировав усилия по разработке?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от R007 on 24-Ноя-07, 03:27
	>если это лишь организационного плана предложение - то оно равно нулю. А как же Dell с DKMS?Правда вы видимо не совсем то имели в виду. >Если же про микроядро, чтоб дрова жили в своем адресном пространстве - >это тема. А в чем тема?Значительно затормозить ядро ос?Вылезут MS и всякие там SUN и *BSD с бенчами где их системы делают это чуть ли не в разы.А индусы обнаглевшие от безнаказанности (ведь крах драйвера не выносит систему - баг более не критичный а ерундовый!) просто начнут клепать глючные и кривые дрова сами.Вместо того чтобы дать спеки вменяемым кернел-девелоперам.Майнтайнить эти дрова никто не будет - да нафиг оно кому?Получится что дрова как бы есть но закрытые и бажные.В силу закрытости фиг поправишь а баги индусы чинить не будут, раз система не грохается - дескать переживут. Есть такая поговорка, от добра добра не ищут.На данный момент линукс достаточно резвая и достаточно стабильная система, с минимум проприетарного кода (в идеале - без оного) способная работать месяцами или годами без крашей в ядре.Зачем чинить то что не сломано?Чтобы потом сказать "хотели как лучше а получилось как всегда"? Извините но я знаю линукс таким каким он есть.И мне он таким нравится.Если вы считаете что сможете лучше - сделайте лучше.Но называть это линуксом не надо.Я понимаю что всем нравятся buzzword-ы, но тормозная система с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у кого-то отождествляться с тем что сегодня называют словом Линукс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 24-Ноя-07, 13:31
	про весь бред о тормозах и глбкалове - я уже сказал выше. >Извините но я знаю линукс таким каким он есть.И мне он таким >нравится.Если вы считаете что сможете лучше - сделайте лучше. Я один - нет. Если бы мог - я бы именно ним щас и занималсо, не рассказывая тебе как это было бы хорошо. >Но называть это линуксом не надо. А вот тут, похоже, тебя никто спрашивать не будет. Равно как и меня, впрочем. Но если же Торвальдс решит (ну, например) 3-ю ветку делать микроядерной, то это будет Linux 3.nn.mm ядро и тебе придетсья с этим жить (даже если ты будешь до конца дней оставаться на монолите 2-ой ветки). Торвальдс владеет копирайтом на это название - ему и решать. >Я понимаю что всем нравятся buzzword-ы, но тормозная система >с микроядром и индусскими кривыми и закрытыми драйверами врядли будет у >кого-то отождествляться с тем что сегодня называют словом Линукс. тормозная и с индусскими закрытыми дровами - это название уже занято конторой негросовт ;) Ессьно, это не может ассоциироваться с Линуксом :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от exn (??) on 23-Ноя-07, 01:31

тыкс.. ксорг до 6.8 откатил, терь пора 23.8 на 19 сменить ^_^ фигли игры стали медленнее работать

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 03:44
	Тетрис тормозит?? %)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от exn (??) on 23-Ноя-07, 11:15
	> Тетрис тормозит?? %) чукча блин.    как мне оставаться папой в ut4 если у меня лага ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 11:18
	если лажа - то никак конечно
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от tux2002 on 23-Ноя-07, 07:47
	У меня 17.13 по некоторым причинам. То что Патрик предлагает в дистре. 23.1 мне не нужно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 07:59
	>У меня 17.13 по некоторым причинам. ухты. Ты представляешь собой ОЧЕНЬ интересный экспонат... А серьезно, че ты на древности живешь? Ну, елси не секрет. Мож че подсказать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от tux2002 on 23-Ноя-07, 08:49
	>>У меня 17.13 по некоторым причинам. > >ухты. >Ты представляешь собой ОЧЕНЬ интересный экспонат... > >А серьезно, че ты на древности живешь? Ну, елси не секрет. >Мож че подсказать? Да я писал здесь. Я привык к песочнице qemu. Она открывает tap интерфейсы. На одном и том же хосте в одной кофигурации на 17.13 от пользователя работает. Пробовал 19, 23 работает только от рута. Мне виртуалки от рута нафик не нужны. Разработчик tun модуля ответил что так теперь будет долго, видимо слишком много перестроили над модулем. Вот такая мелочь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 09:20
	>Да я писал здесь. Я привык к песочнице 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               (чтоб сам подымалсо) и будет тебе счастье :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от tux2002 on 23-Ноя-07, 09:40
	>Для этого поставь пакеты "openvpn" _или_ (по вкусу, вобщем) "usermode-utilities". > >И создавай интерфесы вот так: >   # openvpn --mktun --dev-type tap --dev tap500 >или >   # tunctl -u <your_username> -t tap500 Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo. Тока до 660 с нужной группой на tun я и сам могу додуматься без ядрёных параноиков :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 09:41
	>Спасибо, у меня slackware, можно загнать это в qemu-ifup через sudo. угу :) >Тока до 660 с нужной группой на tun я и сам могу >додуматься без ядрёных параноиков :) ну, видать кто-то че-то перекурил ;))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 23-Ноя-07, 21:25
	Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19, как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 23-Ноя-07, 23:09
	>Ну и чего.... Я на все серваки ставлю 2.6.16.57 (начинал с 2.6.16.19, >как раз поперли 2.6.17, ...18, ...19, ...20, ...21, ..22,....). не тот богат, у кого много денег, а тот - кому хватает ;) ну, а мне и .23-го уже мало ;))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от pavlinux (??) on 24-Ноя-07, 21:33
	Тебе одновременно нужно  CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Nick (??) on 25-Ноя-07, 00:06
	>Тебе одновременно нужно  CONFIG_VIRTUALIZATION и CONFIG_NOHZ, CONFIG_TICKNESS ? не мне нуна одновременно CONFIG_CGROUPS  ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "Опасения по поводу накопления ошибок в Linux ядре"

Сообщение от Kern El on 23-Ноя-07, 22:39

А по моему мнению (то биш ИМХО) этим разработчикам надо приостановить выпуск релизов хотябы на год, и конкретно сесть за исправление ошибок, а то вперед ног бегут :), того и гляди ##нутся, и ядро точго в кашей станет  из ошибок и ошибок :( P.S. А когда все видымые ошибки будут выловлены необходимо создать фонд платы за найденные баги, и подождать еще пол года а уж затем цикл ражработки как у FreeBSD , выпускать когда ядро действительно готово а не когда появятся новые строки кода. Согласитесь, ядро уже созрело, теперь его осталось "вылизать" и по мере необходимости улучшать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от R007 on 24-Ноя-07, 03:33
	>релизов хотябы на год, На сто лет, фигли.Чтобы всякие саны, бсд и микрософт могли уж наверняка на хвост сесть. >то вперед ног бегут :), того и гляди ##нутся, и ядро >точго в кашей станет  из ошибок и ошибок :( Такое ощущение что вас с ножом к горлу заставляют юзать самое-самое ядро да еще и не релизное.А по мне так как не глянешь на список изменений - душа радуется.Система становится реально лучше. >цикл ражработки как у FreeBSD Да, пример для подражания конечно сильный.Это чтобы линукс тоже прозябал на задворках цивилизации пока рулит микрософт и может быть, SUN и Apple?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Опасения по поводу накопления ошибок в Linux ядре"
	Сообщение от Av (??) on 24-Ноя-07, 19:32
	У тебя пена щас пойдет изо рта, орнитолог.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]