>Ядро Linux-2.6 (1061)

FreeBSD - 635. Кто бы сомневался.

В чем победили то? "Defects / KLOC" столбец что значит мысль не пробегала? ;) Естевственно что на большее количество кода ошибок будет больше, но плотность их умеренная. Жить будем =)

>Стенфордский университет провел автоматизированную проверку исходного кода 31 программого продукта. С большим отрывом победили: Ядро Linux-2.6 (1061) Графическая подсистема X (1681) =)

Провокация флейма! :)

По количеству ошибок на строку кода у FreeBSD 0.4, а у Linux 0.3!

>Atlant (*) (06.03.2006 11:23:52)

По коэффициенту Linux показывает лучшие результаты нежели бздя

так у них и строк кода больше.. смотреть надо не по количеству дефектов, а по 4-колонке.. там у линкукса результаты лучше среднего - 0.333

Sun-ch я конечно понимаю что ты фанатаишь от bsd, но там есть еще один не маловажный параметр Lines of Code и Defects / KLOC у фряхи это 0.401, а линукса 0.333, так что у линукса код качественей

Defect per KLOC (Kilo-Line of Code): Linux (0.333) vs FreeBSD (0.401). Действительно, кто бы сомневался.

всё равно много как-то. кто там зарегился, напишите, что за ошибки то они нашли?

Все дело в волшебых пузырьках! Но твоя попытка неправильно интерпретировать факты провалилась.

XMMS 6 116,864 0.051

=))) самый безглючный плейр

> По количеству ошибок на строку кода у FreeBSD 0.4, а у Linux 0.3!

Совершенно необязательно делать в программе несколько ошибок. Достаточно вынести код ошибки в функцию и вызывать ошибку из разных мест программы по мере необходимости :)

XMMS )))))))) Хотя вина во всех глюках в ALSA, arts и тому подобным

Ага, коэффициент - это средняя температура по больнице, у одного +40 а другой уже остыл до температуры окружающей среды. Это большая заслуга фри, что у них кода в 3 раза меньше, при том же функционале. Вы, блин еще с виндой сравните, там ~30 млн. строк - она точно на первом месте будет.

Насчет функционала не надо. Возьмем те же дрова или поддержку оборудования в десктопных условиях.

Санча уже сложно воспринимать серьезно :)

>> По количеству ошибок на строку кода у FreeBSD 0.4, а у Linux 0.3!

>Совершенно необязательно делать в программе несколько ошибок. Достаточно вынести код ошибки в функцию и вызывать ошибку из разных мест программы по мере необходимости :)

Ага, а Coverity в Стэнфорде идиоты писали?

Ну, я так не играю. Почему OpenBSD вниманием обделили? Было бы интересно посмотреть, сколько у них дефектов на KLOC приходится... По сравнению с тем же Linux'ом :-)

А судьи кто?

Что это за маразм прогонять коды через автоматические проверялки? Linux и BSD дураки что ли делали? Они не могли через подобную "проверялку" код прогнать и ошибки исправить? Мне кажется эти "ошибки" очень слабо коррелируют с реальными багами.

А примеры типичных найденных "defects" где-нибудь можно подсмотреть?

Угу, а винда еще куда больше оборудования поддерживает.
Проведем нехитрые мат. вычисления. Допустим в винде 10е6 ошибок. Считаем пресловутый коэффициент k = 10e6/30e6 = 0.333333.... ну прям как в линаксе. Из чего делаем вывод, что винда и линакс одинаково надежны.

>при том же функционале

долго смеялсо. ссаныч кончай п%:?ть как второкласник. измеритель ф-ционала на глаз буга-га-га :))

зы. ты хоть не в литрах то измерял? :)))

Мне кажется, это тест "на стиль". Язык-то Си. Кто-то приводит поинтеры к нужным типам, кто-то нет. Кто-то использует автоматические деструкторы, кто-то рефкаунтинг и т.п. В зависимости от стиля при статическом анализе и получится результат. Ценность таких исследований маловата.

> FreeBSD - 635. Кто бы сомневался.

Угу, вот и я про то, у freebsd ошибок значительно больше, на тысячу строк кода.

> Это большая заслуга фри, что у них кода в 3 раза меньше

LOL бугага. Тогда УжOS самая безопасная OS, и заслуга УЖOS в том, что там всего пара десятков строк кода :) Зассаныч, ну ты клоун :)

Ну просто интересно, какой там может быть мегафункционал, при тройном объеме кода? Разве что numa? Да и то, я не уверен, что это влючено в ванилу.

>FreeBSD - 635. Кто бы сомневался.

Мёртвые не ошибаются.

> XMMS 6 116,864 0.051 > =))) самый безглючный плейр

но падает постоянно!

А я всегда думал, что вероятность наступить на грабли, пропорциональна абсолютному числу ошибок, коих в линаксе больше на целую тыщу.

> А я всегда думал, что вероятность наступить на грабли, пропорциональна

> абсолютному числу ошибок, коих в линаксе больше на целую тыщу.

