Марк Шаттлворт представил (http://www.markshuttleworth.com/archives/786) новый состав управляющего технического совета Ubuntu, избранного путем голосования среди активных разработчиков проекта. Следующие выборы управляющего совета состоятся осенью 2013 года. Всего в совет избрано 6 разработчиков, из которых только три работают в компании Canonical. Число представителей Canonical в совете не закреплено - все решают результаты выборов. По мнению Марка, равное число представителей сообщества и работников Canonical в совете является поводом торжества на обоих фронтах и подчеркивает характер сообщества, ценящего персональные качества и не акцентирующего внимание на различия между добровольцами и работниками Canonical.В совет вошли:
- Stéphane Graber
- Kees Cook
- Martin Pitt
- Matt Zimmerman
- Colin Watson
- Soren HansenURL: http://www.markshuttleworth.com/archives/786
Новость: https://www.opennet.ru/opennews/art.shtml?num=31957
Достойно уважения.
Меритократия, однако. Что есть гут.
> главный сисадмин kernel.org и лидер Ubuntu Security Team... нууже щас kernel.org заработал, ладно. :)
>... нууже щас kernel.org заработал, ладно. :)Ссылки на архивы с главной не работают до сих пор. Чувствуется высокий профессионализм разработчиков Убунту.
>главный сисадмин kernel.org и лидер Ubuntu Security TeamНа мой взгляд, это самая жестокая антиреклама безопасности убунту, которую только можно было придумать. И в плане надежности защиты, и в плане быстроты реакции.
Про Kees'а - в тексте новости ошибки. Да, он один из сисадминов kernel.org (не "главный" и на время недавних событий не активный, так что претензии по времени восстановления - не к нему), и, да, он был в Ubuntu Security Team - и много там сделал позитивного, далеко не только для Ubuntu, но и для upstream-проектов, в том числе ядра Linux. Будь его воля, в upstream-ядрах hardening-изменений уже было бы больше. Недавно он формально перешел в Google для работы над безопасностью ChromeOS, сократив свое участие в Ubuntu Security Team до неформального (к сожалению для Ubuntu).По-моему, новость о том что Kees продолжит принимать участие в жизни Ubuntu - позитивная.
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening
https://wiki.ubuntu.com/Security/Features/Historicalhttp://www.outflux.net/blog/archives/2011/09/12/5-years-with.../
http://www.openwall.com/lists/oss-security/2011/09/16/3http://www.outflux.net/blog/archives/2010/09/14/my-part-in-t.../
http://kerneltrap.org/node/5070 - "The Linux Kernel Archives Mirror System is managed by Kees Cook." - только "mirror system"
Да, в ядре Ubuntu много сомнительных hardening-патчей. Возможно, львиная доля проблем со стабильностью объясняется именно этим.
Вероятно, это был сарказм, но отвечу серьезно:Можно привести пример "сомнительного" hardening-патча в ядре Ubuntu, обосновать его хотя бы сомнительность (а лучше - что именно с ним "не так" - а то сомневаться можно и просто по незнанию или от неуверенности), и объяснить как он приводит к проблемам со стабильностью? Такая информация потенциально будет полезной. Иначе же это FUD.
Вот уж не думал, что буду "защищать Ubuntu" (на моем компьютере - не она), но с работой Kees'а я знаком и оцениваю её позитивно.
>Можно привести пример "сомнительного" hardening-патча в ядре Ubuntu, обосновать его хотя бы сомнительность (а лучше - что именно с ним "не так" - а то сомневаться можно и просто по незнанию или от неуверенности), и объяснить как он приводит к проблемам со стабильностью?А вы почитайте рассылку разработчиков ядра. Там все это давно и подробно разжевано.
Если патч не принят в mainline - значит, тому есть причины.
> Если патч не принят в mainline - значит, тому есть причины.Конечно, но эти причины не всегда связаны с качеством самого патча и его влиянием на стабильность системы. В других дистрибутивах тоже практически в каждом пакете, включая ядро, есть патчи, не принятые upstream - но это не означает, что разработчики этих дистрибутивов делают что-то не так.
Также, иной раз для принятия аналогичных изменений в mainline просто требуется время - не столько технически, сколько чтобы ответственные maintainer'ы приняли другую точку зрения. Это могут быть годы. Так бывало, в том числе в отношении целых подходов, а не только отдельных патчей. Например, для ASLR этап возражений был пройден многими OS, включая Linux. "First they ignore you, then they laugh at you, then they fight you, then you win" - не всегда именно так, но похоже.
Недавний пример - permissions на /proc/slabinfo - сначала были возражения (мол, мешает отладке, а сделать chmod вручную лень), но это изменение всё равно было внесено в Ubuntu (кажется, не патчем, а командой chmod при загрузке системы, но это деталь), а теперь на аналогичный патч в ядро тот же человек дает Reviewed-by:
http://lists.openwall.net/linux-kernel/2011/03/03/442 - "Please don't."
http://lists.openwall.net/linux-kernel/2011/09/14/185 - "I dunno."
http://lists.openwall.net/linux-kernel/2011/09/14/241 - "I'd be happy to ack your patch."
http://lists.openwall.net/linux-kernel/2011/09/14/250 - "Reviewed-by"В данном случае, потребовалось всего полгода. Кстати, по-моему это отлично, что разработчик готов изменить свое мнение (выслушав аргументы или просто со временем). Так бывает.
Другой пример, не связанный с Ubuntu столь непосредственно - перенос реакции на превышение RLIMIT_NPROC из setuid(2) (вернее, из set_user(), который используется несколькими вызовами) в execve(2). В -ow патчах я реализовал такую проверку в execve(2) еще в конце 1990-х (исходно для 2.0.x). В 2.6.x в 2003-м году вместо нее вошла проверка в set_user(), что позволило успешно использовать уязвимости в userspace программах, не проверяющих return value из setuid(2) (баг, конечно, но распространенный). Как минимум в 2006-м этот вопрос поднимался в LKML, но к изменениям в ядре не привел. Лишь в этом году реакцию на превышение лимита перенесли в execve(2), для Linux 3.1. Итого, восемь лет mainline ядра неоправданно делали userspace-программы (да, содержащие баг) более уязвимыми (есть масса известных уязвимостей такого рода с присвоенными CVE-номерами - что было использовано в качестве аргумента для внесения изменения в ядро).
После того, что 11,04 нормально не ставился без дополнительных опций загрузк на каждом первом ноуте (кривые руки или не везло с ноутами?), предпоследнего нужно анально покарать, а не выбирать в руководители. А еще вчера поставил на ноут, так там подсветка экрана не работает. Хорошо хоть заметил, что таки видна картинка рабочего стола. Обновил, - думал пофиксили. Хрен там. Пришлось с настольной лампой в одной руке другой править конфиг груба (или граба?). И теперь при загрузке включается с потухшим экраном, - нужно каждый раз яркости добавлять (делал по нагугленному совету). Ну куда это годиться? Нахрена делать блондинистый интерфейс, который блондинка настроить не сможет в девяти из десяти случаев, а прошаренные товарищи будут плеваться?
Это Вам так повезло, у меня статистика в корне другая. Да, встречались ноуты, у которых под 11.04 что-то было не так, но таковых 1 к 10.
А в линуксе работал? Может это и не убунты проблема.
За последний месяц поставил людям на старенький десктоп, два нетбука и один ноут.
На десктопе не пошла Юнити. Остальное без плясок с бубном.
поставил Убунту 11.04
Мне одному кажется, что все эти люди имели, имеют, а теперь ещё и будут иметь отношение к Canonical и Ubuntu? Какая тут "меритократия" и "сообщество"?
P.S. Продолжаю держаться на Ubuntu 10.04.3 LTS, останусь на 10.04.4 LTS после выхода релиза в январе 2012 года. На 12.04 LTS перейду не ранее 12.04.2 только на новых платформах.
молодец какой!
Дебиан не пробовали использовать?
Стебанул, да:)))
Использовал, но в процессе пятилетнего ожидания обновлений 3.0 - 3.1 - 4.0 и проблем, связанных с ними, решил отказаться в пользу десктопного Ubuntu. На серверах - Gentoo, FreeBSD, на шлюзах - OpenBSD.