Как стать автором
Обновить

Комментарии 10

Важно понимать, что роялит не сам аспект открытости софта напрямую, а количество и качество программистов, привлечённых к его развитию (и количество критичных пользователей). Открытие исходников - лишь один из путей достижения этих очевидных целей (и даже лишь первый шаг на этом пути) :). Удивительно, но качество софта возрастает и с наращиванием количества тестировщиков :).

Скорее больше ищут там, кто больше платит. Поэтому и больше находят.

Пропиетарные приложения часто используют библиотеки с открытым кодом. Вполне вероятно, что часть уязвимостей может быть из-за них. Какая доля фиксов отдается потом сообществу, а какая остаётся внутри компаний, скажем для сохранения конкурентных преимуществ, или просто экономии ресурсов - хороший вопрос.

Я вообще не понял как сделан вывод, вынесенный в заголовок. Это кликбейт просто? В таблице есть единственный опенсорсный продукт - Linux. Ядро? При этом он конкурирует с компаниями. Я не понимаю как. У Гугла есть куча свободого софта, и у Майкрософта. И эти компании вносят существенный вклад в ядро Линукса.

Числа в целом настолько невелики, что искать там статистическую значимость трудно.

Если абсолютно, то у Самсунга меньше багов и все закрыты в срок. Так может у Самсунга меньше уязвимостей и это надо вынести в заголовок?

В последние годы произошло несколько неприятных историй, которые больно ударили по всем.

Странная статья и странные выводы!

Один из важнейших факторов опенсорса - что можно свободно исследовать исходники. А в этом случае искать баги гораздо проще.

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

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

В Linux из-за PID reuse (PID wraparound) можно дел наворосить.

Linux это крайне ненадёжная система. В суперкомпьютерах она относительно успешно используется только из-за физического ограничения кластеров от всего остального.

Особенно PID reuse (PID wraparound) касается любителей клепать всё через короткоживущие процессы и UNIX shell.

Замечу, что в современном Linux PID использует 64 бита. 2^64 наносекунд это 584 года, причём создание процесса — относительно дорогая операция.

А как же pid_max? Документнация по pid_max.

cat /proc/sys/kernel/pid_max
32768
uname --kernel-release
5.4.0-100-generic

PID_MAX_DEFAULT на GitHub

/* * A maximum of 4 million PIDs should be enough for a while. * [NOTE: PID/TIDs are limited to 2^30 ~= 1 billion, see FUTEX_TID_MASK.] */

Зарегистрируйтесь на Хабре, чтобы оставить комментарий