Индюк тоже думал что купается, пока вода не закипела. Выключи свой сервер, и тогда у тебя будет на 635 шансов меньше наступить на грабли, чем на работающей бздне.

Да и ethereal, в котором уже столько дыр нашли, имеет D/K=0.123

Сомнения вызвает данная проверка...

+1. При оценке надежности системы важно именно абсолютное число ошибок (приблизительная оценка абсолюного количества ошибок), а не соотношение количество ошибок/строчек кода. Соотношение - это оправдание для разработчика

> Индюк тоже думал что купается, пока вода не закипела. Выключи свой сервер, и тогда у тебя будет на 635 шансов меньше наступить на грабли, чем на работающей бздне.

Нихрена не так. Шансы здесь подсчитать невозможно. Какой-то код чаще выполняется, какой-то - реже. Чем меньше ошибок, тем лучше

Только надо ещё учитывать, что во всех подобных автоматических проверках очень большой процент (до 80-90%) ложных срабатываний, даже в самых лучших и навороченных системах. Просто в силу особенностей языка Си - он допускает такие хаки, которые по всем признакам будут похожи на ошибку, но при этом всё равно будут стабильно работать. Семантика машины состояний, в которую преобразуется сишный код + "реальное" железо слишком сложна для полноценной верификации, и, соответственно, проверяется всегда упрощённая модель.

Считать количество "ошибок" на тысячу операторов - еще понятно

Но считать на строки кода - маразм полнейший!!! Стили форматирования исходников разные. Считались ли при этом за строки - пустые, кометарии, содержащие только операторную скобкe etc

к томуже еще вопрос что считать ошибкой. использование sprintf, strcpy, strcat? - скорее всего потенциальная ошибка, но если сначала идет контроль размеров - то какбы уже и нет ошибки, а калькулятор ее будет считать

такчто результат - чисто познавательный с точки зрения возможности автоматической дефектации кода

У виндовых драйверов - 0.01 бага на KLOC. Инсайдерская инфа. По результатам аналогичной проверки.

Правда, многие из этих багов такие, что сотни линуксовых стоят. :)

> я всегда думал, что вероятность наступить на грабли, пропорциональна абсолютному числу ошибок

Как выясняется, ты даже думать не умеешь. Даже если в коде поддержки Sparc64 будет десять тысяч ошибок, вероятность наступить на них у большинства пользователей равна нулю.

Сам ты маразм. Откуда разработчики линуха возьмут эти автоматические проверялки? Они пока что все закрытые, кроме разве что CCured, но он несколько из другой песни.

Typically, Coverity delivers four real bugs to one false positive.

Что уже не плохо. Даже если процент ложных срабатываний больше, то это повлияет на абсолютные цифры, а не на относительные.

Ты ничего не знаешь про автоматическую верификацию. Зря.

Посмотри на why и krokatoa.

А я всегда думал, что вероятность наступить на грабли, пропорциональна абсолютному числу ошибок, коих в линаксе больше на целую тыщу. Sun-ch

а я вот думаю. есть две площади. одна - 1 квадратный метр, другая - квадратный километр. на первой лежат одни грабли, на другой - 10. где больше шансов наступить на грабли?

А если так, то он просто довольно малую часть потенциальных ошибок обнаруживает. Например, в случае с Си далеко не все утечки можно отловить, region analisys для него работает очень туго (и стоит недеццки по ресурсам).

На грабли на 1 кв. м быстро наступили и исправили, другое дело трудновоспроизводиме грабли типа неожиданной потери данных в xfs.

Есть предложение считать этот параметр оценкой расп..ва авторов кода.

>А я всегда думал, что вероятность наступить на грабли, пропорциональна абсолютному числу ошибок, коих в линаксе больше на целую тыщу.

А Hello World с одной ошибкой лучше чем Linux.

Если большинство грабель лежит в темном чулане?

>А я всегда думал, что вероятность наступить на грабли, пропорциональна абсолютному числу ошибок, коих в линаксе больше на целую тыщу

Ну ты даешь. Дороги то на которых грабли лежат разные. Возьмем две дороги к светлому будущему: BSD и Linux. Обе усеяны граблями разной критичности. Дорога BSD прямее и поэтому короче. Однако плотность граблей согласно результатам выше чем у извилистого пути под названием Линукс. Где вероятность больше оцени сам пройдя оба пути с завязанными глазами(не прикладывая патчей)

>Угу, а винда еще куда больше оборудования поддерживает. Проведем нехитрые мат. вычисления. Допустим в винде 10е6 ошибок. Считаем пресловутый коэффициент k = 10e6/30e6 = 0.333333.... ну прям как в линаксе. Из чего делаем вывод, что винда и линакс одинаково надежны.

гы... ты забыл на 1000 домножить :)))

По закону Мерфи, именно тебе срочно прийдется зайти в этот чулан в полночь и в полной темноте.

gcc порадовала

так же интересно сравнить PHP & Perl при равном количестве кода, но далеко не равном кол-ве находимых багов

> С большим отрывом победили: ...

а я увидел AMANDA