Тут наблюдаются какие-то разорванные цепочки рассуждений: «выше среднего» -> "'эксперт" -> «знает все в своей проблемной области». На самом деле из одного совершенно не следует другого:
— Программист выше среднего может не является экспертом в той или иной области. Он, например, может просто очень хорошо уметь находить решение, а не сразу знать его. Когда я провожу интервью, я никогда не запрещаю пользоваться какими-то справочными материалами, т.к. ставлю задачи не на знание, а на умение искать и умение решать проблемы.
— В принципе это касается и эксперта в какой-то области. Области (по-крайней мере, в IT) постоянно расширяются, появляются новые знания и методики, и эксперт должен следить за ним. Описанный автором сферический эксперт в вакууме не является таковым на самом деле.
— Ну и знать всего невозможно. Любой адекватный человек это знает. Если он этого не знает, то назвать его экспертом или профессионалом выше среднего вряд ли можно.
P.S. Еще хотел бы заметить, что возможно опрос показал и правильные результаты. Если опрос проводили на профильном сайте, на котором тусуются только профессионалы, то вполне могут получиться и приведенные результаты. Это также как и опрос в Интернете, сколько людей пользуются Интернетом, покажет 100-процентный результат «пользуются все». Я уже не говорю, что средний уровень у программистов очень быстро снижается в последнее время, и уже не проблема увидеть такой код у «средних» программистов.
Вот как раз вы и разводите бюрократию. Кто сказал, что __main__ — это клиентский код? Может в виртуальном мире сферических программистов в вакууме весь __main__-код и является клиентским (т.е. отвечает за взаимодействие с пользователем, как я понимаю), но в реальном мире скрипт может быть вызван через exec, и иметь всю логику именно в __main__.
Приемочные и функциональные тесты — это тоже из области бюрократии. Разве не может быть функциональный тест оформлен в виде модульного теста? Для меня главное — обеспечить качество продукта. Если для вас главное — следовать слово-в-слово апологетам TDD, то нам разговаривать не о чем, я практик, а не теоретик, и мне нужно сдавать проекты в срок с надлежащим качеством и с минимальными расходами ресурсов.
100% лучше 83%, потому что как минимум я буду уверен, что при прохождении тестов на данной конфигурации большая часть кода будет работать. А иметь 17% кода, который неизвестно когда будет вызван, и когда сломается, мне совершенно не хочется, особенно когда код уже внедряется в production.
В данном случае используется метрика от coverage-модуля. Он вычисляет покрытие из расчета строчек кода — если строка кода не была вызвана в тестах, значит она не покрыта. 100% показывает, что каждая строка была вызвана в тестах хотя бы один раз.
«Вызов тестируемого кода» (как я понял, вы имеете в виду код, исполняемый для __main__) тоже должен тестироваться — некоторые скрипты вообще могут быть написаны без объявления функций и классов, и тем не менее содержать сложную логику, которую нужно протестировать. То, что это архитектурно неправильно, другой вопрос — есть legacy-код, который перед рефакторингом нужно покрыть тестами, иначе можно внести ошибку. А этот legacy-код может быть написан как угодно, и без декомпозиции на функции классы.
Среди целочисленных типов в Python 2.6 еще есть тип long. Но на самом деле, дополнительные проверки не нужны — Python сам выдаст TypeError при работе с объектами. Я выделил отдельный случай для float и complex, т.к. для них есть метод вычисления, но он просто не реализован в данной функции.
Насчет дополнительных тестов — они не изменили бы покрытие, оно и так полное. Но даже то, что оно полное, не предотвращает ошибок, и вы правильно указали, какие тесты еще можно было написать.
Упс, я даже не знал, для чего собственно эта программа. Просто я специально купил себе такой ноут, чтобы не пришлось возиться с проприетарными драйверами.
Ну а так — если будут какие-то проблемы, обращайтесь, поможем чем сможем :) Сейчас уже не так много проблем, как было скажем, лет 5-10 назад. Косяки бывают, поэтому мой совет про то, что не надо сразу быстро обновляться, остается в силе. Я обычно жду где-то недели две-три.
А в чем проблема? Сорри, я лично даже не знаю, как его ставить не из консоли. Текстовой редактор есть, apt-get есть, wget есть, даже консольный браузер, если уж вообще приспичит, есть. Обычно все руководства в инете рассчитаны именно на работу с консолью.
А как вы проприетарные драйвере ставите, не используя консоль?
Если вы боитесь, что будут какие-то проблемы, то советую просто подождать с обновлением. Обычно в первые дни всегда находятся какие-то косяки, но и правят их быстро. А ставить с нуля лично для меня не резон — это не по-джедайски. Линукс — это не такая система, которую надо при каждом чихе ставить с нуля, обычно все проблемы можно решить.
А насчет видеодрайвера — всегда есть Ctrl-Alt-F1, в консоли конфигурируйте драйвер как вам надо (обновить или поставить другой). Возврат обратно в графический режим — Alt-F7.
На свой ноут как поставил в свое время 9.04 x64, так с тех пор и работаю, все нормально. Без проблем прошло обновление на 9.10. Были некоторые заморочки с флешем, и то они были вызваны собственно Adobe, а не Canonical. Сейчас никаких неудобств не испытываю — все железо определяется, используются корректные драйвера, ждущие и спящие режимы работают.
Тема действительно весьма обширная, но в данном контексте делать отдельные статьи для новичков и профи не считаю разумным — механизмы одинаковые, отличаются лишь способы использования. А вот описывать как использовать то или иное средство — это тема для отдельной книги, а не статьи.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Про getfacl/setfacl упомянул. Описание chroot тоже поменял, хотя оно и стало немного громоздким.
Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Я не спорю, но признаюсь честно, я не знаю централизованных VCS (и которые при том еще используются), которые не пихают свои внутренние каталоги по всему проекту. Удовлетворите любопытство, если не сложно. Системы, которые работают только под Windows, можно не упоминать.
Спасибо, добавил. В принципе, я на это не хотел особо концентрировать внимание, т.к. думаю, что все знают как работать с ACL. Но для новичков пригодится.
В комментариях были даны толковые ответы, но я бы хотел от себя добавить одно замечание. Наиболее лучшим и безопасным решением будет использовать сервер контроля версий, причем лучше DVCS, а не svn или cvs (думаю все помнят, как смогли поломать кучу серверов прочитав системные директории .svn). Т.е. вы работаете на своей рабочей станции, заливаете код в git/hg/bzr, а на стороне сервере делаете update под нужным пользователем (www или www-data, зависит от настроек). Помимо того, что будет хорошая безопасность, вы сможете более тщательно контролировать ревизии, откатиться при каких-то проблемах и т.п.
Многие разработчики знают filemon, но не знают strace и другие утилиты. Достаточно посмотреть в гугле количество запросов «filemon linux». И везде одни и те же советы — используйте strace, lsof, inotify etc.
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
«Серверный» в данном контексте означает, что система работает без взаимодействия с пользователем. И SELinux и AppArmor работают в ядре, и напрямую не могут ничего запрашивать у пользователя. Максимум «интерактивности», которую добавили разработчики — это уведомление пользователей об ошибках доступа (apparmor-notify, setroubleshoot).
Ну тогда в рамках существующих технологий статические права разруливаются профилями AppArmor, а динамические права потенциально могут разруливаться PolicyKit. Потенциально — потому что PolicyKit сейчас в основном используется системными сервисами (тем же HAL), а менеджеры файловых системы его используют редко.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
Сделано, спасибо за напоминание. Если вы знаете какие-то другие инструменты, дайте знать, если не трудно. Кстати, filemon был когда-то и под Линукс, но потом из-за модификаций ядра он перестал работать.
— Программист выше среднего может не является экспертом в той или иной области. Он, например, может просто очень хорошо уметь находить решение, а не сразу знать его. Когда я провожу интервью, я никогда не запрещаю пользоваться какими-то справочными материалами, т.к. ставлю задачи не на знание, а на умение искать и умение решать проблемы.
— В принципе это касается и эксперта в какой-то области. Области (по-крайней мере, в IT) постоянно расширяются, появляются новые знания и методики, и эксперт должен следить за ним. Описанный автором сферический эксперт в вакууме не является таковым на самом деле.
— Ну и знать всего невозможно. Любой адекватный человек это знает. Если он этого не знает, то назвать его экспертом или профессионалом выше среднего вряд ли можно.
P.S. Еще хотел бы заметить, что возможно опрос показал и правильные результаты. Если опрос проводили на профильном сайте, на котором тусуются только профессионалы, то вполне могут получиться и приведенные результаты. Это также как и опрос в Интернете, сколько людей пользуются Интернетом, покажет 100-процентный результат «пользуются все». Я уже не говорю, что средний уровень у программистов очень быстро снижается в последнее время, и уже не проблема увидеть такой код у «средних» программистов.
Приемочные и функциональные тесты — это тоже из области бюрократии. Разве не может быть функциональный тест оформлен в виде модульного теста? Для меня главное — обеспечить качество продукта. Если для вас главное — следовать слово-в-слово апологетам TDD, то нам разговаривать не о чем, я практик, а не теоретик, и мне нужно сдавать проекты в срок с надлежащим качеством и с минимальными расходами ресурсов.
100% лучше 83%, потому что как минимум я буду уверен, что при прохождении тестов на данной конфигурации большая часть кода будет работать. А иметь 17% кода, который неизвестно когда будет вызван, и когда сломается, мне совершенно не хочется, особенно когда код уже внедряется в production.
«Вызов тестируемого кода» (как я понял, вы имеете в виду код, исполняемый для __main__) тоже должен тестироваться — некоторые скрипты вообще могут быть написаны без объявления функций и классов, и тем не менее содержать сложную логику, которую нужно протестировать. То, что это архитектурно неправильно, другой вопрос — есть legacy-код, который перед рефакторингом нужно покрыть тестами, иначе можно внести ошибку. А этот legacy-код может быть написан как угодно, и без декомпозиции на функции классы.
Насчет дополнительных тестов — они не изменили бы покрытие, оно и так полное. Но даже то, что оно полное, не предотвращает ошибок, и вы правильно указали, какие тесты еще можно было написать.
Ну а так — если будут какие-то проблемы, обращайтесь, поможем чем сможем :) Сейчас уже не так много проблем, как было скажем, лет 5-10 назад. Косяки бывают, поэтому мой совет про то, что не надо сразу быстро обновляться, остается в силе. Я обычно жду где-то недели две-три.
А как вы проприетарные драйвере ставите, не используя консоль?
А насчет видеодрайвера — всегда есть Ctrl-Alt-F1, в консоли конфигурируйте драйвер как вам надо (обновить или поставить другой). Возврат обратно в графический режим — Alt-F7.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Не понял, в чем подвох? PAM используется в основном для аутентификации, причем тут авторизация?
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.